c2.5 Set guardrails with SCPs and RCPs

Service Control Policies (SCPs)

Service Control Policies cap the maximum permissions that AWS IAM can grant in an account. They do not grant access — they set the ceiling. Apply them at the organization, organizational-unit, or account level to enforce security invariants: rules you set once and rarely change.

SCPs apply even to the root user of member accounts, but do not apply to the management (organization root) account — so keep sensitive workloads out of the management account.

Examples: prevent member accounts from leaving the organization, block disabling of security services, or restrict instance types. See the SCP examples in the documentation and the SCP examples repository.

Resource Control Policies (RCPs)

Resource Control Policies are the resource-centric counterpart. They set the maximum access to your resources across the organization — for example requiring that only identities from your own organization can access your Amazon S3 buckets or SQS queues. Like SCPs, RCPs grant nothing; they only constrain. See the RCP examples repository.

Think through everything you never want to happen in your accounts and enforce it with SCPs and RCPs. Test in a non-production OU first, since an over-broad deny can block legitimate operations.

Example RCP: only your organization can access your S3

This Resource Control Policy denies S3 access unless the calling principal belongs to your organization (blocking access from outside identities even if a bucket policy is misconfigured):

{
  "Version": "2012-10-17",
  "Statement": [{
    "Sid": "EnforceOrgIdentitiesOnS3",
    "Effect": "Deny",
    "Principal": "*",
    "Action": "s3:*",
    "Resource": "*",
    "Condition": {
      "StringNotEqualsIfExists": { "aws:PrincipalOrgID": "o-example12345" },
      "BoolIfExists": { "aws:PrincipalIsAWSService": "false" }
    }
  }]
}