Azure Landing Zone Diagram: Management Groups, Subscriptions and Hub Networking

Most Azure estates start the same way. Someone creates a subscription for a pilot, then one for production, then each team gets its own. Two years later, 40 subscriptions sit under the tenant root group, three run their own VPN gateways, a database VM has a public IP, and nobody knows which policies apply where.

An Azure landing zone is Microsoft's blueprint for avoiding that. This post covers each part with a diagram: management groups, platform versus workload landing zones, policy guardrails, hub-and-spoke versus Virtual WAN, identity and deployment.

What an Azure landing zone is

The Cloud Adoption Framework (CAF) defines an Azure landing zone as "a proven and flexible architecture for governing, securing, and scaling a multi-subscription Azure environment" (Microsoft Learn). It has two parts:

• The platform landing zone: the management group hierarchy plus shared resources such as the hub network, logging and security tooling. Microsoft recommends one per Microsoft Entra tenant, run by a platform team.
• Workload landing zones: one per workload, owned by its team, holding every environment (development, test, production) as one or more subscriptions. Older material calls them application landing zones.

The subscription is the building block: CAF calls it a unit of management, billing and scale. In AWS terms, a subscription is roughly an account and a management group an organizational unit; the AWS landing zone diagram shows that side.

The management group hierarchy

A policy or role assignment on a management group applies to everything below it, and subscription owners cannot alter it. Azure allows 10,000 management groups per tenant, six levels below the root and one parent each, according to the management groups documentation.

The reference hierarchy, with notes from the default ALZ policy assignments:

Three rules from the CAF management group guidance save most redesigns:

1. Keep it flat. Three or four levels are enough; do not add management groups for regions or for development, test and production.
2. Assign at the intermediate root, not the tenant root. New subscriptions land under the tenant root by default, and any user can create management groups until you require permission. Change both, and make Sandbox the default.
3. Give workload teams roles at subscription scope. Platform teams may hold roles on management groups, controlled with just-in-time access.

Names are shifting: Security joined Platform in 2025, and the newest CAF overview uses "Workload landing zones" for Landing zones and "Internal" for Corp.

Platform versus workload landing zones

In subscription vending, a request, often a pull request, creates the subscription under Corp or Online, assigns roles and a budget, and for Corp adds a spoke peered to the hub. Microsoft publishes vending modules for Bicep and Terraform.

Policy-driven guardrails

Azure Policy turns the hierarchy into enforcement: assign a rule once at a management group, and every current and future subscription below inherits it.

Region rules need care: the built-in Allowed locations policy skips resource groups and the global location, so pair it with Allowed locations for resource groups, and start in DoNotEnforce mode to see what it would block:

az policy assignment create \
  --name allowed-locations \
  --scope /providers/Microsoft.Management/managementGroups/contoso \
  --policy e56962a6-4747-49cd-b67b-bf8b01975c4c \
  --params '{"listOfAllowedLocations": {"value": ["westeurope", "northeurope"]}}' \
  --enforcement-mode DoNotEnforce

Timing matters: a new assignment applies in about five minutes, a subscription moved into a management group is evaluated in about 30 minutes, and a full scan runs every 24 hours. DeployIfNotExists and Modify policies act on new and updated resources; existing ones need a remediation task.

Networking: hub-and-spoke or Virtual WAN

The connectivity subscription owns the shared network: Azure Firewall, VPN and ExpressRoute gateways, Bastion, private DNS zones and the DNS Private Resolver. CAF's network topology guidance offers two designs:

Peering is non-transitive, so in a hub virtual network each spoke gets a route table that sends 0.0.0.0/0 to the firewall's private IP, the hub peering allows gateway transit, and the spoke peering uses the remote gateway; the hub-and-spoke network topology post covers the routing. Azure Firewall Basic handles up to 250 Mbps, Standard 30 Gbps and Premium 100 Gbps. For Virtual WAN, pick the Standard type; Basic supports only site-to-site VPN.

DNS is where teams most often go wrong. Private DNS zones such as privatelink.blob.core.windows.net live in the connectivity subscription, linked to the hub, where the DNS Private Resolver forwards to Azure DNS at 168.63.129.16; on-premises DNS servers forward zones such as blob.core.windows.net to it. A DeployIfNotExists policy in Corp writes each private endpoint's record into the central zone, so workload teams need no rights on it.

Identity

The Microsoft Entra tenant is the identity boundary. CAF's practical rules:

• Grant workload teams roles on their own subscriptions during vending, never on management groups.
• Let platform engineers activate roles such as Owner through Privileged Identity Management (PIM), with approval and a time limit.
• Apply Conditional Access to everyone who manages Azure, and keep monitored emergency access accounts.
• Use the identity subscription for domain controllers or Microsoft Entra Domain Services if workloads still need them.

Deploying it

At the time of writing (November 2026), Microsoft recommends the Azure Landing Zones IaC Accelerator: Bicep or Terraform built on Azure Verified Modules (AVM). Its PowerShell module bootstraps a GitHub or Azure DevOps repository, pipelines with approvals, and managed identities with federated credentials. Terraform uses separate modules for the hierarchy and policy (avm-ptn-alz), management resources and each network design; Bicep uses deployment stacks, which can delete resources you remove from the templates.

Older options are retiring: the caf-enterprise-scale Terraform module is deprecated, and classic ALZ-Bicep left the accelerator on February 16, 2026, with its repository to be archived on February 16, 2027. A portal accelerator remains, but without code it is hard to update.

Budget for it. The accelerator's scenario page estimates fixed infrastructure at about $5,640 a month for a single-region hub and spoke with Azure Firewall, and $690 for the small-business variant, which among other things turns off the DDoS Network Protection plan (westus retail prices from April 2026, excluding traffic and logs). You also need four platform subscriptions, or two in the small-business setup.

The Azure landing zone diagram

How to read it:

• The tree on the left is the hierarchy; arrows point from parent to child, the direction of inheritance.
• The policy node hangs on the Contoso intermediate root, not the tenant root group, so it reaches the whole landing zone and nothing else.
• Colors show ownership: blue for platform, green for workloads, amber for Sandbox, gray for the root and retired subscriptions.
• Dashed edges show placement: the hub lives in the connectivity subscription, and both spokes are vended into Corp.
• Solid edges carry traffic: peering to the hub and the gateway link to on-premises; each spoke routes 0.0.0.0/0 to the firewall at 10.0.0.4.
• The Markdown block lists the key limits.

Drawing Azure landing zone diagrams clearly

• Draw governance and network as two views, linked only where a subscription lives.
• Attach each policy where it is assigned, so readers see which workloads it constrains.
• Show one or two example subscriptions per group, not an inventory.
• Write address ranges on the hub and every spoke; overlaps are the first thing reviewers check.
• Avoid the classic mistakes: peering drawn as transitive, workloads under the tenant root, and regions or environments as management groups.

See cloud architecture diagrams for typed cloud nodes, and the Terraform architecture diagram post for Terraform-managed estates.

Build it in Archboard

1. Sign in with Google or GitHub and create a diagram.
2. Add eight Cloud resource nodes from the Cloud pack: Tenant root group, Contoso, Platform, Landing zones, Corp, Online, Sandbox and Decommissioned. Put each role in the resource type line and arrange them as an indented tree.
3. Connect parents to children with orthogonal edges and color the branches: blue for Platform, green for Landing zones, amber for Sandbox.
4. Add a Policy node from the Security pack named Azure Policy guardrails and connect it to Contoso.
5. Add a VPC node from the Network pack for the hub, with a Router for the gateway and a Firewall inside, and two VPC nodes for the spokes, each with a Core Text line for its route.
6. Draw dashed edges from Platform to the hub and from Corp to the spokes, peering edges to the hub, and an edge from the gateway to an on-premises Text label.
7. Add a Markdown block from the Core pack with the limits.

If your landing zone is in Terraform, the Terraform to diagram tool turns the files into a first draft.

The example uses 15 diagram nodes, within the Free plan.

FAQ

What is an Azure landing zone? A multi-subscription Azure environment built to Cloud Adoption Framework recommendations before workloads arrive: management groups, policy guardrails, identity, logging and a shared network.

What management groups does an Azure landing zone use? An intermediate root under the tenant root group, with Platform (Management, Connectivity, Identity, Security), Landing zones (Corp, Online, Local), Sandbox and Decommissioned below it.

What is the difference between Corp and Online landing zones? Corp holds workloads that reach the corporate network through the hub, so the defaults deny public PaaS endpoints and public IPs on network interfaces there. Online holds workloads that need direct internet access or no virtual network.

Should I use hub-and-spoke or Virtual WAN? A hub virtual network suits a few regions, fewer than 30 site-to-site tunnels and full routing control; Virtual WAN suits many regions and branches, SD-WAN, or VPN-to-ExpressRoute transit.

Is the caf-enterprise-scale Terraform module still supported? No. It is deprecated and receives no updates. Use the Azure Verified Modules for the platform landing zone, usually through the IaC accelerator; Microsoft documents a migration path.

Start free — one seat, no credit card.