Free — no signup required

Service Control Policies (SCPs): The Organization's Guardrails

2 min read

The Problem at Scale

A company with one AWS account can manage permissions with IAM alone. A company with 200 AWS accounts — one per team, environment, or product — cannot. They need a way to enforce rules across all accounts simultaneously, regardless of what individual account admins do.

AWS Organizations solves this by grouping accounts into a hierarchy of Organizational Units (OUs). Service Control Policies (SCPs) are policies attached to OUs or individual accounts within that hierarchy.

The Critical Distinction: SCPs Filter, They Never Grant

This is the most commonly misunderstood property of SCPs:

  • SCPs do not grant permissions. A user still needs an IAM policy that explicitly allows an action.
  • SCPs define the maximum possible permissions in an account. They are a ceiling, not a floor.

Think of it like a building's master key system. The building manager (SCP) decides which floors each badge type can access. The department manager (IAM policy) decides which specific rooms on those floors an employee can enter. If the building manager says "no access to floor 5," the department manager cannot override that — even if they write "access to all rooms on floor 5" on the employee's badge.

Concrete example:

SCP on account:    Deny s3:DeleteBucket
IAM User Policy:   Allow s3:* (full S3 access)
Effective result:  User can do everything in S3 EXCEPT delete buckets

Common SCP Use Cases

Two patterns show up constantly in production Organizations. The first denies cloudtrail:StopLogging and cloudtrail:DeleteTrail account-wide, so that no identity — not even one with AdministratorAccess — can disable audit logging. The second restricts all activity to a set of approved regions by denying every action whenever the request's region isn't on the approved list.

That second pattern uses NotAction — a subtle but important pattern. Rather than denying a specific action, it denies everything except a named set — in this case IAM, STS, and Support, which are global services that don't have a region. Without that carve-out, the region-restriction SCP would deny the very calls needed to log in, locking everyone out of the account.

Interview Tip

A common interview question: "Can an SCP be used to grant permissions to a user who has no IAM policy?" The answer is no — SCPs only restrict, they never grant. Even if an SCP says "Effect": "Allow" on an action, the user still needs an IAM Identity Policy that also allows it. Both must independently permit the action. This trips up many candidates who conflate SCPs with IAM policies.

This is one of 18 chapters

Get every chapter — Kubernetes, Terraform, SRE, distributed systems, and more — with fast daily review built in.

See pricing