AWS Data Perimeter
A three-layer data perimeter built from SCPs, RCPs, and VPC endpoint policies, validated by denying a second AWS account with valid credentials and explicit IAM permissions.
Without Resource Control Policies, only the bucket policy stops someone outside the org, with valid credentials, from reading a bucket. That policy drifts as soon as someone creates a new bucket without copying the deny block.
Three concentric layers, each a different AWS control type: SCPs stop internal principals acting outside the org, RCPs stop external principals acting on org resources, and VPC endpoint policies combined with aws:VpceOrgID restrict endpoint traffic to org-owned principals and resources. The RCPs attach at the Workloads OU rather than root, trading a small, acknowledged gap around management-account compromise for lower lockout risk.
SCPs don't constrain principals outside your org. RCPs are the layer AWS didn't have until now.
The trusted path worked end to end: an EC2 instance in a private subnet with no internet gateway reached S3, KMS, and STS only through VPC endpoints. The negative tests denied a second account's IAM role from reading the bucket or using the KMS key, despite valid credentials and explicit IAM allow permissions. The deny surfaced directly from the resource control policy.
- RCPs attached at the Workloads OU, keeping the management account outside the perimeter by design
- Six VPC endpoints (S3, STS, KMS, SSM, SSM Messages, EC2 Messages), no internet gateway
- External account with valid credentials and explicit IAM allow still denied at the resource layer