AWS RCP vs SCP: What's the Difference and Which One Do You Need?

The verdict: reach for an SCP when the thing you need to limit is what your own identities can do. Reach for an RCP when the thing you need to limit is who can reach your resources. A data perimeter needs both, because neither one covers the other side.

Key Takeaways

• SCPs and RCPs are both organization-level guardrails in AWS, but they restrict from opposite directions: SCPs cap what your identities can do, while RCPs cap what can be done to your resources.
• You need both to build a complete data perimeter. SCPs don't prevent an external principal from accessing a misconfigured resource, and RCPs don't constrain what your own identities do inside the organization.
• RCPs only apply to services AWS has enabled them for. That list started at five in November 2024 (S3, STS, KMS, SQS, and Secrets Manager) and covers 44 service entries as of August 2026, including DynamoDB, CloudWatch Logs, ECR, EventBridge, and AWS WAF. For services outside that list, SCPs and resource-based policies remain the primary enforcement layer.
• The most common mistake is treating these as alternatives. They're complementary controls that address different sides of the same enforcement problem.

Use SCPs to restrict what your own identities can do. Use RCPs to restrict who can reach your resources. Use both when you're building a data perimeter.

What Each Policy Does

SCPs (Service Control Policies) have been part of AWS Organizations since 2017. They're principal-centric controls: they set the maximum permissions available to IAM users and roles inside your member accounts. An SCP that denies s3:DeleteObject means no identity in that account can call that action, regardless of what any IAM policy allows. SCPs don't grant permissions. They only restrict.

RCPs (Resource Control Policies) arrived in November 2024. They're resource-centric controls: they set the maximum permissions available on your organization's resources. An RCP that requires the aws:PrincipalOrgID condition on S3 means no principal outside your organization can access those buckets, even if a misconfigured bucket policy explicitly allows it. Like SCPs, RCPs don't grant permissions. They restrict what any identity can do to the resource.

Both controls attach at the organization or OU level, both override lower-level policies, and neither applies to the management account. That last point matters practically: the management account sits outside the enforcement scope of both policy types, which is one reason access to it should be separately controlled.

Side-by-Side Comparison

How SCPs and RCPs Fit into the AWS Authorization Model

Understanding where these policies sit in AWS's evaluation logic matters for predicting exactly what they'll block and what they won't.

When AWS evaluates whether to allow a request, it works through several policy layers in sequence. Organization-level policies, meaning SCPs and RCPs, act as the outer boundary. An explicit deny at this layer ends the evaluation immediately, and no lower-level policy can override it. IAM identity-based policies and resource-based policies then determine what's permitted within that boundary. The final effective permission is the intersection of what all applicable policies together allow. Nothing inside a member account can grant access that an SCP or RCP has denied at the organization level.

SCPs constrain principals on their way in. They're evaluated against the identity making the request, so they don't know or care what specific resource is being targeted beyond what the policy conditions specify. RCPs constrain resources on their way out. They're evaluated against the resource receiving the request, so they apply regardless of where the requesting principal originates, including principals from entirely outside the organization.

This is also why RCPs can close a category of exposure that SCPs structurally can't: a principal outside your organization is never subject to your SCPs, because your SCPs only govern principals inside your org. An external identity that has somehow been granted access to a resource in your account through a misconfigured resource policy sits completely outside the scope of your SCP controls. An RCP applied to that resource governs that access regardless.

SCPs and RCPs also sit at a different layer than IAM permission boundaries, which restrict what a specific identity can do rather than what all identities in an account or organization can do. Permission boundaries are useful when you want to delegate permission management while capping the ceiling on what delegated identities can hold. SCPs and RCPs operate above that: they constrain the organization as a whole, not individual identities within it.

Decision Framework

The right starting point is identifying what you're trying to control: the principal, the resource, or both.

Use an SCP when: You want to restrict what services or actions your own IAM identities can take across accounts. Common examples include blocking all identities from disabling CloudTrail, preventing IAM access key creation, enforcing region restrictions for your users and roles, or capping permissions for a specific OU regardless of what individual IAM policies allow. If the threat you're controlling for is your own identities doing something they shouldn't, SCPs are the right tool.

Use an RCP when: You want to prevent your resources from being accessed by principals outside your organization, including scenarios where a resource policy has been misconfigured to allow broader access than intended. RCPs are the right tool when you're enforcing that specific data stores can only be accessed by identities within your org's trust boundary, and you can't rely on every account team to configure every resource policy correctly. If the threat you're controlling for is external access to resources your org owns, RCPs close that gap.

Use both when: You're building a complete data perimeter that governs both what your own identities can do and who can reach your resources from outside. When an IAM principal in your org accesses a resource in your org, SCPs and RCPs both apply. The effective permission is the intersection of what both allow. A deny from either one blocks the action.

[Flowchart: Decision tree with three terminal states: "Use SCP," "Use RCP," "Use Both"]

Worked Scenarios

Scenario 1: Enforcing a data perimeter on S3

An organization runs production workloads across 20 AWS accounts. Their threat model includes two failure modes: a developer in a member account accidentally making a bucket public, and an external party who obtained leaked credentials from a third-party vendor attempting to access internal storage.

An SCP can address the first scenario. Restricting s3:PutBucketPolicy or s3:PutBucketAcl across the organization prevents your own identities from introducing overly permissive configurations. But that SCP doesn't prevent an external principal from accessing a bucket if a resource-based policy already allows it, and it doesn't retroactively close exposure on resources that were misconfigured before the SCP was in place.

An RCP closes the second gap. A policy requiring aws:PrincipalOrgID on all S3 buckets across the organization means access is restricted to principals within the organization boundary, regardless of what individual bucket policies say. The SCP governs what your identities can do. The RCP governs who can reach your resources.

Together, the two controls address both failure modes without relying on every account team to configure every bucket policy correctly every time.

Scenario 2: Protecting KMS keys from cross-account misuse

A security team discovers that a KMS key in a shared services account has a key policy that allows kms:Decrypt to any principal in a specific external AWS account, a configuration that was added for a vendor integration that has since been decommissioned. The external account still has access.

An SCP can't fix this. The external identity isn't a principal in the organization, so the SCP doesn't govern it. The key policy explicitly allows the action, and the external account isn't subject to any controls the organization applies to its own members.

An RCP applied to KMS closes it. A policy requiring aws:PrincipalOrgID on KMS operations across the organization means the external principal's request is denied at the resource level, regardless of what the key policy says. The RCP doesn't require the team to find and fix every misconfigured key policy; it enforces the organization boundary at the resource evaluation layer. Fixing the key policy is still the right thing to do, but the RCP means exposure doesn't persist while that work makes its way through a remediation queue.

Where Teams Get This Wrong

Treating RCPs as a full replacement for SCPs. RCPs cover a defined set of services, 44 entries as of August 2026. For anything outside that list, SCPs and resource-based policies are still doing the work. Removing SCP controls under the assumption that RCPs will cover the same ground creates gaps that are easy to miss until something goes wrong.

Forgetting about service principals. SCPs don't apply to AWS service principals. When AWS services act on your behalf, such as CloudTrail delivering logs to an S3 bucket, the request comes from an AWS service principal rather than an IAM principal in your org. RCPs do apply to service principals in some cases, which can block legitimate service behavior if your RCP doesn't include the right exceptions. Test against your actual cloud activity before deploying.

Assuming SCPs cover all sharing scenarios. SCPs restrict what your identities can do. They don't restrict what external identities can do to your resources if those resources have already been shared. A cross-account role trust, a misconfigured bucket policy, or a KMS key policy that's too broad can all create access paths for external principals that sit entirely outside SCP scope. This is the gap RCPs were designed to close.

Skipping pre-deployment simulation. Both policy types affect live systems the moment they're applied at the org level. Because a deny from either an SCP or an RCP blocks the action regardless of what IAM allows, testing the intersection of proposed controls against your real cloud activity is the correct sequence before anything ships. AWS recommends using IAM Access Analyzer to review RCP impact on existing resource permissions before deploying. At scale, an org-level deny that breaks a production dependency is a serious incident, and the blast radius is hard to undo quickly.

Deploying SCPs and RCPs correctly is one part of the problem. Keeping them aligned as accounts, services, and access patterns change underneath them is where most organizations lose ground. Native helps security teams enforce organizational controls as part of a broader data perimeter architecture, with impact simulation before deployment and continuous alignment after. See how it works on your environment.

FAQ

Do SCPs and RCPs conflict with each other? They're evaluated independently and address different sides of the access decision. Both must allow an action for it to succeed: a deny from either one blocks the action, and they don't interact in a way that requires coordination between the two policies. They're complementary, not competing.

Can an RCP grant access to an external principal? No. RCPs only restrict; they never grant permissions. Granting access to an external principal still requires an explicit allow in a resource-based or identity-based policy. The RCP sets the ceiling on what's permitted, but the actual grant still has to come from somewhere else in the permission model.

Does an SCP apply to the root user? SCPs apply to IAM roles and users in member accounts, including those accounts' root users. They don't apply to the management account root user, which is another reason tight controls on management account access matter separately.

What happens if an RCP breaks a service that was working? RCPs can block legitimate access if they're deployed without testing against existing usage. AWS recommends using IAM Access Analyzer to identify external access and review how an RCP would change resource permissions before applying it. Service principals that AWS uses to interact with your resources on your behalf often require explicit exceptions in RCP conditions, and missing those exceptions is one of the most common causes of unexpected failures after an RCP is deployed.

How do RCPs relate to resource-based policies? They operate at different levels. A resource-based policy is attached directly to a resource, such as a bucket policy on S3 or a key policy on KMS, and it defines who can access that resource. An RCP is an organization-level guardrail that sets the maximum permissions on all resources of supported types across the organization, regardless of what individual resource-based policies say. The RCP can restrict what a resource-based policy is allowed to permit, but it can't expand it. If an RCP denies an action, a permissive resource-based policy can't override it.

Are there services that support RCPs but not SCPs? No. SCPs apply broadly across AWS services. RCPs apply to the 44 service entries AWS lists as of August 2026, and it keeps adding to that list. For services outside that list, SCPs and resource-based policies are your enforcement layer.

When both an SCP and an RCP apply to the same action, which one wins? Neither wins over the other in the sense of priority. Both must allow the action. If the SCP denies it, the action is blocked. If the RCP denies it, the action is blocked. The effective permission is the intersection of what all applicable policies, including identity-based and resource-based policies, allow. All layers have to agree.

How do SCPs and RCPs relate to IAM permission boundaries? They operate at different scopes. SCPs and RCPs apply at the organization or OU level and govern all identities and resources within scope. IAM permission boundaries apply to a specific IAM role or user and cap what that individual identity can do, even if its identity-based policies would otherwise allow more. The controls work at different layers and serve different purposes: organizational guardrails constrain the environment broadly, while permission boundaries constrain specific identities within it. Both restrict rather than grant, and both are evaluated as part of the same authorization chain.