AWS Data Perimeter Gaps Found in 60% of Cloud Environments
Most companies think their AWS cloud data is locked down. New research from Datadog says otherwise, and the gaps are hiding in plain sight.
Datadog’s 2025 Cloud Security report found that approximately 40% of organizations use data perimeters, with most applying them per resource. Of that group, fewer than 1% use recommended organization-level solutions such as resource control policies (RCPs) and service control policies (SCPs). That gap, between per-resource controls and organization-level enforcement, is exactly where attackers find their way in.
AWS data perimeter policies are designed to ensure that only trusted identities access trusted resources from authorized networks. However, applying them per resource creates drift. As environments grow, new buckets get created, third-party tools get onboarded, and policies quietly fall out of sync.
Datadog’s security team used Stratus Red Team, an open source threat emulation tool, to simulate attacks across four perimeter scenarios. First, they tested visibility. Then, they tested identity perimeters, network perimeters, and resource perimeters. In each case, per-resource controls alone proved insufficient.
One of the starkest demonstrations involved S3 bucket policies. A compromised principal within an account can call s3:PutBucketPolicy to grant an external account read access to a bucket, effectively replacing the entire existing policy. Once a backdoor policy is applied, the original identity controls disappear. An attacker in an external account can then pull data freely.
Visibility is also at risk. Tampering with logging is a popular defense evasion technique. CloudTrail trails can capture when a policy blocked or allowed access, as well as any changes to the controls themselves, such as a bucket policy modification. Without organization-level controls, a compromised role can quietly disable logging, eliminating the very evidence needed to detect an attack.
The fix for each gap follows the same pattern: move controls to the organization level. For identity perimeters, an RCP with the aws:PrincipalOrgID condition ensures only your organization’s identities can access S3 buckets, even after a bucket policy is overwritten. For network perimeters, AWS recommends using SCPs and RCPs to cover the control objectives. An RCP can block API calls that originate from VPC endpoints outside your organization, covering gaps that per-resource policies leave behind.
Resource perimeters follow a similar logic. A VPC endpoint policy using only aws:PrincipalAccount or aws:PrincipalOrgID only covers traffic from trusted identities within the VPC. It does not account for where data can go. An attacker who compromises a workload inside the VPC can still route calls through the endpoint and exfiltrate data, because the calls originate from a trusted identity. Upgrading to aws:ResourceOrgID in both the endpoint policy and an SCP closes that path.
The Stratus Red Team techniques used in the research are available on GitHub for teams that want to test their own AWS data perimeter policies. The guidance on managing AWS CloudTrail costs and configuring CloudTrail logs is also publicly available.
The underlying message is clear. AWS data perimeter policies work, but only when they cover the whole organization. Per-resource controls are a starting point, not a finish line.
