The governance backbone is the set of decisions that are almost free to make on day one and genuinely painful to change once workloads are live. It is the management group hierarchy, the subscriptions placed inside it, and the naming and tagging conventions that make the whole estate legible. None of it hosts a workload. All of it decides how every workload you ever deploy will be governed, secured, and paid for. Get it right at the start and growth becomes a placement decision. Get it wrong and you are restructuring the foundation under a running business, which is the one thing this entire approach exists to avoid.
Deploy the whole hierarchy on day one
The instinct at small scale is to build only what you need today and add structure later. Resist it here, because management groups cost nothing, they hold no resources, and restructuring them after subscriptions and policies are in place is exactly the kind of surgery you do not want to perform. So you deploy the full shape immediately, even though most of it starts empty. The empty branches are not waste. They are the answer, already visible, to the question someone will ask in a year: where would our firewall subscription go, where would a dedicated security operations subscription live. The structure below is what I deploy for the running example, Northfork Supply Co., and it is the shape I would deploy for almost any organization at this scale.
Everything in that diagram is a management group. Not a resource group, not a resource, a management group, and the distinction matters because a management group holds subscriptions and nothing else. The mental model that fits best is the one you already know from Group Policy and organizational units. Policy assigned high in the tree applies to everything beneath it. Inheritance flows downward. You can block inheritance at a lower level, and just as with Group Policy, you almost never should. If that model is in your head, the hierarchy stops being abstract and becomes something you can reason about immediately.
The top-level split is the one that carries the most meaning. Platform is the shared infrastructure that IT owns and everything else depends on: the network hub, the connection back to on-premises, the central log workspace, DNS, the security tooling. Landing Zones is where the business workloads actually live, the file server, the line-of-business app, the Cloud PC pool, the databases. Platform serves Landing Zones. The four children under Platform, Management, Connectivity, Identity, and Security, exist from day one as placeholders even though no subscription sits in them yet, because the day you add a dedicated connectivity subscription for a firewall, the place it belongs is already there and already named. The Security placeholder in particular is now part of Microsoft’s own reference hierarchy, so including it is aligned with where the platform is going, not an invention of mine.
Why Production and Non-Production, not Corp and Online
If you have read Microsoft’s reference architecture you will notice a deviation. The reference splits the Landing Zones tier into Corp and Online, archetypes that describe a workload’s connectivity posture: Corp for workloads that need line of sight to on-premises, Online for internet-facing workloads. That distinction earns its keep at enterprise scale, where hundreds of workloads genuinely sort into those two governance profiles and the policy sets attached to each differ materially. At the scale this series addresses, that split is precision the organization cannot yet use. A sub-2k shop has a handful of workloads, and the governance question that actually recurs is not “is this internet-facing” but “is this production or not,” because that is the line along which policy strictness, change control, and blast-radius isolation should differ. So I substitute Production and Non-Production for Corp and Online. Microsoft’s own guidance cautions against over-elaborating the hierarchy for small organizations, and practitioner reference implementations increasingly show exactly this substitution, so the choice is defensible rather than a shortcut. If the organization later grows into genuinely distinct connectivity archetypes, the tier has room to gain them without disturbing anything above it.
Management groups are for inheritance, never for workloads
This is the single most common structural mistake, and it is worth stating plainly because it feels natural in the moment. Management groups exist to make policy inheritance flow to the right places. They do not exist to model your org chart, and they do not exist to hold your workloads. When someone stands up Azure Virtual Desktop and asks where the AVD management group should go, the answer is that there should not be one. AVD is a workload. It lives in a resource group under Production, and if it ever needs true isolation it gets its own subscription under Production, but it never becomes a management group. The same is true of a finance app, a database estate, or a departmental service. The moment you find yourself creating a management group named after a workload or a department, you have confused the tool for policy inheritance with a filing cabinet, and the hierarchy that results will need frequent amendment and deliver very little in return. Keep the tree shallow, keep it aligned to governance rather than to the organization chart, and let resource groups and subscriptions carry the workloads.
Subscriptions: design for two, deploy one
Subscriptions are the billing and isolation boundary that sits inside the hierarchy, and the right posture at this scale is to design for two and deploy one. You design for two, Production and Non-Production, because the separation is real and you want the structure ready for it. You deploy one, the Production subscription, because a second bill is genuinely hard to justify before a single non-production workload exists, and an empty subscription accruing nothing is not a virtue. When there is only one, it is the Production subscription, the Non-Production management group sits empty and ready, and you keep production and non-production work apart inside the single subscription by resource group naming and tagging. Nothing about that is a compromise. It is the correct starting point, and the hierarchy accommodates the second subscription the instant it is justified.
The second subscription arrives on a trigger, not on a feeling. The triggers are specific: the first developer or vendor who should be able to work without any path to production, the first workload that needs genuine isolation from production for compliance or blast-radius reasons, the first regulatory requirement that mandates environment separation. When one of those appears, you create the second subscription under the Non-Production management group and it inherits the governance that is already defined. What you do not do is create subscriptions because the resource count grew, because it feels tidier, or because the enterprise reference architecture uses many of them. Subscription sprawl is its own governance problem, and at this scale a single well-organized subscription is almost always the right answer for longer than people expect.
Names and tags, decided once
The last piece of the backbone is the convention that keeps the estate legible as it grows. The naming pattern I use is resource type, workload, environment, region, and instance, in that order, so a resource group reads as rg-network-prod-wus2-001 and a log workspace as law-platform-prod-wus2-001. The one non-obvious rule is to put the region in the name from the very first resource even when there is only one region, because retrofitting a region segment across a live estate is tedious and error-prone, and adding a disaster-recovery region later is something you want to be a naming non-event.
Tags carry the metadata that names cannot. Six of them are mandatory and worth enforcing rather than hoping for: Environment, so every resource declares production or non-production; Owner, the team or department accountable for the resource; Contact, the actual human to reach when something needs attention, which is a different thing from the owning team and matters most precisely when something is on fire; CostCenter, so spend attributes correctly; Workload, so a resource can be traced to the application it serves; and ManagedBy, so it is clear whether a resource is run by internal IT, a managed provider, or a vendor. The policy layer enforces the presence of these tags and inherits them from the resource group down, but the decision to require them belongs here, in the backbone, because a tagging schema retrofitted onto a sprawling estate is a thankless project and a schema present from the first resource is simply how the place works.
A reader who has followed this far can now draw their own hierarchy, place their subscriptions correctly, say with confidence where a new workload like AVD belongs and why it is not a management group, and name their first ten resources so they will still make sense at the hundredth. That is the whole point of the backbone: it is the small set of decisions that, made once and made deliberately, keep every later decision cheap. The companion build sheet takes this exact structure and stands it up, including the one operation that cannot be automated and the one brownfield rule you break at your peril.
Azure Landing Zones
‹ Previous: [LZ 2.1] Discovery Before You Deploy Anything
Next: [LZ 3.1] Standing Up the Governance Backbone ›
