Which Azure Landing Zone Do You Need? A Scoping Guide (2026)

Which Azure Landing Zone Do You Need? (Short Answer)

“Landing zone” describes four nested things in Azure: a single subscription with guardrails, an application landing zone for one workload, a platform landing zone (the shared identity, connectivity and management backbone), and the full enterprise architecture that combines all of them under management groups and policy as code. Scope from your destination, not the phrase: one workload needs an application landing zone; “we’re moving the business to Azure” needs the platform first. Before you compare quotes or sign off scope, ask the only question that cuts through: which one do you mean, and what is it actually for?

One phrase, four very different things

Microsoft’s own Cloud Adoption Framework uses the term at several nested levels. That’s not Microsoft being sloppy – it’s that a landing zone is genuinely a layered idea. But it means the unqualified phrase tells you almost nothing on its own. Here is the spectrum hiding inside those two words, smallest to largest:

• A single subscription with some guardrails. One subscription, a handful of policies, some RBAC, maybe a budget alert. Microsoft even documents a path for exactly this – transitioning a single subscription into the reference architecture later. For a small estate or a proof of concept, this can legitimately be “the landing zone”.
• An application landing zone. The home for one workload. In CAF terms it’s one or more subscriptions for a single application, with its environments (dev, test, prod) and the controls that workload needs. This is what most people picture when a single team says “we need a landing zone for our app”.
• A platform landing zone. The shared backbone every workload plugs into – identity, connectivity, monitoring and management, usually as dedicated subscriptions run by a central team. This is the part people underestimate, because it’s invisible until it’s missing.
• A full Azure landing zone. The whole standardised environment: the platform landing zone plus every application landing zone underneath it, the management group hierarchy that organises them, and policy as code enforcing the rules across the lot. This is the “scaffolding for a multinational” end of the scale.

Notice that three of those four are literally called “landing zone”. When someone says they have one, they could be anywhere on that ladder.

Why the ambiguity bites – and where it costs you money

This isn’t a vocabulary nitpick. The fuzziness has a price, and it usually lands at procurement and delivery:

• Quotes that look comparable but aren’t. If you put “build us a landing zone” out to three suppliers, you can get three numbers that are honest, competent, and describing completely different things. One quoted a single guarded subscription. One quoted a workload home. One quoted the full platform with management groups and policy as code. The cheapest number wins the meeting and loses you the year.
• Projects scoped as one thing and delivered as another. A team asks for “a landing zone”, gets a single subscription with a few policies, and only discovers six months in that there’s no platform underneath it – no shared identity model, no connectivity hub, no governance to inherit. Now the second, third and fourth workloads have nowhere consistent to land. Worse than over-spending: you’ve delivered the wrong outcome.
• Two teams “have a landing zone” at completely different maturity. One means a governed platform with subscription vending. The other means a subscription they turned on last Tuesday. Both report “done” to the same steering committee, and the committee thinks it has parity. It doesn’t.

So which one do you actually need?

You scope a landing zone from where you’re going, not from the phrase. A few honest questions sort it quickly:

• Is this one workload, or the foundation for many? One app that needs a tidy, governed home is an application landing zone problem. “We’re moving the business to Azure” is a platform problem first, applications second.
• Who runs the shared services? If identity, networking and monitoring need to be owned centrally and inherited by every team, you need a platform landing zone before anything lands on it. If there genuinely are no shared services to speak of yet, a single guarded subscription may be honest for now – as long as everyone knows that’s what it is.
• How regulated and how many teams? The more teams provisioning their own resources, and the more you have to prove governance to an auditor, the further up the ladder you go – management groups, policy as code, subscription vending – because that’s the only way control scales without becoming a bottleneck.
• What does “later” look like? A single subscription is a perfectly good starting point if you’ve deliberately chosen it and know the upgrade path. It’s a trap if you backed into it because nobody asked the question. Microsoft documents the transition from a single subscription into the full reference architecture precisely because so many people start there.

The trap to avoid in both directions: don’t buy a multinational platform to host one internal app, and don’t pour ten workloads onto a single subscription because that’s what “landing zone” meant the first time someone said it.

The one question that cuts through it

Whenever the phrase shows up – in a vendor meeting, a quote, a kickoff – there’s a single question that does most of the work:

“Which one do you mean, and what is it actually for?”

Ask it before you compare prices. Ask it before you sign off scope. Ask it of your own team before they tell the board it’s built. The answer tells you which rung of the ladder you’re really on, and whether the number in front of you is buying that rung or a different one.

Knowing which landing zone a situation needs is the job. The phrase will not tell you. The judgment will.

The Career Angle: This Question Is the Job

Here’s why this matters beyond tidy vocabulary. The gap between an Azure engineer role and a cloud architect role is not more PowerShell. It’s exactly the judgment this article walks through: hearing an overloaded phrase in a meeting, recognising that four different scopes are hiding inside it, and asking the clarifying question before the money moves. UK Azure engineers typically sit around £45k-65k; cloud and solutions architects who can scope this conversation credibly sit at £70k-95k and up. The delta is paid for judgment, not tooling.

It’s also one of the cheapest skills to practise. You don’t need an employer’s estate to learn the ladder: a free-tier tenant lets you build management groups, apply policies and vend yourself subscriptions-in-miniature, and our learning Azure for free guide covers how to do that without a bill. In an interview, being able to say “landing zone can mean four things, here’s how I’d find out which one you mean” is a stronger architect signal than any certification badge, because it demonstrates you’ve seen the ambiguity cost someone money.

Where to go deeper

The companion piece to this article takes the next decision down the ladder: subscriptions vs resource groups, and when you actually need a new one – including why “more subscriptions is bad” stopped being true.

If you want the canonical definitions, Microsoft’s What is an Azure landing zone? is the source of truth for the platform-versus-application split and the eight design areas, and the design area documentation covers what sits inside each rung. If you’re earlier in the Azure journey and want the fundamentals underneath all of this – identity, networking, governance – start with our Azure AZ-104 series, especially the identity and governance module.

And the broader point isn’t really about Azure. The same overloaded word, the same non-comparable quotes, the same “we built it” that means four different things – that pattern shows up across cloud the moment a vendor term gets popular enough to be useful as a label and vague enough to be useless as a specification. The skill is asking the boring clarifying question before the expensive decision.