Azure landing zones get explained backwards. People reach for the diagram first, the management group tree with its neat boxes, and treat the landing zone as a thing you deploy. It is not a thing. It is a set of decisions you make before any workload exists, about how your Azure environment is organized, secured, connected, governed, and paid for, made deliberately and written down so they can be reproduced. The diagram is downstream of the decisions. Pour the foundation, then build the house.
I want to be precise about the two layers, because the whole design depends on keeping them apart. The platform landing zone is the shared infrastructure that IT owns: the network hub, the connection back to on-premises, the central log workspace, DNS, the security tooling. The application landing zones are where the business workloads actually run, the file server, the line-of-business app, the Cloud PC pool, and they inherit their governance from the platform layer above them. Platform serves workloads. When someone stands up a virtual machine in a random resource group with a public IP and no logging, the thing they skipped was the platform layer, and everything painful that follows traces back to that.
Most organizations are already in Azure and do not realize it. Every Microsoft 365 tenant is an Entra tenant, so identity, the real backbone, is already there. What is usually missing is everything else. The common case, and I mean common, is the environment that grew by accident: a pay-as-you-go subscription somebody created to host one or two servers, direct role assignments handed to individual people, a VPN that works but nobody documented, a Secure Score nobody has looked at, and no central logging at all. Often the admin who built it has moved on. This was not built wrong. It was built without a plan, one reasonable decision at a time, until it became something no one wants to own. The landing zone is the plan, applied late but applied correctly, with the accidental environment migrated into it deliberately rather than bulldozed.
The thesis, stated plainly
Microsoft publishes a reference architecture for all of this. It is correct. It is also written for enterprises that have hundreds of subscriptions, a dedicated platform team, and a continuous delivery pipeline whose only job is to own the foundation itself. If you deploy that reference as it ships into a company of four hundred people, you have built a cathedral for a congregation of one, and you will spend the next year maintaining machinery that solves problems you do not have.
The response to that is not to scale the reference down. “Scaled down” is the wrong frame and it breeds bad instincts, because it implies you are shipping a lesser, compromised version and quietly cutting corners. You are not. The principles do not change with size. Separate platform from workloads. Inherit governance from the top. Never assign standing privilege you do not need. Log everything to one place. Those hold at four hundred users exactly as hard as they hold at forty thousand. What changes is the machinery you deploy to honor them. An enterprise honors “separate platform from workloads” with dedicated platform subscriptions and automated subscription vending. A two-hundred-person company honors the identical principle with resource groups and tags inside a single subscription, and reaches for the heavier machinery only when a real trigger arrives. Same principle, right-sized implementation. That distinction runs through every article in this series.
About the accelerator
You will hear, correctly, that Microsoft ships an accelerator that will deploy a landing zone for you. It exists, it is current, and as of early 2026 it is built on Bicep Azure Verified Modules, with the older classic implementation retired from the accelerator this year. It is genuinely good engineering. It will also deploy the full enterprise platform: the complete management group hierarchy, dedicated platform subscriptions, well over a hundred policy assignments, hub networking with Azure Firewall. For a large organization with a platform team to run it, that is exactly right.
I am not going to tell you to run it, and I want to be honest about why. This series builds the foundation by hand, because you are going to operate this environment for the next decade and you should understand every piece of it. An accelerator that provisions eighty percent of an architecture you cannot explain is not a gift. It is a debt with a delayed due date. When something inherits a policy you did not know was assigned, or a private endpoint stops resolving at two in the morning, “the accelerator set it up” is not an answer. So we will name the accelerator, understand what it does, and build the thing ourselves, so that by the end you could evaluate it on its merits rather than trusting it on faith. If you finish this series and then choose to use it, you will use it well. That is the difference I care about.
Who this is for
This series is written for the organization spending somewhere under two thousand dollars a month in Azure, which in practice tends to mean somewhere under two thousand users, though the spend is the sharper line. That is the shop with a handful of servers, maybe a Cloud PC pool, a VPN back to an office, and a bill that has started to attract attention from someone who signs checks. It is deliberately not written for the enterprise with a platform team, and it is not written for the pure cloud-native startup with nothing on-premises and no legacy to carry, though that reader will find most of it applies with less to work around. The running example throughout is the most common real engagement I see: a hybrid organization with on-premises Active Directory, file and application servers, a site-to-site VPN, Business Premium licensing, and a stated intent to move toward the cloud without having finished the journey. Where a cloud-only reader would do something differently, I will say so.
The eight components, and the order they go in
A right-sized foundation is eight things, and naming them now gives you the map for everything that follows. First, the management group hierarchy, the governance backbone. Second, the subscriptions placed inside it. Third, the resource group structure, the day-to-day boundary where most actual work happens. Fourth, the network foundation, the hub-and-spoke topology with its connection to on-premises and its DNS. Fifth, identity and access, which governs who can do what and where. Sixth, the security baseline, which turns on Defender for Cloud and centralizes secrets. Seventh, monitoring and logging, which feeds one Log Analytics workspace. And eighth, the policy baseline, the three layers of Azure Policy that enforce the whole design instead of leaving it as a document nobody follows.
There is a trap here worth naming on day one: the order you read those in is not the order you build them in. Reading top to bottom is pedagogical. Building has dependencies that will bite you if you ignore them. The log workspace has to exist before you assign the policies that auto-configure diagnostics, because those policies take the workspace’s identifier as an input. In a brownfield environment, every policy has to be in audit mode before you move an existing subscription into the hierarchy, or resources that were fine yesterday can start blocking changes today. The VPN tunnel has to be up before the private DNS resolver’s rules mean anything. Each build article in this series states its prerequisites at the top for exactly that reason, and the correct build order runs: hierarchy and subscriptions first, then the workspace, then policy in audit mode, then the network, then private DNS, then identity, then the security plans and the alarms, then the transition of policy from audit to enforcement, and finally the operating rhythm that keeps the whole thing from decaying.
That last piece is the one most guides skip and the one that matters most. A foundation is not a deployment you finish. It is an environment you keep governed, and the day it stops being maintained is the day it starts drifting back toward the accidental IaaS it replaced. We will build it correctly, and then we will spend real time on how to keep it boring, because a boring Azure environment, one where nothing surprises you, is the entire point.
Azure Landing Zones
Next: [LZ 2] Where You Are Starting From ›
