Azure Diagram Guide

Azure landing zone diagram: management groups, subscriptions, and hub and spoke

By the engineer who builds Datadef, from client work on data platforms · Reviewed August 21, 2026

Landing zone diagrams fail for a structural reason. There are two hierarchies in play, the governance scope tree and the network topology, and they do not nest the same way. A diagram that mixes them produces boxes where nobody can tell whether a container is a management group, a subscription, a resource group, or a virtual network. This page separates them and then puts them back together deliberately.

Try it free
8 min readFor platform teams presenting an Azure landing zone to architecture review

See it as a diagram

Everything below, as a diagram you can edit. Describe yours and see it in seconds.

316/2000• 3 credits left
Try:

No account needed · Editable canvas, not a picture

A landing zone diagram is two diagrams stacked

The governance layer is a scope tree: tenant root group, an intermediate root group named after the organisation, then Platform, Landing Zones, Sandbox, and Decommissioned, with subscriptions hanging off the leaves. Platform typically holds Identity, Management, and Connectivity. Landing Zones typically splits into Corp for internally routed workloads and Online for internet-facing ones.

The network layer is a topology: one hub virtual network with Azure Firewall, a gateway subnet carrying ExpressRoute or VPN, and Bastion, peered to spoke virtual networks that live in the workload subscriptions. Peering is not hierarchical, so it cannot be drawn as nesting.

The reliable way to combine them is to let the subscription be the outer zone and the virtual network be a zone inside it, then draw peering as explicit edges between those inner zones. The management group tree above the subscriptions becomes a compact bracket or a separate small panel rather than another layer of nested rectangles. If the audience is a governance review, draw the scope tree alone and skip the network entirely.

Policy is a property of a scope, so label the zone

Azure Policy assignments, RBAC role assignments, and cost budgets are attributes of a management group or a subscription. They do not consume traffic and they do not sit anywhere in a flow, so giving them their own boxes in the middle of the topology invents relationships. This is not a stylistic preference here: in the Terraform resource catalog behind the repository parser, azurerm_role_assignment is classified as wiring, meaning it can never become a node no matter how many of them a stack declares. On a landing zone that is the difference between a readable picture and a wall of identical squares.

Write them on the zone header instead: the Corp management group zone labelled with the policy initiative that denies public IPs, the Connectivity subscription labelled with the network contributor assignment. The Azure set does ship a Policy icon, which is useful in a legend or a small governance panel where you list initiatives.

The same rule applies to Microsoft Defender for Cloud and Microsoft Sentinel. They are platform capabilities scoped at a management group, so they belong in the Management subscription zone with a label saying what they cover, not as nodes in the traffic path.

The icons the Azure set actually ships for this

Microsoft added a dedicated Azure landing zone icon in the November 2024 batch, alongside a mission landing zone variant, so the top-level container no longer needs a generic rectangle. If your reference diagrams predate that batch they will be using a plain container or the Subscriptions mark instead, which is why older landing zone pictures look inconsistent with newer ones. Around it: Management Groups, Subscriptions, Policy, Resource Groups, and the Entra ID family for the identity subscription.

Connectivity: Virtual Networks, Virtual Network Gateways, ExpressRoute Circuits, Firewalls and Firewall Manager, Bastions, Front Door, Application Gateway, Web Application Firewall policies, Private Link and Private Link services, DNS Zones and the DNS Private Resolver, and Route Tables. Management: Log Analytics Workspaces, Monitor, and Key Vaults.

Datadef carries 624 Azure icons, which is enough that every service in the Cloud Adoption Framework reference topology resolves by name. The full collection is at Azure architecture icons, and single files like the virtual network icon have their own pages.

Name the spokes after workloads

A landing zone diagram with spokes labelled spoke-1 and spoke-2 communicates the pattern and nothing about your estate. Name them after the workloads or the business units that own them, and the diagram starts answering ownership questions on its own.

Keeping it true after month three

Landing zones are deployed from code, and the code is usually Terraform. Connect the repository with read-only access to GitHub, GitLab, or Azure DevOps, pick a branch or a tag, and every .tf file is parsed as text: no terraform init, no state file, no cloud credentials. Directories of .tf files become module units and become zones on the canvas. A module call to the registry cannot be expanded locally, so it renders as one node that keeps its source and its version, which is the honest rendering of a caf-enterprise-scale style dependency rather than a guess at what it provisions.

Per-environment counts are where a landing zone diagram usually lies. A for_each driven by a variable bound differently in environments/DEV and environments/QUAL is read from the tfvars rather than assumed, so a node comes back labelled with the real spread, "per spoke_networks (DEV 2, QUAL 1)", instead of one box implying one of everything. A count that resolves to zero is labelled as not deployed rather than silently drawn.

That matters more for a landing zone than for most architectures, because the estate grows by subscription and the hand-drawn version is wrong within a quarter. The diagram and its architecture document rebuild on a daily sync, a commit with no structural change skips regeneration outright, and any node somebody dragged more than twelve pixels from where the previous sync left it keeps the position they gave it. See terraform module diagrams for how modules map to zones.

Export the current version to PNG or JPEG for the steering deck, and put the live embed in the platform wiki so the reference topology page stops drifting.

FAQ

What should an Azure landing zone diagram show?

The management group hierarchy with its subscriptions, the hub virtual network with Azure Firewall and the gateway subnet, the spoke virtual networks peered to it, the shared identity and management services, and the policy initiatives assigned at each scope. Which of those leads depends on whether the audience is a governance review or a network review.

Should management groups and virtual networks be on the same diagram?

They can be, if the subscription is the outer container and the virtual network is drawn inside it, with peering as explicit edges. They should not be flattened into one nesting sequence, because management group containment and network peering are different relationships and a reader cannot tell them apart from rectangles alone.

Which icon represents an Azure landing zone?

The official Azure icon set includes a dedicated Azure landing zone mark, added in the November 2024 batch, along with a mission landing zone variant. Before that batch most diagrams used a generic container or the Subscriptions icon, which is why reference pictures drawn on either side of that date do not look alike even when both used official artwork.

How do I show Azure Policy on a diagram?

As a label on the scope it is assigned to, rather than as a node in the traffic path. Policy assignments and RBAC role assignments are properties of a management group or a subscription, so writing the initiative name on the zone header keeps the relationship accurate and keeps the topology readable. Use the Policy icon in a legend or a small governance panel if you need to list initiatives by name.

Does the diagram need every spoke?

No. Draw the distinct spoke archetypes, typically one internally routed Corp spoke and one internet-facing Online spoke, and put the real count in a label on the zone. Twenty near-identical spoke rectangles make the hub harder to read without adding information, and they hide the one spoke that differs, which is usually the one the review is actually about.