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, the honest answer to "what stops someone outside our org with valid credentials from reading this bucket" is the bucket policy, and only the bucket policy, which drifts the moment 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, one with valid credentials and explicit IAM allow permissions, from reading the bucket or using the KMS key, with the deny surfacing 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