In the first two weeks of March we closed out two landing zone engagements, and the contrast between them is the whole argument for this note. The first was a regional bank standing up its first real Azure estate from a Cloud Adoption Framework blueprint: four subscriptions, four management groups, a hub-and-spoke network, and a policy set that took an afternoon to walk a security reviewer through. The second was a health check on a twelve-subscription "enterprise-scale" build a boutique cloud shop had delivered for a 6,000-seat manufacturer over the previous year — forty-some management groups, north of two hundred policy assignments, and nobody left on staff who could say with confidence why any particular resource lived where it did.
"Landing zone" gets used loosely enough now that it is worth being precise about what one actually is. It is not a GitHub repository, a set of Bicep templates, or a diagram with a hub in the middle. It is an operating model: a management group hierarchy that maps Azure Policy and RBAC scope to how the organization actually works, a small set of platform subscriptions carrying shared services, and a repeatable, low-friction way to land a new subscription into that structure without a change advisory board meeting every time it happens. Microsoft's enterprise-scale reference architecture is a reasonable starting shape for that model. It is a poor target for the size of it, when the estate behind it is forty virtual machines and three workloads.
What follows is the version we actually deploy for clients who are not running a thousand-subscription estate: the floor that still buys the governance benefit, and where we tell clients to stop copying the accelerator.
What a landing zone actually is, once you strip the diagram
Strip away the marketing and the Cloud Adoption Framework's documentation tree, and a landing zone answers five design questions: how billing and the Azure AD tenant are structured, how identity and access map onto that structure, how subscriptions and management groups are organized, how network connectivity is built, and how policy and platform automation get enforced without a human reading every deployment by hand. Everything else — the specific module set, the naming convention, the tag taxonomy — is implementation detail that should follow from those five answers, not precede them.
The manufacturer's environment had all the implementation detail and none of the design answers. Naming convention: enforced. Tag policy: enforced. But nobody could tell us which management group was authoritative for a given subscription's policy set, because subscriptions had been moved between groups by hand across three reorganizations and the diagrams were never updated to match. The Azure Policy compliance blade showed the current state of assignments. It did not show intent, and intent is what a landing zone is supposed to encode.
We start every engagement, large or small, by making a client answer those five questions on a whiteboard before we open the portal. If nobody in the room can say where a new production workload lands and why, no amount of Bicep is going to fix that afterward.
The four-subscription floor
Below the enterprise-scale reference's dozens of subscriptions, there is a floor that still buys the governance benefit. We rarely go below four: one for identity-adjacent platform services, one for management (Log Analytics, Azure Automation, backup), one for connectivity (hub virtual network, firewall, gateways), and at least one landing zone subscription per environment tier for actual workloads. Smaller clients collapse identity and management into a single platform subscription. We do not recommend collapsing connectivity into anything else — a compromised workload subscription should never be able to touch firewall rules or gateway configuration.
The management group tree carrying this is deliberately shallow:
Tenant Root Group
├─ Platform
│ ├─ Identity
│ ├─ Management
│ └─ Connectivity
├─ Landing Zones
│ ├─ Corp
│ └─ Online
├─ Sandbox
└─ Decommissioned
Four levels, and every level exists because something inherits from it. Policy assigned at Landing Zones applies to Corp and Online without reassignment. Sandbox exists so an engineer can spin up a throwaway subscription with looser policy for a proof of concept without touching production guardrails. Decommissioned exists so a subscription slated for closure loses its production policy assignments and network peering before someone forgets to close it and it sits there accruing a support charge for months. The bank's environment used exactly this shape. The manufacturer's had eleven top-level groups under root, three of them holding a single subscription each with no policy assignments of their own — inheritance nobody was using, complexity nobody needed.
Azure Policy is the guardrail; the compliance blade is not
Policy assigned at the management group level is the only part of this that actually prevents bad configuration before it ships; everything else is detection after the fact. We assign the built-in Azure Security Benchmark initiative at the Landing Zones management group, then layer a short list of deny-effect policies on top: allowed locations, matched to the client's actual data-residency requirement, not every region Azure offers; allowed resource types where the client has a genuine reason to restrict them; and a deny on public IP creation anywhere outside the connectivity subscription. Audit-effect policies cover tagging and diagnostic settings; we lean on deployIfNotExists so a new resource gets a Log Analytics diagnostic setting attached automatically, instead of failing an audit six weeks later.
New-AzManagementGroupSubscription -GroupName 'contoso-landingzones-corp' -SubscriptionId $subId
Get-AzPolicyState -ManagementGroupName 'contoso-landingzones' -Filter "ComplianceState eq 'NonCompliant'"
That second line is the one we run live in front of clients during a design review, because it turns policy from a slide into a fact. The manufacturer's tenant had an Azure Security Benchmark initiative assigned at the root — audit-only on every effect, no deny policies anywhere, and a compliance dashboard nobody had opened since it was assigned. Report-only policy is a legitimate stage of a rollout. It stops being legitimate the day nobody is scheduled to actually look at it.
Hub-and-spoke earns the diagram; a mesh rarely does
Connectivity is the design area clients most want to over-build, usually because someone read about ExpressRoute and multi-region failover before they had a second Azure region. The hub carries the Azure Firewall (or a vendor NVA, for clients already standardized on a specific appliance), the VPN or ExpressRoute gateway, and shared DNS resolution. Spokes peer to the hub only, never spoke to spoke, so the firewall stays the one inspection point for anything crossing a workload boundary. That constraint is worth defending. The first time a team asks for a direct spoke-to-spoke peering "just for this one project," you have started toward a mesh nobody can reason about during a two a.m. incident.
ExpressRoute earns its circuit cost when there is steady, latency-sensitive traffic between an on-premises datacenter and Azure — a SQL Server Always On configuration split across both sides, or a call center dependent on Azure-hosted line-of-business applications. A site-to-site VPN gateway, or for smaller estates a point-to-site setup limited to administrative access, covers the rest at a fraction of the fixed monthly cost. The bank had one region and one on-premises datacenter; a VPN gateway with BGP-based failover handled availability well enough that ExpressRoute is a conversation for next year, not one for this quarter.
Subscription vending kills the request queue
The Cloud Adoption Framework calls this "subscription vending," and the phrase describes something more modest than it sounds: a repeatable process — not always automated — that creates a new subscription, places it in the correct management group, applies tags, inherits the baseline policy set, and peers its virtual network to the hub, all without a two-week change ticket. For the bank, that process is a short pipeline triggered by a work item. For smaller clients we have built it as a documented runbook a platform engineer runs by hand in under an hour, because the automation is not worth engineering until an organization is vending more than a handful of subscriptions a quarter.
The point is not the tooling. The point is that a new subscription lands compliant on day one because policy is inherited from the management group it was placed into, rather than compliant eventually because someone remembered to run a hardening checklist. The manufacturer's process was a ticket into a cloud team that had since been reorganized twice. The last five subscriptions created had no consistent home, no consistent tagging, and no policy assignment beyond whatever the requester happened to configure on their own. None of that is a tooling gap. It is a process nobody owns.
Where mid-market stops needing the enterprise-scale accelerator
Microsoft's enterprise-scale reference implementation — the full architecture, deployed from the published modules — assumes an organization running dozens to hundreds of subscriptions, a dedicated platform team, multiple landing zone archetypes for different workload classes, and central connectivity sized for multi-region growth. Most of our clients are not that organization, and deploying the accelerator's defaults onto a twelve-subscription estate produces something close to the manufacturer's environment: correct in isolation, unmanageable in aggregate.
| Design area | What a 12-subscription estate needs | What we found deployed |
|---|---|---|
| Management groups | Four levels, one archetype (Corp) | Eleven top-level groups, three empty of policy |
| Connectivity | Single hub, Azure Firewall Standard, one VPN gateway | Two hubs, one unused, Premium firewall features enabled nowhere they mattered |
| Policy | One initiative plus five to eight custom deny policies | Root-level initiative, audit-only, 200-plus assignments, no owner |
| Identity | PIM-eligible roles for platform subscription owners only | Twenty-two permanent Owner role assignments across the tenant |
The fork is a staffing and growth question, not a technology one. When there is no dedicated platform team and no credible plan to reach fifty-plus subscriptions within two years, we build the four-subscription floor and leave clear extension points — an unused Online landing zone archetype, headroom in the policy initiative for a second workload class — rather than provisioning the full hierarchy up front. Growing into structure you left room for costs an afternoon later. Un-growing out of structure that was over-built from day one, with production workloads depending on it, costs a quarter and an invoice neither side enjoys.
If you're facing this
If your Azure estate has accumulated more management groups than anyone on staff can explain, or your policy initiative has been sitting in audit-only mode since assignment, that is worth a design review before you vend a fifth subscription onto the pile. We build full enterprise-scale landing zones for the clients who genuinely need them and the four-subscription floor for the ones who don't — bring us the management group tree you have today, however tangled it looks, and we will tell you honestly which one you are.