Organizations, OUs, and SCP Strategy

AWS Organizations lets you centrally manage many AWS accounts as one structure. Within it, Service Control Policies (SCPs) set permission ceilings, and Organizational Units (OUs) group accounts for policy targeting. Designing this hierarchy well is a core skill for the SCS-C02 exam's governance domain.

An organization has a management account (formerly master) at the top, a root container, and OUs that can nest to group member accounts. Policies attached at any level flow down to everything beneath. This tree lets you apply controls broadly or narrowly with one attachment.

An Organizational Unit (OU) groups accounts that share governance needs, for example a "Production" OU, a "Sandbox" OU, and a "Security" OU. Attaching an SCP to an OU applies it to every account inside, so you organize accounts by the policies they should inherit.

SCPs are inherited down the tree: an account is governed by the SCPs at the root, its parent OUs, and itself, combined. For an action to be allowed, it must be permitted at every level. A deny anywhere in the chain blocks it. This cumulative effect is central to SCP design.

There are two strategies. A deny-list starts from the default FullAWSAccess and adds explicit denies for things you never want, like disabling CloudTrail. An allow-list removes FullAWSAccess and explicitly lists only permitted services, a much stricter posture. Most organizations begin with deny-list for flexibility.

This SCP denies anyone from stopping CloudTrail logging, a common guardrail applied org-wide so no member account can blind the audit trail.

A vital rule: SCPs never grant permissions; they only set the maximum. An action must be allowed by both an SCP and an IAM policy in the account. An allow-list SCP simply makes services available to be granted; IAM still has to grant them.

SCPs do not apply to the management account, and they do not affect service-linked roles. They also do not touch resource-based policy grants from outside the org in some cases. Knowing these exceptions prevents wrong answers when a scenario expects an SCP to block something it cannot.

Two classic protective SCPs deny leaving the organization (organizations:LeaveOrganization) and deny member accounts from disabling security services like GuardDuty, Security Hub, Config, and CloudTrail. Applied at the root, these ensure no member account can detach itself from governance or blind the organization's detection, a strongly recommended baseline.

A typical design: a baseline deny-list SCP at the root (protect CloudTrail, deny leaving the org, restrict regions), stricter SCPs on the Production OU, and looser ones on a Sandbox OU. Grouping accounts by risk profile into OUs lets you tune governance precisely with minimal policy sprawl.

Organizations structures accounts into OUs under a root and management account. SCPs inherit down the tree and an action needs an allow at every level. Choose deny-list (flexible) or allow-list (strict) strategy, remember SCPs only cap, never grant, and that they do not apply to the management account or service-linked roles.

Test your SCP strategy.

AWS Organizations groups accounts into OUs under a root and management account. SCPs inherit down the tree and require an allow at every level; any deny blocks. Use deny-list (flexible) or allow-list (strict) strategy. SCPs only cap, never grant, and do not apply to the management account or service-linked roles.