A landing zone is the set of subscriptions, identity, networking, logging and guardrails that make later Azure work boring. If those pieces are missing, every project invents its own hub, its own DNS hack, and its own “temporary” exception that never expires.
The first release should be small enough to operate. Management groups that match how you approve spend. A hub that carries hybrid connectivity, DNS and shared services. Spoke patterns that application teams can copy. Central logging that security can query. Backup and key management with named owners. Policy that blocks the mistakes you have already made, not a thousand unused initiatives.
On one estate, the first Azure subscription had been created for a single project, then a second for another, each with its own VNet, its own address space and a VPN back to the datacentre. Two of them ended up with overlapping ranges and a third had no logging at all. The fix was a hub, an address plan agreed up front and Azure Policy enforcing diagnostic settings.
What does not belong in v1: a perfect CAF diagram, twenty management groups for an organisation with three application teams, and custom policy at a density nobody can explain. Over-governance is how landing zones stall. Under-governance is how you get public storage accounts and mystery peering.
Identity is the usual failure point. Hybrid Entra ID, privileged access, break-glass, and workload identities need a design before the first production subscription is used. Networking is the second: address space, ExpressRoute or VPN, private DNS, and outbound internet paths. Get those two right and most other Azure services become configuration rather than invention.
Treat the landing zone as a product with a backlog. Version it. Document the exceptions. Review them. The measure of a landing zone is whether an application team can add a spoke without a specialist re-designing the network each time.
Have a platform or landing zone project to get done? Transformation Engineering
All resources