Why Landing Zone Design Decisions Matter
An Azure landing zone is the foundation on which your entire cloud estate sits. Design decisions made in the first weeks of platform build will constrain โ or enable โ every workload that follows for years.
Most landing zone implementations get the basics right: management group hierarchy, policy framework, network topology. It's the decisions beneath the surface that organisations consistently get wrong โ and discover the consequences of 18 months later.
The Design Decisions That Matter Most
1. Management Group Hierarchy
The management group hierarchy determines where Azure Policy is applied and how subscription-level governance is inherited. Getting this wrong creates governance gaps that are expensive to remediate at scale.
The Microsoft Cloud Adoption Framework provides a solid starting point, but enterprise environments typically require customisation based on regulatory requirements, business unit boundaries, and operational models.
Key decisions: How granular should the hierarchy be? Where do sandbox/dev subscriptions sit? How are policy exceptions managed?
2. Network Topology: Hub-Spoke vs. Virtual WAN
This is the decision with the longest tail. Hub-spoke provides maximum control and flexibility. Virtual WAN simplifies management but constrains customisation.
For most large enterprises, hub-spoke remains the right choice โ particularly those with on-premises connectivity requirements, complex security inspection needs, or multiple regions. Virtual WAN is compelling for organisations with simpler network requirements or those running primarily SaaS-adjacent workloads.
The wrong choice here is expensive to reverse.
3. Identity Integration
How Azure AD (Entra ID) integrates with on-premises Active Directory has significant implications for hybrid identity, conditional access policy, and application authentication patterns.
Key decisions: Pass-through authentication vs. password hash sync vs. federation. Hybrid joined vs. Entra ID-only device management. Guest identity governance model.
These decisions affect every application that runs on the platform.
4. Policy-as-Code Strategy
Azure Policy is the governance engine of the landing zone. The design decision is how to manage policy โ deployed manually, via Terraform, via Bicep, or via Azure Landing Zones accelerator patterns.
The right answer for enterprise is infrastructure-as-code, version-controlled, with a clear approval and deployment pipeline. Policy that lives outside source control creates governance drift.
5. Connectivity to On-Premises
ExpressRoute vs. VPN is often decided on cost alone. For regulated industries or latency-sensitive workloads, ExpressRoute is non-negotiable. For others, VPN with redundancy may be appropriate.
More importantly: how does the connectivity architecture handle failover? What are the bandwidth constraints? How is routing governance managed?
Common Mistakes
- Under-investing in tagging standards โ Tagging policies enforced from day one save significant cost attribution effort later
- Over-engineering the initial hierarchy โ Start with what you need; the hierarchy can be extended, but simplifying it is painful
- Ignoring operational model โ The platform must be operable by the team that will run it; elegant architecture that the ops team can't manage is a liability
Conclusion
Landing zone design is a foundation decision. Invest appropriately in the upfront design โ involve security, networking, identity, and operations stakeholders โ and document the decisions made and the rationale behind them.
The organisations that rush landing zone design to meet a deadline consistently spend more time and money remediating the consequences than the original design would have taken to get right.