Azure Landing Zone Architecture Guide

An Azure landing zone is the governed foundation that prevents all of that — a management group hierarchy, a subscription strategy, a network topology and a policy baseline, established before workloads arrive rather than retrofitted around them.

This guide covers the architecture, the decisions that are expensive to reverse, and a realistic build order. It also flags the tooling change most online tutorials have not caught up with.

What Is an Azure Landing Zone?

A landing zone is not a product or a single Azure resource. It is an environment that has already made its governance decisions, so that a workload team can be given a subscription and start building without negotiating identity, networking or compliance from scratch.

Microsoft's Cloud Adoption Framework defines it across eight design areas:

The useful mental model: a landing zone is a metropolis, not a building. Roads, power, water and zoning laws exist before anyone constructs a house. Workload teams build houses.

When you need one

• More than 5–10 subscriptions, or that many arriving within a year
• A compliance obligation where auditors ask how controls are enforced, not whether they are documented
• Overlapping VNet address ranges already causing peering problems
• Subscriptions being requested by ticket, each configured slightly differently
• A migration programme about to move workloads in bulk

When you do not

One team running one product in two subscriptions does not need this. It needs Defender for Cloud enabled, MFA enforced, a budget alert and infrastructure as code. Building a full enterprise-scale foundation for that workload adds friction without adding safety.

The honest threshold: build a landing zone when the cost of inconsistency exceeds the cost of the platform, which for most organisations lands somewhere between five and fifteen subscriptions, sooner if regulated.

Management Groups, Subscriptions, and Enterprise-Scale Design

The hierarchy is the architecture

Management groups are containers for subscriptions, and Azure Policy and RBAC inherit downward through them. Where a subscription sits determines what it is permitted to do. Get this structure right and governance is a placement decision; get it wrong and you are assigning policy per subscription forever.

The CAF reference hierarchy:

Tenant Root Group          ← leave empty
└── Intermediate Root      ← your org; everything hangs here
    ├── Platform
    │   ├── Identity
    │   ├── Management
    │   └── Connectivity
    ├── Landing Zones
    │   ├── Corp
    │   └── Online
    ├── Sandbox
    └── Decommissioned

Corp and Online are the distinction that matters most. Corp landing zones host workloads that need corporate connectivity and no public endpoints — policy denies public IPs outright. Online landing zones host internet-facing applications that may not need hub connectivity at all. Two genuinely different policy sets, so two management groups.

Rules worth treating as non-negotiable

• Never assign policy at the Tenant Root Group. It applies to everything with no escape hatch, and it is awkward to manage. Create an intermediate root and work below it.
• Keep the hierarchy shallow. Azure supports six levels below root; three or four is plenty. Deep nesting makes policy evaluation impossible to reason about during an incident.
• Nothing runs in the Platform management group directly — its children hold the subscriptions.
• Group by policy, not by org chart. If two subscriptions need identical policy, they belong together regardless of which department pays.

Subscriptions are the unit of scale

A subscription in Azure is a scale and billing boundary, not a security perimeter in the way an AWS account is. Azure quotas apply per subscription per region, so subscriptions are how you avoid hitting ceilings.

The pattern that works: one subscription per application per environment. Production and non-production are separated by subscription, not by resource group, because that is what lets you apply genuinely different policy, RBAC and budget.

Split when any of these is true:

• Different environments — production and non-production always separate
• Different compliance scope — PCI workloads isolated from everything else
• Quota pressure — vCPU or resource limits approaching the ceiling
• Different cost ownership — separate invoices, separate budgets
• Different blast radius tolerance

Do not split simply because a new team exists. A team with three applications in one environment can share a subscription with resource-group-level RBAC.

Subscription vending

Once the hierarchy exists, creating subscriptions by hand defeats the point. A vending process should produce a subscription that already has: correct management group placement, RBAC assigned from Entra groups, VNet with address space allocated from a central register, peering to the hub, budget alerts, tags, and a diagnostic settings configuration sending logs to the central workspace.

Two numbers tell you whether it works:

A note on tooling, because this changed recently

If you are following a tutorial that tells you to use terraform-azurerm-caf-enterprise-scale or ALZ-Bicep Classic, it is out of date. Both have been superseded by Azure Verified Modules for Platform Landing Zone (ALZ), which is now the default starter module in both the Bicep and Terraform accelerators.

The timeline, so you can judge what you are reading:

• February 2026 — ALZ-Bicep Classic removed from the accelerator; repository archives February 2027
• August 2026 — terraform-azurerm-caf-enterprise-scale archived, no further updates

Use the ALZ IaC Accelerator, which bootstraps a continuous delivery pipeline against Azure DevOps or GitHub. For other version control systems, the alz_local bootstrap module produces the code and you wire up the pipeline yourself.

One thing to expect: the accelerator deploys the management group hierarchy, subscription placement and connectivity resources. It deliberately does not deploy every CAF design area — security, management and monitoring are separate, and policy assignments are archetype-driven. If your custom archetypes do not inherit or explicitly include policy and role assignments, nothing is applied. This surprises people who assume the accelerator is a complete environment.

Bicep or Terraform is mostly an organisational question. Bicep is native, needs no state management, and suits Azure-only estates. Terraform suits multi-cloud teams and those with existing expertise — the kind of decision covered in our Terraform consulting work.

Platform vs. Application Landing Zones

The distinction is one of the more useful ideas in the framework and is frequently blurred in practice.

Platform landing zones: the three subscriptions

Identity — domain controllers if you run hybrid AD, Entra Connect, and identity infrastructure. Often not needed in cloud-only estates.

Management — the central Log Analytics workspace, automation accounts, backup vaults, monitoring. This is where the answer to "what happened?" lives, so it needs to be readable by the people who ask and writable by nobody else.

Connectivity — the hub VNet, Azure Firewall, VPN and ExpressRoute gateways, private DNS zones. Owned entirely by the platform team; workload teams consume it via peering and never modify it.

Application landing zones: what teams actually get

A workload team receives a subscription that is already governed. They can create resources, deploy applications and manage their own RBAC within it. They cannot turn off diagnostic logging, deploy to unapproved regions, create public IPs in a Corp landing zone, or modify hub connectivity.

The line to hold: platform teams own the guardrails, workload teams own everything inside them. When a platform team starts approving individual application deployments, it has become a bottleneck rather than a platform — the same failure mode we cover in platform engineering vs DevOps vs SRE.

Workload-specific accelerators

Microsoft publishes landing zone accelerators for specific workload types — AKS, Azure Virtual Desktop, API Management, App Service, Container Apps, HPC and others. Each deploys a reference implementation of that workload into an existing enterprise-scale landing zone.

They are genuinely useful as starting points, but they assume the platform landing zone already exists. Build the foundation first.

Networking: Hub-Spoke vs. Azure Virtual WAN

The comparison

Choosing

Hub-spoke if you operate in one or two regions, need a specific third-party firewall, or require precise control over routing. It is the more familiar model and the one most network teams can reason about.

Virtual WAN if you have many regions, many branch offices, or a global network where managing inter-hub connectivity manually would become the job. The managed transit routing is the main draw — with hub-spoke across five regions you are maintaining a peering mesh by hand.

The practical tipping point is roughly three or more regions with any-to-any connectivity requirements. Below that, hub-spoke is usually simpler and cheaper.

Address space, before anything else

This is the decision with the worst reversal cost in the entire architecture. Re-IPing a live production VNet means downtime, and there is no shortcut.

Allocate deliberately — overall space first, then region, then environment:

10.0.0.0/8              Organisation total
  10.0.0.0/12           Region A
    10.0.0.0/16         Platform / hub
    10.1.0.0/16         Corp production
    10.2.0.0/16         Corp non-production
    10.3.0.0/16         Online
  10.16.0.0/12          Region B
    ...
  Reserved              VPN clients, acquisitions, second tenant

Keep a central register, and have your subscription vending process allocate from it rather than letting teams choose. Convention alone always fails eventually.

Two practical points teams learn late:

• Size VNets larger than feels necessary. AKS with Azure CNI consumes an IP per pod, and running out of addresses in a live cluster is a genuinely bad day.
• Leave deliberate gaps for a region you do not use yet, or an acquisition. Gaps cost nothing; filling them later costs a migration.

Centralise egress and DNS

Route outbound traffic through Azure Firewall in the Connectivity subscription. One inspection point, one rule set, one place to answer "what left our network?".

Private DNS zones belong in Connectivity too, linked to spoke VNets. Zones created per-subscription produce resolution failures that are genuinely difficult to diagnose, usually at the worst moment.

Identity, Security, and Governance in an Azure Landing Zone

Identity

Microsoft Entra ID is the control plane. Get four things right:

• Groups, not users, in RBAC assignments. Assign roles to Entra groups; manage membership through your existing identity processes.
• Privileged Identity Management for elevated roles. Owner and Contributor at management group scope should be time-bound and approval-gated, not standing.
• Conditional Access on everything administrative. MFA for portal access, device compliance for privileged operations.
• Break-glass accounts excluded from Conditional Access, with alerting on any use.

The deeper principle: assign RBAC at management group or subscription scope, not resource by resource. Resource-level assignments accumulate, become undocumented, and nobody dares remove them.

Security

The baseline every landing zone should have on day one:

• Microsoft Defender for Cloud enabled at subscription scope, with the plans that match your workloads
• Diagnostic settings sending activity logs and resource logs to the central Log Analytics workspace, enforced by policy
• Key Vault for secrets, with purge protection and soft delete on
• Customer-managed keys where compliance requires them
• Microsoft Sentinel if you have a SOC that will actually use it

The Microsoft Cloud Security Benchmark policy initiative gives you a reasonable starting set of controls without designing them yourself. This is the same territory as broader cloud security and DevSecOps work — the controls are only useful if they run automatically.

Governance through Azure Policy

Policy is what makes a landing zone a landing zone rather than a diagram. Four effects matter:

Roll out in Audit mode first. Assign a policy as Audit, look at what it would have blocked, fix the non-compliant resources, then switch to Deny. Going straight to Deny on a live estate breaks deployments in ways that are hard to attribute.

Policies inherit downward, so assign at the highest management group where the rule genuinely applies. A policy assigned to Landing Zones applies to both Corp and Online; one that only makes sense for Corp belongs on Corp.

Cost governance belongs here too — budgets per subscription with alerts at 80% and 100%, and a tag policy enforcing cost centre at creation rather than reconciling at month end. Tags applied retrospectively never reach full coverage, which is the root of most cloud cost attribution problems.

How to Plan an Azure Landing Zone Architecture

Sequence the decisions

Some choices constrain everything downstream. Make them in this order:

1. Tenant and billing structure. One tenant or several? Enterprise Agreement, MCA or CSP?
2. Management group hierarchy. Start from CAF's reference design and adapt rather than inventing.
3. Address space allocation. Before any VNet exists. This is the irreversible one.
4. Network topology. Hub-spoke or Virtual WAN, and which regions.
5. Identity model. Entra groups, RBAC scopes, PIM configuration.
6. Policy baseline. Start with Microsoft Cloud Security Benchmark, add your own.
7. Subscription vending. Automate before the requests start arriving.

Realistic timelines

Based on how these projects actually run:

The accelerator itself is fast — a bootstrap that once took weeks now runs in minutes. The time goes into the decisions, not the deployment. Agreeing the management group structure across three business units takes longer than deploying it.

Common mistakes

• Deploying the accelerator before agreeing the structure. It is easy to run and produces a hierarchy someone has to live with.
• Allocating IP space after subscriptions exist. Overlapping CIDRs surface when two VNets first need to talk, months later.
• Running workloads in platform subscriptions. Connectivity and Management are infrastructure, not hosting.
• Enforcing policy before auditing it. Deny-first rollouts break deployments in ways nobody can attribute.
• Treating the landing zone as a project. It needs an owning team and a change process, or it drifts within two quarters.

Migrating existing subscriptions in

Moving a subscription between management groups is straightforward — policy re-evaluates and applies. The hard part is what is already inside: overlapping address space, IAM assignments at resource scope, resources in unapproved regions, missing diagnostic settings.

The workable sequence: build the hierarchy, place new subscriptions into it, then migrate existing ones one at a time, starting with the least critical. A Transitional management group with relaxed policy gives you somewhere to park subscriptions while you remediate them.

If this runs alongside a migration programme, sequence matters: landing zone first, then migration waves. Attempting both simultaneously is how you end up migrating workloads twice — a pattern our cloud migration services team sees regularly.

Conclusion

An Azure landing zone is mostly a set of decisions, and a handful of them are effectively permanent.

The management group hierarchy is the architecture. Policy and RBAC inherit downward, so where a subscription sits determines what it can do. Start from the CAF reference — Platform, Landing Zones, Sandbox, Decommissioned under an intermediate root — and adapt rather than invent. Group by the policy accounts need, not by org chart, and never assign at Tenant Root. Keep it shallow: three or four levels is plenty.

Address space is the decision you cannot undo cheaply. Allocate the whole range before the first VNet exists, subdivide by region then environment, leave deliberate gaps for regions and acquisitions you do not have yet, and have your vending process allocate from a central register. Overlapping CIDRs are discovered months later when two VNets need to peer, and the only fix is re-IPing something live.

Platform and application landing zones are genuinely different things. Three platform subscriptions — Identity, Management, Connectivity — owned by the platform team and consumed as a service. One application subscription per app per environment, owned by the workload team, governed by policy rather than by approval queues. When the platform team starts approving individual deployments, it has become the bottleneck it was meant to remove.

Policy makes it real, and Audit mode makes it safe. Assign as Audit, look at what would have been blocked, remediate, then switch to Deny. Enable Defender for Cloud and enforce diagnostic settings from day one. Budgets and tag policy at creation, not reconciliation at month end.

Check your tooling before you start. ALZ-Bicep Classic left the accelerator in February 2026 and terraform-azurerm-caf-enterprise-scale was archived in August 2026. Azure Verified Modules for Platform Landing Zone is the current default for both Bicep and Terraform. A surprising number of tutorials still online point at the archived modules.

The accelerator will stand up a hierarchy in minutes. Decide what that hierarchy should be first — that part takes weeks, and it is the part that matters.

If you are building a foundation, inherited one that has drifted, or need existing subscriptions brought under governance without disrupting production, our cloud migration services and Terraform consulting cover exactly this — hierarchy design, policy rollout, subscription vending and the network foundation underneath. Related reading: our AWS landing zone guide covers the same problem on the other major cloud.

Talk to our team → We will start with your subscription inventory and your address space, because that is where the expensive surprises live.