Catching Data Perimeter Drift Before It Reaches Production

A development-time validation pattern to catch data perimeter setup issues and preserve the historical context of a data perimeter project.

Suresh Gururajan

May. 26, 26 · Analysis

Likes (0)

Comment

Save

219 Views

Cloud providers provide tools for customers to prevent data exfiltration attempts by creating a data perimeter — a set of permission guardrails that ensure that only trusted identities from expected networks can access trusted resources [1]. For example, a company can set up controls so that users within its organization can access only their company-specific S3 buckets from their corporate networks. Any other access patterns will be denied. These are important for organizations that are generally sensitive to data exfiltration, such as finance, healthcare, and government.

Setting up a data perimeter in AWS involves creating an organization-wide policy and network policy. Service control policies (SCP) [10] and resource control policies (RCP) [11] define the maximum allowable permissions for a given identity or a resource, while VPC endpoint policies [12] define the maximum allowable permissions for a given service through a private network. Together, these controls establish a boundary around the organization’s network and resources to enforce a data perimeter.

In this article, we focus on establishing and maintaining data perimeter controls for a specific access pattern: users managing their resources through the AWS Management console — a web interface for resource management. This is a unique scenario involving complex setup steps, multiple service dependencies, and a high probability of data perimeter drifting over time. Then, we introduce a development-time validation pattern, demonstrated using Kiro's Powers feature as one implementation. We explain how to encode a team's knowledge into the development process and how to catch possible data perimeter drift during development.

This article does not intend to replace critical controls such as infrastructure monitoring, integration tests, and notification systems. Rather, it aims to work in tandem with them to help prevent teams from accidentally breaking their data perimeter setups by catching these issues early on, during development. This way, teams do not wait until code is deployed to a non-production environment to catch data perimeter breaches. This is useful because some organizations have separate testing and CloudOps/DevOps teams that take a long time to deploy and iterate, wasting days of time just to detect and fix data perimeter setup issues.

The focus is to ensure that breaking changes are caught before a pull request is made, and encoding historical context into code. The same pattern can be replicated in any IDE via a simple team-built IDE extension or a managed service.

Background: AWS Management Console Private Access

AWS Management Console (console) provides network perimeter controls via VPC endpoints. This feature works in tandem with AWS Sign-In to prevent unauthorized access to the AWS Management Console. With this feature, customers can “limit access to the AWS Management Console only to a specified set of known AWS accounts when the traffic originates from within their network. Console Private Access is also useful when customers want to ensure that all calls from the AWS Management Console to AWS services originate from within their network and from allowed accounts.” [2].

Setting up AWS Management console private access is unique in that it makes API requests to AWS service endpoints. If we load the S3 console web page, the console makes API requests to the S3 endpoint to load the list of buckets. This means that if a company wants a truly isolated network, it must set up not just a console VPC endpoint but also that of S3.

Additionally, static assets must be routed through the public internet because assets and console-supporting API calls do not have a VPC endpoint.

Problems

DNS Setup

Setting up console private access requires creating two VPC endpoints: console and signin [3]. Typically, AWS services’ VPC endpoints come together with private DNS support, providing the ability for requests to resolve DNS from within a private subnet. For example, enabling private DNS at the S3 endpoint helps resolve S3 requests within the VPC. However, console and endpoints do not provide private DNS names.

Instead, customers are asked to set up Route53 private hosted zones for the console and signin domains and attach them to their VPCs to resolve console endpoints correctly [4]. This setup adds friction to an otherwise standard process of creating VPC endpoints and toggling private DNS support for those endpoints.

Service Endpoints

Service-specific management consoles, such as S3, depend not only on the S3 API endpoint but also on the CloudWatch monitoring API endpoint (e.g., monitoring.us-east-1.amazonaws.com). This knowledge is encoded in a JSON file [4] where customers are expected to pick up all service endpoints for a given region to make all service-specific consoles work. Missing endpoints in that list can result in a broken web experience.

Endpoint Policies

Endpoint policies control which users can access the AWS management console in a trusted network, while unauthorized users are denied login to the console. The endpoint policy format for AWS console private access is slightly different from other services — they do not support all sets of context keys and require every Principal and Resource to be set to * and the Action to either * or signin:*. If this is not documented or tested properly, it can cause someone to accidentally put a more specific action on the endpoint policy, breaking AWS management console access over Privatelink.

Infrastructure Management

AWS provides a CloudFormation stack example to set up Private Access. While it works, it does not scale to real-world environments. It becomes unmaintainable for teams to keep updating and deploying CFN stacks. The better alternative is AWS CDK, which helps manage infrastructure as code, but there are no examples online for this topic.

Operational Best Practices

Setting up Privatelink for a service endpoint is generally part of a bigger project involving setting up data perimeter controls for a large organization. Today, the example CloudFormation template [5] does not include important components such as monitoring potential data exfiltration attempts, validation of the stack as to whether endpoint policies are being set correctly, enabling CloudTrail network activity and data events, etc. These steps are necessary to enable a production-ready data perimeter in any organization.

To expand on operational best practices, if customers do not enable CloudTrail data and network events, they lose visibility into who accessed their resources and into tracing data exfiltration attempts. This is important because VPC endpoints are an integral part of enforcing network perimeter protection [6].

Data perimeter drift: As teams evolve and new team members start contributing to and maintaining their data perimeter code, historical context (the whys) on their existing setup may be lost. This is common, especially when software has been maintained for several years, with documents scattered across multiple sources and code comments not being accurately maintained.

For example, if a team member attempts to “optimize” or “unify,” say, VPC endpoint creation and remove the Route53 special instructions, then the Private access setup breaks, failing to resolve DNS from within the VPC. In the best case, this change breaks nonproduction systems, while in the worst case, it breaks large production systems, leading to business outages. Therefore, there must be some way of encoding, capturing, and enabling validation for preserving historical context.

Proposal

To begin, we categorize our problems into four distinct categories:

Infrastructure setup – involving setup complexity like Route53 DNS entries, AWS service API endpoints, and maintaining proper VPC endpoint policies.
Operational best practices – including several necessary components like monitoring, alarming and detection
Software evolution – as team members rotate over time
Data perimeter drift

To address the infrastructure setup issue (problem #1), we start by encoding setup instructions in code. AWS provides Cloud Development Kit (CDK) to maintain Infrastructure as code (IaC). Alternatively, one could use Terraform or shell scripting to maintain their IaC.

In this example, the CDK code compiles into a CloudFormation template, which will be used to provision infrastructure in our AWS account. With CDK, the setup step becomes simpler — instead of maintaining CloudFormation stacks by ourselves, we leverage CDK to make our code more readable, maintainable, and testable in a pipeline. I created one such example in my code repository [7], available publicly, and a sample snippet is included below:

    TypeScript
   
 

   // ============ ROUTE53 HOSTED ZONES =========== 

// Console Hosted Zone 
const consoleHostedZone = new route53.PrivateHostedZone(this, 'ConsoleHostedZone', { 
  vpc, 
  zoneName: 'console.aws.amazon.com', 
}); 

// Console records - use alias records to VPC endpoint 
new route53.ARecord(this, 'ConsoleRecordGlobal', { 
  zone: consoleHostedZone, 
  target: route53.RecordTarget.fromAlias( 
    new InterfaceVpcEndpointTarget(consoleEndpoint) 
  ), 
  recordName: 'console.aws.amazon.com', 
}); 
  

Similarly, operational best practices (problem #2) like monitoring and detection can be encoded in the CDK stack as well — by leveraging AWS deep integration with services, we can use CDK to set up network and data events for CloudTrail and enable monitoring using CloudWatch in the same CDK repository. My code repository [7] contains one such example, like the snippet below:

    TypeScript
   
 

   // Helper to create VpceAccessDenied event selectors 
const createVpceAccessDeniedSelector = (serviceName: string, eventSource: string) => ({ 
  name: `${serviceName} VPC Endpoint Denied Events`, 
  fieldSelectors: [ 
    { field: 'eventCategory', equalTo: ['NetworkActivity'] }, 
    { field: 'eventSource', equalTo: [eventSource] }, 
    { field: 'errorCode', equalTo: ['VpceAccessDenied'] }, 
  ], 
});
  

While these two pieces of code already simplify setup, someone can still change what the code does by not having enough historical background of the setup (problem #3). This is where development-time validation can help. To demonstrate this pattern, I built a Kiro Power [9] — a bundle of steering files, MCP tool configuration, and event-driven hooks that encodes project-level domain knowledge and validates changes automatically. The steering file serves as an onboarding manual for the AI agent, describing what tools are available and when to use them. Hooks trigger validation on specific events like file saves, and the MCP server runs the actual checks against the project's best practices. The bundle loads dynamically based on context rather than in every conversation, keeping the agent's context window small. The same pattern can be replicated using any team-built IDE extension or managed service.

Unlike traditional MCP, Kiro Powers aren’t loaded in each conversation. Instead, they are loaded dynamically based on certain keywords we define and are activated only when there is a match. This approach keeps the context window low.

I created a Kiro power to setup AWS Management Console Private Access [8]. This power contains (1) knowledge related to Private Access, (2) an MCP validator that checks whether a given CloudFormation template follows best practices, and (3) hooks to review VPC endpoint policies and validate CloudFormation stacks after changes are made.

With this Kiro Power, all project-level information and best practices are encoded in the Power.md file [9]. Historical context can be written to this file and is version-controlled in Git. Now, a team member can use Kiro IDE and install the Kiro Power. Any time they want to make a code change, they can talk to the Kiro agent to validate their changes. When this Kiro power activates, the LLM understands all the context about this project and responds accordingly. Upon responding, the LLM runs a validator to ensure that the CDK changes adhere to the company’s best practices by using the validator MCP.

With this solution, we have effectively found a way to:

Preserve historical context for the project
Enforce best practices are being followed
Set up a standard development pattern that can scale to multiple developers within the team

If a team member makes a breaking change to the setup, the Kiro agent catches it immediately. This potentially prevents data perimeter drift (problem #4) because the goal and historical context of the project are encoded in the AI agent. The team can incorporate git hooks to trigger an agent to audit the local code changes, effectively alerting the user on potential drifts, catching issues, and potentially blocking pull request creation entirely.

To sum it all up, the three properties that a development-time data perimeter validator must have are:

Version-controlled context encoding
Pre-commit validation hooks
IDE-agnostic tools

Limitations

Kiro Powers is not a one-stop shop for this issue. This pattern does not work if some team members do not use the specific IDE or standard team development practice. This approach requires the team to adopt a shared validation step in their development workflow. For example, the team can require a pull request to contain the output of the LLM-validated CFN stack.

Secondly, it does not imply teams can skip critical setup steps like monitoring whether 1) Cloudtrail network events are enabled, 2) VPC endpoint policies are set properly, and 3) whether Route53 resolution still happens within the VPC. These are essential to catch breaking changes caused by CDK changes early on.

Conclusion

We explored a development-time validation pattern to catch data perimeter drift before it reaches production. We applied it to a specific use case: setting up AWS Management Console Private Access, a setup that is easy to break and hard to debug without historical context.

The core idea is straightforward — encode the whys behind your infrastructure in version-controlled files and validate changes against that context before a pull request is made. Kiro Powers is one way to implement this pattern, but the same approach works with any team-built IDE extension or validation hook.

This does not replace monitoring, CloudTrail, or integration tests. It works alongside them by catching issues earlier, when they are cheapest to fix.