How to Design Azure Landing Zones: The Enterprise
Architecture Blueprint That Prevents Cloud Sprawl
Cloud sprawl doesn't arrive as a single bad decision. It arrives as fifty reasonable ones, made by different teams, on different days, with no shared foundation underneath any of them. A landing zone is that foundation — decided once, before the first workload lands, so every subscription that follows inherits governance instead of inventing its own.
# Eighteen months of organic growth, no landing zone, five different
# teams "just getting something running." A composite, realistic picture:
Subscriptions: 50, created ad hoc via support tickets
Naming conventions: 4 different schemes, none documented
VMs deployed: 200 (40 abandoned, still billing ~$30K/month)
Public IPs: 15 (3 with no firewall rules in front of them)
Central monitoring: None — each team built its own, or none at all
Tagging: Inconsistent — cost attribution is a manual audit
RBAC: Ranges from "everyone is Owner" to undocumented
Network topology: Flat VNets, ad hoc peering, no consistent hub
# None of these fifty decisions was individually irrational. Team A
# needed a subscription fast and support took three weeks, so Team B
# just used Team A's. Team C picked their own naming scheme because
# nobody had published one. Multiply reasonable local decisions by
# eighteen months and zero shared foundation, and this is what you get.
# The fix is not a cleanup project. It's deciding, once, BEFORE this
# happens: the management group hierarchy, the subscription model, the
# network topology, and the governance guardrails every future
# subscription inherits automatically. That decision is the landing zone.The pattern: Cloud sprawl is what happens when subscription creation, networking, and governance are each decided independently, workload by workload, with no shared platform underneath. The fix: An Azure Landing Zone — a pre-configured, multi-subscription environment with governance, identity, networking, and security decided once and inherited automatically by everything deployed after it. The cost of skipping it: Not zero — deferred. Every team's local decision becomes a remediation task once the organization eventually needs consistency, and remediation is reliably more expensive than designing it up front.
Every organization that adopts Azure at scale eventually asks the same question, usually after the fact: who decided the naming convention, who owns network connectivity, and why do fifteen subscriptions have fifteen different security postures? An Azure Landing Zone is Microsoft's answer to asking that question before the fact instead of after. It is not a product you buy or a single resource you deploy — it's an architecture pattern, part of the Cloud Adoption Framework, that defines a multi-subscription environment where governance, identity, networking, and security are decided once, centrally, and inherited automatically by every workload that lands afterward. The name is literal: it's the landing zone a workload lands into, already governed, rather than a blank subscription a team has to govern themselves, inconsistently, under deadline pressure. This guide walks through the architecture end to end — the eight design areas Microsoft's own reference architecture is built around, the management group hierarchy that makes policy inheritance possible, the networking and governance patterns that hold at enterprise scale, and a concrete, step-by-step path to deploying one.
Microsoft's Cloud Adoption Framework defines an Azure Landing Zone as the standardized, recommended approach for organizations using Azure — a multi-subscription environment that accounts for scale, security, governance, networking, and identity, built from the start rather than retrofitted later. It provides a consistent way to set up and manage an Azure environment through two categories of subscription working together: platform landing zones (shared services every workload depends on) and application landing zones (the workloads themselves).
- It's an architecture pattern, not a product. There's no single "Landing Zone" resource you provision. It's a way of organizing management groups, subscriptions, policies, and networking that Microsoft documents as a reference architecture and provides tooling (the Landing Zone accelerator) to help deploy.
- It's opinionated by design. The reference architecture represents Microsoft's recommended target — you're expected to adapt it to your organization's specifics, but it starts from a defined position on every design area rather than a blank slate.
- It's modular and repeatable. Configurations and controls apply consistently to every subscription that lands in the structure, and components can be deployed or modified independently as requirements evolve.
- It exists before workloads do. The landing zone is the foundation deployed first — governance, identity, networking, security — so that the first application team to arrive lands into an already-governed environment rather than building governance themselves under deadline pressure.
You'll often see "Azure Landing Zone" and "Enterprise-Scale Landing Zone" used close together. Enterprise-scale is Microsoft's recommended architecture specifically for large organizations deploying Azure broadly — it's the landing zone concept taken to its full, opinionated conclusion, with the complete management group hierarchy, policy set, and networking pattern this guide describes. Smaller organizations can and should apply landing zone principles without adopting every piece of the enterprise-scale reference architecture — start with a management group hierarchy, a baseline policy set, and centralized logging, and grow into the rest.
The Cloud Adoption Framework organizes cloud adoption into five phases, and the landing zone is specifically the technical output of the third.
| CAF Phase | What it covers | Relationship to landing zones |
|---|---|---|
| Strategy | Business justification, motivations, expected outcomes | Informs why you're adopting Azure at all |
| Plan | Digital estate assessment, adoption plan, skills readiness | Informs what needs to migrate or be built |
| Ready | Landing zone deployment — the architecture foundation | This is where landing zones live |
| Adopt | Migrate existing workloads; build new cloud-native ones | Builds on top of the landing zone foundation |
| Govern & Manage | Ongoing governance, operations, cost optimization | Operates the landing zone's guardrails continuously |
The organic-growth failure mode this guide opened with is, structurally, what happens when an organization skips the Ready phase — deploying workloads directly into Azure without first deciding the management group hierarchy, subscription model, or governance baseline those workloads should inherit. Each team effectively invents their own miniature "Ready" phase, inconsistently, which is why the fifty-subscription sprawl scenario has four different naming conventions rather than one.
Microsoft's reference architecture is organized around eight design areas, evaluated together rather than in isolation, because decisions in one area constrain the others — your network topology affects your security design; your subscription model affects your governance policy scope.
| # | Design area | Core question it answers |
|---|---|---|
| 1 | Azure billing & Microsoft Entra tenant | How is billing structured, and which Entra tenant(s) are in play? |
| 2 | Identity and access management | How are identities provisioned, and how is access granted and reviewed? |
| 3 | Management group and subscription organization | How are subscriptions grouped, and what does each one host? |
| 4 | Network topology and connectivity | How do workloads reach each other, on-premises, and the internet? |
| 5 | Security | What's the baseline security posture, and how is it enforced? |
| 6 | Management | How are resources monitored, backed up, and operated day to day? |
| 7 | Governance | What policies are enforced, audited, and by whom? |
| 8 | Platform automation and DevOps | How is the platform itself deployed, updated, and extended as code? |
The remaining sections of this guide walk through the design areas that most directly shape the architecture — management groups and subscriptions (design area 3), networking (4), governance (7), security (5), and platform automation (8) — in enough depth to actually make the decisions each requires.
Every governance mechanism in a landing zone — Azure Policy assignment, RBAC scope, cost management boundaries — is expressed as "at which level of the management group tree does this apply." Getting the hierarchy right is disproportionately important, because subscriptions moving between management groups later is a real but non-trivial operation, and a poorly designed hierarchy tends to calcify around whatever shape it started with.
| Management group | Contains | Typical policy focus |
|---|---|---|
| Platform | Management, Identity, and Connectivity subscriptions | Platform-specific: logging retention, DNS, hub network standards |
| └ Management | Log Analytics, Automation Accounts, monitoring tooling | Diagnostic settings enforcement, retention policy |
| └ Identity | Domain controllers, identity-related infrastructure | Strict network isolation, no public endpoints |
| └ Connectivity | Hub VNet, firewall, gateways, private DNS zones | Network security baseline, peering standards |
| Landing Zones | Application/workload subscriptions | Broad governance: tagging, allowed regions, deny public IP |
| └ Corp | Internal-facing application subscriptions | No direct internet inbound; hub-routed only |
| └ Online | Public-facing application subscriptions | WAF requirements, DDoS protection standards |
| Sandbox | Experimentation subscriptions, disconnected from production | Relaxed policy, auto-expiry, cost caps |
| Decommissioned | Subscriptions pending deletion | Locked down, read-only, awaiting teardown |
Most enterprise-scale implementations add a further layer under both Corp and Online: separate Production and Non-Production management groups, each with its own policy set. Production inherits stricter security and change-control policies; Non-Production carries relaxed policies alongside cost controls like auto-shutdown schedules for VMs. This split is what lets a single "deny public IP" policy at the Landing Zones level coexist with looser experimentation rules specifically scoped to non-production workloads.
The reference hierarchy assumes a specific operating model — centralized platform team, workload teams operating within Corp/Online boundaries. If your organization's actual operating model doesn't match (a strongly federated model where business units run near-independent platforms, for instance), copying the reference hierarchy exactly can create friction rather than resolve it. Use the reference as a starting point and default, but validate it against how your organization genuinely makes decisions before locking it in — correcting a management group hierarchy after dozens of subscriptions exist under it is a real migration project, not a quick edit.
Subscriptions are Azure's hard isolation boundary — for billing, for quota, for certain security controls (some resources can only be isolated at the subscription level, not the resource group level). Getting subscription granularity right avoids two failure modes: too few subscriptions (blast radius and cost attribution collapse into a shared blob) and too many (operational overhead and quota fragmentation).
| Subscription model | What it gets you | What it costs you |
|---|---|---|
| One subscription per workload per environment | Clean blast-radius isolation, independent RBAC, clear cost attribution — CAF's standing recommendation | More subscriptions to manage; needs a low-friction vending process to stay practical |
| Shared subscription per business unit | Fewer subscriptions to administer | Blast radius spans every workload in the unit; cost attribution requires disciplined tagging instead of natural subscription boundaries |
| One giant subscription for everything | Simplest to set up initially | No meaningful isolation at all; this is the shape that produces the sprawl scenario at the opening of this guide, just consolidated into fewer subscriptions |
The CAF recommendation — one subscription per workload per environment, e.g. separate subscriptions for "App A Production" and "App A Non-Production" — sounds like it produces subscription sprawl of its own, and it does produce more subscriptions than a shared model. The difference is that this sprawl is structured: every subscription has a clear owner, a clear cost boundary, and a clear place in the management group hierarchy, versus the unstructured sprawl of fifty ad hoc subscriptions with four naming conventions and no shared governance.
Unlike workload subscriptions, the platform side typically stays intentionally small — a Management subscription, an Identity subscription, and a Connectivity subscription cover most organizations' shared-services needs, sometimes with additional Connectivity subscriptions for multi-region or regulatory requirements. These are provisioned once by the platform team, rarely by self-service, since they carry the shared infrastructure every workload subscription depends on.
Azure Landing Zones support two network topologies, and the choice is largely a function of scale and operational preference rather than one being universally "better."
| Aspect | Hub-and-Spoke (traditional) | Virtual WAN |
|---|---|---|
| Management model | You build and manage the hub VNet, gateways, and peering yourself | Microsoft-managed backbone; you configure connections, not the underlying transit infrastructure |
| Best fit | Single region or a small number of regions; teams wanting full control over hub configuration | Many regions, many branch/VPN connections, large-scale global connectivity |
| Complexity at scale | Grows manually — more regions means more hubs to manage and peer | Scales more automatically — Virtual WAN handles cross-region transit natively |
| Familiarity | Well-understood, widely documented, easier to reason about for smaller teams | Newer mental model; fewer engineers have deep operational experience with it |
Both topologies share the same core landing zone principle: shared connectivity infrastructure — firewalls, gateways, DNS — lives centrally (in the hub or in Virtual WAN's managed backbone), and workload subscriptions connect to it rather than each building their own path to the internet or on-premises networks.
One of the most common landing zone anti-patterns is over-engineering the network topology relative to actual scale — deploying Virtual WAN, Azure Firewall Premium, and a full Sentinel deployment to support twenty resources. The governance infrastructure ends up costing more, and requiring more specialized operational knowledge, than the workloads it protects. Hub-and-spoke is a perfectly sufficient, well-understood starting point for most organizations; grow into Virtual WAN when the number of regions and connection types genuinely justifies it.
Whichever topology you pick, the hub typically hosts the same core set of shared services: Azure Firewall (or a third-party NVA) for centralized egress and inter-spoke traffic inspection, VPN Gateway and/or ExpressRoute Gateway for on-premises connectivity, Azure Bastion for secure RDP/SSH access to VMs without exposing public IPs, and Private DNS Zones for name resolution across private endpoints. These live in the Connectivity platform subscription, managed centrally, consumed by every spoke.
Governance is where the management group hierarchy actually pays off — Azure Policy assignments at each level enforce and audit rules automatically, without a human checking every new subscription by hand. A mature enterprise-scale landing zone commonly carries well over 100 policy assignments across the hierarchy, though the count matters far less than the coverage.
| Policy category | Example rule | Typical assignment level |
|---|---|---|
| Tagging | Require costCenter, owner, environment tags on all resources | Tenant Root — applies everywhere |
| Allowed locations | Restrict resource deployment to approved regions | Tenant Root or Landing Zones |
| Network exposure | Deny public IP creation on VMs | Landing Zones (Corp especially) |
| Encryption | Require encryption at rest for storage accounts, disks | Tenant Root |
| Diagnostics | Require diagnostic settings sending logs to the central Log Analytics workspace | Tenant Root or Landing Zones |
| Security posture | Require Microsoft Defender for Cloud plans enabled | Tenant Root |
| Non-production controls | Auto-shutdown schedules, relaxed SKU restrictions | Non-Production sub-groups only |
Every new policy assignment should typically start in Audit effect — logging non-compliant resources without blocking them — so you can measure the real-world impact before switching to Deny, which actively blocks non-compliant deployments. Flipping straight to Deny on a policy nobody has validated against real traffic is a common way to turn a governance improvement into an unplanned outage for a team who had no warning their deployment pattern would suddenly fail.
Microsoft's own design principles guidance is explicit that segmenting workloads differently from the management group hierarchy — grouping by Azure service instead of by the organizational structure the hierarchy assumes, for instance — increases governance policy complexity and access control complexity measurably. It's not a hypothetical risk; it's a documented, common failure mode. Align workload organization to the management group hierarchy rather than working around it, unless there's a specific, well-understood reason not to.
A landing zone's security baseline is what every workload inherits by default, before any application-specific hardening. Three pillars carry most of the weight.
| Pillar | What it establishes | Where it lives |
|---|---|---|
| Identity (Microsoft Entra ID) | The primary security boundary. Role-based access control, Conditional Access, Privileged Identity Management for just-in-time elevated access | Tenant-wide, foundational to everything else |
| Microsoft Defender for Cloud | Cloud Security Posture Management (CSPM) and workload protection plans — vulnerability scanning, threat detection, secure score | Enabled tenant-wide via policy, typically enforced from Tenant Root |
| Microsoft Sentinel | Centralized SIEM/SOAR — security event correlation and response across the whole estate | Deployed in the Management platform subscription, ingesting from every workload |
Identity-related risk is consistently cited as a top driver of landing zone security design — role-based access, least-privilege, and Zero Trust principles need to be built into the identity model from the start, because retrofitting access control after hundreds of role assignments already exist is a much harder problem than designing it correctly from the first subscription.
Whether your organization needs to demonstrate alignment with HIPAA, PCI DSS, SOC 2, FedRAMP, GDPR, or another framework, the mechanism is the same one this guide has already described: policy initiatives (bundled sets of individual policies) assigned at the appropriate management group level, with Defender for Cloud's regulatory compliance dashboard providing continuous, automated evidence of adherence rather than a periodic manual audit. Compliance isn't a bolt-on to the landing zone — it's an expression of the same governance-at-scale mechanism, applied to a specific framework's requirements.
A landing zone's governance is only as good as how easy it is for teams to actually get a compliant subscription. If getting a new subscription takes three weeks of tickets, application teams will find workarounds — reusing an existing subscription, or escalating for an exception — that quietly erode the isolation the whole architecture was designed to provide. Subscription vending is the fix: an automated, typically self-service process that provisions a new, correctly-configured subscription on demand.
| Step in a vended subscription's creation | What happens automatically |
|---|---|
| Request submitted | A team requests a new subscription via a form, portal, or pull request — self-service, no manual ticket triage |
| Approval (if required) | Lightweight approval gate, often automated for standard requests and manual only for exceptions |
| Subscription created | New subscription provisioned under the correct management group automatically |
| Policy inheritance | Governance policies apply immediately, inherited from the management group — no separate configuration step |
| Network peering | Spoke VNet created and peered to the hub automatically |
| Monitoring wired up | Diagnostic settings pointed at the central Log Analytics workspace |
| RBAC assigned | Requesting team granted appropriate roles on their new subscription |
The difference this makes in practice is stark: a manual, ticket-driven process commonly takes weeks; an automated vending process can complete the same work in minutes. That speed difference is what determines whether teams work within the governed platform or route around it.
The eighth design area — platform automation and DevOps — is not an optional extra layered on top of the architecture; it's how the architecture stays correct over time. Management group structure, policy assignments, the hub network, and the subscription vending process itself should all be defined in Bicep or Terraform, stored in source control, and deployed through a reviewed pipeline. A landing zone configured by hand through the portal drifts from its documented design the first time someone makes an emergency change under pressure and forgets to document it — infrastructure as code is what keeps the deployed reality matching the architecture this guide describes.
A practical, ordered path from zero to a working platform foundation, using the Azure Landing Zone accelerator as the starting point rather than hand-building every management group and policy from scratch.
Design the management group hierarchy on paper before deploying anything
Start from the reference hierarchy (Platform / Landing Zones / Sandbox / Decommissioned), and validate it against your actual organizational structure and operating model. This is the decision that's hardest to change later — get explicit sign-off from whoever owns governance before moving to deployment.
Decide your networking topology: hub-and-spoke or Virtual WAN
Base this on your actual region count and connectivity needs today, not a guess about future scale. Most organizations starting out should default to hub-and-spoke; reserve Virtual WAN for genuinely multi-region, multi-connection scenarios.
Deploy the platform foundation using the Azure Landing Zone accelerator
Use the portal-based wizard for a first exploratory deployment, or go straight to the Bicep or Terraform module set if your team is ready to manage it as code from day one. This step provisions the management group hierarchy, the Management/Identity/Connectivity subscriptions, the hub network, and a baseline set of policy assignments in one coordinated deployment.
Validate the baseline policy set in Audit mode before enforcing Deny
Let the accelerator's default policies run in audit-only mode against your environment for a defined period — a few weeks is common — and review what would have been blocked. Adjust exceptions or policy parameters based on real findings, then move validated policies to Deny.
Build and test the subscription vending process
Before onboarding any real application team, provision a test subscription through your vending pipeline end to end — request, approval, creation, management group placement, network peering, monitoring, RBAC — and confirm every step actually works as designed, not just individually but as a full chain.
Onboard one pilot workload team before opening broadly
Choose a real but low-risk application team as your first tenant. Their experience — how long provisioning actually took, which policies caused friction, what documentation was missing — is far more valuable feedback than anything caught in internal testing, and it's much cheaper to fix issues discovered with one team than after fifty teams have onboarded.
Document the platform and open self-service vending broadly
Publish the subscription request process, the management group structure, the policy set, and who owns what — then open the vending process to the rest of the organization. This is the point where the landing zone stops being a project and starts being the platform.
A minimal landing zone using the accelerator's defaults can be stood up in days. A fully customized enterprise deployment — custom policies, hybrid networking, multiple compliance frameworks, CI/CD-driven platform automation — realistically takes several weeks of dedicated architecture and engineering time, even with strong automation. Be wary of either extreme claim: "days" for a fully customized enterprise environment undersells the real design work involved, and "months" for a straightforward, accelerator-driven deployment usually reflects process friction more than technical necessity.
A landing zone isn't immune to producing sprawl of its own if the design or the operating discipline around it goes wrong. These are the specific ways that happens.
| Anti-pattern | Why it feels right | Why it isn't |
|---|---|---|
| Skip the landing zone, plan to "add governance later" | "We need to move fast; governance can catch up" | Governance later never comes cheaply — by the time it does, there are hundreds of unmanaged resources and the fix is a remediation project costing multiples of what up-front design would have |
| Over-engineer on day one | "Let's build the full enterprise architecture from the start" | Virtual WAN, Firewall Premium, and a full Sentinel deployment for twenty resources means the governance infrastructure costs more than the workloads it protects, and adds operational complexity nobody yet needs |
| Copy the reference hierarchy without validating against your operating model | "Microsoft's diagram must be right for us too" | The reference assumes a specific operating model. A strongly federated organization forcing itself into a centralized hierarchy creates friction the diagram doesn't warn you about |
| No subscription vending automation | "We'll handle subscription requests manually for now" | Slow, manual provisioning is exactly what pushes teams toward workarounds — reusing subscriptions, requesting exceptions — that quietly recreate the sprawl the landing zone exists to prevent |
| Configure the platform by hand through the portal | "Just this once, it's faster than writing Bicep" | Manual changes drift from documented design immediately and invisibly. The next person to read the Bicep templates sees a platform that no longer matches what's actually deployed |
| Flip new policies straight to Deny without an audit period | "We're confident this policy is correct" | An unvalidated Deny policy can block a legitimate, unanticipated deployment pattern with no warning — turning a governance improvement into an outage for whichever team hits it first |
Key Takeaways
Frequently Asked Questions
Related FAVRITE Articles
- How Azure Resource Manager Differs from the Classic Deployment Model
- Azure Availability Set vs Availability Zone: The Complete Guide
- RBAC for Azure Files: Least-Privilege Access Patterns
- Microsoft Defender for Cloud: A Practical Guide