A landing zone is the word Azure uses for something much more important than it sounds. It is not a template. It is not a starter kit. It is the set of architecture decisions about identity, networking, policy, management, and connectivity that every workload you ever deploy into Azure will inherit. Get those decisions right and your platform is a foundation. Get them wrong and every new workload adds to the remediation debt. The difference between the two is almost always visible within 12 months.
What a Landing Zone Actually Is
Microsoft’s definition is deliberately broad: “an environment for hosting your workloads, pre-provisioned through code.” That definition is accurate but not particularly useful. The more useful framing is narrower: a landing zone is the answer to the question “what must be true about every Azure environment before we deploy anything into it?”
That question resolves into three categories of decisions. First, identity and access — who can do what, where, and under what conditions. This covers your management group RBAC hierarchy, Privileged Identity Management configuration, and how workload identities authenticate. Second, network topology — hub-and-spoke vs Virtual WAN and DNS resolution architecture. Third, governance and management — which Azure Policy initiatives are assigned at which scope.
The Cloud Adoption Framework (CAF) provides a reference architecture for all of this. It is a genuinely useful starting point, but it is not a prescription.
My View on CAF Bloat: I frequently see teams adding Management Groups just for the sake of having them because they saw it in a reference diagram. I’ve seen “ghost layers”—Management Groups sitting in the middle of a hierarchy that serve no purpose. If a group doesn’t have its own unique policy or RBAC requirements that differ from the layer above or below it, it has no value. It’s just an extra click in the portal and extra complexity in your IaC that does nothing but confuse the hierarchy.
The Three Most Common Landing Zone Mistakes
Mistake 1: Building one landing zone for everything. A single management group structure and policy set that applies equally to production, development, and sandbox workloads is a common failure point. The result is a policy configuration that is either too restrictive for development or too permissive for production.
Mistake 2: Deferring networking decisions. Network topology is the hardest landing zone decision to reverse. Teams that defer the network decision and connect workloads ad hoc end up with overlapping IP ranges and a network topology that cannot be normalised without redeploying workloads.
Mistake 3: Manual landing zones. A landing zone applied through the portal is not a landing zone. Drift begins on day one. Within twelve months, nobody is confident they know what is actually configured.
The Decisions That Are Hard to Undo
Some landing zone decisions are costly to change after workloads are deployed. These deserve disproportionate attention at design time.
Management group hierarchy depth. Removing a level after RBAC and policy assignments exist at that scope is disruptive and error-prone. Design the hierarchy for where the organisation will be in three years, not where it is today. (See Management Groups and Subscription Design: Getting the Hierarchy Right for hierarchy design discipline.)
Primary region and paired region strategy. Changing an Azure region after workloads are deployed means redeploying those workloads.
The Global Hub Challenge: While people often fail to plan IP ranges, the bigger struggle I see is understanding Hub and Spoke at a global scale. A single hub isn’t enough for a global footprint; you need a multi-hub strategy. The critical question architects fail to ask early enough is: Where are the users? The answer to that question determines where the hubs must live to keep latency low, but it also forces you to deal with the complexity of cross-region traffic and data residency before you’ve even deployed your first spoke.
Hub network IP ranges. RFC 1918 space is finite. Hub VNet address space cannot be extended without redeployment of resources in that VNet. Document every known network range before committing to hub address space, and leave more room than you think you need.
Getting It Right
The organisations that build landing zones that hold up start with questions, not architecture. What workload types will we host? What is the identity model? What are the compliance obligations? The answers to these questions should determine the architecture; the architecture should not determine the answers.
Validate the landing zone design with a real workload deployment before declaring it done. The policy assignments that seemed reasonable in design will produce unexpected deny effects. The network topology that looked correct in the diagram will have routing gaps.
Treat the landing zone as a product, not a project. It needs owners, a backlog, and a release process. Policy assignments will be added as compliance requirements evolve. Network topology will change as workload connectivity requirements expand. Teams that treat the landing zone as a project produce a foundation that decays because it was never maintained.
The maintenance reality: Even well-governed environments drift over time without active prevention. See Governance Drift: How Azure Environments Decay Over Time and How to Prevent It for how to maintain governance as a continuous practice.
The most expensive landing zone mistake is the one you make at the beginning and discover at scale. The decisions that feel like details at deployment time — IP ranges, management group depth, policy scope — are the ones that drive the most remediation cost when they turn out to be wrong. The time to be deliberate about them is before the first workload is in production.
