Multi-account governance on AWS has always been told as a story about principals: Service Control Policies (SCPs) set the maximum permissions an IAM user or role in your organization can ever have, no matter how generous their identity policy is. That half of the story is well understood, and it is exactly what the AWS Certified Solutions Architect - Professional (SAP-C02) exam probes in Domain 1 when it hands you an organizational-complexity scenario.
But there is a second half that trips up even experienced architects. SCPs cap what your people can do. They say nothing about what can be done to your resources — by a misconfigured bucket policy, a forgotten cross-account role, or a third party you shared a KMS key with years ago. Closing that gap is the job of Resource Control Policies (RCPs), and together SCPs and RCPs are the two org-wide guardrails that let you build a data perimeter: a provable boundary that says only my identities, only my resources, only my networks. This guide is the resource-side companion to the SAP-C02 multi-account architecture guide, which owns the SCP and landing-zone fundamentals — here we focus on the perimeter model the exam’s data-protection scenarios are really testing.
Two Sides of Every Request
Every AWS API call has two ends, and each end has an owner who can constrain it:
- The principal end — the IAM identity making the request. Its ceiling is set by its identity policy, any permissions boundary, and, org-wide, the SCP attached to its account or OU.
- The resource end — the thing being acted on (an S3 bucket, a KMS key, a queue). Its ceiling is set by the resource-based policy and, org-wide, the RCP attached to the resource owner’s account or OU.
For years AWS only gave you an org-wide control on the principal end. If you wanted to guarantee that no one outside your organization could read an S3 bucket, your only tool was the bucket policy — and a bucket policy lives on a single resource, can be edited by anyone with the permission, and has to be correct on every one of thousands of buckets. RCPs move that guarantee up to the organization, where it is central, tamper-resistant, and applies to every current and future resource in scope.
Signal words: “regardless of the resource policy”, “even if a bucket policy is misconfigured”, “prevent any external principal”, “organization-wide, on all buckets” → you are being asked for an RCP, not a resource policy and not an SCP.
Service Control Policies: Guardrails on Your Principals
A quick refresher, since RCPs mirror them exactly. SCPs:
- Attach to the root, an OU, or an account in AWS Organizations.
- Set the maximum permissions for principals in those accounts — they never grant anything.
- Are evaluated as a filter: effective permission = identity policy ∩ SCP. An action must be allowed by both.
- Follow the universal rule that an explicit
Denyalways wins. - Ship with a default
FullAWSAccesspolicy so attaching an OU changes nothing until you add restrictions.
The classic SCP question — “an administrator with AdministratorAccess still can’t launch resources in ap-south-1; why?” — is answered by a region-restriction SCP. For the full set of SCP design patterns, see the multi-account architecture guide and the SAP-C02 security and compliance scenarios.
Resource Control Policies: The Missing Half
RCPs are the resource-side counterpart, and if you already understand SCPs you already understand RCPs — just point the mental model at the resource instead of the principal:
- They attach to the root, an OU, or an account, exactly like SCPs.
- They set the maximum permissions available on resources owned by those accounts — they never grant access.
- They apply to a request no matter where the principal comes from — an IAM role in the same account, a role in another account, or a principal in a completely different organization. This is the crucial difference: an SCP can only constrain principals inside your org; an RCP constrains what happens to your resources even when the caller is a stranger.
- They ship with a default
RCPFullAWSAccesspolicy, so attaching an OU changes nothing until you add restrictions. - At launch they cover a focused set of services — including Amazon S3, AWS STS, AWS KMS, Amazon SQS, and AWS Secrets Manager — with more added over time. This matters on the exam: RCPs are the right answer for data-bearing services, and you should know the service is supported before you reach for one.
Here is the SCP-vs-RCP distinction the exam rewards, side by side:
| Service Control Policy (SCP) | Resource Control Policy (RCP) | |
|---|---|---|
| Constrains | What principals in your org can do | What can be done to resources in your org |
| The “ceiling” is on | The identity | The resource |
| Affects principals outside your org? | No — only your org’s principals | Yes — any caller touching your resource |
| Grants permission? | Never (guardrail only) | Never (guardrail only) |
| Default policy | FullAWSAccess | RCPFullAWSAccess |
| Typical use | Restrict regions, services, root user | Enforce “only my org’s principals” on data |
The Data Perimeter: Three Questions, Three Perimeters
A data perimeter is a set of org-wide guardrails that answers three questions about every request touching your data. Each question maps to one perimeter, one primary policy type, and one or two global condition keys. This table is the spine of the whole topic — memorize it and most scenarios answer themselves:
| Perimeter | The question it answers | Primary control | Key condition keys |
|---|---|---|---|
| Identity | Only trusted identities can access my resources | RCP | aws:PrincipalOrgID, aws:PrincipalIsAWSService |
| Resource | My identities can only access trusted resources | SCP | aws:ResourceOrgID |
| Network | My resources are only reached from expected networks | RCP / SCP / VPC endpoint policy | aws:SourceVpc, aws:SourceVpce, aws:ViaAWSService |
Notice the symmetry: the identity perimeter and resource perimeter are mirror images. One uses an RCP to check who the principal belongs to when they touch your resource; the other uses an SCP to check who owns the resource when your principal reaches out. The network perimeter then constrains where the request came from.
Building Each Perimeter
Identity Perimeter (RCP)
Goal: nobody outside your organization can touch your data, no matter what a resource policy says. Attach an RCP that denies any access whose principal is not in your org and is not an AWS service:
{
"Version": "2012-10-17",
"Statement": [{
"Sid": "EnforceOrgIdentities",
"Effect": "Deny",
"Principal": "*",
"Action": ["s3:*", "sqs:*", "kms:*"],
"Resource": "*",
"Condition": {
"StringNotEqualsIfExists": { "aws:PrincipalOrgID": "o-myorg123" },
"BoolIfExists": { "aws:PrincipalIsAWSService": "false" }
}
}]
}The aws:PrincipalIsAWSService guard is essential — without it you would break legitimate AWS service access (logging to your bucket, for example). The ...IfExists operators keep the condition from misfiring when a key is absent.
Resource Perimeter (SCP)
Goal: your principals can only read and write resources your organization owns — a direct block on exfiltration to a personal or third-party account. This one is an SCP, because you are constraining your principals:
{
"Version": "2012-10-17",
"Statement": [{
"Sid": "EnforceOrgResources",
"Effect": "Deny",
"Action": ["s3:GetObject", "s3:PutObject"],
"Resource": "*",
"Condition": {
"StringNotEqualsIfExists": { "aws:ResourceOrgID": "o-myorg123" },
"BoolIfExists": { "aws:PrincipalIsAWSService": "false" }
}
}]
}This is the guardrail that answers the perennial scenario “stop employees from copying company data into their own personal S3 buckets.” An IAM policy on each user is easy to forget; an SCP with aws:ResourceOrgID closes the door for every principal in the OU at once.
Network Perimeter
Goal: your data is only reached over expected network paths — your VPCs, your VPC endpoints, or by an AWS service acting on your behalf. Enforce it with an RCP (to protect the resource) or an SCP (to constrain the principal), using network condition keys:
"Condition": {
"StringNotEqualsIfExists": {
"aws:SourceVpc": ["vpc-aaa", "vpc-bbb"]
},
"BoolIfExists": { "aws:ViaAWSService": "false" },
"NotIpAddressIfExists": { "aws:SourceIp": ["203.0.113.0/24"] }
}The network perimeter is also where VPC endpoint policies earn their place — they constrain which principals and resources can be reached through a specific interface or gateway endpoint. For the endpoint mechanics, the SAP-C02 networking deep dive covers gateway vs interface endpoints and PrivateLink in full.
How a Request Is Actually Evaluated
Under time pressure, the exam wants you to know the order in which these controls combine. A request to act on a resource succeeds only if every applicable check allows it and nothing explicitly denies it:
- Is there an explicit
Denyanywhere — identity policy, resource policy, SCP, RCP, permissions boundary, or session policy? If yes, the request is denied. Deny always wins. - Does an SCP (and permissions boundary / session policy, if present) allow the action for the principal? If not, denied.
- Is the action granted by an identity-based policy or a resource-based policy? If neither grants it, denied.
- Does an RCP allow the action on the resource? If not, denied.
The principal side (steps 2–3, identity policy + SCP) and the resource side (steps 3–4, resource policy + RCP) are evaluated together. The mental shortcut: SCP + identity policy gate the caller; RCP + resource policy gate the resource; a deny anywhere ends it.
Signal words: “even though the IAM policy allows it”, “the bucket policy grants access but the request still fails” → look for a guardrail (SCP or RCP) or an explicit deny higher up the chain.
Mapping Exam Scenarios to the Right Control
This is where points are won. Read the intent of the scenario and pick the perimeter:
| Scenario | Right control |
|---|---|
| ”No principal outside our org may read our S3 data, regardless of bucket policy.” | RCP — identity perimeter (aws:PrincipalOrgID) |
| “Employees must not upload data to buckets we don’t own.” | SCP — resource perimeter (aws:ResourceOrgID) |
| “Our KMS keys must only be usable from our VPCs.” | RCP / VPC endpoint policy — network perimeter |
| ”Block all use of a specific region across every account.” | SCP — principal guardrail (aws:RequestedRegion) |
| “Prevent the root user in member accounts from taking an action.” | SCP — the only control that binds root |
| ”Guarantee it on all current and future buckets, centrally.” | RCP at the OU (not per-bucket policies) |
The recurring trap is choosing a resource policy (a bucket policy, a key policy) when the scenario says organization-wide or regardless of the resource configuration. A single resource policy can be edited, can be forgotten on a new resource, and can’t express “everyone in my org.” An RCP at the OU is central, inherited by new accounts, and tamper-resistant — that is why it wins those questions.
Common Traps
- Confusing which side an SCP protects. An SCP can never stop an external principal from touching your resource — it only constrains principals in your org. That is precisely the gap RCPs fill.
- Forgetting the
aws:PrincipalIsAWSServiceexception. A blunt “deny all non-org principals” RCP will break legitimate AWS service access (log delivery, replication). Always allow the service path. - Assuming guardrails grant access. Neither SCPs nor RCPs ever grant a permission. You still need an identity or resource policy that allows the action; the guardrail only sets the ceiling.
- Reaching for an RCP on an unsupported service. RCPs cover a growing but finite set of (mostly data-bearing) services. If the service isn’t supported, the answer is an SCP, a resource policy, or a network control.
- Ignoring the default policy.
RCPFullAWSAccess, likeFullAWSAccessfor SCPs, means attaching the policy set to an OU does nothing until you add explicit restrictions.
Where Practice Makes the Difference
The data perimeter is a reasoning topic: the exam rarely asks you to recite a condition key, but it constantly asks you to read a five-line scenario and pick the control that enforces the intent org-wide. That reflex is built by drilling scenarios, not by re-reading policy syntax. The Sailor.sh SAP-C02 mock exam bundle is built around exactly these organizational-complexity and data-protection scenarios, with explanations that reinforce why an RCP beats a bucket policy or why the resource perimeter is an SCP. Gauge where you stand first with the free SAP-C02 practice questions with answers, then reinforce the governance foundations with the multi-account architecture guide and identity federation and centralized access.
Frequently Asked Questions
What is the difference between an SCP and an RCP?
An SCP sets the maximum permissions for principals (IAM users and roles) in your organization’s accounts — it constrains what your people can do. An RCP sets the maximum permissions available on resources in your organization’s accounts — it constrains what can be done to your data, including by principals outside your organization. They are mirror images: SCPs guard the caller, RCPs guard the resource. Both are guardrails that never grant access, and both honor an explicit Deny.
Do Resource Control Policies grant access?
No. Like SCPs, RCPs only set a ceiling. A request still needs an identity-based or resource-based policy that allows the action; the RCP simply defines the maximum that is permitted on the resource. If nothing grants the action, it is denied regardless of the RCP.
What is a data perimeter on AWS?
A data perimeter is a set of organization-wide guardrails ensuring that only trusted identities can access your resources (identity perimeter), your identities can only access trusted resources (resource perimeter), and access happens only over expected networks (network perimeter). It is built from SCPs, RCPs, VPC endpoint policies, and resource-based policies, using global condition keys such as aws:PrincipalOrgID, aws:ResourceOrgID, and aws:SourceVpc.
Which condition key blocks access from outside my organization?
Use aws:PrincipalOrgID in an RCP to deny any principal that does not belong to your organization — this builds the identity perimeter. Use aws:ResourceOrgID in an SCP to stop your principals from reaching resources your organization does not own — the resource perimeter. Pair both with aws:PrincipalIsAWSService so you don’t accidentally block legitimate AWS service access.
Can an SCP stop a third party from accessing my S3 bucket?
No. An SCP only constrains principals inside your own organization, so it cannot govern a request made by an external principal. To guarantee that no external principal can access your bucket — regardless of the bucket policy — attach an RCP with an aws:PrincipalOrgID condition at the OU or account level. That is the specific gap RCPs were created to close.
Why use an RCP instead of just a bucket policy?
A bucket policy lives on one resource, can be modified by anyone with the permission, and must be correct on every bucket you ever create. An RCP applies org-wide, is inherited by new accounts and resources automatically, and can only be changed by your organization’s management or a delegated administrator — making it central, scalable, and tamper-resistant. For an org-wide guarantee, the RCP is the durable control.
Conclusion
For the SAP-C02, hold three ideas in reflex. First, every request has a principal side and a resource side: SCPs and identity policies gate the caller, RCPs and resource policies gate the resource, and an explicit Deny anywhere ends the request. Second, the data perimeter answers three questions — trusted identities (RCP, aws:PrincipalOrgID), trusted resources (SCP, aws:ResourceOrgID), and expected networks (aws:SourceVpc and friends). Third, when a scenario says organization-wide or regardless of the resource policy, reach for a guardrail — usually an RCP — not a per-resource policy. Master that mapping and the exam’s data-protection and organizational-complexity questions stop being puzzles and start being pattern recognition.