An AWS landing zone is not a slide deck of account names. It is the operating model for identity, networking, logging, and guardrails that every new workload inherits.
Start with Organizations structure: management account separation, OUs for shared services, non-prod, and production, and SCPs that block the few catastrophic actions teams should never need. Pair that with centralized CloudTrail, Config, and GuardDuty—not per-account afterthoughts.
Identity should be intentional: SSO federation, break-glass roles, and least-privilege patterns for CI/CD deploy roles. Networking baselines (hub-and-spoke or similar) and tagging standards make cost and incident response possible later.
Ship documentation and a runbook with the build. A landing zone nobody can operate is just expensive scaffolding.
Treat shared networking and logging accounts as products with SLAs. If those accounts are unstable, every workload account inherits the pain.
Define account vending inputs up front: owner, cost centre, data classification, and connectivity needs. Ad-hoc accounts become ungovernable within a quarter.
Rehearse break-glass access quarterly. Unused emergency roles that nobody can activate are not a control—they are theatre.
Key takeaways
- Separate the management account from workloads and lock down break-glass access.
- Centralize CloudTrail, Config, and GuardDuty before the first production account proliferates.
- Ship OU structure, SCPs, SSO, and tagging with a runbook—not only Terraform.
FAQ
Do we need Control Tower for a landing zone?
Not always. Control Tower helps many teams start faster, but a Terraform-first multi-account design can work if you still cover account vending, identity, logging, and guardrails.
What should SCPs block first?
A short deny list for catastrophic actions (for example disabling logging, leaving mandatory regions, or bypassing identity providers)—not hundreds of noisy denies that break delivery.