Define and Apply Resource Control Policies (RCPs)
Specification & Description
Use Resource Control Policies from the Management account to enforce centralized maximum-permission guardrails on resources across the organization, closing the gap that SCPs cannot address. RCPs complement SCPs in the policy evaluation chain: SCPs constrain what identities can do, RCPs constrain what resources can accept. Together they form the data perimeter of the landing zone. Recommended foundational RCPs for a landing zone:
- Deny access to S3 buckets from principals outside the organization (prevents cross-account exfiltration via bucket policy)
- Deny access to SQS queues from principals outside the organization
- Deny access to Secrets Manager secrets from principals outside the organization
- Deny sts:AssumeRole on roles from principals outside the organization unless the role trust policy explicitly allows it
- Restrict S3 access to known VPC endpoints only for sensitive OUs
- Deny ECR image pulls from outside the organization
- Deny OpenSearch Serverless collection access from outside the organization
Technical Specifications
SCPs restrict what IAM identities in member accounts can do - but they cannot prevent an external principal from accessing a resource if that resource's own policy grants them access. A member account operator who adds an external account to an S3 bucket policy bypasses all SCP-based controls entirely. RCPs close this gap: they sit on the resource side of the policy evaluation and cap the maximum permissions any resource policy can grant, regardless of what the resource policy says. The effective permission on a resource is the intersection of the RCP, the identity's SCP, the IAM identity policy, and the resource-based policy - all four must allow the action. RCPs are supported on S3, SQS, STS, Secrets Manager, ECR, OpenSearch Serverless, ... They are managed from the Management account and attached at the organization root or OU level. Unlike SCPs, RCPs do apply to the Management account. The primary use case is building a data perimeter: ensuring that only trusted identities (organization principals), from trusted networks (known VPCEs), can access sensitive resources - regardless of what individual resource policies say.
Security Rationale
SCPs alone are insufficient to prevent data exfiltration. An operator in a member account with sufficient IAM permissions can attach a permissive S3 bucket policy that grants an external attacker-controlled account direct resource access. The SCP cannot see or block this because the access request comes from the external account, which is outside the organization's SCP boundary entirely. RCPs enforce the organization boundary on the resource itself, meaning even a deliberately misconfigured resource policy cannot grant access beyond the RCP limit.
Policy Exceptions (2)
Unlike SCPs, RCPs apply to the Management account. Ensure that RCP conditions include appropriate carve-outs for AWS service principals and Management account roles that require cross-account resource access for legitimate operational tasks (e.g. AWS Backup cross-account copy, CloudFormation StackSets).
Approved third-party SaaS integrations that require cross-account S3 access must be explicitly permitted via RCP condition keys (aws:PrincipalOrgID, aws:PrincipalArn) before deployment. Document each exception with vendor account ID and annual review date.
Operational & Implementation Notes
RCPs are a relatively new AWS feature and are not yet supported on all resource types - check the AWS documentation for the current list of supported services before drafting policies. Unlike SCPs, RCPs do apply to the Management account; this is intentional and means the Management account is protected by the same resource-side guardrails as member accounts. The FullAWSAccess RCP is attached by default at the root and must remain - custom RCPs are Deny additions on top of it, identical to the SCP model. RCP evaluation is AND-ed with SCP evaluation: both must allow the action. A Deny in either blocks the request regardless of what the other allows. Run Access Analyzer before applying any RCP to identify existing cross-account resource policies that would be affected.