The Complete Guide to Microsoft Azure Landing Zones in 2026

Why landing zones matter more than ever

A landing zone is the opinionated baseline of identity, networking, policy, security, and operational tooling that every workload in your tenant inherits. Done well, it lets product teams deploy on day one without re-deciding the same questions over and over. Done badly, it becomes the technical debt every engineering team works around for years.

Microsoft's Cloud Adoption Framework provides the reference, but the reference is a starting point, not a destination. In this guide we walk through the architecture choices we have made deploying landing zones across more than 80 business units, the trade-offs we encountered, and the patterns that have survived contact with reality.

Subscription topology and management groups

Start with a management group hierarchy that maps to how your organization actually governs, not how it is drawn on an org chart. We recommend a top-level split into Platform, Landing Zones, Decommissioned, and Sandbox, with Landing Zones further divided by data classification or business unit depending on which dimension drives policy.

Place subscriptions, not resource groups, at the boundary of blast radius. A subscription is the unit of quota, the unit of Azure Policy assignment, and the unit of cost reporting. Resource groups are a deployment convenience; do not use them as a governance boundary.

Identity and Entra ID

Use a separate Entra ID tenant only when you have a hard regulatory requirement to isolate identity. The operational cost of a second tenant — guest invites, conditional access drift, license management — is high and the security benefit is usually achievable with administrative units and Privileged Identity Management.

Bake Conditional Access baselines into the landing zone itself. Block legacy authentication, require phishing-resistant MFA for administrative roles, and require compliant or hybrid-joined devices for sensitive applications. Document every exception and review them quarterly.

Networking and connectivity

Hub-and-spoke is still the right default for most enterprises. Azure Virtual WAN is the better choice when you have more than a handful of regions or significant SD-WAN connectivity needs. Whichever you choose, terminate ExpressRoute or VPN in the hub and route east-west traffic through Azure Firewall or a third-party NVA.

Use a single, deliberate IP address plan that leaves headroom for at least three years of growth. Conflicts with on-premises ranges or acquired companies are the single most common reason landing zones have to be partially rebuilt.

Policy as code and guardrails

Codify your guardrails in Azure Policy and assign them at the management group level so they cascade. Use the built-in initiatives as a starting point for ISO 27001, NIST 800-53, and the Microsoft Cloud Security Benchmark, but expect to customize.

Treat policy exemptions as first-class objects. Require a documented justification, an owner, and an expiry date. The most damaging policy posture is a permanent allow-list nobody remembers granting.

Operational baseline and observability

Every landing zone needs a centralized log destination, a baseline of monitoring rules, and a backup and disaster recovery strategy that applies by default. We use a single Log Analytics workspace per region, with dedicated workspaces for security telemetry to satisfy retention requirements.

Pre-deploy Defender for Cloud across the management group hierarchy. The cost is meaningful but the alternative — turning it on later, per subscription — guarantees coverage gaps.

Conclusion and next steps

A good landing zone is boring. It makes the easy thing safe and the unsafe thing inconvenient. Use this guide as the starting point for a design review with your platform, security, and FinOps stakeholders, then codify the decisions in Bicep or Terraform so they can be replayed for every new subscription you onboard.