Designing Azure Governance at Scale: Management Groups, Subscriptions, and Landing Zones
Defining what a subscription or a management group is is one thing; deciding how many of each an organisation should actually have, and how to arrange them, is a design problem with real trade-offs. This post covers that design layer — plus a timely correction, since one of the tools this topic traditionally leans on is being retired.
Why governance needs a hierarchy in the first place
Governance, in the general sense, is the process of establishing rules and policies and making sure they're actually enforced. It's what keeps a cloud environment compliant with both external standards (information security management frameworks, for instance) and internal ones (a requirement that all network data be encrypted, say). It matters most once an organisation has multiple engineering teams, multiple subscriptions, real regulatory obligations, or standards that need to hold across every cloud resource — below that scale, informal conventions can carry you further.
Applying a governance strategy in practice means first building a hierarchical structure to hang it on. Azure's hierarchy runs four levels deep: management groups, subscriptions, resource groups, and resources, each inheriting settings from the level above.
Designing the management group layer
Management groups are where you apply Azure Policy and role assignments to everything that needs the same security, compliance, connectivity, or feature settings, without repeating the assignment per subscription. Microsoft's own Cloud Adoption Framework guidance leans firmly toward keeping this hierarchy as flat as the organisation can manage — a deep, org-chart-mirroring hierarchy is harder to reason about and slower to change than a shallow one, even though a flatter structure does trade away some of the fine-grained separation a very large or complex organisation might otherwise want. In practice, the framework recommends grouping by workload type rather than by department — at minimum, separating internal/corporate workloads from internet-facing ones — since that's what actually determines whether two workloads need the same guardrails, more than which team happens to own them.
A single top-level management group for platform-wide policy and role assignments is still worth having regardless of how the rest of the hierarchy is shaped. Beyond that baseline, a few groupings show up repeatedly in practice: by organisational or departmental structure (separate management groups for Sales, Corporate, and IT, say), by geography (separate West and East regions, where compliance requirements differ by location), by production status (a dedicated management group for policies that apply to all corporate products), by sandbox (a deliberately looser environment for experimentation), and by sensitivity (isolating resources that need standard and enhanced compliance policies into their own group, separate from the main office's baseline).
Designing the subscription layer
Subscriptions do double duty as both a billing boundary and a policy/RBAC boundary, and different compliance standards can be satisfied by putting workloads in different subscriptions rather than trying to differentiate policy within one. Treat subscriptions as a democratised unit of management aligned to business needs, and group subscriptions that share the same policies and role assignments under the same management group so they inherit those settings together rather than needing them re-applied.
A shared services subscription — holding common network resources that get billed together and kept isolated from the workloads that consume them — is a common pattern worth considering early. Subscriptions also work as a scale unit: large, specialised workloads (high-performance computing, IoT, SAP, and similar) are often better placed in their own subscription, partly to avoid bumping into subscription-level service limits that a shared subscription would hit sooner (Data Factory's integration runtime limits are one commonly cited example).
Subscriptions provide a genuine management boundary for separation of concerns — a Corporate management group might reasonably run HR and Legal out of a single shared subscription, for instance, if neither needs isolating from the other. And subscriptions are just as valid a policy boundary as a management group is: a workload needing Payment Card Industry (PCI) compliance, for example, can often be isolated with its own subscription rather than a whole separate management group — worth remembering before defaulting to "new management group" for every compliance requirement, since a hierarchy with too many management groups holding only a handful of subscriptions each becomes its own management burden.
Network topology is one more real constraint on subscription boundaries: virtual networks can't be shared across subscriptions, though resources in different subscriptions can still connect to each other through virtual network peering or a VPN. Which workloads genuinely need to talk to each other is worth weighing before deciding a new subscription is warranted. And whatever the final structure, subscription owners need to actually know what they're responsible for — an unowned or ambiguously-owned subscription undermines the whole design.
Landing zones: the foundation before you deploy
An Azure landing zone is the infrastructure environment workloads get deployed into — it puts the foundational pieces in place before deployment starts, the same way a city's water, gas, and electricity utilities exist before a house is built on top of them. Network topology, identity and access management, policy, and monitoring all need to be ready in advance, not bolted on after the fact.
Landing zones are meant to be pre-provisioned through code (infrastructure as code, not manual portal clicks), and scoped to support both migration of existing workloads and greenfield development — designed to scale across an organisation's entire IT portfolio rather than just the next project. Without one, different teams tend to solve the same foundational problems inconsistently: one team forgets to enable a firewall, another burns through a weekend's budget without anyone noticing, a third builds a network segment that can't reach the rest of the estate. A landing zone exists specifically to make sure every workload starts from the same standardised, secure baseline from day one, rather than reinventing (or skipping) that baseline every time.
Azure Blueprints is being retired
The traditional tool for packaging and deploying this kind of governance baseline consistently was Azure Blueprints — but it's being retired, and the timeline matters if you're planning around it now. Microsoft extended the original retirement date, and the current phased schedule is: no new blueprint definitions or versions from 31 July 2026, no modifications to existing definitions and no new assignments from 31 October 2026, no modifications to existing assignments from 31 December 2026, and full retirement — API stops responding, portal blade removed, unexported definitions and assignments deleted — on 31 January 2027. Resources that were already deployed through a blueprint aren't affected or deleted; only the blueprint objects themselves are.
Conceptually, Blueprints combined two jobs: storing and versioning a reusable governance package (policies, role assignments, resource groups, ARM templates) as a definition, and then deploying that package consistently as an assignment — which had to be created at the subscription level even when the definition itself was authored higher up, at a management group, so that every subscription ended up with the same artefacts applied consistently. Blueprint definitions were also tenant-scoped: a definition couldn't span tenants, so the same definition had to be recreated separately in each tenant that needed it.
Template specs and Azure Deployment Stacks
Those two jobs are now split across two purpose-built, generally-available replacements: template specs (or a Git repository) take over storing and versioning the reusable template, and Azure Deployment Stacks take over deploying it, managing its lifecycle, and enforcing deny-assignment locking — the part of Blueprints' job that stopped a deployed resource from being modified or deleted outside the intended process. The two are meant to be used together: store the template as a template spec, then deploy and govern it with a deployment stack. If you're setting up governance tooling for the first time now, start with deployment stacks and template specs directly rather than learning Blueprints — but recognising the Blueprints concepts is still useful if you inherit an environment that already uses it, since it needs to be migrated before January 2027.