AWS Organizations and Control Tower

AWS Organizations provides the structure for a multi-account estate. AWS Control Tower automates setting that structure up according to a prescribed set of practices. Together they make it possible to run many accounts without governing each one by hand.

AWS Organizations

Core components

• Management account — creates the organisation, provisions member accounts and pays the consolidated bill. It should hold no workloads: service control policies do not apply to it, so anything running there is outside the organisation’s guardrails.
• Member accounts — where workloads and data live. Each is a hard isolation boundary.
• Organizational units (OUs) — groups of accounts that share access patterns or purpose. A policy attached to an OU applies to every account beneath it, and OUs can nest.

Why multiple accounts

Security

• Coarse-grained isolation that no IAM policy can accidentally cross
• Least privilege at the account level, not just the principal level
• Sensitive data confined to accounts few people can reach
• A limited blast radius: a compromise or a mistake in one account does not reach the others

Operations

• Workloads grouped by business purpose and ownership, so cost and responsibility line up
• Consolidated billing across every account
• Volume discounts and Savings Plans applied across the organisation
• Service quotas that are per-account, so one noisy workload does not exhaust another’s

AWS Control Tower

Control Tower sets up and governs a multi-account environment automatically.

Landing zone

The landing zone is the initial environment. Setting it up creates the OU structure, enables the baseline controls, configures logging, and establishes the permissions needed to provision further accounts. New accounts created through Control Tower receive the baseline automatically.

Controls

A control is a high-level governance rule, expressed in plain language, that applies to an OU and therefore to every account in it. AWS previously called these guardrails and both terms still appear in the documentation and console; they mean the same thing.

Controls come in three behaviours:

• Preventive — implemented as service control policies. The action fails.
• Detective — implemented as AWS Config rules. The action succeeds and a finding is raised.
• Proactive — implemented as AWS CloudFormation hooks. A resource is checked against the rule before it is provisioned, so a non-compliant template fails in the pipeline rather than in production.

Controls are also classified by guidance: mandatory, strongly recommended and elective. The AWS Control Catalog is the consolidated catalogue of available controls, browsable by use case — security, cost, durability, operations — and reachable through its own API without setting up Control Tower.

One exception is worth knowing: the root user and administrators in the management account can perform actions that a control would otherwise deny. This is deliberate, so that the management account cannot be rendered unusable, and it is another reason to keep workloads out of it. Those actions are still recorded in the log archive account.

Blueprints and baselines

Blueprints are CloudFormation stacks that grant Control Tower access to a managed account and apply the controls to it. The baseline is the combination of blueprints and controls applied to each new account.

Architecture

• Management account — holds the Control Tower configuration and the integration with IAM Identity Center
• Log archive account — created automatically; aggregates CloudTrail and AWS Config logs from every account, with access restricted so that logs cannot be altered by the accounts that produce them
• Audit account — created automatically; holds cross-account roles for read access and security notifications
• Core OU — the system accounts above
• Custom OUs — the accounts that hold workloads, with the baseline applied automatically

Practice

1. Keep the management account free of workloads.
2. Group accounts into OUs by the guardrails they need, not by the team that happens to own them today.
3. Apply controls at OU level and prefer proactive and preventive controls where the rule can be expressed that way.
4. Provision accounts automatically rather than by hand, so no account escapes the baseline.
5. Centralise logging in the log archive account and restrict who can read it.
6. Use IAM Identity Center for human access to every account.