A landing zone is the unglamorous foundation work nobody wants to fund and everybody regrets skipping. It is the account structure, the network topology, the guardrails, and the identity setup that every workload after it inherits. Get it roughly right early and the next hundred deployments are easy. Get it wrong and you are doing a painful re-org of live accounts two years in.
Multiple accounts are the unit of isolation
The single strongest decision is to use many accounts, not one big shared account with everything tagged. An AWS account is a hard security and billing boundary. Separate production from non-production, separate workloads from each other, and keep shared services and security tooling in their own accounts. Control Tower and Organizations make this manageable with organizational units, so a guardrail you set on the production OU applies to every account that lands in it.
- A management account that runs nothing but billing and the org itself.
- A security and audit account where logs land and nobody deploys workloads.
- Separate prod and non-prod accounts per workload or per team, not one shared bucket.
- OUs grouped by environment and sensitivity so guardrails apply by policy, not by hand.
Plan the network address space before you need it
The cheapest mistake to avoid is overlapping CIDR ranges. The day two VPCs need to talk and their address spaces collide, you are into NAT gymnastics or a re-addressing project. Carve up a non-overlapping plan for every account and region up front, leave room to grow, and assign blocks deliberately. It costs an afternoon now and saves a quarter later.
Overlapping CIDRs are a decision you make once by accident and pay for repeatedly on purpose.
Centralise the network rather than letting each team build its own. A shared-services VPC or a Transit Gateway in a network account gives you one place to manage routing, egress, and connectivity to on-premises. Teams get their own VPCs but plug into a topology you control.
Guardrails over gates
The point of a landing zone is to let teams move fast safely, not to put a human approval in front of every change. Use service control policies to make the dangerous things impossible (no public S3 by default, no leaving the approved regions, no disabling CloudTrail) and then get out of the way. A guardrail that runs automatically beats a review board that becomes a bottleneck.
- Service control policies to forbid the genuinely dangerous, applied at the OU level.
- Centralised CloudTrail and Config so every account is logged whether teams remember or not.
- A standard VPC and tagging baseline that new accounts get automatically.
- Everything in infrastructure as code so the landing zone is reproducible, not hand-clicked.
Nobody gets promoted for a clean landing zone, and everybody suffers from a messy one. Do the boring structural work before the first real workload arrives, because retrofitting account boundaries and network plans onto a running estate is one of the most expensive projects we get hired to fix.