AWSDOP-C02
On this page
Beginner-friendly overview

SCP

SCPs are guardrails applied at the AWS Organizations level. They set the maximum permissions any identity in an account (or group of accounts) can have — regardless of what IAM policies say. Think of them as a permission ceiling: even if a user has AdministratorAccess, an SCP can prevent them from doing anything outside the boundaries you define.

IAM Grants; SCP Limits

The key mental model: IAM policies grant permissions; SCPs limit the maximum permissions that can be exercised. For an action to succeed, both the IAM policy must allow it AND the SCP must allow it (or at least not deny it).

This matters for the management layer. Even the most powerful IAM user in a member account cannot delete CloudTrail logs if an SCP in the parent organizational unit denies cloudtrail:DeleteTrail. SCPs are enforced before IAM evaluation and cannot be overridden by anything in the account.

SCP inheritance funnel: effective permissions = the INTERSECTION down the chain Org Root — SCP: FullAWSAccess + Deny outside approved regions broadest guardrails apply to everything below OU: Workloads — SCP: Deny rds:DeleteDBInstance adds restrictions — can never re-allow what Root denied Account: prod-app ceiling = approved regions ∩ no RDS deletes Management account SCPs NEVER apply here — it lives outside the funnel The funnel only narrows. And even inside the ceiling, an IAM policy must still grant the action.
SCP = the ceiling, IAM = the ladder. The ladder (an IAM Allow) lifts you up, but never through the ceiling (the SCP). A taller ceiling grants nothing — you still need a ladder. Effective permissions = SCP ∩ IAM, always the intersection. And the management account lives on the roof: no ceiling ever applies to it.

What SCPs Are For

SCPs are the tool for organization-wide, non-negotiable policy. Common uses:

  • Enforce regional restrictions — deny all API calls outside approved regions, so workloads can't accidentally be deployed in unapproved locations
  • Protect security tooling — deny modifications to GuardDuty, Config, CloudTrail, or Security Hub in all member accounts so teams can't disable them
  • Prevent IAM escalation — deny the creation of IAM users or certain high-risk actions in accounts where you want to enforce SSO-only access
  • Enforce tagging — deny resource creation without required tags, so every resource has cost-center and environment metadata

The Organizational Hierarchy

SCPs attach to the root of your organization, to specific Organizational Units (OUs), or to individual accounts. A policy attached to an OU applies to every account in that OU and every child OU beneath it. This hierarchy lets you set broad rules at the root and add specific exceptions at deeper levels.

What SCPs Don't Do

SCPs don't grant permissions — a broad "allow everything" SCP doesn't give an IAM user any permissions they don't already have. They also don't apply to the management account itself (a deliberate AWS decision to prevent accidental lockout). And they have no effect on resource-based policies — an S3 bucket policy allowing public access is not blocked by an SCP.