Building a Multi-Account AWS Landing Zone

A landing zone is a multi-account AWS setup built on AWS Organizations: one account per isolation boundary, grouped into OUs and constrained by service control policies, with identity unified through IAM Identity Center. For a 10-80 engineer regulated SMB it's typically five OUs and about ten accounts. It's the foundational layer you build before workloads sprawl.

The account is the only hard security wall AWS gives you, so tag-based separation means a leaked CI token can reach production. Quotas like Lambda concurrency and EC2 vCPU are account-scoped, so a load test in staging can take prod down with it. And a SOC 2 or HIPAA assessor asking how production is isolated won't accept 'a tag' as the answer.

SCPs are a deny-list, not a grant — an action is allowed only if IAM permits it AND no SCP denies it. A good starter set denies leaving the org, blocks CloudTrail tampering, denies root-user actions, restricts regions to the ones you operate in, and protects the log-archive bucket. Note they never apply to the management account, which is why nothing should run there.

If you already run Terraform through CI and one engineer owns platform, roll your own in plain Terraform and skip Control Tower — the org config is then managed like everything else you operate, which matters when an auditor asks for change history. Choose Control Tower only if platform ownership is genuinely nobody's job yet. Don't adopt AFT at this scale.

You don't move production. Invite the existing account into the organization and place it under the Workloads OU as prod, then build the new accounts around it — log-archive first, then Identity Center, then shared-services. Apply SCPs to the staging OU, watch for a week, then extend to prod. The planned migration weekend is the anti-pattern.

Ten to fifteen is the healthy range for a 10-80 engineer company. Add an account for a new blast radius worth isolating — a new compliance boundary, a workload with its own on-call, a data classification that shouldn't share IAM space — not for every microservice. At forty accounts you've rebuilt the original governance problem, now with a per-account Config, GuardDuty, and Security Hub bill.