Azure Landing Zone Structure — Diagram
What sits at each level of an Azure hierarchy and why — where policy applies, where blast radius stops, and the two decisions that are expensive to reverse once resources exist.
SVG. No sign-up, no email.
The Azure hierarchy is four levels, and each one exists for a different reason. Getting the allocation roughly right takes a day at the start and becomes a migration project after a year of growth.
The diagram shows what belongs at each level and what each level actually gives you.
What each level actually gives you#
Management groups carry policy. Assign once at the right level and every subscription beneath inherits it — allowed regions, required tags, denied public network access. Without them you are applying the same rules repeatedly and discovering the gaps during an incident.
Subscriptions are where the practical boundaries sit: blast radius, quota limits, and cost attribution that works without any tagging discipline. This is why production gets its own, regardless of size.
Resource groups are a deletion and lifecycle boundary. Group things created, updated and deleted together.
Resources are cheap to move and rarely worth agonising over.
The trap in resource groups#
Grouping by resource type — "all the databases", "all the storage" — feels tidy and works against the one thing a resource group is for. It is a deletion boundary; if the things inside it do not share a lifecycle, you can never safely delete it, and it accumulates orphans indefinitely.
Group by what dies together.
Why the middle lane has no arrows#
Subscriptions are siblings, not a sequence. The important property is that they are isolated from each other: a policy mistake in one cannot reach into another, and their costs are separable without any tagging.
That isolation is why "we will separate production later" is a decision to do a migration.
Sandbox needs a hard spend cap#
The sandbox management group exists so people can experiment without fighting policy. That same looseness is why it needs a budget with a hard limit rather than an alert.
An alert tells you afterwards. In a sandbox, afterwards is the wrong time.
The two shaded levels#
Management group structure and subscription allocation are the expensive ones. Both are a day's work before resources exist and a project afterwards, because moving a resource between subscriptions is not always possible and is never free.
Resource groups, by contrast, are cheap to reorganise. Do not spend the same care there.
See Azure, the landing zone checklist, and the cost overrun example for what happens when the tagging that depends on this structure is not in place.