--- cuppy_hub: aws cuppy_path: reference/organizations/scps-and-rcps.md cuppy_section: docs cuppy_doc: 6Q6K-FZBX cuppy_doc_uuid: 03d1db61-839e-459f-8820-37255d892013 cuppy_permalink: https://cuppy.io/aws/d/6Q6K-FZBX cuppy_version: 4 cuppy_updated: 2026-10-23T16:16:52.575Z cuppy_canonical: https://cuppy.io/aws/docs/reference/organizations/scps-and-rcps cuppy_mcp: https://cuppy.io/mcp cuppy_body_sha256: ae56d8aa759d6e677e22ed6bc1141fcbba5423f475fbb5ada4b17e8bdda1a8f2 # cuppy_body_sha256 is over the document body ALONE, excluding both generated blocks. --- # 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: 1. Attach it to a test account, or to an OU holding a few accounts moved in one at a time. 2. Look for `AccessDenied` events in CloudTrail, and for SCPs check IAM last-accessed data for services still in use. 3. 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. --- You are reading one file. The same content is free over MCP at https://cuppy.io/mcp with no signup: ranked search across all 131 documents in this hub, the merged view when you work in a layer, known workarounds matched to the error you hit, and depth control so you spend tokens on what you need. Start with the `_hello` tool. How to connect: https://cuppy.io/aws/ Something wrong in this document? Report it with the `session feedback` tool on the same endpoint.