The Core Concept

RCPs are the mirror image of SCPs. SCPs control what your principals can do. RCPs control what can be done to your resources.

SCPRCP
DirectionGoverns outgoing — what IAM principals (users/roles) in your org can requestGoverns incoming — who can access resources that live in your org
Attached toRoot, OU, or accountRoot, OU, or account
Applies toPrincipals in member accountsResources in member accounts
Grants permissions?No — only sets a ceilingNo — only sets a ceiling
External principals?SCPs can't reach external principalsRCPs do restrict external principals

As AWS puts it plainly: Use an SCP when you need to limit permissions of IAM principals within your organization's member accounts. Use an RCP when you need to restrict IAM principals that are external to your organization accounts making requests to access resources within your organization's member accounts [1].

Why RCPs Exist: The Problem They Solve

SCPs have a blind spot. If a developer in a member account attaches a permissive S3 bucket policy that grants access to an external third-party account, an SCP cannot stop that — SCPs only constrain your own principals. The external principal's IAM permissions are outside your control.

RCPs close that gap. An RCP says: No matter what the resource-based policy on this bucket says, nobody outside my organization can touch it. It's a data perimeter — a hard boundary around everything your organization owns.

AWS introduced RCPs in November 2024 and they are explicitly in scope for the SCS-C03 exam (December 2025 onward).

How the Evaluation Logic Works

The effective permissions for any request are the logical intersection of four layers [1]:

Effective   =  SCP allow  ∩  RCP allow  ∩  Identity-based policy allow  ∩  Resource-based policy allow
Permissions     (on principal)  (on resource)   (on principal)               (on resource)

Every layer must permit the action. If any layer denies, the request is denied.

Example: An external user in Account B (outside your org) tries to read an S3 object in your member account. Even if your S3 bucket policy explicitly allows them:

  1. SCP: Not applicable (principal is external)
  2. RCP: Evaluates — if it denies external access → Deny
  3. Identity policy (external account): Might allow
  4. Resource policy (your bucket): Might allow

Result: Denied because the RCP blocked it [2].

The key insight: when a principal makes a request, the RCP from the resource owner's account is pulled into the evaluation, regardless of where the principal lives [1]. RCPs apply regardless of whether the principals belong to the same organization or not. This includes root users [1].

Cross-Account Behavior

RCPs are straightforward in cross-account scenarios:

The canonical RCP for a data perimeter looks like this [2]:

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

This denies everything unless the caller belongs to your org or is an AWS service acting on your behalf (e.g., CloudTrail writing logs).

Services Currently Supported

At launch (Nov 2024): S3, STS, KMS, SQS, Secrets Manager. Since expanded to include [1]:

Cognito, CloudWatch Logs, DynamoDB, AppConfig, AppStream, EC2 Auto Scaling, CodeBuild, CodeCommit, Comprehend, DAX, ECR, AWS Health, Kinesis Video Streams, OpenSearch Serverless, AWS Sign-In, AWS Support, Textract, Transcribe, Translate, and more.

RCPs only apply to services on this list. For unsupported services, there is no RCP evaluation at all [1].

Important Limitations