AWS SCPs vs RCPs: Multi-Account Security Guardrails

Service control policies (SCPs) and resource control policies (RCPs) are AWS Organizations guardrails that set the maximum permissions allowed in your member accounts. SCPs limit what your own IAM users and roles can do, while RCPs limit what anyone, including principals outside your organization, can do to your resources. Neither one grants access on its own.

If you run more than one AWS account, these two policy types are the backbone of a secure multi-account strategy. This guide explains how they work, how they differ, which guardrails to start with, and how to roll them out without locking your own teams out of production.

Why multi-account security needs organization-level guardrails

IAM policies live inside a single account. That works well until you have dozens of accounts owned by different teams, each with its own administrators. Any admin with AdministratorAccess can disable logging, open a bucket to the internet, or spin up workloads in a region you never approved.

Organization policies solve this by moving the ceiling above the account. Even an account administrator cannot exceed what the organization allows. According to the AWS Organizations documentation on SCPs, if a permission is blocked at any level above an account, a user or role in that account cannot use it, even with full admin permissions attached.

This is least privilege applied at scale, and it is a core skill for anyone working toward a cloud security role. If you are new to the underlying concepts, start with our guide to cloud IAM fundamentals across AWS, Azure, and GCP.

How SCPs work

An SCP defines the maximum available permissions for IAM users and roles in member accounts. Key behaviors to understand:

• SCPs never grant permissions. A user still needs an identity-based or resource-based policy that allows the action.
• Effective permissions are an intersection. An action must be allowed by the SCPs at every level above the account and by the IAM policies in the account.
• The member account root user is affected. SCPs restrict root in member accounts, which makes them one of the few controls that can limit root.
• The management account is not affected. SCPs do not restrict users or roles in the management account, which is why you should keep workloads out of it.
• Service-linked roles are exempt. AWS services must be able to act on your behalf, so SCPs do not restrict service-linked roles.

SCPs attach to the organization root, to organizational units (OUs), or to individual accounts, and they inherit downward. By default, every entity has the AWS managed FullAWSAccess policy attached. Do not remove it unless you replace it with another allow policy, or every action in affected member accounts will fail.

How RCPs work

RCPs are the newer, resource-focused counterpart. They set the maximum permissions available on resources in your member accounts, no matter who is making the request. That includes principals from other AWS accounts outside your organization.

This closes a gap that SCPs cannot cover. An SCP only restricts principals that belong to your organization. If a bucket policy in one of your accounts accidentally grants access to an external account, the SCP does nothing to stop that external principal. An RCP can.

Important RCP details from the AWS RCP documentation:

• RCPs apply to a defined list of services, including Amazon S3, AWS KMS, AWS Security Token Service (STS), Amazon SQS, and AWS Secrets Manager, among others. Check the current list before relying on one.
• Like SCPs, RCPs do not affect resources in the management account and do not restrict service-linked roles.
• RCPs do not apply to AWS managed KMS keys.
• Both SCPs and RCPs require an organization with all features enabled, not just consolidated billing.

SCPs vs RCPs: side-by-side comparison

Feature	Service control policy (SCP)	Resource control policy (RCP)
What it restricts	IAM users and roles in member accounts	Resources in member accounts
Who it affects	Principals inside your organization	Any principal accessing your resources, including external ones
Grants permissions?	No	No
Affects management account?	No	No
Affects service-linked roles?	No	No
Service coverage	Broad	A defined subset of services
Typical use	"Our people can never do X"	"Our data can never be reached by Y"

A simple way to remember it: SCPs protect you from your own identities doing the wrong thing. RCPs protect your resources from the wrong identities, wherever they come from. Together, they form what AWS often describes as a data perimeter.

Starter guardrails worth considering

Every organization is different, so treat these as patterns to evaluate, not policies to paste. Test each one before broad rollout.

SCP guardrails

1. Protect your security tooling. Deny actions that stop, delete, or modify CloudTrail trails, GuardDuty detectors, and AWS Config recorders, except for a dedicated security role. Our guide to AWS GuardDuty threat detection covers why that detection layer must stay on.
2. Restrict regions. Use the aws:RequestedRegion condition key to deny activity outside approved regions. Remember to exempt global services that route through specific regions.
3. Prevent leaving the organization. Deny organizations:LeaveOrganization so an account cannot escape your guardrails.
4. Limit root user activity in member accounts. Deny most actions when the principal is the root user, since daily work should never use root.
5. Block public S3 changes. Deny changes to S3 Block Public Access settings so account admins cannot quietly turn them off.

RCP guardrails

1. Enforce an identity perimeter. Deny access to supported resources unless the calling principal belongs to your organization, using the aws:PrincipalOrgID condition key, with carefully scoped exceptions for AWS services and trusted partners.
2. Require encrypted transport. Deny requests to S3 and other supported services when aws:SecureTransport is false.
3. Protect STS role assumption. Restrict which external principals can assume roles in your accounts, a common path in cross-account attacks.

The identity perimeter is powerful but easy to get wrong. AWS services that access your resources on your behalf, and legitimate third-party integrations, need explicit exceptions. This is exactly why testing matters.

How to roll out guardrails safely

AWS strongly recommends testing SCPs and RCPs before attaching them to the organization root. A practical rollout looks like this:

1. Design your OU structure first. Common patterns separate Security, Infrastructure, Workloads (with Prod and Non-Prod), Sandbox, and Suspended OUs. Guardrails then map naturally to risk.
2. Start with deny-list policies. Keep FullAWSAccess attached and add targeted Deny statements. This is easier to reason about than a strict allow-list.
3. Attach to a test account, then a test OU. Move accounts in small numbers so you can catch breakage early.
4. Watch CloudTrail for AccessDenied errors. CloudTrail shows when a guardrail blocks something, and IAM service last accessed data shows which allowed services are actually used.
5. Version-control your policies. Store SCPs and RCPs as code, review changes through pull requests, and deploy with Terraform, CloudFormation, or AWS Control Tower.
6. Keep a break-glass path. Document how the security team can respond if a guardrail blocks a critical operation, and keep the management account locked down and nearly empty.

Common mistakes to avoid

• Assuming SCPs grant access. They only filter. Missing IAM permissions will still cause denials.
• Running workloads in the management account. Neither SCPs nor RCPs protect it.
• Forgetting service-linked roles and AWS service principals. Overly broad RCP perimeters can break integrations like logging and backups.
• Attaching untested policies at the root. One bad statement can affect every member account at once.
• Hitting size limits. Policies have a maximum size. Consolidate statements rather than stacking many tiny policies.

Where this fits in a cloud security career

Organization-level guardrails show up in real job interviews and on the AWS Certified Security Specialty exam, because they reflect how enterprises actually secure AWS at scale. Explaining the difference between an SCP and an RCP, and designing a data perimeter, signals that you think beyond single-account IAM. See our AWS Security Specialty SCS-C03 exam guide for how these topics connect to certification prep.

At PrimeSec Academy, multi-account governance is taught through hands-on labs where you build OU structures, write and test guardrails, and troubleshoot AccessDenied errors in real AWS environments. Explore the full curriculum to see where it fits in the 20-week program.

Frequently asked questions

Do SCPs grant permissions to IAM users and roles? No. SCPs only set the maximum permissions available in member accounts. Users and roles still need identity-based or resource-based policies that allow an action.

What is the main difference between an SCP and an RCP? An SCP restricts what IAM principals inside your organization can do. An RCP restricts what any principal, including external ones, can do to resources in your member accounts.

Do SCPs and RCPs apply to the management account? No. Neither policy type affects the management account, which is why AWS recommends keeping workloads out of it and tightly controlling access to it.

Can an SCP restrict the root user? Yes. SCPs restrict the root user in member accounts. They do not restrict the management account or service-linked roles.

Which services do RCPs support? RCPs support a defined list of services that includes Amazon S3, AWS KMS, AWS STS, Amazon SQS, and AWS Secrets Manager, among others. Always check the current AWS documentation for the latest list.

How should I test a new guardrail? Attach it to a test account or test OU first, monitor CloudTrail for AccessDenied errors, and expand gradually before attaching it to the organization root.

Build real AWS guardrails, not just theory

Reading about SCPs is a start. Designing, testing, and defending them in a live environment is what employers pay for. PrimeSec Academy's 20-week Cloud and AI Platform Security Engineer program gives you hands-on labs across AWS, Azure, and GCP, 36 portfolio projects, and a defended capstone. Not sure if you are ready? Take the eligibility quiz, or go straight to enroll and start building.