The Azure Landing Zone Field Guide

Most Azure environments are not designed. They accrete. Someone creates a subscription to try something, a second team lands their workload beside it, and eighteen months later the "platform" is a single subscription with forty resource groups, inconsistent RBAC, no policy, and a network that grew one peering at a time. Everything works until it doesn't — until an audit, a breach, a cost review, or a merger forces the question nobody owned: how is this actually structured?

A landing zone is the answer you wish you'd had on day one. It is the environment you stand up before the workloads, so that everything after has a defined place to live, a consistent identity model, a network it plugs into, and guardrails it inherits. Microsoft's Cloud Adoption Framework formalizes this, and this guide walks the version of it we actually deploy for mid-market organizations — the 80% that matters, without the enterprise-scale ceremony that a 200-person company will never use.

What a landing zone actually is

Strip away the marketing and a landing zone is four decisions made once, deliberately, at the platform level so no individual team has to re-make them:

1. How subscriptions are organized — the management group hierarchy and what governs each tier.
2. How identity works — who can do what, where, enforced by RBAC and Entra ID, not by convention.
3. How the network is shaped — the topology workloads connect into, and how traffic is inspected and routed.
4. What is non-negotiable — the policies that apply automatically, so compliance is the default state rather than a quarterly clean-up.

Get these four right and the environment scales by addition: a new team gets a subscription in the right place, inherits the right policy, plugs into the right network, and starts with the right access boundaries. Get them wrong and every new workload is a small negotiation.

Design area 1: the management group hierarchy

The management group hierarchy is the skeleton. Management groups are containers above subscriptions; policy and RBAC assigned to a group flow down to every subscription beneath it. This is the single highest-leverage structural decision you make, because it decides what "applies to everything" even means.

The mistake we see most is mirroring the org chart — a management group per department. Reorganizations then break your governance model, and they always come. Instead, structure by governance intent, which is far more stable than headcount:

• A top intermediate group under the tenant root (never assign policy at the tenant root itself — it is a blast radius you cannot easily undo).
• A Platform group for the shared services every workload depends on: identity, management, connectivity. These get their own subscriptions.
• A Landing Zones group for the actual workloads, typically split into Corp (internal, no direct internet exposure) and Online (internet-facing) because those two populations want genuinely different network and policy defaults.
• A Sandbox group with loose policy for experimentation, deliberately isolated so it can never become production by accident.
• A Decommissioned group where cancelled subscriptions land under a deny-most policy while they wind down.

For a mid-market org, that is the whole tree. Three or four intermediate groups, not fifteen. Depth is cost: every layer is another place policy can be assigned, another thing to reason about when a deployment is unexpectedly denied.

Design area 2: subscription organization

With the hierarchy in place, subscriptions become the unit of scale and isolation. A subscription is a billing boundary, a policy boundary, and a natural blast-radius boundary. The old advice to cram everything into one subscription "for simplicity" is exactly backwards — one subscription means one policy set, one set of quota limits, and one very bad day when something in it goes wrong.

Our default vending pattern for mid-market:

• One subscription per platform capability — a Management subscription (Log Analytics, automation, monitoring), an Identity subscription (domain controllers or Entra Domain Services if used), and a Connectivity subscription (the network hub, firewall, gateways).
• One subscription per workload environment where isolation matters — production separate from non-production at minimum. A regulated workload often earns its own subscription outright.
• Tags from birth. Every subscription and resource carries owner, cost-center, and environment tags, enforced by policy (design area 4). Untagged resources are un-ownable resources, and un-ownable resources are where both waste and risk hide.

You do not need automated subscription vending tooling at this scale. A documented request-and-provision process a platform engineer runs is fine until you are creating subscriptions weekly. Don't buy the enterprise machine before you have the enterprise problem.

Design area 3: network topology

Network is where landing zones earn their keep, because it is the design area that is genuinely painful to change later. Re-tag a resource in an afternoon; re-architect a network topology across live workloads over a quarter.

The default is a hub-and-spoke topology. A central hub VNet in the Connectivity subscription holds the shared network services: the firewall (Azure Firewall or an NVA), the VPN or ExpressRoute gateway to on-premises, and shared DNS. Each workload lands in its own spoke VNet, peered to the hub. Traffic between spokes, and to on-premises or the internet, routes through the hub where it can be inspected and logged.

Why this shape:

• Centralized inspection. One firewall, one set of rules, one place to log egress — instead of each workload team inventing their own perimeter.
• Clean isolation. Spokes don't peer to each other by default, so a compromise in one workload doesn't have lateral network paths into the next.
• Shared connectivity, paid once. The expensive ExpressRoute circuit and the VPN gateway live in the hub and serve every spoke.

For organizations already spread across many regions or planning to be, Azure Virtual WAN is the managed evolution of this same pattern — Microsoft runs the hub for you. But for a single-region or two-region mid-market footprint, a hand-built hub-and-spoke is cheaper, more transparent, and entirely sufficient. Start there.

Address space is the one thing to get right up front: allocate a non-overlapping private range per region and carve spokes out of it deliberately. Overlapping ranges are the single most common reason two Azure networks cannot be joined later — and "later" is usually an acquisition or a partner integration you can't reschedule.

Design area 4: policy and guardrails

This is what makes a landing zone stay a landing zone. Azure Policy evaluates resources against rules and can audit, deny, or automatically remediate. Assigned at a management group, a policy applies to every subscription beneath it — which is exactly why the hierarchy came first.

The starter guardrail set we deploy, in roughly the order of value:

• Allowed regions. Deny resource creation outside your approved regions. Stops accidental sprawl into geographies with different compliance and latency, and it is the single most effective cost and data-residency control you can set.
• Required tags. Deny (or auto-append) resources missing owner and cost-center. Ownership is the foundation of both cost governance and incident response.
• Deny public IPs on workloads that shouldn't have them — enforced in the Corp landing zone group so internal workloads cannot accidentally expose themselves.
• Diagnostic settings by default. A deployIfNotExists policy that routes resource logs to the central Log Analytics workspace automatically. Observability you have to remember to turn on is observability you won't have during the incident.
• Encryption and secure-transport baselines — HTTPS-only storage, TLS minimums, encryption at rest — audited everywhere and denied in production.

Deploy these as audit-first, watch what they flag for a week, then flip the high-confidence ones to deny. Turning on deny policies blind, over a live estate, is how you break a Friday deployment and lose the room's trust in governance. Ease in.

Accelerators: don't hand-build what Microsoft maintains

Everything above can be stood up by hand, and understanding it by hand is worth doing once. But in practice we deploy most of it with the Azure landing zone accelerator — Microsoft's maintained Bicep and Terraform modules that provision the hierarchy, the platform subscriptions, the hub network, and the baseline policy set from a parameter file.

The accelerator is worth using because it encodes current Microsoft guidance and is kept in step with platform changes — you inherit updates instead of maintaining a bespoke fork. The judgment is in the parameters, not the plumbing: which regions, which policy posture, hub-and-spoke versus Virtual WAN, how the management groups are named. That is where experience matters and where a generated template alone will not save you.

The operational handoff

A landing zone is not a project you finish; it is an environment you operate. The handoff that makes it stick has three parts:

• A platform owner. One named person or small team owns the management groups, the policy set, and the network hub. Without an owner, entropy wins and you are back to accretion within a year.
• A change path for guardrails. Policy exemptions and new policies go through a defined request, not an ad-hoc portal click. The whole value is that the rules are deliberate.
• A review cadence. Azure ships new services and new policy definitions constantly. Revisit the guardrail set and the network posture on a schedule — quarterly is reasonable — against current Microsoft guidance.

Where to start

If you're standing up Azure from scratch, build the hierarchy and the platform subscriptions first, then the hub network, then the policy set in audit mode — before a single production workload lands. If you're retrofitting an environment that already accreted, don't try to boil the ocean: introduce the management group hierarchy, move existing subscriptions into it, and start applying audit policies to see where you stand. The guardrails come next, the network last, because it's the hardest to move under live traffic.

We run this as a structured foundation engagement — mapping the current state, designing the hierarchy and network, deploying the accelerator with your parameters, and handing it off with the ownership model in place. If you'd rather have a checklist to self-assess against first, our Azure Landing Zone Checklist is the condensed version of everything above. And if you want us to build it with you, that's the Azure Foundation service — book a discovery call and we'll tell you where your environment sits against this and what we'd do first.