Azure landing zone work is the least glamorous and most consequential thing you will do in a cloud programme. Nobody demos it. No board paper celebrates it. But it is the set of decisions you make once, in the first few weeks, and then live with for the next decade: the tenant, the management group hierarchy, the identity model, the network topology, the policy baseline, and the process by which a workload team gets a subscription of its own.
Get those roughly right and every project afterwards is faster, because the guardrails already exist and nobody has to relitigate them. Get them wrong and you do not find out for eighteen months, at which point the fix is a remediation programme that costs several times what doing it properly would have cost. That asymmetry is the whole argument for taking the Azure landing zone seriously before the first production workload arrives.
This checklist walks the implementation in the order the decisions actually need to be made. It covers what belongs in an Azure landing zone, which choices are genuinely expensive to reverse, how the deployment paths compare now that Microsoft has consolidated on Azure Verified Modules, and what the work realistically costs in money, effort and elapsed time. If you are still deciding between platforms, our comparison of AWS vs Azure for UK SMEs is the better starting point, and the cloud migration business case guide covers getting the money approved.
One framing note before the steps. An Azure landing zone is not a project you finish; it is a product you operate. The organisations that get the most out of this work are the ones that assign an owner on day one and keep the platform current, rather than treating the build as a one-off engagement that ends at handover.
Table of contents
- What an Azure landing zone actually is
- Before the first deployment: decisions that are expensive to reverse
- Step 1: Identity and access management
- Step 2: Management group hierarchy and subscription design
- Step 3: Azure landing zone network topology and connectivity
- Step 4: Azure landing zone policy and security baseline
- Step 5: Management, monitoring and the operations baseline
- Step 6: Choose the Azure landing zone deployment path
- Step 7: Subscription vending
- What an Azure landing zone costs and how long it takes
- Keeping the Azure landing zone current
- Common Azure landing zone mistakes
- Azure landing zone FAQ
- References
What an Azure landing zone actually is
The term gets used loosely enough to be genuinely confusing, and half the disagreements in a design workshop come from two people using it to mean different things.
A platform foundation plus the workload environments it governs
Microsoft’s Cloud Adoption Framework splits the concept in two. The platform landing zone establishes governance, security and shared services for everything else: identity, connectivity, management tooling, policy. Application landing zones are the environments where workload teams actually deploy, operating inside the guardrails the platform sets. When someone says “we need an Azure landing zone”, they almost always mean the platform half, and the workload half is what they get afterwards.
It is not one subscription, and it is not a template
The most common misconception is that this is a template you deploy and are done with. It is not. The reference implementation gives you a management group hierarchy, a set of policy assignments and some networking, but every one of those needs decisions that only your organisation can make. A template with the wrong management group names and the wrong policy posture is worse than no template, because it looks finished.
The design areas are the real checklist
The Cloud Adoption Framework organises the work into design areas, split between environment design and compliance. Environment design covers Azure billing and the Microsoft Entra tenant, identity and access management, resource organisation, and network topology and connectivity. Compliance covers security, management, governance, and platform automation and DevOps. Every serious Azure landing zone checklist is a restatement of those areas in delivery order.
Scale changes the shape, not the principles
A 40-person business does not need Virtual WAN, three regions and a dedicated security subscription. It does need a management group hierarchy, a policy baseline and centralised logging. The principles hold at every size; the components you actually deploy do not. Scaling the Azure landing zone reference architecture down deliberately is a legitimate design decision. Deploying all of it because the diagram said so is not.
Before the first deployment: decisions that are expensive to reverse
Some choices can be changed on a Tuesday afternoon. Others require a migration. It is worth knowing which is which before you start, because the expensive ones deserve a workshop and the cheap ones do not.
Tenant and billing come first
Tenant creation, enrolment and billing setup are genuinely foundational. A Microsoft Entra tenant is not something you rename or merge casually, and the billing structure determines how costs roll up for the rest of the Azure landing zone’s life. If there is any chance of an acquisition, a divestment or a separate regulatory boundary, that conversation belongs here rather than in year two.
Naming and tagging conventions are cheap now and brutal later
Nobody enjoys the naming convention workshop, and it takes an afternoon. Retrofitting a convention across a few thousand deployed resources takes weeks and breaks automation that hardcoded the old names. Decide the resource naming pattern, the mandatory tag set, and which tags are enforced by policy rather than by hope. A cost centre tag that is not enforced with a Deny or Modify effect stops being reliable within a quarter.
Region selection carries compliance weight
Region choice looks like a latency decision and is actually a data residency decision. For UK organisations that usually means UK South as primary with UK West or a European region for recovery, but the pairing matters for the services you intend to use, because not every service is available in every region. Decide it once, write down why, and resist the urge to sprinkle resources into whatever region a portal default suggested.
Somebody has to own the Azure landing zone
The single best predictor of whether an Azure landing zone stays healthy is whether a named team owns it. Not a project. A team, with a backlog, that reviews policy exemptions and takes upstream module updates. Where that ownership does not exist internally, it is the part most worth outsourcing, and it fits naturally alongside managed IT services rather than sitting as an orphaned architecture artefact.
| Decision | Who decides | Cost of changing later |
|---|---|---|
| Entra tenant and billing structure | Finance and IT leadership | Very high |
| Management group hierarchy | Platform team | Moderate |
| Network address space | Network architect | Very high |
| Hub topology model | Network architect | High |
| Naming and tagging convention | Platform team | High |
| Primary and paired regions | Architecture and compliance | High |
| Policy baseline and effects | Security and platform team | Low |
| IaC tooling choice | Platform team | Moderate |
| Log Analytics workspace design | Operations and security | Moderate |
| Subscription vending process | Platform team | Low |
Step 1: Identity and access management
Identity is the primary security boundary in a public cloud, which makes it the first design area with teeth. Everything downstream inherits whatever you decide here.
Break-glass accounts before anything else
Create two emergency access accounts, exclude them from Conditional Access policies, give them permanent Global Administrator, store the credentials somewhere physically controlled, and alert on their use. Do this before you start enforcing multi-factor authentication and Conditional Access, not after. Organisations that skip this step discover the gap during the incident where they most need it.
Design roles around groups, never individuals
Assign Azure role-based access control to Microsoft Entra groups, and manage membership in those groups. Direct assignments to named users are impossible to audit and impossible to offboard cleanly. This is also the point at which an Azure landing zone tends to drift, because a one-off direct assignment made to unblock somebody on a Friday never gets removed.
Use Privileged Identity Management for standing access
Standing Owner or Contributor rights at a management group scope are the single most common over-permissioning finding in Azure reviews. Platform teams do need broad access to troubleshoot, but they need it for an hour, not permanently. Privileged Identity Management gives you time-bound, approved, audited elevation, and it turns a permanent risk into a logged event.
Decide the hybrid identity model explicitly
If there is on-premises Active Directory, decide now whether it stays authoritative, whether you are synchronising with cloud authentication, and whether domain controllers are going into the identity subscription. Each option has different recovery implications. The identity subscription in an Azure landing zone exists precisely so those resources have their own policy posture and blast radius.
Step 2: Management group hierarchy and subscription design
This is the step people rush, and it shapes governance for years. Management groups are how policy and access get applied at scale; subscriptions are the units of management and scale beneath them.
Use the reference hierarchy unless you have a specific reason not to
Under the tenant root sits an intermediate root management group carrying your organisation’s prefix, so you never assign policy at the tenant root itself. Beneath that sit Platform, with Management, Connectivity, Identity and often Security children, then Landing Zones with Corp and Online children, plus Sandboxes and Decommissioned. For most organisations, Corp and Online are the right starting point.
Keep it flat and resist the org chart
Microsoft recommends no more than three or four levels, against a hard limit of six levels of depth below the tenant root. The most common design error is mirroring the company’s organisational structure into a deeply nested hierarchy. Management groups exist for policy assignment, not for billing or reporting. Use tags for the reporting, and keep the tree shallow.
Do not create management groups for dev, test and production
Separate environments into different subscriptions inside the same management group instead. A development subscription that sits under a different policy posture from production stops being a meaningful test of anything, because the thing you validate in development is no longer subject to the controls production applies.
Set a default management group and lock the hierarchy
By default, every new subscription lands under the tenant root, and by default any user in the tenant can create management groups. Fix both. Configure a default management group, ideally the sandbox, so nothing lands ungoverned, and enable role-based access control authorisation on the hierarchy so only privileged users can restructure it.
| Management group | What lives there | Policy posture |
|---|---|---|
| Intermediate root | Nothing directly | Organisation-wide minimum |
| Platform | Shared platform subscriptions | Strict, platform team only |
| Identity | Directory services, domain controllers | Hardened |
| Connectivity | Hub network, firewall, private DNS | Hardened |
| Management | Log Analytics, automation, backup vaults | Hardened |
| Corp | Workloads needing corporate connectivity | No public inbound |
| Online | Internet-facing workloads | Public allowed, tightly controlled |
| Sandboxes | Experimentation, isolated | Loose, no corporate connectivity |
| Decommissioned | Cancelled subscriptions awaiting deletion | Read-only |
Step 3: Azure landing zone network topology and connectivity
Networking decisions are the other genuinely expensive-to-reverse area, mostly because of addressing. An overlapping address range discovered during a merger is a project, not a change request.
Plan the address space with far more headroom than you need
Reserve a large, contiguous, non-overlapping range for Azure before you deploy a single virtual network, and check it against every range already in use on premises and at any partner you connect to. Subnetting generously costs nothing. Running out of space in a hub and having to renumber production spokes costs a great deal.
Choose between hub-and-spoke and Virtual WAN deliberately
Hub-and-spoke gives you a hub virtual network you build and control, with peered spokes. Virtual WAN gives you a Microsoft-managed hub with automated any-to-any transit and branch connectivity. Hub-and-spoke is usually right for a single region and a modest number of spokes; Virtual WAN earns its keep with multiple regions, many branches or SD-WAN integration. Both are valid inside an Azure landing zone.
Decide how egress is controlled
Whether that is Azure Firewall, a third-party network virtual appliance, or something lighter for a small estate, decide it now, because forced tunnelling and route tables are much harder to introduce once workloads exist. This is also where the platform cost baseline is largely set, since firewall and gateway resources dominate the monthly bill of an otherwise idle Azure landing zone.
Get private DNS right the first time
Private DNS zones for Private Link endpoints belong centrally in the connectivity subscription, linked out to spokes, with policy enforcing that private endpoints register in the right zone. Devolving DNS to workload teams produces an estate where name resolution works from some subnets and not others, and the diagnosis of that is miserable.
| Factor | Hub-and-spoke | Virtual WAN |
|---|---|---|
| Who manages the hub | You do | Microsoft does |
| Best fit | One or two regions | Many regions or branches |
| Transit routing | You configure it | Any-to-any by default |
| Branch and SD-WAN | Manual per connection | Native, automated |
| Entry cost | Lower at small scale | Higher fixed baseline |
| Operational effort | Grows with spokes | Broadly flat |
| Control over the data path | Complete | Constrained by the service |
Step 4: Azure landing zone policy and security baseline
Policy is what makes the guardrails real. Without it, the hierarchy is just a filing system and the standards document is a suggestion.
Start in audit, move to deny on a schedule
Assign the baseline in audit mode first, look at what fails, fix or exempt it, then switch the effects that matter to Deny. Going straight to Deny on day one in an estate with existing resources produces a flood of failed deployments and a platform team that immediately loses the room. Publish the date the effects tighten, so nobody is surprised.
Know which policies earn their place on day one
A small set does most of the work: allowed regions, allowed resource types, required tags with Modify to append defaults, no public IP on virtual machines in Corp, diagnostic settings deployed to the central workspace via DeployIfNotExists, and encryption in transit. Long initiative assignments at the root scope are hard to debug when a deployment fails three levels down, so keep the root scope light.
Enable Defender for Cloud and decide the logging destination
Defender for Cloud gives you the secure score and the regulatory compliance view against standards you probably already need to evidence. Decide early whether Microsoft Sentinel sits in a dedicated security subscription, because moving a workspace later means losing the history or running a migration. Our cybersecurity practice sees more foundations fail on logging design than on policy design.
Every exemption gets an owner and an expiry date
Exemptions are legitimate. Permanent, unowned, undocumented exemptions are how a compliant Azure landing zone quietly becomes a non-compliant one. Record who approved it, why, and when it expires, and review the list on a fixed cadence. If an exemption has been renewed three times, the policy is probably wrong and should be changed rather than bypassed.
Step 5: Management, monitoring and the operations baseline
The management design area is the one that determines whether you can actually run the thing. It is also the one most often deferred until after go-live, which is exactly backwards.
Centralise logs, but think about who reads them
A single Log Analytics workspace in the management subscription is the default and it is usually right, because cross-workload queries and Sentinel correlation both get harder when data is scattered. Split only for a concrete reason, such as data residency or a genuinely separate security team, and understand that you are accepting query complexity in exchange.
Set a backup and recovery baseline centrally
Decide the default backup policy, where recovery services vaults live, and how immutability is applied, then enforce it with policy rather than asking workload teams to remember. A workload owner who forgets to configure backup is not a training problem; it is a platform design problem, and the platform should default it on.
Alerts nobody owns are worse than no alerts
Define which platform alerts exist, who receives them, and what the response is. An Azure landing zone that emits hundreds of unrouted alerts trains everybody to ignore the channel, which is measurably worse than a small set of alerts somebody actually acts on.
Step 6: Choose the Azure landing zone deployment path
There are three supported ways to deploy an Azure landing zone, and the right one depends far more on your team’s operating model than on technical merit.
The Azure portal accelerator
A guided, portal-based deployment of the Azure landing zone reference architecture, including management groups and policies. It is the fastest route to something real, and it suits organisations without an established infrastructure-as-code practice. The trade-off is that what you get is harder to version, review and reproduce than code.
Bicep and Terraform with Azure Verified Modules
Both accelerators now build on Azure Verified Modules and deploy through a continuous delivery pipeline in Azure DevOps or GitHub. This is the right default for any organisation that already treats infrastructure as code. Note that the classic ALZ-Bicep approach was retired from the accelerator in early 2026 in favour of the verified modules, so anything you inherited before that is worth revisiting.
Enterprise Policy as Code for larger estates
If policy management is the hard part of your estate, Enterprise Policy as Code is an alternative way to deploy and operate Azure Policy across the whole tenant. It suits mature DevOps teams. Microsoft’s own advice is to evaluate the native policy management first, because changing policy governance method after the fact is difficult.
Sovereign and regulated variants
For organisations with strict data residency or sovereignty obligations there is a dedicated sovereign landing zone variant. If you are deploying into a sovereign cloud rather than the public cloud, only the Bicep and Terraform paths can be adapted, and you will need to remove unsupported policies and adjust resource API versions by hand.
| Consideration | Portal accelerator | Bicep or Terraform |
|---|---|---|
| Time to first deployment | Days | Weeks |
| Skills required | Azure administration | IaC and pipelines |
| Repeatability | Limited | Full |
| Change review | Manual | Pull request |
| Sovereign cloud support | Not supported | Adaptable |
| Ongoing update path | Manual reapplication | Module version bump |
| Best for | Smaller estates, fast start | Teams with a DevOps practice |
Step 7: Subscription vending
The foundation is only useful once workloads can get into it without a two-week email thread. Subscription vending is the process that makes that repeatable.
Standardise the request, then automate it
Vending standardises how workload teams request a subscription and how the platform team provisions and governs it. The request needs to capture the workload name and owner, the environment, whether it needs corporate connectivity, the expected address space, the cost centre, and the compliance classification. That set of answers is enough to place it in the right management group with the right policy inheritance.
Define product lines rather than bespoke builds
Most organisations end up with a handful of subscription styles: a Corp workload with private connectivity, an Online workload with public ingress, a sandbox, and perhaps a data platform variant. Naming those product lines and building each as a parameterised deployment prevents the slow slide back into hand-crafted subscriptions.
Use the supported modules
Both Bicep and Terraform have dedicated subscription vending modules that orchestrate subscription creation, management group placement, networking and role assignments. Wiring these into a pipeline early is what turns the Azure landing zone from an architecture diagram into something a workload team experiences as a service. The target is request to governed subscription in hours, not weeks.
What an Azure landing zone costs and how long it takes
Two questions dominate every budget conversation: what does the Azure landing zone cost to run when nothing is deployed on it, and how long before the first workload can land.
The platform has a standing monthly cost
Even idle, an Azure landing zone costs money, because firewalls, gateways, Bastion, Defender plans and log ingestion all bill whether or not a workload exists. For a small UK estate the platform baseline commonly lands somewhere in the region of a few hundred pounds a month; a full enterprise build with premium firewall tiers, DDoS protection and multi-region hubs runs to several thousand. The variation is driven almost entirely by the networking and security tiers you selected in steps three and four.
Build effort depends on the deployment path
A portal-accelerator build for a modest estate is a matter of days of effort plus the decision workshops. A code-based platform build with pipelines, a policy baseline and vending automation is typically a four to eight week engagement. The decisions, not the deployment, consume most of the calendar time, which is why front-loading the workshops shortens the whole thing.
Budget for the operate phase, not just the build
The build is the smaller number. Keeping an Azure landing zone current, reviewing exemptions, taking module updates and vending subscriptions is ongoing work. Organisations that fund the build and not the operation end up with an Azure landing zone that is accurate on the day it was handed over and progressively less accurate every month afterwards. Sensible cost optimization assumes both lines exist.
Keeping the Azure landing zone current
An Azure landing zone is a product with a version number. Treating it as a finished project is the most reliable way to end up back where you started.
Upstream moves, and so should you
Microsoft ships changes to the reference implementation, the verified modules and the policy set continuously. Set a cadence, quarterly is reasonable, to review what has changed and decide what to adopt. Taking updates in small increments is straightforward; taking two years of them at once is a project.
Detect drift before an auditor does
Things get changed in the portal under pressure and never make it back into code. Periodic reconciliation between the deployed state and the repository, plus policy compliance reporting, catches that early. An Azure landing zone that has silently drifted still passes a casual look and fails the first real audit.
Review the exemption register on a fixed cadence
Policy exemptions accumulate. Reviewing them quarterly, with the owner present, is a short meeting that prevents a long remediation. It also surfaces the policies that are wrong, which is genuinely useful feedback for the platform backlog.
Common Azure landing zone mistakes
Most failures are not technical. They repeat across organisations of very different sizes and are entirely avoidable.
Deploying workloads first and governing later
This is the expensive one. Standing up production workloads in an ungoverned subscription and promising to retrofit governance later means the retrofit competes with feature work and loses. Retrofitting also means moving resources between subscriptions, which some services do not support cleanly.
Copying the enterprise diagram wholesale
Deploying every component of the Azure landing zone reference architecture because it appears in the picture leaves smaller organisations paying for Virtual WAN, DDoS Protection and a dedicated security subscription they will not use for years. Tailoring down is explicitly supported. Do it consciously and write down what you excluded and why.
Deny policies with no path to yes
A guardrail that blocks a legitimate deployment with no documented exemption route teaches teams to route around the platform entirely. Every Deny effect needs a published exception process with a realistic turnaround, or shadow IT becomes the workaround.
Nobody owns it after handover
The most common failure of all. The consultancy leaves, the documentation goes into a folder, and eighteen months later nobody knows why a policy exists or who can approve an exemption. Name the owner before the build starts, not at handover.
Treating the hierarchy as a reporting structure
Management groups are for policy, not for cost reporting or mirroring the org chart. Organisations that use them for reporting end up with deep hierarchies that are painful to reason about and produce surprising policy inheritance.
Azure landing zone FAQ
Do small businesses need one?
Yes, but a smaller one. The full reference architecture is overkill for a 40-person business, but a management group hierarchy, an enforced policy baseline and centralised logging pay for themselves quickly and take days rather than months to establish.
Can we add a landing zone to an existing Azure estate?
Yes. Build the hierarchy and policy baseline, assign the policies in audit mode, then move existing subscriptions into the appropriate management groups and remediate what fails. It is more work than starting clean, but it is a normal and well-supported path.
Bicep or Terraform?
Whichever your team already uses. Both accelerators are built on Azure Verified Modules and both reach the same architecture. If you have no existing preference and no multi-cloud requirement, Bicep has the shorter learning curve for a Microsoft-centric team.
How many subscriptions should we start with?
Enough to separate the platform from the workloads: typically management, connectivity, identity, and one per workload environment. Subscriptions are free and act as policy and scale boundaries, so the instinct to conserve them is misplaced.
How does this relate to the Well-Architected Framework?
The Cloud Adoption Framework tells you how to build and govern the environment; the Well-Architected Framework tells you how to design the workloads that run inside it. You need both, and they meet at the application landing zone boundary.
References
What is an Azure landing zone? — Microsoft Cloud Adoption Framework
Azure landing zone design areas — Microsoft Learn
Management groups — Cloud Adoption Framework
What are Azure management groups? — Azure Governance documentation
Deploy Azure landing zones — Azure Architecture Center
Subscription vending implementation guidance — Azure Architecture Center
