The management group and subscription hierarchy is the skeleton of your Azure governance. Every policy assignment, every RBAC assignment, every cost boundary inherits from it. Get it right and governance scales naturally as the organisation grows. Get it wrong and you face a choice between painful restructuring or permanent workarounds. This post is about the decisions that matter and the patterns that don’t age well.
Management Group Design Principles
The hierarchy exists to allow governance to be applied at the right scope without duplication. A policy applied at a management group level applies to every subscription beneath it — that inheritance mechanism is what makes centralised governance possible at scale. Without it, you are assigning the same policies to each subscription individually, and any change to the baseline requires touching every subscription in the estate.
Depth versus breadth is the first structural decision. Deeper hierarchies — more management group levels — allow finer-grained policy inheritance but increase complexity and make it harder to reason about what a subscription is actually inheriting. Flatter hierarchies are simpler but require more per-subscription policy assignments when different subscription groups need different treatment. Most organisations land at three to four levels: Root → Platform/Landing Zones → Workload categories → individual subscriptions.
The Microsoft CAF reference architecture uses: Root, Platform (Connectivity, Identity, Management), Landing Zones (Corp, Online), Sandbox, Decommissioned. This is a sound starting point for most enterprise organisations. Where it breaks is in highly regulated estates that need separate policy scopes for different regulatory regimes. An organisation with FCA-regulated workloads sitting alongside unregulated digital services often benefits from an additional management group level that creates a clear policy boundary between compliance domains — one that maps to the audit evidence structure the regulator expects to see.
Don’t design for today’s subscription count. A management group structure that made sense for five subscriptions becomes painful at fifty. The hierarchy is not easy to restructure once workloads are inheriting policies from it. Design for the organisational shape the business will have in three years — which means understanding where the growth is coming from, whether that is new products, new geographic markets, or acquisitions that will bring their own estates.
[DAN: Add your experience with management group hierarchy depth — specifically whether you’ve seen organisations go too deep (and the maintenance burden) or too shallow (and the policy assignment explosion). What depth do you typically recommend and why?]
Subscription Design Patterns
There are three primary subscription models, and choosing between them is one of the more consequential decisions in the early design phase.
Workload-based subscriptions give each application or workload its own subscription. The advantages are real: clean blast radius isolation, simple cost attribution, and easier lifecycle management when a workload is decommissioned. This model works well for large workloads with distinct teams and distinct operational characteristics. The problem is sprawl — organisations with many small services accumulate subscriptions faster than they can manage them, and the overhead of managing many near-empty subscriptions (their own policy assignments, their own RBAC, their own monitoring configuration) becomes significant.
Environment-based subscriptions create separate subscriptions for prod, staging, and dev — either per workload or per workload group. The clear policy separation between production and non-production is the main draw, and for compliance-heavy environments this separation is often non-negotiable: the policy set that governs production resources is stricter than what you want applied to a developer sandbox, and having them in the same subscription means either over-governing non-prod or under-governing prod. The cost is that subscription count multiplies fast.
The mixed model is where most enterprise organisations actually land: platform subscriptions (connectivity, identity, management) managed workload-based; application workloads environment-based where compliance requires it, consolidated where it does not. The trade-off is complexity in the model itself — you need clear rules for which workloads get their own subscription per environment and which share — but it avoids the worst failure modes of either pure approach.
Subscription limits to design around: 800 resource groups per subscription, 980 deployments per resource group per month (a limit that catches CI/CD-heavy teams by surprise — if you have multiple pipelines deploying to the same resource group multiple times a day, you will hit this), and Azure Policy assignment limits at the subscription level. None of these limits are likely to be hit in most workloads, but they matter for high-throughput deployment patterns and consolidated subscriptions.
The “one subscription for everything” pattern is common in organisations that started small and grew without restructuring. The structural problem is that blast radius, policy scope, and cost attribution all collapse into a single unit. You cannot apply a stricter policy to your production resources without it applying to everything. You cannot give a team access to their workload without giving them visibility of all other workloads in the subscription. Cost chargeback becomes an exercise in tagging discipline rather than structural separation. Restructuring out of this pattern is possible but requires a migration plan and acceptance that it will take multiple quarters.
The Decisions That Determine Everything Downstream
Management group naming deserves more thought than it usually gets. Use names that reflect governance scope, not team names. Teams reorganise; governance scopes are more stable. “Corp-LandingZones” ages better than “DigitalTeam-Subscriptions.” When the digital team splits into product and platform, the management group name becomes a source of confusion for every new engineer who has to reason about the hierarchy.
Root management group policies are the highest-leverage and highest-risk assignment scope. Policies assigned at the root apply to everything — every subscription in the entire estate, including platform subscriptions, sandbox subscriptions, and any subscriptions added in the future. Use this scope only for policies that genuinely apply universally: mandatory logging baseline, required diagnostic settings, prohibited resource types that should never exist anywhere in the organisation. Overusing the root scope is a common mistake: it feels efficient to apply governance broadly, but the result is a growing list of exemptions for legitimate scenarios that the root-level policy did not anticipate. If your exemption list is longer than your policy list, you have over-scoped your root assignments.
The Sandbox management group is often underestimated in initial designs. A dedicated scope for experimentation — with no Deny policies, minimal compliance requirements, and relaxed network controls — is not a concession to governance; it is what prevents governance bypass in production environments. Without a legitimate place to experiment, engineers work around governance where they have access, which is usually in the environments where they are doing their primary work. The Sandbox must have hard spending controls — budget alerts and ideally resource quotas — to prevent it becoming a cost problem. The combination of no Deny policies and uncapped spending is the failure mode to avoid.
[DAN: Add your view on sandbox subscription management — specifically whether you’ve given individual engineers their own sandbox subscriptions, used a shared sandbox, or a different model. What worked and what the failure modes were.]
Restructuring an Existing Hierarchy
Moving subscriptions between management groups is a supported operation, but it has immediate consequences: all policy assignments and RBAC inherited from the old parent are removed, and all assignments from the new parent are applied. In an enforced governance environment — one with Deny-effect policies — moving a subscription can immediately trigger policy violations on existing resources or block operations that were previously permitted. This is not a reason to avoid restructuring, but it is a reason to plan it carefully and test it first.
Test hierarchy changes in a non-production environment before applying them to production subscriptions. If the target management group has policies you have not validated against the subscription’s existing resources, you may be creating compliance violations at scale.
The brownfield reality is that most organisations reading this post have an existing hierarchy that was not designed — it grew. The relevant question is not “how do I design the right hierarchy from scratch” but “how do I migrate to a better hierarchy without breaking production.” The answer is gradually, with policy exemptions that have expiry dates and are reviewed rather than accumulated, and with a target state defined and agreed before migration begins.
That last point deserves emphasis: the target state must be defined before migration starts. Migrating without a defined target produces a hybrid hierarchy that is neither the old model nor the new one — subscriptions at different levels of the migration, inheriting inconsistent policy, with nobody confident about what the final state looks like. The worst governance posture is mid-migration without a destination.
Management group and subscription design is one of the few Azure decisions where the cost of getting it wrong compounds with every workload you add. Each new subscription that inherits from a poorly designed hierarchy adds to the restructuring effort later. The right time to get this right is before the first production workload. The second-best time is with a migration plan and a defined target state. The worst time is after fifty subscriptions, when everything in the estate has inherited policies and RBAC from a hierarchy that nobody designed intentionally.
