skip to content

AWS Organizations supports both service control policies and resource control policies. What does an RCP constrain that an SCP cannot?

level: middleimportance: nice to knowfreq 22%

answer

  1. one bounds identities, one bounds resources
  2. SCPs cannot reach outside callers
  3. the data-perimeter policy type
  4. RCP statements carry a Principal element
  5. both are ceilings, neither grants

basics

~20 s

An SCP caps what principals inside your member accounts may do. A resource control policy caps what may be done to resources inside those accounts, including by principals from outside your organization — which SCPs never reach.

solid answer

~50 s

Both are organization policies attached to the root, an OU or an account, and both are ceilings that never grant. The difference is which side of the request they bound. An SCP follows the **principal**: it limits what identities in your member accounts can do, anywhere. An RCP follows the **resource**: it limits what can be done to resources in those accounts, regardless of who is calling. That closes the gap SCPs structurally cannot — an external principal accessing your S3 bucket through a bucket policy is governed by *their* organization, not yours, so no SCP of yours applies. The canonical RCP is a data-perimeter rule: deny access to your buckets unless the caller is in your organization or is an AWS service acting on your behalf. Note that RCPs arrived in late 2024 and cover a subset of services rather than everything, so check support before designing around them.

code

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

go deeper

for a junior

Know the one-line distinction: SCPs bound what your identities may do, RCPs bound what may be done to your resources, and neither grants anything.

for a middle

Explain the structural gap — SCPs are principal-side so they cannot reach callers from other organizations — and recognise that an RCP statement carries a Principal element because it is resource-side.

for a senior

Design the perimeter: pair RCPs that keep foreign identities out of your resources with SCPs that keep your identities out of foreign resources, and always exempt AWS services or you break legitimate integrations.

for a principal

Judge whether an organization-wide perimeter is worth its failure modes, given partial service coverage and controls that are invisible from inside a member account, and decide what evidence you need before enforcing one broadly.

## Two ceilings, two sides of the request An AWS request has a principal on one side and a resource on the other. Organizations gives you a ceiling for each. | | Service control policy | Resource control policy | |---|---|---| | Bounds | principals in your member accounts | resources in your member accounts | | Applies to external callers | no | yes | | Applies to the management account | no | no | | Grants anything | never | never | | Attached to | root, OU, account | root, OU, account | Both inherit down the OU tree exactly the same way, both are enabled as policy types in an organization with all features, and both come with a default wide-open managed policy attached (`FullAWSAccess` for SCPs, `RCPFullAWSAccess` for RCPs) so that turning the feature on changes nothing until you act. ## The gap RCPs fill SCPs are a principal-side control, which means they can only ever constrain identities that live in your accounts. Consider a bucket in your account whose bucket policy allows a partner's account to read objects. That partner's role is not in your organization, so no SCP of yours touches it. Historically the only defence was to get every bucket policy right, everywhere, forever — a per-resource discipline that scales badly and fails silently the first time someone adds a bucket in a hurry. An RCP moves that guarantee up to the organization. Attach one at the root and it constrains every supported resource in every member account beneath, no matter what an individual resource policy says. ## What an RCP looks like Unlike an SCP, an RCP statement includes a `Principal` element, because it is a resource-side policy and has to describe who it is talking about: ```json { "Version": "2012-10-17", "Statement": [ { "Sid": "EnforceOrgIdentities", "Effect": "Deny", "Principal": "*", "Action": "s3:*", "Resource": "*", "Condition": { "StringNotEqualsIfExists": { "aws:PrincipalOrgID": "o-exampleorgid" }, "BoolIfExists": { "aws:PrincipalIsAWSService": "false" } } } ] } ``` Read it as: deny anything against S3 in these accounts unless the caller belongs to my organization, and do not break AWS services acting on my behalf. The second condition matters — omitting it breaks service integrations that legitimately call into your resources. ## Scope and caveats - **Service coverage is partial.** RCPs launched in November 2024 supporting a limited set of services — Amazon S3, AWS STS, AWS KMS, Amazon SQS and AWS Secrets Manager at launch. Coverage has been expanding, so confirm current support rather than assuming a service is included. - **The management account is exempt from RCPs too**, exactly as it is from SCPs. - **RCPs do not replace resource policies.** They subtract; something still has to grant the access in the first place. - **They interact with SCPs, not instead of them.** A request from inside your organization to a resource inside your organization has to clear both ceilings. ## When to reach for which Use an **SCP** when the sentence starts with "nobody in our accounts may…": no resources outside these regions, nobody may disable the trail, nobody may leave the organization. Use an **RCP** when the sentence starts with "nothing may be done to our resources unless…": unless the caller is in this organization, unless the connection used TLS, unless the request came through our expected path. That second family is a **data perimeter** — the class of control that keeps your data from being read by identities you do not manage, and keeps your identities from writing your data into places you do not own. In an interview, the crisp version is one line: an SCP is a ceiling on your identities, an RCP is a ceiling on your resources, and only the second one reaches callers you do not control.

  • Why does the example RCP include a condition on whether the caller is an AWS service?
    Because AWS services legitimately access your resources on your behalf — a log delivery writing into your bucket, for instance — and those calls are not made by a principal in your organization. Without exempting them, an organization-wide deny quietly breaks service integrations, and the failures surface far away from the policy you just attached.
  • Does an RCP remove the need to write correct bucket policies?
    No. An RCP only subtracts; the access still has to be granted by the resource policy or by IAM. What it does is make a mistake in an individual bucket policy non-fatal, because the organization-level ceiling still refuses callers outside your perimeter. It is a backstop for the failure mode of one bucket being wrong, not a replacement for getting them right.
  • Which policy type would you use to stop your own principals writing data into a bucket outside the company?
    That is the principal side, so an SCP — a Deny on write actions conditioned on the target resource not belonging to your organization. The RCP protects your resources from outside identities; the SCP protects against your identities reaching outside resources. A complete data perimeter needs both directions, which is why the two policy types are usually designed together.

saying these in an interview costs you the question

  • Thinks an SCP can restrict principals from other organizations
  • Believes an RCP grants access to a resource
  • Assumes RCPs cover every AWS service
  • Omits the AWS-service exemption and breaks integrations
  • Says RCPs replace bucket and key policies

context

resolving links…