Landing Zone

The alternative to a landing zone is what most organisations did first: teams create accounts on demand, each inventing its own network layout, identity model, tagging and logging. Within two years there are two hundred accounts, no consistent way to enforce anything, overlapping address ranges preventing connectivity, and no reliable answer to what exists or what it costs.

A landing zone establishes the foundation once. The account or subscription structure with organisational units matching how policy should apply. Network topology with a planned, non-overlapping address plan and a hub for shared connectivity. Identity with federated access and role definitions rather than local users. Centralised logging to an account the workload teams cannot modify. Guardrails as organisation-level policies that cannot be disabled locally. And tagging enforced at creation so cost allocation works from day one.

The design decision that matters most is account granularity, and the modern consensus is finer than teams expect: an account per workload per environment. The account is the strongest blast radius, security and cost boundary the provider offers, and treating it as cheap and disposable is what makes the rest of the governance model simple.

The point to press when someone proposes retrofitting one: address planning and account structure are the two hardest things to change later, and both are decided in the first month.