Skip to content

CONCEPT Cited by 2 sources

Service Control Policy (SCP)

What it is

A Service Control Policy (SCP) is an AWS Organizations policy that defines the maximum set of permissions any principal in an AWS account (or OU) can use — even the account's root user and even IAM administrators in the account. SCPs are a deny-by-default ceiling, not a grant: attaching an SCP cannot grant a permission that IAM hasn't, but it can take one away.

The concept matters whenever the architecture depends on fleet-wide guardrails that cannot be bypassed by the account operator — canonical multi-account scenarios being:

  • Regulated baseline enforcement (e.g. "no principal may disable CloudTrail in any account").
  • Region fencing (e.g. "no resource may be created outside approved Regions").
  • Tenant-account restriction (e.g. "this tenant OU may not access sensitive cross-account shared services").

How it fits account-per-tenant isolation

In ProGlove's account-per-tenant platform, SCPs are one of two pillars of baseline guardrails (the other is strict IAM management):

"Baseline guardrails – Enforce compliance and security controls using SCPs and a strict IAM management." (Source: sources/2026-02-25-aws-6000-accounts-three-people-one-platform)

SCPs are what structurally prevent a tenant-account misconfiguration from reaching outside its blast-radius boundary. Because the boundary is already the AWS account, the SCP layer mostly enforces compliance and platform-admin invariants rather than tenant-vs- tenant rules.

Inheritance model

SCPs attach to the Organization root, OUs, or individual accounts. The effective ceiling at any account is the intersection of all SCPs applied from the root down to that account — an account cannot do anything that any SCP in its path denies.

At scale (ProGlove's ~6,000 tenant accounts, sovereign-cloud multi-Organization topologies), the operational concern is replicating the OU + SCP hierarchy across multiple Organizations — specifically:

"You can manage the same organizational units (OUs) and policies for the AWS European Sovereign Cloud by reusing your existing deployment automation." (Source: sources/2026-01-30-aws-sovereign-failover-design-digital-sovereignty)

— because AWS Control Tower can't directly manage sovereign-partition accounts.

Key limitations

  • SCPs don't grant permissions — IAM still has to grant them inside the account.
  • SCPs don't apply to service-linked roles for some AWS services.
  • SCPs don't apply to the Organization management account by default (a classic footgun — the management account must be operated as a minimal-privilege root).
  • SCP size/attach-count limits constrain policy composition; complex policy sets need to be factored into OUs.

Seen in

Last updated · 200 distilled / 1,178 read