Organizing the Chaos
AWS Organizations is the underlying service that Control Tower builds on. It provides the account hierarchy, consolidated billing, and the attachment point for Service Control Policies. Control Tower adds the automation layer on top.
You group accounts into Organizational Units (OUs) based on security posture and function — not by team name or HR reporting lines. The key insight is that OUs define what rules apply, not who owns the account. A "Production" OU has strict guardrails regardless of which team's workload lives there.
The recommended OU structure (AWS prescriptive guidance):
Root
├── Security OU
│ ├── Log Archive Account
│ └── Audit Account
├── Infrastructure OU
│ ├── Network Account (Transit Gateway, Direct Connect, DNS)
│ └── Shared Services Account (CI/CD tools, artifact registries)
├── Workloads OU
│ ├── Prod OU
│ │ ├── Team A Production
│ │ └── Team B Production
│ └── SDLC OU
│ ├── Team A Staging
│ ├── Team A Dev
│ └── Team B Dev
├── Sandbox OU
│ └── Developer Experiment Accounts
└── Suspended OU
└── Accounts pending deletion (billing stops, access blocked)
Why the Suspended OU matters: When you need to decommission an account, you cannot immediately delete it — AWS requires accounts to be standalone for 90 days before deletion. Moving an account to a Suspended OU lets you apply a Deny * SCP immediately (blocking all activity and cost) while the 90-day clock runs.
Nesting depth: OUs can be nested up to 5 levels deep. In practice, more than 3 levels creates management complexity without meaningful benefit. Prefer wider (more OUs at the same level) over deeper (more nesting).