The subscription, policy and tagging structure that keeps a public sector estate governable — and survives a council review.
Landing zone design is cheap now and genuinely disruptive to retrofit. This guide covers the structure that keeps spending traceable, satisfies the questions elected members ask, and lets your own staff operate the estate afterwards.
Management group hierarchy, subscription topology, Azure Policy assignment, tagging enforcement, network design and the identity model underneath it.
Public sector cloud programmes fail at governance and procurement far more often than at technical migration. An estate that grew subscription by subscription becomes unmanageable at a few hundred resources, and the retrofit is a project in its own right.
The questions members ask — where is the data, who can access it, how do we know we are not overpaying, what is the exit route — are all answerable, but only if the architecture was designed with them in mind.
Check these before beginning. Most stalled implementations stall on one of them.
An Azure agreement appropriate to your procurement route. Confirm whether you need a government cloud region before designing.
Owner at the tenant root management group for the initial setup; Contributor is insufficient for policy assignment at that scope.
Data residency requirements, and whether workloads must remain in a specific jurisdiction. Raise this at design time, not at contract stage.
Agreement on who approves subscription creation. Without this, the structure erodes within a year.
Configuration is straightforward once these are clear. Skipping them is why most first attempts produce something that works and cannot be maintained.
Policy assigned at a management group applies to every subscription beneath it. Design the hierarchy around governance requirements rather than around organizational structure, because departments reorganise and governance requirements do not.
Azure Policy can audit, deny or remediate. Deny effects prevent non-compliant resources being created at all, which is considerably cheaper than finding them afterwards. Tagging enforcement in particular should be a deny.
Cost attribution is an accountability problem before it is a technical one. Spend that nobody owns is spend that nobody reduces, and the only way to attach a name to a resource reliably is to make untagged creation impossible.
Settings shown are the ones that matter, not every field on the form. Values are starting points to validate against your own environment.
Keep it shallow. Three or four levels covers almost every agency, and deeper hierarchies become difficult to reason about.
A workable structure is: tenant root, then a platform group for shared services, then landing zone groups split by governance requirement — typically corporate, and a separate group for anything with elevated data requirements.
Assign broad policy at the root or platform level and narrow exceptions lower down. Assigning everything at subscription level produces drift the first time somebody creates a subscription without the assignments.
Start with a small set that carries most of the value.
Three tags carry most of the value: owner, workload and environment. Add a cost centre tag if your finance system needs it.
Enforce by deny policy rather than by guidance. A tagging standard that relies on people remembering produces a partially tagged estate, which is only slightly better than none.
Hub-and-spoke remains the default for good reason. Put shared services — firewall, gateway, DNS — in the hub, and give each landing zone a spoke.
Design privileged access at the same time. Just-in-time elevation through privileged identity management is the control auditors ask about, and it is far easier to establish before people have standing permissions.
Write the documentation for your own staff rather than for the supplier. Infrastructure as code so the structure is reproducible and reviewable.
If a partner cannot describe how they would hand over, that is a lock-in arrangement being described as a partnership.
Every one of these is avoidable, and every one of them is common enough that we check for it by default.
It produces a compliance report and a non-compliant estate. If a control matters, deny it at creation.
Departments reorganise. Governance requirements do not. A hierarchy built on the org chart needs rebuilding after every restructure.
Every untagged resource created before the standard exists has to be tagged retrospectively by somebody who has to work out who owns it. This is genuinely unpleasant work.
Raise it at design time. Discovering a residency requirement after workloads have landed can invalidate the architecture and occasionally the procurement.
We will design the landing zone with your governance and residency requirements written into it, and validate the documentation by having your own engineer deploy from it.
Describe the situation in your own words.
