Every Azure estate that grows past a handful of subscriptions eventually needs the same thing: a governed place to put workloads. Microsoft calls that an Azure landing zone, and it offers two ways to get one. Deploy an Azure landing zone accelerator, which is Microsoft’s reference architecture delivered as infrastructure as code, or design and build your own.
Microsoft’s own position is now explicit: for most organisations, accelerators provide the fastest path to a deployment that aligns with Microsoft’s recommended practices. That is a stronger recommendation than the framework used to make, and it is worth understanding before deciding your estate is the exception.
This piece sets out what the accelerator actually deploys, the three topology choices you make before running it, and the conditions under which a custom build genuinely is the better answer.
What a landing zone is made of
The vocabulary trips people up, so it is worth being precise. A landing zone has two components, and they belong to different teams.
The platform landing zone is the centralised foundation. It establishes governance, security and shared resources for everything else. It consists of a management group hierarchy and whatever centralised resources you decide to run: connectivity and networking, security monitoring, identity services, management tooling. Most organisations should have exactly one platform landing zone per Microsoft Entra tenant.
Application landing zones are where workloads actually live. Most workloads use several, typically one per environment, so development, test and production each get their own. An application landing zone can be one subscription or several, and you only need several when workload requirements, organisational boundaries or Azure subscription limits force it.
The platform team places application landing zones under one of three management groups, Online, Internal (labelled “Corp”) or Local, beneath the Landing zones management group. Everything placed there inherits the Azure Policy assignments applied to the hierarchy above it. That inheritance is the entire mechanism by which governance holds as the estate grows, and it is why the hierarchy is the decision that costs most to get wrong.
The decision that gets made too quickly: what to centralise
The framework’s guidance on centralised resources contains a line worth reading twice: only centralise capabilities that provide clear governance, operational or economic benefit across multiple workloads.
In practice this is where most platform designs overreach. Centralising connectivity, identity and security monitoring is nearly always right. Centralising the build pipeline, the data platform, or a shared application gateway usually is not, because it converts a platform team into a delivery bottleneck for every workload team in the organisation.
The test is whether centralising the capability makes workload teams faster or slower. If a workload team has to raise a ticket with the platform team to ship, the boundary is in the wrong place.
The one we see most often is CI/CD. Clients centralise the build and release pipeline under the platform team for consistency, and it turns into a queue: workload teams waiting days for a pipeline change that should have taken an hour.
The fix is usually to split the two things that got conflated. Centralise the policy, approved base images and scanning gates, and leave pipeline ownership with the workload team. The platform team still decides what good looks like. It just stops being the bottleneck for every release.
Choosing a network topology before you run anything
An Azure landing zone accelerator will deploy whichever topology you choose, so the choice is yours and it is made first. There are three published patterns.
| Topology | What it gives you | Choose it when |
| Hub and spoke | Peered hub virtual networks per region, with Azure Firewall, Azure DNS, DDoS Protection and VPN or ExpressRoute gateways in a connectivity subscription | You want full control of routing and firewall policy, and you have the network engineering capacity to run it |
| Virtual WAN | Microsoft-managed Virtual WAN hubs per region carrying the same gateway and firewall services | You want Microsoft to operate the transit layer, and you value branch and remote connectivity at scale over granular routing control |
| Management group hierarchy only | The governance structure and policy inheritance, with no centralised networking | Your workloads do not need shared network transit, for example a mostly platform-as-a-service or SaaS-integration estate |
That third option is the underused one. Plenty of estates that are entirely platform-as-a-service inherit a hub and spoke design because it is the default picture in every architecture deck, then pay for firewall and gateway capacity that carries almost no traffic. The management group hierarchy alone is a legitimate landing zone.
Whichever you choose, the reference architecture is a starting point rather than a specification. Microsoft describes it as a recommended target architecture to adapt, not to adopt unchanged.
Subscription vending is the part that actually scales
The framework names a specific platform responsibility that is easy to skip and expensive to skip: you need a repeatable process for requesting, creating and distributing application landing zones to workload teams.
That process is called subscription vending, and it can be manual at first. The framework is direct about what happens next: as the number of requests grows, automation becomes increasingly important.
This is the difference between a landing zone that holds and one that decays. The governance model works because every new subscription arrives already placed in the right management group with the right policies inherited. The moment subscriptions start being created outside that process, by a workload team in a hurry or by a project with its own agreement, the policy inheritance no longer describes the estate. Drift does not usually begin with someone disabling a policy. It begins with a subscription that was never vended.
Our position: automate vending on day one
In our view you should automate subscription vending from day one, not when it becomes necessary. By the time it feels necessary you already have a handful of subscriptions that were created outside the process, and those are precisely the ones nobody can explain a year later.
A basic vending pipeline with a request form and an approval gate is a day of work. Waiting for volume to justify it only means the drift starts before the control exists.
When a custom build is the right call
The accelerator is the default, not a rule. There are conditions under which building your own is correct, and they are narrower than most organisations believe.
Regulatory or sovereignty requirements the reference architecture does not model. Some regulated estates have constraints on data residency, key custody or network egress that need a design conversation rather than a parameter.
An existing estate too large to re-platform. If you already run several hundred subscriptions under a hierarchy that works, adopting the accelerator wholesale is a migration project with limited return. Taking the design areas and applying them to what you have is usually better.
A genuinely unusual operating model. Organisations that operate as a federation of independent businesses, rather than one enterprise, sometimes need more than one platform landing zone despite the one-per-tenant guidance, and that is a deliberate exception rather than a default.
What does not justify a custom build is a preference for building things, or an assumption that the estate is too complex for a template. The accelerator is infrastructure as code and it is designed to be modified. Starting from it and diverging where you need to is nearly always cheaper than starting from nothing.
The design areas exist for exactly this reason. You work through the organisational decisions first, then choose whether an accelerator or a custom build implements them. Doing it the other way round, choosing the implementation and then discovering the decisions, is how estates end up with a hierarchy nobody can explain.
In the estates we have stood up, the accelerator route has consistently landed faster than the custom timeline it replaced, typically by weeks rather than months.
The more useful observation is where that time actually goes. It is almost never the deployment. It is the design-area decisions upstream of it, which is exactly why working through those first matters more than which implementation path you eventually pick.
Adopting new technology without redesigning
One property of a well-built landing zone is worth stating because it is the argument for doing this work before you need it.
A landing zone supports new and emerging technologies without changes to the overall architecture. Workload resources deploy into application landing zones regardless of workload type, including AI. When new requirements appear, you update governance and security policies in the platform landing zone, and those policies apply consistently across every application landing zone beneath.
That is why the AI conversation and the landing zone conversation are the same conversation, arriving in the wrong order. Organisations that already have a governed hierarchy absorb an AI workload as a policy update. Organisations that do not treat it as a new project with its own governance, and then have two governance models.
Where to start
Work through the design areas before choosing an implementation, then default to an accelerator unless you can name the specific constraint that rules it out. Decide your network topology deliberately rather than inheriting hub and spoke from a diagram. And automate subscription vending earlier than feels necessary, because that is the control that decides whether the design still describes the estate in two years.
Veratas designs and builds Azure platforms, and the enterprise architecture work that decides how they should be structured. Where workloads are custom applications rather than packaged software, our .NET and React practice builds into the same landing zones rather than alongside them.
If you have an Azure estate that grew without a landing zone and you are deciding whether to retrofit one, talk to our team. The answer depends on the hierarchy you already have, and it is a short conversation.
Frequently asked questions
What is an Azure landing zone accelerator? It is Microsoft’s reference landing zone architecture delivered as infrastructure as code, so you deploy a governed platform aligned to recommended practices rather than designing and building one from scratch.
Should we use an accelerator or build our own? Microsoft’s guidance is that accelerators are the fastest path for most organisations. A custom build is justified by regulatory constraints the reference architecture does not model, an existing estate too large to re-platform, or a genuinely federated operating model.
How many platform landing zones do we need? Most organisations should have exactly one per Microsoft Entra tenant. More than one is a deliberate exception, usually for organisations that operate as separate businesses rather than one enterprise.
Do we need hub and spoke networking? Not always. Hub and spoke and Virtual WAN both provide centralised transit, but a management group hierarchy with no centralised networking is a valid landing zone for estates that are largely platform-as-a-service.
What is subscription vending? It is the repeatable process for requesting, creating and distributing application landing zones to workload teams so each one arrives correctly placed in the management group hierarchy. It can start manual, but it needs automating as volume grows.
Cloud and enterprise architect with 17 years of experience across data platforms, integration and application development. Focus areas include Azure architecture, cloud-native application design, and ERP to data platform integration.