SCP (Service Control Policy)

What is a Service Control Policy?

A Service Control Policy (SCP) is a feature of AWS Organizations that sets the maximum available permissions for entire accounts (or organizational units) in a multi-account AWS setup. An SCP is a guardrail: it defines the ceiling on what anyone in the affected accounts can do — and critically, it applies to every principal in the account, including account administrators and even the root user. An SCP does not grant any permissions; it only limits them. This “limits, never grants” nature is the single most important thing to understand about SCPs, and the most common source of confusion.

Why “limits but doesn’t grant” matters — the intersection model

Because an SCP only caps permissions, an action in a member account is allowed only if it’s permitted by both the account’s IAM policies (which do the granting) AND the applicable SCPs (which set the ceiling). Effective permissions are the intersection: IAM grants ∩ SCP allows (∩ any permission boundaries, ∩ resource policies), and an explicit Deny anywhere wins. So an SCP that “allows” S3 doesn’t give anyone S3 access — it just means S3 isn’t blocked at the org level; a user still needs an IAM policy granting S3 to actually use it. This trips people up constantly: “my SCP allows it and my IAM policy allows it, but it’s still denied” (something else denies it), or “my IAM policy grants admin but I can’t do X” (an SCP caps it above). The power of SCPs is exactly that they sit above individual account permissions: even a full-admin IAM user — even the root user — in a member account cannot do something an SCP denies. That makes SCPs the tool for organization-wide guardrails that no one in the account can override.

What SCPs are for, and the realities

SCPs enforce org-wide security and compliance rules that must hold regardless of what account admins do. Classic uses: “no account may disable CloudTrail or GuardDuty” (preserving the audit/security baseline even from a compromised or careless admin), “no account may operate outside approved regions” (data-residency/compliance), “no account may leave the organization” or delete org-managed resources, “deny disabling of security controls,” and restricting particularly dangerous actions. They’re the backbone of a well-governed multi-account strategy — typically applied to organizational units so guardrails cascade to groups of accounts (dev OUs, prod OUs) with different rules. SCPs are commonly set up via AWS Control Tower, which provisions a governed landing zone with sensible SCP guardrails rather than requiring you to write them by hand. The realities to respect: because SCPs affect entire accounts including admins, an overly-broad Deny can lock everyone out of something important — SCPs must be tested carefully (and there’s a real risk of a broad SCP breaking legitimate access or even affecting the management account’s ability to manage the org, which is why the management account is handled specially). They also don’t affect the management account by default and interact with the default FullAWSAccess policy (removing it switches from allow-list to deny-list thinking, a common design choice to be deliberate about). And they cap only what they cover — SCPs govern IAM-controllable actions in member accounts, not everything. The recurring mistakes: thinking SCPs grant permissions (they only cap), forgetting the intersection when debugging denials, and deploying broad Denies without testing (locking out legitimate access org-wide).

What people get wrong

• Thinking SCPs grant access — they only set the ceiling; principals still need IAM policies to be allowed anything, and effective access is the intersection of grants and SCP limits.
• Forgetting the intersection when debugging denials: an IAM policy that “allows admin” still can’t exceed an SCP — “allowed but denied” usually means an SCP (or permission boundary) is capping it above.
• Broad Denies without testing — because SCPs apply to entire accounts including admins and root, an overly-aggressive Deny can lock out legitimate access org-wide; test guardrails carefully before rollout.

Primary source: AWS Organizations: Service Control Policies