Multi-account governance with Control Tower and Organizations
AWS Organizations gives you the account tree; Control Tower stands up the opinionated, guardrailed landing zone on top of it.
Two layers: the container and the opinionated setup
Multi-account governance on AWS is built from two distinct layers that people often blur together. The lower layer is AWS Organizations: it is the container that groups many AWS accounts under a single management (payer) account, arranges them into a hierarchy of organizational units (OUs), consolidates billing, and enforces service control policies (SCPs). Organizations by itself is just the tree and the policy engine; you still have to design the structure and wire up logging, identity, and baselines yourself.
The upper layer is AWS Control Tower. Control Tower is the opinionated automation that sits on top of Organizations and stands up a well-architected multi-account environment, called a landing zone, based on AWS best practices. It orchestrates Organizations, AWS IAM Identity Center, AWS CloudTrail, and AWS Config for you rather than replacing them. The mental model for the exam: Organizations is the mechanism, Control Tower is the managed, best-practice way to configure and continuously govern that mechanism.
Two governance layers: Organizations (mechanism) and Control Tower (orchestration)
Trace
AWS Organizations is the lower layer: the container that groups accounts under a management account, arranges OUs, consolidates billing, and enforces SCPs. AWS Control Tower is the upper layer: opinionated automation that orchestrates Organizations, IAM Identity Center, CloudTrail, and AWS Config to stand up and continuously govern a best-practice landing zone rather than replacing any of them.
The landing zone: a management account and a Security OU
When Control Tower sets up a landing zone it creates a specific baseline structure. The management account sits at the root of the organization; it is where Control Tower and IAM Identity Center run, and the guidance is to keep production workloads out of it. Control Tower also provisions a foundational Security OU that contains two shared accounts: a Log Archive account and an Audit account. A Sandbox OU is offered for experimentation, and you add your own workload OUs (for example a Workloads OU holding Prod and Dev accounts) beneath the root.
The Log Archive account holds a central, restricted Amazon S3 bucket that aggregates AWS CloudTrail and AWS Config logs from every account in the organization, giving you one immutable place to audit activity. The Audit account is the restricted security account: it is where the security and compliance teams get cross-account access and where notifications and security tooling (such as AWS Config aggregation and AWS Security Hub) are centralized. Splitting logging away from the tooling that reads it is what keeps an attacker who compromises one account from also erasing the evidence.
Control Tower landing zone: management account and Security OU
Trace
Control Tower provisions a baseline structure: the management account runs Control Tower and IAM Identity Center and holds no workloads, a foundational Security OU holds the Log Archive and Audit accounts, a Sandbox OU is offered for experimentation, and workload OUs hold everyday accounts. Every account streams CloudTrail and Config logs to one restricted, immutable bucket in the Log Archive account, while the Audit account aggregates Config compliance and centralizes Security Hub and GuardDuty. Splitting the logs from the tooling that reads them stops a single-account compromise from erasing the evidence.
Guardrails come in three flavors
Control Tower expresses governance as controls (historically called guardrails), and there are three enforcement styles. Preventive controls stop disallowed actions before they happen and are implemented with SCPs, so a denied action simply fails. Detective controls do not block anything; they are implemented with AWS Config rules that continuously evaluate resources and report non-compliant ones, surfacing drift on the Control Tower dashboard. Proactive controls are implemented with AWS CloudFormation hooks and check resources against policy before they are provisioned, so a non-compliant resource is rejected at deploy time rather than flagged afterward.
Controls are also grouped by guidance level: mandatory controls are always applied by Control Tower and cannot be turned off, strongly recommended controls reflect AWS best practices you are encouraged to enable, and elective controls lock down actions many organizations choose to restrict. You apply controls to OUs, and every account in that OU inherits them, which is why the OU is the real unit of governance, not the individual account.
Three control styles: preventive, detective, and proactive
Trace
Control Tower expresses governance as controls applied to an OU and inherited by every account in it. Preventive controls are SCPs that stop a disallowed action before it happens (it simply fails). Proactive controls are CloudFormation hooks that check a resource against policy before it is provisioned and reject non-compliant ones at deploy time. Detective controls are AWS Config rules that continuously evaluate live resources and report non-compliant ones as drift on the Control Tower dashboard, without blocking anything.
SCPs set a ceiling; they do not grant
The single most tested idea in multi-account governance is what an SCP actually does. A service control policy sets the maximum available permissions for the accounts it is attached to; it never grants a permission on its own. An action is only allowed if it is permitted by both the SCP (the ceiling) and an IAM identity-based or resource-based policy (the grant). Attach an SCP to the organization root, an OU, or a single account, and it flows down the tree to everything beneath it.
Two exceptions matter. SCPs do not apply to the management account, which is why you keep workloads out of it and never rely on an SCP to protect it. SCPs also do not affect service-linked roles. Do not confuse an SCP with a permission boundary: an SCP is an Organizations-level ceiling over whole accounts and OUs, while a permission boundary is an IAM feature that caps a single user or role inside one account. For provisioning at scale, Control Tower Account Factory hands out new accounts that already inherit the OU's controls and baseline, and CloudFormation StackSets push resources across many accounts and Regions from the management or a delegated admin account, so a new account is governed the moment it exists rather than after someone remembers to configure it.
SCP as a ceiling, plus governed provisioning at scale
Trace
An SCP sets the maximum available permissions and never grants on its own: an action succeeds only where the SCP ceiling and an IAM identity- or resource-based policy both allow it. Attach an SCP to the root, an OU, or an account and it flows down to everything beneath, but it never applies to the management account. Control Tower Account Factory hands out new accounts that already inherit the OU's controls and baseline, and CloudFormation StackSets push resources across many accounts and Regions, so a new account is governed the moment it exists.
