AWS Builder Center

Builder Center

AWS Organizations: SCP vs RCP vs Permission Boundaries : Which Lever to Pull

AWS Organizations: SCP vs RCP vs Permission Boundaries : Which Lever to Pull

Most AWS teams deploy SCPs and assume their data is protected, but SCPs only constrain principals inside your organisation, leaving resources exposed to external access entirely. This guide breaks down how SCPs, RCPs, and IAM Permission Boundaries each operate at a different layer of the AWS access model, where each one fails, and how to layer all three into a defence-in-depth posture that actually holds up in a real multi-account environment.

Samuel Ajisafe

Introduction

AWS gives you three distinct mechanisms to restrict what IAM principals can do and what your resources will accept. Most teams only reach for one of them, and pick the wrong one for the job at least half the time.
Service Control Policies (SCPs), Resource Control Policies (RCPs), and IAM Permission Boundaries are not interchangeable tools. They exist at different layers of the AWS authorisation model, they solve different problems, and deploying the wrong one against a given threat does not make you safer; it just gives you the false confidence that you are protected when you are not.
This article is a practitioner's guide to all three. By the end, you will know what each control does, where each one falls short, when to reach for one over another, and how to layer all three into a robust, defence-in-depth posture for a real AWS multi-account environment.

How AWS Evaluates Access: The Layered Model

Before diving into each mechanism, it is worth understanding the order in which AWS evaluates access decisions, because this directly affects what happens when policies conflict.
When any principal makes an API call to AWS, the evaluation chain looks like this:
  1. Explicit Deny in any policy: immediately blocks the request
  2. RCP evaluation: does the resource's organisation allow this caller?
  3. SCP evaluation: does the principal's organisation allow this action?
  4. Resource-based policy: does the resource itself grant access?
  5. Identity-based policy: does the principal's own IAM policy allow it?
  6. Permission Boundary: does the boundary cap the principal's effective permissions?
  7. Session policy: if using temporary credentials, does the session scope allow it?
A single Deny at any layer is final. All applicable layers must allow the action for the request to succeed. This is the foundation on which SCPs, RCPs, and Permission Boundaries each play a role.

Service Control Policies (SCPs)

What They Are

SCPs are organisational guardrails applied through AWS Organizations. They define the maximum permissions available to all IAM principals within an AWS account, including the account root user. They do not grant permissions; they set the ceiling on what can ever be allowed.
SCPs can be attached at three levels: the organisation root, an Organisational Unit (OU), or an individual account. A policy attached at the root applies to every account in the organisation. A policy attached to an OU applies to every account within that OU and any nested OUs beneath it.
One critical limitation: SCPs do not apply to the management account. This is an AWS constraint, not a configuration choice. The management account always has full access regardless of any SCP. This is why AWS strongly recommends keeping the management account empty of workloads.

How They Work

SCPs use the same IAM policy language as regular identity-based policies. AWS supports two strategies:
Allow-list (restrictive by default): You explicitly allow only the services and actions you permit. Everything not listed is implicitly denied. This is stricter but more maintenance-heavy as your cloud footprint grows.
Deny-list (permissive by default): AWS provides a FullAWSAccess managed SCP that allows everything, and you layer explicit Deny statements on top. New AWS services are automatically available to accounts without policy changes. This is the more scalable approach for most organisations.
As of September 2025, AWS introduced full IAM policy language support for SCPs, enabling conditions in Allow statements, individual resource ARNs in Deny statements, and NotAction with Allow. This opened the door to significantly more precise, attribute-based SCPs.

What SCPs Protect Against

SCPs are the right control when you need to prevent your own identities from doing something they should never be allowed to do, regardless of what their IAM policies say. Classic examples:
  • Preventing any principal in any account from disabling AWS CloudTrail
  • Blocking the creation of IAM access keys (forcing IAM Identity Center usage instead)
  • Restricting workloads to approved AWS regions
  • Denying any action that would leave an account without a root MFA
  • Preventing accounts from leaving the organisation

Scenario: Region Restriction Gone Wrong

A team at a financial services organisation applied a region-restriction SCP to lock workloads to eu-west-1 and eu-central-1. Three days later, the network team could no longer manage CloudFront distributions. Route 53 records stopped updating. IAM role changes began failing.
The reason: IAM, CloudFront, Route 53, AWS WAF (global), and AWS Support are global services; they do not operate in a specific region, and a region-restriction SCP that does not use NotAction to exempt these services will break them silently.
The correct pattern uses aws:RequestedRegion in a condition on a Deny statement, combined with NotAction to exclude global services:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
{
"Effect": "Deny",
"NotAction": [
"iam:*",
"organizations:*",
"route53:*",
"cloudfront:*",
"waf:*",
"support:*",
"sts:*"
],
"Resource": "*",
"Condition": {
"StringNotEquals": {
"aws:RequestedRegion": ["eu-west-1", "eu-central-1"]
}
}
}

Where SCPs Cannot Help You

This is the most important thing to understand about SCPs, and the most commonly missed:
SCPs only restrict principals within your AWS organisation. They cannot stop an external principal from accessing your resources.
If a misconfigured S3 bucket policy grants access to an external AWS account, an SCP in your organisation has zero effect on that external account. The SCP only constrains your own users and roles. An attacker who has obtained credentials from an account outside your organisation, or who is exploiting a public bucket policy, is not subject to your SCPs at all.
This is the precise gap that RCPs were built to fill.

Resource Control Policies (RCPs)

What They Are

RCPs are the newer sibling of SCPs, introduced by AWS in November 2024. Where SCPs constrain principals, RCPs constrain resources. An RCP defines the maximum permissions available for resources within an AWS account, regardless of who is calling.
Think of SCPs as a leash on your people, and RCPs as a lock on your doors. The leash only holds the people inside your organisation. The lock works on anyone who tries to come through the door, from anywhere.

Current Coverage

RCPs currently support 44 service entries, including:
  • Amazon S3
  • AWS KMS
  • AWS STS
  • Amazon SQS
  • AWS Secrets Manager
  • Amazon DynamoDB
  • Amazon CloudWatch Logs
  • Amazon ECR
  • Amazon EventBridge
  • AWS WAF
This is narrower than the scope of SCPs, which apply to all AWS services. For services not covered by RCPs, SCPs remain the only organisational guardrail.

The Data Perimeter Framework

AWS's official data perimeter whitepaper describes a three-layer model for securing cloud access. RCPs are central to two of those three layers:
Identity Perimeter (using RCPs): Ensures that only trusted identities (principals belonging to your AWS organisation) can access your resources. The key condition is aws:PrincipalOrgID, which validates that the calling principal is part of your organisation before allowing access.
Network Perimeter (using RCPs and SCPs): Ensures that requests originate from expected networks. Conditions like aws:SourceVpc and aws:SourceIp enforce this at the resource level.
Resource Perimeter (using SCPs): Ensures that your principals only access trusted resources, specifically those belonging to your own organisation.

Scenario: The S3 Exfiltration an SCP Cannot Stop

This is one of the most common real-world gaps in AWS security posture.
An organisation has mature SCPs in place. No principal in their accounts can disable CloudTrail. No one can create unencrypted S3 buckets. Region-based access is locked down. The security team is confident.
Then a developer in account 111111111111 accidentally writes a bucket policy that grants s3:GetObject to * (all principals). A security researcher scans the internet, finds the bucket, and exfiltrates data. The attacker is never subject to any SCP in your organisation. They are external.
An RCP would have caught this. The policy below, attached at the organisation root, ensures that no S3 bucket in any member account can be accessed by a principal outside the organisation:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "EnforceOrgIdentityPerimeter",
"Effect": "Deny",
"Principal": "*",
"Action": "s3:*",
"Resource": "*",
"Condition": {
"StringNotEqualsIfExists": {
"aws:PrincipalOrgID": "o-xxxxxxxxxxxx"
},
"BoolIfExists": {
"aws:PrincipalIsAWSService": "false"
}
}
}
]
}
Note the aws:PrincipalIsAWSService exception. AWS service principals (cloudtrail.amazonaws.com, lambda.amazonaws.com, config.amazonaws.com) are not IAM principals in your organisation, and without this exception, your own AWS services acting on your behalf would be denied. This is one of the most common mistakes when first implementing RCPs.

What RCPs Cannot Do That SCPs Can

RCPs cannot prevent your own principals from taking actions that are not resource-access actions. If you want to prevent a principal in your organisation from disabling GuardDuty, changing Config rules, or creating IAM access keys, none of those are controlled by RCPs. Those are actions on services, not access patterns on resources that external entities are trying to reach. SCPs handle those.

IAM Permission Boundaries

What They Are

Permission Boundaries operate at a completely different level from SCPs and RCPs. They are not organisational controls; they are per-principal controls. A Permission Boundary is an IAM managed policy that, when attached to a role or user, defines the maximum permissions that principal can ever use, regardless of what their identity-based policies grant.
The boundary does not grant anything. It only restricts. The effective permissions of a principal are always the intersection of the identity-based policy and the Permission Boundary; whichever is more restrictive wins.

The Delegated Administration Pattern

The canonical use case for Permission Boundaries is delegated IAM administration, specifically the problem of allowing developer teams to create IAM roles for their applications without giving them the ability to escalate their own privileges.
Without boundaries, the moment a developer can create IAM roles, they can create a role with AdministratorAccess and assume it, bypassing whatever permissions they were originally given. This is the privilege escalation problem.
With a Permission Boundary, the central security team defines a managed policy that represents the maximum permissions any application role should ever have. For example, access to specific S3 buckets, CloudWatch Logs, and SQS queues, but nothing beyond that. The security team then uses an SCP to require that any role created by developers must attach this boundary:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
{
"Effect": "Deny",
"Action": [
"iam:CreateRole",
"iam:PutRolePolicy",
"iam:AttachRolePolicy"
],
"Resource": "*",
"Condition": {
"StringNotEquals": {
"iam:PermissionsBoundary": "arn:aws:iam::111111111111:policy/ApplicationBoundary"
}
}
}
Critically, the security team also adds explicit denies to prevent the boundary from being removed or replaced:
1
2
3
4
5
6
7
8
{
"Effect": "Deny",
"Action": [
"iam:DeleteRolePermissionsBoundary",
"iam:PutRolePermissionsBoundary"
],
"Resource": "*"
}
Without this protection, a developer could simply remove the boundary after creating the role, defeating the entire purpose.

Scenario: CI/CD Pipeline with Scoped Role Creation

A fintech platform team wants to enable each product team to manage their own IAM roles for their microservices. The security posture requirement is that no application role created by product teams can ever touch the core banking data: an Aurora database, a KMS key, and an SQS queue that handles transaction messages.
The security team creates a Permission Boundary named ProductTeamApplicationBoundary that allows:
  • s3:* on buckets prefixed with the team name
  • cloudwatch:* and logs:* for observability
  • ssm:GetParameter scoped to the team's parameter path
  • sqs:SendMessage, sqs:ReceiveMessage, sqs:DeleteMessage on team-owned queues
Explicitly, the boundary does NOT include:
  • Any KMS actions
  • Any RDS or Aurora API calls
  • Any IAM actions
  • Any sqs:* on the core transaction queue
Product teams can now create application roles freely within their CI/CD pipelines. Any attempt to create a role that could access core banking infrastructure either fails (because the boundary is required by SCP) or silently has no effect (because the boundary caps permissions below what any identity policy tries to grant).

Technical Constraints

  • Maximum of one Permission Boundary per IAM principal; you cannot stack them
  • Boundaries must be managed policies; inline policies are incompatible
  • Maximum boundary size: 6,144 characters
  • Boundaries apply only to roles and users, not to groups
  • Boundaries have no effect on resource-based policies or session policies

Choosing the Right Lever: A Decision Framework

When you need to add a restriction, the following questions narrow it down:
1. Is the threat coming from outside your AWS organisation? An external principal trying to access your resources, a misconfigured resource policy that is too permissive, a public S3 bucket, a Secrets Manager secret with a broad resource policy: these are RCP problems. SCPs cannot help here.
2. Is the threat coming from your own principals acting beyond their role? Principals in your accounts trying to do things they should never be allowed to do: disable logging, change billing settings, leave the organisation, create unencrypted resources, deploy to unapproved regions: these are SCP problems.
3. Are you delegating IAM management and need to cap what those delegated administrators can grant? Developer teams creating roles for their own applications, CI/CD pipelines that need limited IAM permissions, team-level autonomy with central guardrails: these are Permission Boundary problems.
4. Do you need a data perimeter? Use all three. SCPs prevent your principals from accessing untrusted resources (aws:ResourceOrgID). RCPs prevent external principals from accessing your resources (aws:PrincipalOrgID). Permission Boundaries prevent delegated admins from granting application roles access beyond their scope.

The Common Mistake That Keeps Coming Up

The single most frequent error encountered in cloud security reviews is this: using an SCP where an RCP is the right answer.
A team discovers that S3 buckets in their accounts could theoretically be made public by a misconfigured bucket ACL. They write an SCP that denies s3:PutBucketAcl across all accounts. This is correct and useful.
But they then believe their data is protected from external access. It is not.
If a developer writes a bucket policy that grants access to a specific external AWS account (perhaps a contractor's account that is no longer in use) the SCP will not block that external account from reading the bucket. The SCP applies to principals inside the organisation. The contractor is outside. The data is exposed.
The RCP identity perimeter policy, attached at the root, would catch this. Any access attempt by a principal whose aws:PrincipalOrgID does not match the organisation's ID would be denied, regardless of what the bucket policy says.
The defence is SCP plus RCP, not SCP alone.

Real Incidents and What the Controls Would Have Done

Capital One (2019)

A SSRF vulnerability in a misconfigured WAF allowed an attacker to query the EC2 metadata service from within a container, retrieve temporary IAM credentials, and use those credentials to enumerate and download over 100 million customer records from S3.
What SCPs could have done: Enforcing IMDSv2 (http_tokens = required) as an organisational invariant would have blocked the metadata service credential theft. An SCP using aws:ec2InstanceSourceVPC could have further restricted credential use to within the issuing VPC.
What RCPs could have done: An identity perimeter RCP requiring aws:PrincipalOrgID on all S3 access would not have helped here. The attacker was using credentials belonging to a principal inside the organisation. The attack was an insider-credential misuse, which is an SCP and network perimeter problem.

The External Contractor Scenario

A consulting firm finishes a six-month engagement with a retail company. Their AWS account is decommissioned, but the retail company's S3 bucket policy still contains a statement granting s3:GetObject to the consulting firm's account.
Three months later, the consulting firm's account is acquired by a competitor. The old trust policy is still active.
An SCP cannot help because the competitor's account is not in the retail company's organisation.
An RCP identity perimeter policy with aws:PrincipalOrgID would have denied all access from the consulting firm's account the moment their engagement ended, regardless of the bucket policy. No manual cleanup required. The perimeter is self-enforcing.

Implementation Checklist for a Mature Posture

Foundation (implement first):
  • [ ] Enable AWS Organizations with all member accounts
  • [ ] Attach FullAWSAccess as the base SCP (deny-list approach)
  • [ ] Deploy CloudTrail organisation trail (one trail, all accounts)
  • [ ] Enable AWS Config across all accounts
SCP baseline:
  • [ ] Deny CloudTrail disable/delete
  • [ ] Deny GuardDuty disassociation
  • [ ] Deny unapproved region usage (with global service exceptions)
  • [ ] Deny IAM access key creation (enforce Identity Center)
  • [ ] Deny root user activity except break-glass
  • [ ] Deny leaving the organisation
RCP data perimeter:
  • [ ] Deploy identity perimeter RCP (aws:PrincipalOrgID) at root for S3
  • [ ] Extend RCP to KMS, Secrets Manager, SQS as scope permits
  • [ ] Add aws:PrincipalIsAWSService exception for service principals
  • [ ] Test with IAM Access Analyzer before production rollout
Permission Boundaries for delegated teams:
  • [ ] Define team-level boundary managed policies
  • [ ] Add SCP requiring boundary attachment on role creation
  • [ ] Add explicit deny for boundary deletion/modification
  • [ ] Apply to CI/CD pipeline roles
Monitoring:
  • [ ] Alert on CloudTrail Deny events matching SCP/RCP denials
  • [ ] Run IAM Access Analyzer on all accounts quarterly
  • [ ] Review SCP deny logs monthly for false positives

Summary Table

DimensionSCPRCPPermission Boundary
ControlsPrincipals (who can act)Resources (what can be accessed)Individual principal ceiling
ScopeOU / Account levelOU / Account levelSingle IAM role or user
Blocks external accessNoYesN/A
Applies to management accountNoNoN/A
Grants permissionsNoNoNo
Use forOrg-wide invariantsData perimeterDelegated admin
Introduced2017November 20242018
AWS service coverageAll services44 service entriesAll services
Max size10,240 characters5,120 characters6,144 characters

Closing Thoughts

None of these controls are optional in a serious cloud security posture. SCPs are the most mature and widely adopted, but teams that stop there have left the resource-side door unlocked. RCPs close that door, and their coverage will expand as AWS continues to add supported services. Permission Boundaries are the mechanism that makes organisational self-service possible without sacrificing governance.
The question is never "which one do I need?" The answer is almost always all three, layered, with each one solving the specific problem it was designed for.
The team that configures all three correctly does not just have a better security posture; they have one that can be explained, audited, and defended. And in a well-run cloud organisation, that explainability is as important as the control itself.
# security-best-practices# security# cloud-security# iam# devops
Any opinions in this article are those of the individual author and may not reflect the opinions of AWS.
Enjoyed reading this content? Let the author know!

Your likes, comments, shares, and saves help creators reach more builders.

Loading recommendations

Loading article