SCPs and RCPs

Use an SCP to limit what your organization's principals can do. Use an RCP to limit what anyone can do to your organization's resources. Both are AWS Organizations policies, both need an organization with all features enabled, and neither ever grants access: an identity-based or resource-based policy must still allow the request.

	Service control policy (SCP)	Resource control policy (RCP)
Caps	IAM users and roles in member accounts, including the member account's root user	Resources in member accounts, whoever calls them, including principals outside the organization
Default	`FullAWSAccess` attached; remove it only after attaching a replacement Allow, or every action in the affected accounts fails	`RCPFullAWSAccess` attached to the root, every OU and every account; it cannot be detached
Services	All	Only the services listed as supporting RCPs (S3, KMS, Secrets Manager, SQS, STS, DynamoDB, ECR, CloudWatch Logs and others; check the list)
Error text when it refuses	`… because no service control policy allows …` or `… with an explicit deny in a service control policy`	`… with an explicit deny in a resource control policy`

What neither can restrict

The management account. SCPs don't affect its users or roles; RCPs don't affect its resources. Delegated-administrator accounts are member accounts and are restricted.
Service-linked roles. Neither SCPs nor RCPs limit them, and RCPs do not affect a service's ability to assume its service-linked role.
RCPs only: AWS managed KMS keys, and the kms:RetireGrant permission.
SCPs only: principals in accounts outside the organization, and a short list of exempt tasks (some root-user tasks among them).

Inheritance

Policies attach to the organization root, to OUs, and to accounts.

SCPs: an action is available in an account only if an SCP explicitly allows it at every level from the root, through each OU in the direct path, down to the account itself. One level without the Allow blocks every account beneath it. A Deny at any level wins.
RCPs: a resource has only the permissions every parent above it permits. Because customer RCPs can only Deny, the practical rule is that a Deny attached anywhere above the resource's account applies to it, even if the resource's own policy allows everyone.

RCP syntax rules

Effect must be Deny in any RCP you write; Allow exists only in RCPFullAWSAccess.
Principal is required and must be "*"; narrow it with a Condition.
Action must name a service prefix; "*" cannot be the whole value. * and ? work within Action and Resource.
Each statement needs Resource or NotResource.
NotPrincipal and NotAction are not supported.

The size limit and the number of policies per organization are quotas, not fixed rules: all characters count toward the size, so strip white space outside quotation marks if a policy is near its limit. The RCPs-per-organization quota was raised in July 2026; read current values in the Organizations quotas documentation.

Choosing which one to write

You want to	Write
Stop anyone in an account from leaving approved Regions or disabling a security service	SCP (caps your principals)
Stop anyone outside the organization from reading your S3 objects or secrets, whatever a bucket or secret policy says	RCP (caps your resources)
Require something of every request to a resource type (for example TLS)	RCP, where the service supports RCPs
Delegate role creation inside one account with a ceiling	Neither: a permissions boundary (`reference/iam/policy-evaluation.md`)

AWS's published RCP examples live in the aws-samples/resource-control-policy-examples repository linked from the RCP examples page. Read them for the structure of a data-perimeter Deny and its exceptions for AWS service principals before writing your own.

Rolling one out safely

AWS strongly recommends against attaching a new SCP or RCP to the organization root before testing it:

Attach it to a test account, or to an OU holding a few accounts moved in one at a time.
Look for AccessDenied events in CloudTrail, and for SCPs check IAM last-accessed data for services still in use.
Move the attachment up the OU tree one level at a time.

A Deny-based RCP can block AWS services that call your resources on your behalf unless its conditions make an exception for them.

Who can change them

The organization's administrators, from the management account (whether a delegated administrator can manage these policy types was not confirmed in the collected sources). An agent working inside a member account cannot fix an SCP or RCP denial itself: hand the action, resource, policy type and, if the message gives one, the policy ARN to the organization's administrators.