SCPs vs RCPs: Understanding the Principal from Opposite Directions
If you manage AWS Organizations, you've probably used Service Control Policies (SCPs) to restrict what your teams can do. But in late 2024, AWS introduced Resource Control Policies (RCPs), and the natural question is: how are they different? Don't they both restrict access?
They do. But they look at the problem from opposite directions. Understanding that difference is the key to building a complete data perimeter.
Two Security Guards, Two Jobs
Think of your AWS account as a building. You have people inside (your IAM users and roles) and people outside (external accounts, third parties, the public internet).
An SCP is a security guard watching the people inside. It controls what your own users and roles are allowed to do. Can they launch EC2 instances? Can they use SageMaker? Can they operate in eu-west-1? The SCP sets the boundary.
An RCP is a security guard watching the door from the outside. It controls who can access your resources, regardless of where they come from. Even if a developer accidentally makes an S3 bucket public, the RCP can block external access at the Organization level.
One watches what your people do. The other watches who touches your stuff.
The Fundamental Difference
| Feature | SCP | RCP |
|---|---|---|
| Primary focus | Outbound (the subject) | Inbound (the object) |
| What it restricts | What IAM users/roles in your account can do | Who can access resources in your account |
| Who it affects | Principals inside your Organization only | Any principal, inside or outside your Org |
| Analogy | Parental controls on a phone | A guest list at the front door |
How They Look at the Principal
SCPs ask: "What can my people do?"
SCPs attach to AWS accounts or OUs. They set the maximum permissions for IAM entities within those accounts. The principal is implicitly the user or role inside your organization trying to perform an action. An SCP cannot block an external actor from accessing your S3 bucket if your bucket policy allows it. SCPs only govern your own identities.
RCPs ask: "Who can touch my stuff?"
RCPs let you define a central rule like: "No one outside my Organization ID can access any S3 bucket in these accounts." Unlike SCPs, RCPs can block external principals. Even if a developer sets a bucket to public, the RCP acts as a global guardrail to deny that external access at the Organization level.
This is the gap SCPs couldn't fill. You could restrict your own people all day, but you had no Organization-level control over external access to your resources. RCPs close that gap.
The Authorization Chain
For any action to succeed in AWS, it has to pass through every layer:
- SCP: Does the Organization allow this user to perform this action?
- RCP: Does the Organization allow this resource to be accessed by this principal?
- IAM Policy: Does the user have permission?
- Resource Policy: Does the bucket/key/secret allow the user?
If any of these contains a Deny, the request is blocked. They're layered, not competing. Each one adds a check that the others don't cover.
When to Use Which
Use SCPs when you want to stop your developers from using expensive services (like SageMaker), operating in unapproved regions, or performing actions that violate your governance policies. SCPs control what your people can do.
Use RCPs when you want to ensure your data stays within your data perimeter, regardless of who tries to access it from outside. RCPs control who can touch your stuff.
Use both when you want a complete data perimeter. SCPs are the leash on your own identities. RCPs are the lock on your own resources. One without the other leaves a gap.
The Mental Model
SCPs are the leash on your own identities. RCPs are the lock on your own resources. You need both to build a complete data perimeter.