Do we need a landing zone, or just a subscription?

If one team is running one workload and nothing has to be governed across subscriptions, a subscription and good habits will hold for a while. A landing zone earns its cost when a second team arrives, when policy has to be provable rather than promised, or when somebody has to answer for what is deployed where. The honest test is whether anyone could currently tell you what exists across the tenant.

Should we use Microsoft's accelerator or build our own?

Start from the accelerator. It deploys the recommended patterns as infrastructure as code, and the parts of it you disagree with are visible and changeable. A custom build is justified when a real constraint makes the accelerator wrong - a regulated network boundary, an existing tenant that cannot be reorganised - and not because it feels more tailored.

We already have Azure. Is it too late?

No, and this is the usual starting point. An existing estate is retrofitted rather than replaced: the hierarchy is designed around what is already deployed, policy is introduced in audit mode before it enforces anything, and subscriptions move in a planned order. It is slower than starting clean and entirely normal.

Is there something we can look at first?

Yes. DBHQ publishes a working application landing zone as an open reference build - golden-path Terraform on Microsoft's own Azure AI Landing Zone Verified Module, for a private-networked workload, with the expensive resources off by default. It is there to be read and judged before anyone is engaged.

What access do you need?

For an assessment, read-only across the tenant is enough - the management group hierarchy, subscriptions, policy assignments and network topology. Anything that changes the estate is agreed separately and in writing.

A fixed fee for an agreed scope, quoted after a short call. Where the estate is undocumented enough that the scope cannot be bounded honestly, the investigation is quoted on its own first rather than hidden inside a build price.

Azure Landing Zone

Microsoft's architecture for governing a multi-subscription Azure estate comes in two halves, and knowing which one you actually need is most of the decision.

Two halves, and most explainers only describe one

An Azure landing zone is Microsoft's proven architecture for governing, securing and scaling an estate that spans more than one subscription. It has a platform landing zone - the centralised foundation - and application landing zones, where workloads actually run inside the guardrails that foundation sets.

The ratio is the useful part. Microsoft's guidance is that most organisations should have exactly one platform landing zone per Entra tenant, and that each workload gets a single application landing zone. So "we need a landing zone" is usually two different projects wearing one name, on different timescales, bought by different people.

Either half can be deployed from a Microsoft accelerator or built bespoke. The accelerator is the right default, and the interesting question is which parts of it your constraints make wrong.

Which half is which

Microsoft's own terms, and the scope rule that goes with each - the thing to settle before anyone opens a template.

PLZPlatform landing zoneOne per Entra tenant
The centralised foundation: a management group hierarchy that applies governance to every subscription under it, the shared capabilities worth centralising (connectivity, identity, security monitoring, management), and a repeatable way to hand landing zones out to workload teams. Microsoft's guidance is that most organisations should have exactly one.
ALZApplication landing zoneOne per workload
Where a workload actually lives, inside the guardrails the platform sets. It holds every environment that workload needs - development, test, production - each of which is one or more subscriptions, and the platform team places it under the Internal, Online or Local management group according to how exposed it is.

Both sit under the same management group hierarchy, and that hierarchy is what makes policy inheritable rather than aspirational. It is also the first of the four decisions below.

The decisions that stick

Cheap on day one, structural by month six. These are the four worth slowing down for.

The management group hierarchy is the governance, not a folder tree

Policy is assigned to management groups and inherited by every subscription beneath them, so the shape of the hierarchy decides what can be enforced and what has to be asked for. Separating platform subscriptions from workload subscriptions is the part that is painful to retrofit, because moving a subscription changes what it inherits.

Hub-and-spoke or Virtual WAN is a commitment, not a preference

Microsoft publishes both as reference architectures and they are not interchangeable later. Virtual WAN buys managed transit and routing at a price and with less control; hub-and-spoke keeps the control and hands you the routing. Pick against what the network has to do in three years, not what is quickest to stand up now.

Centralise only what earns it

Microsoft's own wording is to centralise capabilities that give clear governance, operational or economic benefit across multiple workloads. Everything else centralised becomes a queue: a platform team approving changes for teams who could have owned them.

Decide how a landing zone gets handed out before you need the tenth

Subscription vending is the repeatable request-create-distribute process for application landing zones. Manual is fine for the first few and becomes the bottleneck; automating it after the backlog exists means retrofitting governance onto subscriptions that were created without it.

What DBHQ does with this

Azure platform and application landing zones designed, built as infrastructure as code, and handed over to a named operational owner. Bounded, scoped and quoted before anything starts.

One engagement from the delivery record, as the first engineer on the programme:

A platform foundation built from zero
First engineer and cloud architect on a major defence programme, rebuilding its clinical systems from the ground up.
- Built the programme's entire Azure estate from zero: three isolated environments on a hub-and-spoke network across multiple security boundaries
- A Terraform framework of reusable modules, adopted as the programme-wide infrastructure standard

See the work

There is a working application landing zone to read before anyone is engaged: golden-path Terraform on Microsoft's own Azure AI Landing Zone Verified Module, for a secure, private-networked workload, with the money-pit resources off by default. See the reference builds →

Where the estate already exists and the question is whether one workload on it can go live or change hands, that is a different purchase with its own answer. The Azure Well-Architected Review in full → Production delivery in full →

Questions, answered

Do we need a landing zone, or just a subscription?: If one team is running one workload and nothing has to be governed across subscriptions, a subscription and good habits will hold for a while. A landing zone earns its cost when a second team arrives, when policy has to be provable rather than promised, or when somebody has to answer for what is deployed where. The honest test is whether anyone could currently tell you what exists across the tenant.
Should we use Microsoft's accelerator or build our own?: Start from the accelerator. It deploys the recommended patterns as infrastructure as code, and the parts of it you disagree with are visible and changeable. A custom build is justified when a real constraint makes the accelerator wrong - a regulated network boundary, an existing tenant that cannot be reorganised - and not because it feels more tailored.
We already have Azure. Is it too late?: No, and this is the usual starting point. An existing estate is retrofitted rather than replaced: the hierarchy is designed around what is already deployed, policy is introduced in audit mode before it enforces anything, and subscriptions move in a planned order. It is slower than starting clean and entirely normal.
Is there something we can look at first?: Yes. DBHQ publishes a working application landing zone as an open reference build - golden-path Terraform on Microsoft's own Azure AI Landing Zone Verified Module, for a private-networked workload, with the expensive resources off by default. It is there to be read and judged before anyone is engaged.
What access do you need?: For an assessment, read-only across the tenant is enough - the management group hierarchy, subscriptions, policy assignments and network topology. Anything that changes the estate is agreed separately and in writing.
What does it cost?: A fixed fee for an agreed scope, quoted after a short call. Where the estate is undocumented enough that the scope cannot be bounded honestly, the investigation is quoted on its own first rather than hidden inside a build price.

An independent view of Microsoft's Azure landing zone guidance. DBHQ is not affiliated with, endorsed by, or certified by Microsoft. Microsoft's architecture, terminology and accelerators change - check the current Cloud Adoption Framework documentation before committing to a design.

Platform foundation, or one workload?

Describe what is already in the tenant, who has to govern it and what is waiting to be deployed. You will get a straight answer on which half of this you need and whether it is ready to quote.

Bring me the problem Book a call

I reply within 24 hours