AWS Control Tower

AWS Control Tower sets up and governs a multi-account AWS environment to a prescriptive pattern. It orchestrates AWS Organizations, AWS Service Catalog and AWS IAM Identity Center to build a landing zone in under an hour, then keeps that environment from drifting away from the baseline it established.

Control Tower requires AWS Organizations

Control Tower is built on top of AWS Organizations and cannot run without it. It uses Organizations to create and structure accounts, service control policies to enforce preventive controls, and the organization’s management account as its own management account. If you have not enabled Organizations, Control Tower creates an organization for you; if you already have one, it adopts it.

Setting up a landing zone also creates two shared accounts alongside the management account: a Log Archive account for centralised CloudTrail and Config logs, and an Audit account for centralised security notifications and cross-account audit access.

graph TD MGMT["Management account<br/>(Organizations, Control Tower)"] MGMT --> SEC["Security OU"] MGMT --> WORK["Workload OUs<br/>(one per team or environment)"] SEC --> LOG["Log Archive account<br/>CloudTrail and Config logs"] SEC --> AUD["Audit account<br/>security notifications, cross-account audit"] WORK --> A["Member account"] WORK --> B["Member account"] A -. "Config rules report non-compliance" .-> AUD B -. "CloudTrail and Config logs" .-> LOG

Features

• Landing zone — the multi-account environment itself: the OU structure, the shared accounts, centralised logging, and identity through IAM Identity Center.
• Controls — high-level governance rules expressed in plain language and applied to an entire OU, so every account in that OU is subject to them.
• Account Factory — a configurable account template built on AWS Service Catalog. Teams provision new accounts themselves and the accounts arrive already enrolled, already governed.
• Dashboard — a single view of provisioned accounts, enabled controls and non-compliant resources by account and OU.

Controls

AWS is transitioning its terminology: what older material and some console screens call a guardrail is now called a control. The terms are synonymous. What has genuinely changed is that there are now three kinds, not two.

Type	Implemented with	When it acts
Preventive	Service control policies	Denies the API call outright, so the non-compliant action never happens.
Detective	AWS Config rules	Evaluates resources after they exist and reports non-compliance on the dashboard.
Proactive	CloudFormation hooks (preCreate and preUpdate handlers)	Checks a resource before CloudFormation deploys it, so a non-compliant stack fails at deploy time.

Proactive controls are the ones worth knowing about if you deploy through CloudFormation, because they catch a mistake in a pull request rather than in an audit report. Their limitation is the mirror image of that strength: because they are CloudFormation hooks, they do not see changes made directly in the console, through the AWS APIs, or by other infrastructure-as-code tools. Preventive controls, being SCPs, catch those.

Controls also carry a guidance category that says how strongly AWS recommends them:

• Mandatory — always enforced; you cannot turn them off.
• Strongly recommended — established best practice, enabled by choice.
• Elective — locks down behaviour that some organizations forbid and others rely on.

Which controls exist, what each one does and which Regions it applies to are recorded per control in the AWS Control Tower Control Catalog, which is also queryable through the ListControls and GetControl APIs.

The management account exception

Controls do not restrain the management account. The root user and administrators there can do things a control would otherwise deny — deliberately, so that the management account cannot lock itself out. Their actions are still recorded in the Log Archive account. This is the main reason the management account should hold no workloads and very few people.