Business Challenge
A financial services platform team starts building in Azure the week their programme is approved. They need somewhere to put things, so they create one subscription per environment, three resource groups per application named after the tier they hold, and they leave every subscription directly under the tenant root because nothing in the portal suggests otherwise.
Eighteen months later, two things have gone wrong and neither announced itself. The first is access: a security engineer who needs read access across the estate has forty-one separate role assignments, because there was never a scope between "one subscription" and "everything in the tenant" to hang a single one on. The second is policy: a rule requiring customer-managed keys on storage accounts was assigned to each subscription individually as the estate grew, and the four subscriptions created last quarter do not have it. Nothing failed. The compliance dashboard simply reports on the subscriptions where the policy exists.
Both are the same mistake with two faces. The team modelled Azure's hierarchy as an org chart, when it is a propagation mechanism. A scope in Azure is not a label describing what something is. It is a place where a setting can be attached so that it reaches everything underneath.
Almost everything else in Azure can be rebuilt. A VNet can be re-addressed, a workload can be redeployed, a storage account can be migrated. The scope hierarchy cannot be rearranged casually, because role assignments, policy assignments and custom role definitions are anchored to positions within it — moving a subscription to a different parent can break the path between a role assignment and the role definition it depends on, and Azure will refuse the move rather than silently orphan it.
Architecture
Azure provides four levels of management scope: management groups, subscriptions, resource groups and resources. They nest, and settings applied at one level inherit downward to everything below it. Nothing inherits upward, and a lower scope cannot decline what a higher scope assigned.
The tenant is not a scope you assign things to
A Microsoft Entra tenant is the identity boundary. It is where users, groups and service principals live. It is not where Azure resources live, and it is not a level of the resource hierarchy — the top of that hierarchy is the root management group, which is created automatically and carries the tenant ID as its own ID.
Two properties of the root make it different from every other management group. It cannot be moved or deleted, and nobody has access to it by default: a Global Administrator has to explicitly elevate themselves to User Access Administrator on it before anything can be assigned there at all. That friction is deliberate. Anything assigned at the root applies to every management group, subscription, resource group and resource in the directory.
Management groups are the propagation layer
A management group's entire purpose is to be a place to attach a policy or a role assignment so that it reaches many subscriptions at once. The rules that shape a design:
Ten thousand groups, six levels deep
A single directory supports 10,000 management groups, and the tree can be up to six levels deep — a limit that excludes the root level and the subscription level. Breadth is effectively free; depth is the scarce thing, and almost no organisation needs all six.
One parent, always
Each management group and each subscription has exactly one parent. There is no way to place a subscription under two branches, so the hierarchy has to encode the one dimension that most needs to propagate — and everything else has to be expressed another way.
All subscriptions are in it
There is one hierarchy per directory, and every subscription is somewhere in it. New subscriptions default to the root management group, which means a subscription created by someone in a hurry sits at the level with the broadest assignments and the fewest guardrails.
The hierarchy is cached
Azure Resource Manager caches details of the management group hierarchy for up to 30 minutes. A move that appears not to have worked has very often worked. This is worth knowing before someone repeats the operation.
Subscriptions are the limit boundary
A subscription is the billing and isolation boundary, which is how most people describe it. What that description leaves out is how often it is the quota boundary that ends a design. A subscription holds 980 resource groups. It allows 4,000 role assignments. Service quotas — cores of a given VM family in a given region, public IP addresses, and so on — are counted per subscription, not per tenant.
This is why "one subscription per environment" stops working at scale and "one subscription per application per environment" starts to. The subscription is not an accounting convenience; it is the unit at which you buy headroom.
Resource groups are the lifecycle boundary
A resource group is where the deletion story lives. Deleting one deletes everything in it, which makes it the right container for things that are created and destroyed together, and the wrong container for a mixture of things that are not.
Three properties surprise people, all three documented and all three the source of real incidents:
- A resource group has its own location, and the resources inside it can be in different regions. The group's region is where its metadata lives, and where control plane operations for it are routed.
- Tags applied to a resource group are not inherited by the resources in it. Cost allocation built on the assumption that they are will under-report from the first day, silently.
- A resource group holds up to 800 instances of a given resource type, and keeps 800 deployments in its deployment history. The second limit is the one that bites first: a pipeline deploying several times a day reaches it, and Azure starts removing the oldest entries as it approaches the ceiling.
Why This Architecture Holds Up
The most common failed design is a management group tree that mirrors the company: a group per business unit, then per department, then per team. It fails because a hierarchy has one parent per node, and the thing you actually need to propagate is almost never the reporting line.
What propagates well is governance posture: how regulated is this, how exposed is it, what is allowed to run here. That is why the Cloud Adoption Framework's reference hierarchy separates platform from landing zones from sandbox from decommissioned, rather than separating retail from wholesale from treasury. A sandbox subscription and a production subscription need genuinely different policy sets. Two production subscriptions owned by different departments usually do not.
Everything that is genuinely multi-dimensional — ownership, cost centre, application, data classification — belongs in tags and in Azure Policy conditions, not in the tree. The tree gets the one dimension along which you would apply a deny policy.
Name the policy or role assignment that would live at the new level and at no other level. If there isn't one, the level is a folder, and folders in this hierarchy are not free — they add a scope that every future assignment has to be reasoned about against.
Where the role assignment budget goes
A role assignment or a policy assignment can be placed at any of ten inheriting scopes: the root management group, the six management group levels beneath it, the subscription, the resource group, and the resource itself. Each step down makes the assignment more specific and multiplies how many of them you need.
The budgets are not symmetric, and the asymmetry points the right way. A subscription allows 4,000 role assignments; a management group allows 500 — one eighth as many. Management group scope is deliberately not where hundreds of assignments belong. It is where a handful of broad ones belong, each replacing dozens of subscription-scoped copies.
The security engineer with forty-one role assignments in the opening story is the symptom this budget is describing. One assignment on the right management group replaces all forty-one, and it applies automatically to the forty-second subscription nobody has created yet. That last property — covering what does not exist yet — is the entire argument for building the hierarchy before you need it.
Key Architecture Decisions
| Decision | Choose this | Because |
|---|---|---|
| Depth of the management group tree | Three or four levels, not six | Depth costs nothing to create and everything to reason about. Six levels is the ceiling, not a target; each level is another scope where an assignment might be hiding. |
| What the tree is organised by | Governance posture — platform, landing zones, sandbox, decommissioned | One parent per node means the tree can encode exactly one dimension. Posture is the dimension whose settings must propagate; org structure is not. |
| Subscription granularity | Per application per environment, once the estate is more than a handful of workloads | Quotas, the 980 resource group limit and the 4,000 role assignment limit all count per subscription. A shared subscription shares its ceilings. |
| Resource group granularity | By shared lifecycle, not by resource type | The group is the deletion boundary. A group of "all the storage accounts" cannot be deleted meaningfully; a group of "everything this release created" can. |
| Where to put a broad role assignment | The highest management group whose whole subtree should have it | It covers subscriptions that do not exist yet, and it is one assignment against a budget of 500 rather than dozens against 4,000. |
| Ownership and cost centre | Tags plus Azure Policy, never a level in the tree | They are multi-dimensional and they change. Remember that resource group tags do not flow to resources — enforce tags on the resources themselves. |
| Access to the root management group | Nothing, except by deliberate elevation | Everything assigned there reaches every resource in the directory. Assignments at that scope should be the ones you would defend in an audit. |
A custom role can name only one management group in its assignable scopes. If a role is defined on one branch and assigned on a subscription, moving that subscription to a different branch severs the path between the assignment and the definition, and the move is rejected. The fixes are all deliberate ones — remove the assignment first, add the subscription to the assignable scope, or raise the definition to a common ancestor. None of them is something to discover during a reorganisation.
Closing Thought
The Azure hierarchy rewards being boring. A shallow tree organised by how strictly a workload must be governed, subscriptions sized so that quotas are somebody's deliberate choice, and resource groups drawn around things that die together will carry an estate for years. A tree that mirrors the company will be wrong the week after the next reorganisation, and the assignments anchored in it will have to be untangled by hand.
Everything in the rest of this series — identity in #2, RBAC in #3, policy in #4 — assumes the scopes described here. They are the nouns the rest of Azure governance is written in.
#2 looks at Microsoft Entra ID as the identity plane: tenant against directory against subscription, what "one tenant, many subscriptions" actually costs, and why the trust relationship between a subscription and a tenant is the thing that makes a subscription move difficult.
Comments