A cloud environment rarely fails all at once. It erodes. Someone spins up a subscription for a proof of concept, a second team copies the pattern, a third inherits an account from an acquisition, and within a year the tenant holds forty subscriptions that share no naming convention, no common policy, no agreed network model, and no clear owner. Azure landing zones exist to stop that erosion before it starts, by giving an organization a deliberate structure for its subscriptions, its governance, its connectivity, and its identity instead of letting all four accrete by accident. The pattern is not a single resource you deploy and forget. It is the set of platform services, management group placements, policy assignments, and access controls that form the operational floor every workload stands on.

The problem a landing zone solves is the cost of disorder discovered late. When a security team finally tries to enforce a tagging standard across a sprawl of ungoverned subscriptions, the work is no longer a policy assignment; it is a migration project touching hundreds of resources owned by people who have moved teams. When a network team tries to route every subscription through a central firewall after the fact, half the workloads already have public endpoints and direct internet egress baked into their design. The structure that would have been cheap to impose on day one becomes expensive precisely because it was deferred. A landing zone front-loads that structure so the foundation is in place before the first production workload arrives.

This guide treats the landing zone as an architecture pattern with a defensible internal logic rather than a checklist to copy. You will leave understanding what a landing zone is at the level of its moving parts, how the management group hierarchy organizes subscriptions so that governance applies once at the top instead of being repeated per subscription, why the platform concerns split cleanly from the application concerns, and how the whole arrangement aligns with the Cloud Adoption Framework that Microsoft publishes as its reference. The aim is that you can design a foundation that scales, defend each placement decision in a review, and recognize the failure modes (sprawl, per-subscription policy, mixed concerns) before they cost you a quarter to unwind.

What an Azure landing zone actually is

Strip away the marketing and a landing zone is an answer to a single organizational question: where does a new workload go, and what does it inherit when it gets there? In an ungoverned tenant the answer is improvisation. Someone creates a subscription, someone else grants access, a network engineer eventually peers it to something, and a security reviewer discovers the gaps months later. A landing zone replaces that improvisation with a known destination. A workload lands in a subscription that already sits under the right management group, already carries the policies that group enforces, already connects to the central network through a sanctioned path, and already trusts the central identity provider. The workload team does not assemble the foundation; they receive it.

That framing matters because it corrects the most common misreading, which is to treat a landing zone as a product or a single template. It is neither. It is a composition of several Azure constructs working together. Management groups arrange subscriptions into a hierarchy so that policy and access flow downward by inheritance. Azure Policy expresses the guardrails (allowed regions, required tags, denied resource types, mandatory diagnostic settings) and assigns them at the management group level so every subscription beneath inherits them. A central virtual network or a Virtual WAN hub carries connectivity so traffic between workloads and to on-premises follows a controlled route. Microsoft Entra ID anchors identity so authentication and role assignment use one trusted source rather than a patchwork of local accounts. Log Analytics and Defender for Cloud collect the telemetry and the security posture in one place. The landing zone is the coordinated arrangement of those pieces, not any one of them.

What is an Azure landing zone?

An Azure landing zone is a pre-configured, multi-subscription environment built to the Cloud Adoption Framework, with governance, network connectivity, identity, and monitoring established before any workload deploys. It gives each new workload a governed subscription that inherits policy and access from a management group hierarchy rather than starting from a blank, ungoverned account.

The Cloud Adoption Framework, Microsoft’s published guidance for adopting Azure at scale, formalizes the concept and breaks it into design areas that a complete environment must address. The current reference identifies eight: the billing and Entra tenant arrangement, identity and access management, management group and subscription organization, network topology and connectivity, security, management, governance, and platform automation with DevOps. You do not have to memorize the list, but the shape it implies is worth holding onto. Roughly half of those areas are shared concerns that serve every workload, and roughly half describe how an individual workload plugs into the shared foundation. That division is the seed of the platform-versus-application split this article builds toward, and it is the reason the framework reads less like a feature catalog and more like an organizational chart for your cloud.

It helps to name what a landing zone is not, because the term gets stretched. A landing zone is not a resource group with some resources in it. It is not a naming convention on its own. It is not a one-time deployment that you run and walk away from, because the policies, the connectivity, and the access model all evolve as the organization does. And it is emphatically not a separate construct for each new kind of workload. Teams sometimes ask where the “data landing zone” or the “AI landing zone” goes in the hierarchy, and the Cloud Adoption Framework answer is blunt: those are workloads, and they deploy into ordinary application landing zones alongside everything else. The foundation is general; the workloads that arrive on it are specific.

The management group hierarchy that organizes subscriptions

The structural heart of a landing zone is the management group hierarchy, and understanding why it exists requires understanding what a subscription is and is not. A subscription is a billing and management boundary. It is the unit Azure uses to scope quotas, to bound a deployment, to attach an Entra tenant, and to isolate one set of resources from another. What a subscription is not, on its own, is a place where policy and access naturally aggregate. If you assign a policy directly to a subscription, that assignment lives and dies with that subscription. Assign the same policy to two subscriptions and you maintain two assignments. Scale that to forty subscriptions and the per-subscription approach becomes a maintenance burden that guarantees drift, because no human keeps forty copies of anything synchronized for long.

Management groups break that trap. A management group is a container for subscriptions, and crucially, for other management groups. You build a tree: a root group at the top, intermediate groups beneath it that represent meaningful divisions, and subscriptions as the leaves. Policy assigned at a management group flows down to every subscription and every child group beneath it through inheritance, and role assignments behave the same way. Assign the “require a tag for cost center” policy once at an intermediate group and every subscription under it inherits the rule without a separate assignment. Move a subscription to a different group and it picks up that group’s inherited governance immediately. The hierarchy turns governance from a per-subscription chore into a property of position.

How do management groups structure a landing zone?

Management groups arrange subscriptions into a tree so that Azure Policy and role assignments inherit downward. You place a subscription under the group whose governance it should receive, and it inherits every policy and access grant assigned at that group and above. Governance becomes a function of where a subscription sits rather than a setting you repeat per subscription.

The reference hierarchy the Cloud Adoption Framework recommends has a recognizable shape, and it is worth walking through because the shape encodes the platform-versus-application split. Below the tenant root sits an intermediate root group, often named for the organization, that exists so you never assign policy directly at the tenant root (a placement that is hard to scope and easy to get wrong). Beneath the intermediate root sit the meaningful divisions. One branch, usually called Platform, holds the subscriptions that run shared services: a connectivity subscription for the central network, an identity subscription for domain controllers or Entra Connect, and a management subscription for logging and monitoring. A second branch, usually called Landing Zones, holds the application subscriptions where workloads actually run, frequently split further into a corporate group for internally connected workloads and an online group for internet-facing ones. Two more branches typically round out the tree: a Sandbox group for experimentation that is deliberately isolated and loosely governed, and a Decommissioned group where subscriptions go to be retired in a controlled way.

A discipline worth internalizing early is to keep the hierarchy shallow. The framework guidance is explicit that a management group tree should rarely exceed three to four levels, because every level adds cognitive overhead and inheritance complexity without adding governance value. The temptation to model the entire org chart in management groups (a level for the division, a level for the department, a level for the team, a level for the project) produces a tree so deep that nobody can reason about what a given subscription actually inherits. Resist it. Management groups exist to apply governance at scale, not to mirror reporting lines. If two groups would carry identical policy, they should probably be one group. The structure should reflect how governance differs, not how the company is organized.

A second discipline concerns where policy and access actually attach. Because inheritance flows down, the correct instinct is to assign the broadest, most universal guardrails as high as they apply and the narrower, workload-specific rules as low as they belong. A policy that denies resource creation outside approved regions belongs near the top, because it applies to everyone. A policy that requires a specific network configuration for internet-facing workloads belongs on the online group, because only those workloads need it. Getting this layering right is what lets the hierarchy do its job; getting it wrong, by assigning everything at the root or everything per subscription, throws away the inheritance the structure was built to provide.

The platform-then-application rule

Here is the central organizing claim of this article, the rule that turns a pile of Azure constructs into a coherent design. A landing zone separates shared platform concerns from application workloads, and building the platform foundation first is what lets application environments scale without sprawl. Call it the platform-then-application rule. The shared concerns are connectivity, identity, and governance: the central network everyone routes through, the identity source everyone trusts, and the policy and monitoring that apply to everyone. The application concerns are the workloads themselves: the web app, the data pipeline, the API, each in its own subscription. The rule states that you establish the shared foundation as a coherent unit before you onboard the first workload, because the workloads depend on the foundation and a foundation retrofitted under live workloads is the single most expensive mistake in cloud architecture.

The reason the ordering matters is dependency direction. Application landing zones consume what the platform provides. A workload subscription peers to the central network, sends its logs to the central workspace, inherits its policies from the management group above, and authenticates against the central identity provider. If the platform exists first, onboarding a new workload is a repeatable act: create a subscription, place it under the right group, peer it to the hub, and the inherited governance and the established connectivity are simply there. If the platform does not exist first, every new workload improvises its own networking, its own logging, and its own access model, and you have recreated the sprawl the landing zone was meant to prevent, only now with the added cost of pretending it was a design.

What is the platform versus application landing zone split?

The platform landing zone holds shared services that every workload uses: central connectivity, identity, management, and governance, typically one per tenant. Application landing zones hold individual workloads, one per workload and often one per environment. The platform is built first because applications depend on the connectivity, identity, and policy it provides.

The platform side decomposes into three or four subscriptions, each with a single responsibility. The connectivity subscription owns the central network: the hub virtual network or the Virtual WAN hub, the firewall, the gateways for site-to-site or ExpressRoute links, and the private DNS that workloads rely on for name resolution. The identity subscription owns whatever identity infrastructure the organization runs in Azure, whether that is domain controllers for legacy workloads or the components that synchronize on-premises identity to Entra ID. The management subscription owns the shared observability and security tooling: the Log Analytics workspace that aggregates platform logs, the automation accounts, and the configuration that feeds Defender for Cloud. Keeping these separate is deliberate. A blast radius in the connectivity subscription should not touch identity, and the access needed to administer the network is not the access needed to administer identity, so the subscriptions enforce a separation of duties that a single shared subscription would blur.

The application side is simpler in concept and more numerous in practice. Each workload gets its own subscription, and a workload that spans environments often gets one subscription per environment so that production carries stricter policy and tighter access than development. The application subscription is intentionally thin: it holds the workload’s resources and nothing of the shared foundation, because the foundation is inherited and consumed rather than reproduced. The corporate branch of the hierarchy holds workloads that need private connectivity to the rest of the estate and to on-premises, while the online branch holds workloads that face the internet and therefore carry stricter perimeter policy. The distinction is about connectivity posture and exposure, not importance, and it lets the online group enforce internet-facing guardrails that the corporate group does not need.

What makes the rule defensible rather than dogmatic is the failure it prevents. Mixing platform and application concerns in one subscription is the anti-pattern. Put the central firewall in the same subscription as a customer-facing web app and you have coupled the lifecycle of a shared service to the lifecycle of a single workload: a redeployment of the app risks the network everyone depends on, the access needed to operate the app leaks into the network everyone depends on, and the cost of the shared service is buried in a workload’s bill. The platform-then-application rule is the discipline that keeps shared concerns shared and workload concerns isolated, and the management group hierarchy is the mechanism that lets the shared governance reach the isolated workloads without being copied into each one.

The Azure services that realize a landing zone

A pattern is only as real as the services that implement it, and a landing zone maps onto a specific set of Azure constructs. Naming them and the role each plays turns the abstract design into something you can actually build.

Management groups, covered above, provide the inheritance backbone. They are free, they exist at the tenant scope, and they are the only construct that lets a single policy or role assignment reach an arbitrary number of subscriptions. Everything else in the landing zone hangs off the hierarchy they define.

Azure Policy is the guardrail engine. A policy definition expresses a rule (deny a resource type, require a tag, enforce a configuration, audit a deviation), and a policy assignment binds that rule to a scope. Assigned at a management group, the rule governs every subscription beneath. Policy operates in several effects worth distinguishing: a deny effect blocks a non-compliant deployment outright, an audit effect records the deviation without blocking, an append or modify effect adjusts a resource at deployment to bring it into line, and a deployIfNotExists effect provisions a missing companion resource such as a diagnostic setting. Initiatives group related definitions so you assign a coherent baseline in one action rather than dozens. Designing the policy baseline is enough of a discipline in its own right that it deserves dedicated treatment; the mechanics of authoring definitions, choosing effects, and assigning initiatives across a hierarchy are covered in depth when you set up Azure Policy for governance across a management group hierarchy, and the landing zone is exactly the structure that policy work assumes.

The connectivity layer is realized by either a hub-and-spoke virtual network topology or by Azure Virtual WAN. In the hub-and-spoke model, a hub virtual network in the connectivity subscription hosts the shared firewall, the gateways, and the DNS, and each workload’s spoke network peers to that hub so traffic transits the central controls. Virtual WAN is the managed alternative that Microsoft operates as a service, automating the hub and the routing for organizations with many regions or many branch connections. The choice between them turns on scale and operational preference, and the spoke-side design (peering, route tables, the way a spoke reaches the firewall) is the part teams most often get subtly wrong; the reasoning behind the topology, including how traffic actually routes through the hub and where the common peering mistakes hide, is the subject of the deep dive on hub-and-spoke network topology.

Microsoft Entra ID anchors identity for the entire arrangement. The tenant is the trust boundary, every subscription associates with it, and role assignments through Azure role-based access control flow down the management group hierarchy exactly as policy does. The landing zone’s identity design decides who can administer the platform, who can operate a given workload, and how privileged access is granted and audited. Because identity is the control plane an attacker most wants, the landing zone is where least-privilege and conditional access become structural rather than aspirational, a theme that runs through the treatment of Azure zero trust architecture and identity-centered security.

The management and observability layer is realized by Log Analytics, Azure Monitor, and Defender for Cloud. A central Log Analytics workspace in the management subscription receives platform diagnostic logs, activity logs, and the security signals that Defender for Cloud generates, so the organization has one place to query posture and investigate an incident rather than a workspace per subscription that nobody correlates. Diagnostic settings, frequently enforced through a deployIfNotExists policy so that no subscription can opt out, are what route the telemetry to that central workspace.

The InsightCrunch landing-zone blueprint

The pieces above are easier to hold together as a single reference. The table below is the InsightCrunch landing-zone blueprint: it names each part of the hierarchy, says whether it is a platform concern or an application concern, identifies which subscription or group it lives in, and states what governance, connectivity, or identity responsibility sits there. Read it as the map the rest of this article has been building toward.

Layer	Platform or application	Where it sits	Primary responsibility
Intermediate root group	Structural	Below tenant root	Anchor for organization-wide policy and access; never assign at tenant root
Platform group	Platform	Under intermediate root	Parent for the shared-service subscriptions
Connectivity subscription	Platform	Under Platform group	Hub network or Virtual WAN, firewall, gateways, private DNS
Identity subscription	Platform	Under Platform group	Domain controllers or Entra synchronization, identity infrastructure
Management subscription	Platform	Under Platform group	Central Log Analytics workspace, automation, Defender configuration
Landing Zones group	Application	Under intermediate root	Parent for workload subscriptions, split into corporate and online
Corporate group	Application	Under Landing Zones group	Internally connected workloads; private-connectivity guardrails
Online group	Application	Under Landing Zones group	Internet-facing workloads; perimeter and exposure guardrails
Application subscription	Application	Under corporate or online	A single workload, often one per environment
Sandbox group	Isolated	Under intermediate root	Experimentation, deliberately isolated and loosely governed
Decommissioned group	Lifecycle	Under intermediate root	Controlled retirement of subscriptions

The blueprint makes the platform-then-application rule visible. Everything in the Platform group is a shared concern built once and consumed by many. Everything in the Landing Zones group is a workload that inherits from above and peers into the platform. The Sandbox and Decommissioned groups sit outside that flow on purpose: Sandbox to give experimentation a low-governance space that cannot touch production, and Decommissioned to give a retiring subscription a holding place where access is stripped and resources are wound down before deletion. Where policy attaches, where connectivity terminates, and where identity is administered are all answered by position in this tree.

A reference design walked through

Abstraction becomes concrete when you build it, so this section walks the foundation from an empty tenant to a workload landing in a governed subscription. The commands use Azure CLI and a Bicep deployment at the management group scope, both of which a reader can run against a tenant they own. Treat the exact resource names and region as examples to adapt; the order of operations is the durable part.

Start by establishing the hierarchy. Management groups are created top down, each child naming its parent, so the intermediate root comes first and the branches follow.

# Create the intermediate root beneath the tenant root group
az account management-group create \
  --name "contoso" \
  --display-name "Contoso"

# Platform branch and its children
az account management-group create --name "platform" --parent "contoso" --display-name "Platform"
az account management-group create --name "connectivity" --parent "platform" --display-name "Connectivity"
az account management-group create --name "identity" --parent "platform" --display-name "Identity"
az account management-group create --name "management" --parent "platform" --display-name "Management"

# Application branch and its children
az account management-group create --name "landingzones" --parent "contoso" --display-name "Landing Zones"
az account management-group create --name "corp" --parent "landingzones" --display-name "Corp"
az account management-group create --name "online" --parent "landingzones" --display-name "Online"

# Isolated and lifecycle branches
az account management-group create --name "sandbox" --parent "contoso" --display-name "Sandbox"
az account management-group create --name "decommissioned" --parent "contoso" --display-name "Decommissioned"

With the tree in place, move the subscriptions that already exist into the positions they belong in. A subscription created for the central network moves under the connectivity group, a workload subscription moves under corp or online, and each picks up the inherited governance of its new position the moment it lands.

# Place an existing subscription under the connectivity group
az account management-group subscription add \
  --name "connectivity" \
  --subscription "00000000-1111-2222-3333-444444444444"

# Place a workload subscription under the corporate group
az account management-group subscription add \
  --name "corp" \
  --subscription "55555555-6666-7777-8888-999999999999"

Next comes governance, assigned at the level it applies. A region restriction belongs high in the tree because it should bind everyone, so assign the built-in allowed-locations policy at the intermediate root. The assignment names the policy definition, the scope, and the parameter that lists the permitted regions.

# Restrict resource locations across the whole organization
az policy assignment create \
  --name "allowed-locations" \
  --display-name "Allowed locations" \
  --scope "/providers/Microsoft.Management/managementGroups/contoso" \
  --policy "e56962a6-4747-49cd-b67b-bf8b01975c4c" \
  --params '{ "listOfAllowedLocations": { "value": ["eastus", "westeurope"] } }'

A narrower rule, such as enforcing diagnostic settings that ship logs to the central workspace, can be assigned lower or organization-wide depending on intent, and is best expressed as a deployIfNotExists policy so a subscription cannot quietly skip it. The pattern below shows assigning an initiative at the management branch so every workload inherits the logging baseline, with a managed identity granted because deployIfNotExists policies need permission to remediate.

# Assign a logging baseline initiative with a remediation identity
az policy assignment create \
  --name "logging-baseline" \
  --display-name "Central logging baseline" \
  --scope "/providers/Microsoft.Management/managementGroups/landingzones" \
  --policy-set-definition "<initiative-definition-id>" \
  --mi-system-assigned \
  --location "eastus" \
  --identity-scope "/providers/Microsoft.Management/managementGroups/landingzones" \
  --role "Contributor"

For teams that prefer to express the foundation as code rather than imperative commands, Bicep deploys at the management group scope using a targetScope declaration. The fragment below assigns a policy at a management group and is the kind of module you would commit to source control so the foundation is reproducible and reviewable rather than clicked into existence.

targetScope = 'managementGroup'

@description('Permitted Azure regions for resource deployment.')
param allowedLocations array = [
  'eastus'
  'westeurope'
]

resource allowedLocationsAssignment 'Microsoft.Authorization/policyAssignments@2022-06-01' = {
  name: 'allowed-locations'
  properties: {
    displayName: 'Allowed locations'
    policyDefinitionId: '/providers/Microsoft.Authorization/policyDefinitions/e56962a6-4747-49cd-b67b-bf8b01975c4c'
    parameters: {
      listOfAllowedLocations: {
        value: allowedLocations
      }
    }
  }
}

The final step in the walkthrough is the one a workload team experiences as onboarding: a new subscription is created, placed under corp or online, peered to the hub network in the connectivity subscription, and confirmed compliant. Confirming inheritance is the verification that proves the design works, because a subscription in the right position should show the inherited assignments without any per-subscription action.

# List policy assignments that a workload subscription inherits
az policy assignment list \
  --scope "/subscriptions/55555555-6666-7777-8888-999999999999" \
  --query "[].{name:displayName, scope:scope}" \
  --output table

When that command returns the allowed-locations assignment scoped to the intermediate root and the logging baseline scoped to the landing-zones group, the inheritance is working and the workload sits on the foundation rather than beside it. The whole sequence, from empty tenant to a compliant workload subscription, is the kind of build worth running end to end before you do it for real; you can stand up the hierarchy, assign the policies, and watch inheritance take effect when you run the hands-on Azure labs and command library on VaultBook, where the management group and policy steps above are reproducible against a sandbox tenant.

Governance applied at scale

Governance is the concern that most clearly demonstrates why the hierarchy is worth building, because governance is where the per-subscription approach fails most visibly. Consider a single, ordinary requirement: every resource must carry a cost-center tag so finance can attribute spend. In an ungoverned estate that requirement is enforced by hope and email. In a landing zone it is a policy with a modify effect assigned once at the intermediate root, appending the tag at deployment for any resource that lacks it and inheriting down to every subscription automatically. The difference is not cosmetic. One approach scales to a thousand subscriptions without additional effort; the other does not scale past the patience of the person sending the emails.

The governance design in a landing zone works in layers that mirror the hierarchy. At the top sit the universal guardrails: the allowed regions, the denied resource types that the organization will never permit, the requirement that every resource emit diagnostics, and the baseline security controls that apply regardless of workload. These belong as high as they apply because they apply to everyone. One level down, the corporate and online branches carry the guardrails specific to their connectivity posture. The online group, holding internet-facing workloads, can enforce that public IP addresses are denied unless explicitly exempted, that web application firewall is present on the front door, and that storage accounts disable public blob access. The corporate group enforces the private-connectivity rules its workloads need. At the bottom, an individual workload subscription might carry one or two assignments specific to a regulatory regime it falls under, but the bulk of its governance is inherited rather than local, which is the entire point.

How do policy and governance fit a landing zone?

Azure Policy assignments attach to management groups and inherit down to every subscription beneath, so the landing zone applies governance once at the right level rather than per subscription. Universal rules attach high in the hierarchy, connectivity-specific rules attach to the corporate or online branch, and individual workloads inherit the combined baseline.

A subtlety that separates a working governance design from a frustrating one is the choice of policy effect, because the effect determines whether the guardrail blocks, records, or repairs. A deny effect is the right choice for a rule that must never be violated, such as forbidding a resource type that the organization has decided is out of bounds, but deny is also the effect most likely to break a deployment in a surprising way if assigned carelessly, because it rejects at provisioning time with an error that workload teams must then decode. An audit effect is the gentler starting point: it records non-compliance so you can measure how widespread a problem is before you decide to block it, which is the sane way to introduce a new rule into an estate that predates it. The deployIfNotExists and modify effects are the workhorses of a landing zone because they remediate rather than reject, appending a missing tag or provisioning a missing diagnostic setting so the resource ends up compliant without the workload team doing anything. A mature governance baseline uses all of these deliberately, reserving deny for the genuine prohibitions and leaning on audit and remediation for everything that can be corrected rather than blocked.

The failure mode this section exists to prevent is per-subscription policy, the habit of assigning the same rules over and over at the subscription scope because the hierarchy was never built or never used. The symptom is drift: subscription A has the tagging policy, subscription B got it three months later, subscription C never got it because the person who maintained the script left. By the time anyone audits, the estate is a patchwork of partial compliance that no single change can fix, and the remediation is the migration project the landing zone was supposed to make unnecessary. Assigning governance at the management group level is not a stylistic preference; it is the mechanism that makes compliance a property of the structure rather than a task that decays the moment attention moves elsewhere. The full mechanics of authoring those assignments, structuring initiatives, and rolling out an audit-then-deny progression across a hierarchy are where the governance work gets detailed, and the landing zone is the structure that work assumes exists.

Connectivity in the platform zone

Connectivity is the platform concern that workload teams feel most directly, because a workload that cannot reach what it needs, or that reaches it through an uncontrolled path, is a workload that either fails or creates risk. The landing zone centralizes connectivity in the platform’s connectivity subscription so that traffic between workloads, traffic to on-premises, and traffic to and from the internet all transit a controlled set of shared resources rather than each workload inventing its own egress.

The dominant model is hub-and-spoke. A hub virtual network in the connectivity subscription hosts the resources every workload shares: a firewall that inspects and filters traffic, a virtual network gateway for site-to-site VPN or ExpressRoute connectivity to on-premises, and private DNS zones that resolve the private endpoints workloads depend on. Each workload’s network is a spoke, a separate virtual network in the application subscription that peers to the hub. The peering plus route configuration sends the spoke’s traffic through the hub’s firewall rather than straight out, which is what gives the platform a single place to enforce egress rules, inspect traffic, and connect to on-premises without every workload holding its own gateway. The spoke holds only the workload’s own subnets; the shared plumbing lives in the hub, consistent with the platform-then-application rule.

How is connectivity designed in a landing zone?

Connectivity is centralized in the platform’s connectivity subscription as a hub network or a Virtual WAN hub. Workload spokes peer to the hub so their traffic transits a shared firewall, gateways, and private DNS. The hub holds the shared network plumbing; each spoke holds only its workload’s subnets and consumes the central path rather than building its own.

The managed alternative to a self-built hub is Azure Virtual WAN, which Microsoft operates as a service. Where hub-and-spoke asks you to build and operate the hub virtual network, the routing, and the gateways yourself, Virtual WAN provides a managed hub with automated branch and virtual network connectivity and built-in routing, which earns its place for organizations spanning many regions or connecting many branch sites where operating the routing by hand becomes a burden. The decision between a traditional hub and Virtual WAN turns on scale and the appetite for managing routing: a single-region estate with a handful of spokes is well served by a self-built hub that the team fully controls, while a global estate with dozens of branches benefits from letting Microsoft operate the routing fabric. Neither choice changes the landing zone’s shape; both place the shared connectivity in the platform and peer workloads into it.

The mistakes that bite here are spoke-side, which is why connectivity rewards careful design rather than improvisation. A spoke peered to the hub without the route table that forces traffic through the firewall will happily send traffic straight to the internet, defeating the central inspection the hub was built to provide. A private endpoint created in a spoke without the corresponding private DNS zone linked from the hub resolves to a public address and fails in a way that looks like a firewall problem but is a DNS problem. Overlapping address spaces between spokes that later need to communicate force a painful re-addressing. Each of these is a routing or resolution detail rather than a conceptual flaw, and each is exactly the kind of production incident that the deeper treatment of the topology, the peering behavior, and the route propagation rules is written to prevent. The landing zone gives connectivity a home; designing the hub and the spokes so traffic actually flows the way the diagram promises is the work that makes the home livable.

Identity in the platform zone

Identity is the control plane, and in a landing zone it is the concern that decides who can do what across the entire estate. Microsoft Entra ID is the trust anchor: the tenant is the boundary, every subscription associates with it, and authentication and authorization across all of them flow from that single source. The landing zone’s identity design is the answer to three questions that an ungoverned estate answers inconsistently. Who administers the platform itself? Who operates a given workload? And how is privileged access granted, scoped, and audited so that the people with power over the foundation are a known, small, and monitored set rather than an accreted list nobody remembers granting?

Azure role-based access control is the mechanism, and it inherits down the management group hierarchy exactly as policy does, which is what makes the hierarchy do double duty. A role assignment at the platform group grants its holder authority over every platform subscription beneath, so the small team that operates connectivity, identity, and management can be granted access once at the right level rather than subscription by subscription. A role assignment at a workload subscription stays scoped to that workload, so the team that runs an application has authority over their own resources and nothing else. The same inheritance that makes governance scale makes access manageable: position in the tree determines reach, and reach is granted at the level it should apply rather than copied everywhere.

How does identity fit into a landing zone?

Microsoft Entra ID is the trust boundary, and Azure role-based access control assignments inherit down the management group hierarchy. Platform administrators are granted access at the platform group; workload teams are granted access scoped to their own subscriptions. Position in the tree determines reach, so access is granted once at the level it should apply rather than per subscription.

The principle that turns this from a convenience into a security posture is least privilege, applied concretely rather than as a slogan. A workload team needs authority over its workload, not standing access to the central firewall or the identity infrastructure, so their assignments stop at their subscription. Platform operators need authority over the shared services, granted at the platform group, but they do not need standing access to read every workload’s data, so their roles are scoped to the platform rather than the whole tenant. Highly privileged roles, the ones that can alter the foundation itself, are the smallest set and the most heavily controlled, ideally activated just in time through privileged identity management rather than held permanently, so that the window in which a high-privilege credential is live is short and logged. The landing zone is where these distinctions become structural, because the hierarchy gives each kind of operator a natural scope and the inheritance makes that scope enforce itself.

The reason identity deserves this care in the foundation rather than as an afterthought is that identity is the path an attacker most wants. A workload subscription compromised through an application vulnerability is a contained incident if its access stops at its own resources, and a tenant-wide catastrophe if that workload’s identity happened to carry broad rights it never needed. Designing the landing zone so that no workload identity reaches beyond its workload, so that platform access is scoped and audited, and so that the most far-reaching roles are time-bound and monitored is the structural expression of zero trust: trust is never inherited from network position, every access is scoped to need, and privilege is granted narrowly and watched closely. That posture is the through-line of the broader treatment of zero trust architecture and identity-centered security in Azure, and the landing zone is the structure that makes it enforceable across an entire estate rather than negotiated workload by workload.

Naming, tagging, and the conventions that keep a foundation legible

A structure is only useful if humans can read it, and the conventions that make an estate legible are an underrated part of the pattern. Two resources with cryptic names in two unlabeled accounts tell an operator nothing; the same two resources under a consistent naming scheme and a complete tagging baseline tell the operator what they are, who owns them, what they cost, and which environment they belong to, all without opening a ticket. The landing zone is where these conventions are established and, more importantly, enforced, because a convention that depends on everyone remembering to follow it is not a convention but a wish.

Naming conventions give every resource a predictable, parseable identity. A good scheme encodes the resource type, the workload, the environment, and the region into a name that an operator can read at a glance and a script can parse without guessing, so a firewall in the production hub and a development storage account are distinguishable on sight. The discipline matters most at the boundary level: accounts and resource groups named consistently let an operator navigate an unfamiliar part of the estate by inference rather than by asking. Because Azure imposes its own length and character rules on different resource types, the scheme has to bend to those constraints, which is why a thought-out convention beats an improvised one that breaks the first time it meets a resource type with a tight name limit.

Tagging carries the metadata that names cannot. A tagging baseline typically requires a cost-center tag for financial attribution, an owner tag so an orphaned resource has someone to ask about, an environment tag distinguishing production from the rest, and often a data-classification tag that downstream policy keys off. The reason tagging belongs in the foundation rather than in each team’s discretion is that finance and security both depend on it being complete: a cost report with half the resources untagged attributes nothing useful, and a security policy that keys off a classification tag cannot act on resources that lack one. Enforcing the baseline through a policy with a modify effect, which appends a required tag at deployment when a team forgets, is what turns tagging from an aspiration that decays into a property the estate maintains automatically.

How do naming and tagging fit into a landing zone?

Naming conventions give every resource a predictable identity encoding its type, workload, environment, and region, while a tagging baseline carries metadata for cost attribution, ownership, and classification. The landing zone enforces both through policy, often appending a missing tag at deployment, so the conventions hold automatically rather than depending on everyone remembering to follow them.

The conventions interact with the hierarchy in a way that reinforces the platform-then-application rule. Cost attribution, for example, depends on both the account a resource sits in and the tags it carries: the account rolls spend up to a billing scope while the tags slice it by cost center and environment, so a finance team can answer both “what does this division spend” and “what does this environment cost” from the same data. Blast-radius thinking depends on the boundaries the hierarchy draws: a resource group is the smallest blast radius, an account a larger one, and a management group branch larger still, so a deployment scoped tightly damages less when it goes wrong than one that sprawls across boundaries. Drift, the slow divergence between what was designed and what actually exists, is detected by comparing the live estate against the policy baseline and the infrastructure-as-code source, which only works if the conventions are enforced consistently enough that a deviation is visibly a deviation rather than just one more inconsistency among many.

Exemptions deserve a word because no real estate is perfectly uniform. A policy assigned across a branch occasionally needs an exception for a workload with a legitimate reason to deviate, and the mature way to grant one is a scoped, documented, time-bound exemption rather than weakening the policy for everyone or quietly removing the assignment. Azure Policy supports exemptions as first-class objects precisely so that a deviation is recorded, justified, and reviewable rather than invisible, and treating exemptions this way keeps the governance honest: the baseline still expresses the rule, the exemption documents the exception, and an auditor can see both. An estate that handles exceptions by loosening the rule instead loses the ability to say what its actual posture is, which is the slow death of governance by a thousand quiet accommodations.

These conventions are not glamorous, and that is the point. The work of naming, tagging, blast-radius scoping, drift detection, and disciplined exemptions is the unglamorous maintenance that keeps a foundation legible and operable years after the architecture diagram was drawn. A landing zone that gets the hierarchy and the connectivity right but neglects the conventions ages into an estate that is structurally sound and practically illegible, where operators cannot tell what they are looking at and finance cannot attribute what they are paying for. The conventions are what make the structure usable by the people who live in it, and enforcing them through the same policy mechanism that enforces everything else is what keeps them from decaying the moment attention moves on.

The trade-offs and failure modes the pattern must handle

No pattern is free, and a landing zone carries real costs that an honest design accounts for rather than ignores. The first is upfront effort. Building the hierarchy, defining the policy baseline, standing up the platform subscriptions, and wiring the connectivity is work that happens before a single workload ships value, and an organization impatient to deploy can experience the foundation as a delay. The answer is not to skip the foundation but to right-size it: a small organization does not need the full enterprise hierarchy on day one, and the Cloud Adoption Framework explicitly supports a start-small approach that establishes a minimal but correct structure and expands it as the estate grows. The cost is real, but it is far smaller than the cost of retrofitting governance onto a sprawl later, which is the comparison that justifies paying it.

The second cost is operational ownership. A landing zone is not a deployment that runs once; it is a living foundation with policies that evolve, connectivity that changes as the network grows, and access that must be reviewed as people and teams move. Someone owns the platform, and that ownership is a standing responsibility rather than a project that closes. Organizations that build a beautiful landing zone and then assign nobody to operate it discover that the policies go stale, the access list grows, and the foundation slowly stops reflecting reality. The pattern assumes a platform team, even a small one, and a landing zone without an owner decays like any other system without an owner.

The third trade-off is the tension between central control and team autonomy. A landing zone enforces guardrails, and guardrails constrain. Set them too tight and workload teams chafe, file exception requests, and look for ways around the controls, which undermines the governance the controls were meant to provide. Set them too loose and the guardrails do not guard anything. The framework’s notion of subscription democratization is the resolution: give workload teams real autonomy within their own subscriptions, bounded by the platform’s guardrails, so they move fast inside a safe envelope rather than waiting on a central team for every change. The design skill is choosing which decisions are platform decisions that must be enforced and which are workload decisions that should be delegated, and getting that line wrong in either direction is a failure the pattern must consciously avoid.

The failure modes the pattern exists to handle are the ones this article has named throughout, now collected. Subscription sprawl is the baseline disorder: subscriptions created ad hoc with no hierarchy, no consistent governance, and no clear owner, the condition a landing zone is built to prevent. Per-subscription policy is the half-measure that feels like governance but does not scale, assigning the same rules repeatedly until drift makes the estate a patchwork. Mixed platform and application concerns is the coupling failure, putting shared services and workloads in the same subscription so that their lifecycles, their access, and their costs entangle. An operating model misalignment is the subtler failure: the reference hierarchy assumes a particular split of responsibility between a central platform team and workload teams, and an organization whose actual operating model differs can find the standard structure fights its way of working, which is why the framework asks you to align the operating model before committing to a hierarchy rather than after. Each failure has the same root, which is structure deferred or structure misapplied, and the same remedy, which is to build the foundation deliberately and to keep it aligned with how the organization actually operates.

When a landing zone fits and when it is overkill

The honest question about any architecture pattern is when not to use it, and a landing zone is no exception. The full enterprise structure, with its multi-branch hierarchy, its three or four platform subscriptions, and its policy baseline spanning the estate, fits an organization that runs many workloads, has compliance obligations, employs distinct teams that need bounded autonomy, and expects the estate to grow. For that organization the foundation pays for itself many times over, because every new workload onboards onto an established structure rather than improvising, and governance applies by inheritance rather than by repeated effort. This is the case the Cloud Adoption Framework is written for, and it is the case where skipping the foundation guarantees the expensive retrofit later.

The pattern is overkill, or at least premature in its full form, for the genuinely small estate. A startup with one product, a single team, and three subscriptions does not need a ten-group hierarchy and a dedicated platform team; that much structure for that little estate is overhead without payoff, governance theater that slows the team without protecting anything material. The judgment is not whether to have any structure but how much, and the answer scales with the estate. Even the smallest serious deployment benefits from a basic hierarchy, a handful of universal policies, and the platform-then-application instinct, because those cost little and prevent the worst of the sprawl. What the small estate does not need is the full reference architecture deployed in anticipation of growth that may not come.

When should an organization build an Azure landing zone?

Build a landing zone when you run multiple workloads, have governance or compliance obligations, employ teams that need bounded autonomy, or expect the estate to grow. The full enterprise structure fits at scale; a small estate benefits from a minimal hierarchy and a few universal policies rather than the complete reference architecture deployed prematurely.

The deciding signal is the cost of disorder weighed against the cost of structure. When the estate is small and slow-growing, the cost of disorder is low and the cost of structure feels high, so a light foundation is correct. When the estate is large or growing fast, the cost of disorder compounds quickly, governance retrofitted onto sprawl becomes a migration project, and the cost of structure is trivial by comparison, so the full foundation is correct. The mistake in both directions is failing to match the structure to the trajectory: over-building for an estate that will stay small wastes effort and frustrates a team that wanted to ship, while under-building for an estate that will scale defers a cost that grows every month it is deferred. The framework’s start-small-and-expand path exists precisely so an organization can begin with a foundation sized to today and grow it deliberately rather than guessing at the eventual scale and building for it on day one.

How to evolve a landing zone over time

A foundation that cannot change becomes a constraint the organization grows around rather than through, so the pattern includes its own evolution path. The starting point for most organizations is the minimal version: an intermediate root, a basic platform-and-application split, a connectivity subscription with a hub, a management subscription with a central workspace, and a small set of universal policies in audit mode so you can see compliance before you enforce it. This minimal foundation is correct from the first workload and grows without being rebuilt, which is the property that distinguishes a designed foundation from an improvised one.

The first axis of growth is governance maturity. Policies that began in audit mode, recording deviations without blocking, progress to deny mode once you have measured compliance and remediated the existing estate, so the rule that was once a measurement becomes a guarantee. New policies enter the baseline as audit, prove themselves against real deployments, and graduate to enforcement, which is the safe way to tighten governance on a living estate without breaking the workloads already running. The hierarchy makes this progression clean because each tightening is an assignment change at a management group, inherited by everyone beneath, rather than a campaign across subscriptions.

The second axis is the onboarding mechanism. Early on, a new subscription is created and placed by hand, which is fine at low volume. As the estate grows and the rate of new workloads rises, hand placement becomes a bottleneck and an inconsistency risk, which is where subscription vending enters. A vending process automates the creation of a workload subscription, its placement under the correct management group, its peering to the hub, and its baseline configuration, so a workload team requests a landing zone and receives a governed, connected subscription without a platform engineer performing the steps manually. Vending is the mechanism that lets the foundation scale to many workloads without the platform team becoming the constraint, and it is the natural maturation of the onboarding sequence the reference walkthrough performed by hand.

The third axis is the connectivity and identity infrastructure itself, which grows as the estate spans more regions, connects more on-premises sites, and serves more teams. A single-region hub becomes a multi-region topology or migrates to Virtual WAN when the routing burden justifies it. The identity design adds conditional access controls, privileged access management, and finer role scoping as the organization’s security posture matures. None of this requires rebuilding the foundation, because the hierarchy and the platform-application split are stable shapes that accommodate growth within them. The landing zone evolves by deepening, not by replacement, which is the payoff of having built it as a designed structure rather than an accident in the first place.

Alignment with the Cloud Adoption Framework and Well-Architected Framework

A landing zone does not stand alone; it is the implementation of guidance Microsoft publishes in the Cloud Adoption Framework, and it is governed by the quality principles of the Well-Architected Framework. Understanding how the landing zone sits between these two is what lets you defend its design as principled rather than arbitrary.

The Cloud Adoption Framework is the strategy-to-execution guidance: it walks an organization from defining a cloud strategy, through planning and readiness, into governance and management, and the landing zone is the concrete environment that the readiness phase produces. The framework’s eight design areas, named earlier, are the checklist a complete landing zone addresses, and the reference architecture (sometimes still called enterprise-scale, the accelerator Microsoft ships as Bicep and Terraform to deploy the whole structure) is the framework’s opinionated default. When you build a landing zone you are implementing the framework’s readiness guidance, which is why the design areas, the hierarchy shape, and the platform-application split all trace back to it. The framework answers what to build and in what order; the landing zone is what gets built.

How does a landing zone align with the Cloud Adoption Framework?

The Cloud Adoption Framework is Microsoft’s guidance for adopting Azure at scale, and the landing zone is the environment its readiness phase produces. The framework defines eight design areas, from identity to connectivity to governance, and the landing zone is the concrete implementation that addresses all of them, with the reference accelerator shipping as Bicep and Terraform.

The Well-Architected Framework plays a different and complementary role. Where the Cloud Adoption Framework tells you what foundation to build, the Well-Architected Framework tells you how to judge whether any given design (including the landing zone itself) is sound, through its pillars of reliability, security, cost optimization, operational excellence, and performance efficiency. A landing zone is a security and operational-excellence asset by nature: it centralizes the controls that make an estate secure and the observability that makes it operable. But the landing zone’s own choices are subject to the pillars too. The cost of running platform subscriptions is a cost-optimization concern. The resilience of the central connectivity is a reliability concern. The clarity of the access model is an operational-excellence concern. Designing a landing zone well means applying the Well-Architected Framework’s pillars and trade-off reasoning to the foundation itself, not just to the workloads that land on it, so the foundation you impose on everyone else is held to the same standard you would hold any production system.

The two frameworks together give the landing zone its intellectual footing. The Cloud Adoption Framework supplies the structure and the order of operations; the Well-Architected Framework supplies the quality bar. A landing zone built without the first is improvised; a landing zone built without the second is structured but not necessarily sound. The pattern earns its authority by sitting at the intersection, implementing a published reference architecture and subjecting that implementation to a published quality model, which is what lets an architect defend each decision in a review by pointing to the principle behind it rather than to taste.

The eight design areas in practice

The Cloud Adoption Framework names eight design areas, and a foundation that addresses all of them is complete rather than partial. Walking each one briefly grounds the abstract pattern in the specific decisions a team actually makes, and it shows why a landing zone is a coordinated whole rather than a network diagram with some policies bolted on.

The first area is the billing and Entra tenant arrangement. Before any resource exists, an organization decides how its agreement with Microsoft maps onto enrollment accounts and billing scopes, and how many Entra tenants it will run. The default and usually correct answer is a single production tenant, because a tenant is a trust boundary and splitting it fragments identity in ways that are painful to reconcile later. The billing structure underneath determines how cost rolls up and who can create the accounts that become workload homes, so getting it coherent early prevents the finance reconciliation headaches that ungoverned billing produces.

The second area is identity and access management, treated above as the platform’s identity subscription and the role-assignment model that inherits through the tree. The decision here is which directory services the organization needs in the cloud, how on-premises identity synchronizes upward, and how administrative access is structured so the people who can change the foundation are a small, audited set. This area and the management-group area together decide who holds authority and over what.

The third area is resource organization, which is the management group hierarchy and the subscription strategy this article has built its argument around. The decision is the shape of the tree, where subscriptions sit, and how new ones are created and placed. The fourth area is network topology and connectivity, the hub-and-spoke or Virtual WAN design in the connectivity subscription, the address planning that keeps spokes from colliding, and the private DNS that makes private endpoints resolve. These two areas are where most of the visible structure lives, and they are the areas a poorly planned estate most conspicuously lacks.

The fifth area is security, which spans the controls that defend the estate: the threat detection that Defender for Cloud provides, the encryption defaults the policy baseline enforces, the network perimeter the firewall maintains, and the secret management that keeps credentials out of code. Security is not a single subscription but a posture woven through the others, expressed largely as policy and as the central security tooling in the management subscription. The sixth area is management, the operational backbone: the monitoring, the alerting, the backup and recovery configuration, and the patching and update strategy that keep the estate healthy after it is built. This is the area that distinguishes a foundation someone operates from one someone merely deployed.

The seventh area is governance, the policy baseline and the compliance posture, assigned through the hierarchy as discussed at length earlier. The eighth area is platform automation and DevOps, which is the recognition that the entire foundation should be expressed as code, deployed through pipelines, and version-controlled rather than clicked into existence. The Bicep and Terraform accelerators Microsoft ships exist to serve this area, letting an organization deploy the whole hierarchy, the policies, and the platform subscriptions reproducibly and review changes the way it would review application code. A foundation built by hand drifts the moment someone makes an undocumented change in the portal; a foundation built as code carries its own history and can be redeployed or audited against its source of truth.

Seen together, the eight areas explain why a landing zone is more than a clever subscription layout. Four of them (resource organization, networking, identity, governance) describe the structure most teams picture when they hear the term. Two of them (billing and tenant, automation and DevOps) describe how the structure is established and paid for. Two of them (security and management) describe how it is defended and operated after it exists. A foundation that nails the first four but neglects the last four is structured but neither operable nor durable, which is the quiet way many landing-zone efforts fail: the diagram is correct, but nobody automated it, nobody operates it, and within a year it has drifted away from what was drawn.

Recurring landing-zone patterns engineers report

The same situations recur across organizations adopting Azure at scale, and recognizing each as a pattern with a known structure is faster than rediscovering it the hard way. These are the cases that show up repeatedly when engineers describe what went right and what went wrong with their foundations.

The first recurring case is the sprawl that arrived before any structure did. An organization adopts Azure organically, each team creating accounts as it needs them, and a year later the tenant holds a few dozen ungoverned billing boundaries with no common policy, no shared network model, and ownership that has scattered as people changed roles. The structure that resolves this is not a heroic cleanup but the incremental migration described earlier: build the hierarchy alongside the existing mess, introduce governance in audit mode to measure the damage, move accounts into position one branch at a time, remediate what the audit surfaced, and only then enforce. The pattern’s lesson is that sprawl is cheaper to prevent than to cure, which is the entire argument for building the foundation before the disorder accumulates.

The second case is governance that was applied per account because the hierarchy was never used. A team that understands policy but not inheritance assigns the same rules to each billing boundary individually, and the result is the drift covered earlier: partial coverage, inconsistent enforcement, and an audit that reveals a patchwork. The structure that resolves it is to lift those repeated assignments up to the management group that should own them and delete the per-account copies, so a single assignment governs everyone beneath. The lesson is that the hierarchy is not optional decoration; it is the mechanism that makes governance a property of position rather than a task that decays.

The third case is the platform zone doing its job well, which is worth describing because success has a recognizable shape too. A connectivity subscription centralizes the hub, the firewall, and the private DNS; an identity subscription anchors the directory services; a management subscription aggregates the telemetry; and every workload that arrives peers into that platform and inherits its governance. When this works, onboarding is boring in the best sense: a new workload is a request, a placement, a peering, and a confirmation of inherited compliance, with no improvisation. The lesson is that a well-built platform makes the interesting work (the workloads) possible by making the foundational work (the plumbing) invisible.

The fourth case is consistent application onboarding, the experience a workload team should have. Rather than negotiating networking, logging, and access from scratch, the team receives a governed account that already connects, already logs to the central workspace, and already inherits the baseline, and they spend their effort on the workload rather than on reinventing the foundation. When the rate of onboarding rises, this consistency is automated through subscription vending, turning a request into a provisioned environment without a platform engineer in the loop. The lesson is that consistency at onboarding is what lets an organization add workloads linearly without the platform team’s effort growing with each one.

The fifth case is alignment with the Cloud Adoption Framework as a living practice rather than a one-time checkbox. Organizations that treat the framework as guidance to revisit, reassessing their design areas as the estate grows and the operating model shifts, keep their foundation aligned with reality. Those that implement the reference architecture once and never revisit it find, often after a reorganization, that the hierarchy assumes a division of responsibility the company no longer has. The lesson, and the framework’s own caution, is to align the operating model with the structure before committing to it and to revisit that alignment as the organization changes, because a foundation that fits the org of two years ago fights the org of today.

The sixth case is governance enforced top-down, which is both the pattern’s promise and its political reality. A landing zone enforces guardrails from the center, and that enforcement only holds if the central team and the workload teams agree on where the guardrails sit. Enforced too tightly, teams route around the controls and the governance becomes theater; enforced with the right balance, teams move fast inside a safe envelope and the controls hold because they do not obstruct legitimate work. The structure that resolves the tension is the framework’s subscription democratization: real autonomy inside each workload’s own boundary, bounded by guardrails that exist for genuine safety rather than for central control’s own sake. The lesson is that top-down governance succeeds as a negotiated balance, not as an edict, and the design skill is deciding which decisions are genuinely platform decisions and which should be delegated to the teams doing the work.

The verdict

A landing zone is the decision to treat your cloud foundation as architecture rather than as the residue of whatever subscriptions happened to get created. The platform-then-application rule is the spine of that decision: establish the shared concerns (connectivity, identity, governance, monitoring) as a coherent platform before the first workload arrives, so that workloads land on a foundation and inherit it rather than improvising one each. The management group hierarchy is the mechanism that makes the rule enforceable, because inheritance turns governance and access from per-subscription chores into properties of position in a tree. Everything else, the policy baseline, the hub-and-spoke or Virtual WAN connectivity, the Entra-anchored identity, the central workspace, hangs off that hierarchy and that rule.

The strategic verdict is to build the foundation early and size it to your trajectory. For an organization of any real scale, the cost of building the structure is trivial against the cost of retrofitting it onto a sprawl, and the start-small path means even a young estate can establish a correct minimal foundation that grows by deepening rather than by replacement. Match the structure to the estate: a light hierarchy and a few universal policies for the small and slow-growing, the full reference architecture and a vending process for the large and fast-moving. Hold the foundation to the Well-Architected pillars and keep it aligned with how your organization actually operates, because a landing zone misaligned with the operating model fights the people it was meant to serve. Do that, and a new workload becomes a subscription placed under the right group, peered to the hub, and compliant by inheritance, which is the whole promise: scale without sprawl, governance without drift, and a foundation that holds.

Frequently Asked Questions

Q: What is an Azure landing zone in simple terms?

An Azure landing zone is a pre-configured, governed environment that a new workload lands in, with the network connectivity, identity, policy, and monitoring already established before the workload arrives. Rather than create a blank subscription and assemble governance from scratch, a team receives a subscription that already sits under the right management group, already inherits the organization’s policies, already connects to the central network, and already trusts the central identity provider. It is not a single resource or template but a coordinated arrangement of management groups, Azure Policy, central networking, Entra ID, and Log Analytics that together form the operational floor every workload stands on. The point is to make the foundation a known destination instead of an improvisation, so that governance and connectivity are inherited rather than reinvented for each new workload, which is what lets the estate scale without descending into sprawl.

Q: What is the difference between a platform landing zone and an application landing zone?

A platform landing zone holds the shared services that every workload uses, typically one set per tenant: central connectivity in a connectivity subscription, identity infrastructure in an identity subscription, and shared monitoring and automation in a management subscription. An application landing zone holds an individual workload, with one subscription per workload and often one per environment so production carries stricter controls than development. The distinction is about who consumes what. The platform produces shared capabilities; applications consume them. An application subscription peers to the platform’s network, sends logs to the platform’s workspace, and inherits policy from the management group above, holding only its own workload resources. The platform is built first because applications depend on it, and mixing the two in one subscription couples a shared service’s lifecycle to a single workload, which is the anti-pattern the split exists to prevent.

Q: How many management group levels should a landing zone have?

Keep the management group hierarchy shallow, ideally no more than three to four levels deep, which is the explicit guidance in Microsoft’s Cloud Adoption Framework. The reason is that every level adds inheritance complexity and cognitive overhead without adding governance value, and a deep tree quickly becomes one where nobody can reason about what a given subscription actually inherits. A typical shape is an intermediate root group below the tenant root, a layer of meaningful divisions such as Platform and Landing Zones beneath it, and subscriptions as the leaves, with the Landing Zones branch split once more into corporate and online. That is three to four levels and it is enough. The common mistake is modeling the entire organizational chart in management groups, a level per division, department, team, and project, which produces a tree too deep to manage. Management groups exist to apply governance at scale, not to mirror reporting lines, so two groups that would carry identical policy should usually be one.

Q: Do I need a separate landing zone for data, AI, or analytics workloads?

No. A common question is where a data landing zone or an AI landing zone goes in the hierarchy, and the Cloud Adoption Framework answer is that those are workloads, not separate foundations. A data platform or an AI deployment lands in an ordinary application landing zone alongside everything else, inheriting the same governance and peering into the same platform connectivity. What changes is inside that application subscription, where the workload may need more opinionated networking, specific private DNS configuration, or particular policy exemptions, but the landing zone itself remains the general application subscription under the corporate or online branch. Treating every new category of workload as a reason to invent a new top-level zone reintroduces the sprawl the pattern was built to prevent. The foundation is deliberately general; the workloads that arrive on it are specific, and the right place for a specialized workload is a properly configured application landing zone, not a bespoke structure parallel to the platform.

Q: What is the platform-then-application rule and why does ordering matter?

The platform-then-application rule states that you build the shared platform foundation (connectivity, identity, governance, monitoring) before onboarding any application workload, because workloads depend on the platform and a foundation retrofitted under live workloads is the most expensive mistake in cloud architecture. Ordering matters because of dependency direction. An application subscription peers to the central network, sends logs to the central workspace, inherits policy from the management group above, and authenticates against the central identity provider. If the platform exists first, onboarding a workload is repeatable: create the subscription, place it correctly, peer it to the hub, and the governance and connectivity are simply present. If the platform does not exist first, every workload improvises its own networking, logging, and access, recreating the sprawl the landing zone was meant to prevent and adding the cost of unwinding it later. Build the foundation as a coherent unit first, then let workloads land on it.

Q: How do Azure Policy and governance work across a landing zone?

Azure Policy assignments attach to management groups and inherit down to every subscription beneath, so a landing zone applies governance once at the right level instead of repeating it per subscription. The design works in layers that mirror the hierarchy: universal guardrails such as allowed regions and required diagnostics attach high in the tree because they apply to everyone, connectivity-specific rules attach to the corporate or online branch, and an individual workload inherits the combined baseline plus any rule specific to its own regulatory regime. The policy effect matters: deny blocks a non-compliant deployment, audit records the deviation without blocking, and deployIfNotExists or modify remediate by provisioning a missing resource or appending a missing tag. A mature baseline reserves deny for genuine prohibitions and leans on audit and remediation for everything correctable, often introducing a new rule in audit mode, measuring compliance, and graduating it to deny once the estate is remediated.

Q: What happens if I assign policies per subscription instead of at the management group level?

Per-subscription policy is the half-measure that feels like governance but does not scale, and it produces drift. When you assign the same rules subscription by subscription, you maintain a separate copy of each assignment per subscription, and no human keeps dozens of copies synchronized for long. The symptom appears over time: one subscription has the tagging policy, another received it months later, a third never got it because the person maintaining the script changed teams. By the time anyone audits, the estate is a patchwork of partial compliance that no single change can correct, and the remediation is the migration project the landing zone was supposed to make unnecessary. Assigning governance at the management group level instead makes compliance a property of position in the hierarchy, inherited automatically by every subscription beneath, so a new subscription placed correctly is compliant on arrival rather than after someone remembers to apply the rules to it.

Q: How is networking and connectivity designed in a landing zone?

Connectivity is centralized in the platform’s connectivity subscription so that traffic between workloads, to on-premises, and to the internet transits a controlled set of shared resources rather than each workload inventing its own egress. The dominant model is hub-and-spoke: a hub virtual network hosts the shared firewall, the gateways for site-to-site VPN or ExpressRoute, and the private DNS zones, and each workload’s spoke network peers to the hub with routing that forces traffic through the firewall. The spoke holds only the workload’s own subnets; the shared plumbing lives in the hub. Azure Virtual WAN is the managed alternative, where Microsoft operates the hub and the routing, which suits organizations spanning many regions or branches. Either way, the shared connectivity sits in the platform and workloads peer into it. The common mistakes are spoke-side: a missing route table that lets traffic bypass the firewall, or a private endpoint without its private DNS zone, which resolves to a public address and fails.

Q: How does identity and access management work in a landing zone?

Microsoft Entra ID is the trust boundary, and Azure role-based access control assignments inherit down the management group hierarchy exactly as policy does. The landing zone’s identity design answers who administers the platform, who operates each workload, and how privileged access is granted and audited. Platform operators are granted access at the platform group, reaching the shared-service subscriptions beneath without per-subscription grants. Workload teams are granted access scoped to their own subscriptions, so their authority stops at their resources. The principle is least privilege applied concretely: no workload identity reaches beyond its workload, platform access is scoped to the platform rather than the whole tenant, and the most far-reaching roles are the smallest set, ideally activated just in time through privileged identity management rather than held permanently. This structural separation is what contains a compromised workload to its own subscription instead of letting it become a tenant-wide incident, which is the landing zone’s expression of zero-trust identity.

Q: What is subscription vending and when do I need it?

Subscription vending is an automated process that creates a workload subscription, places it under the correct management group, peers it to the central network, and applies the baseline configuration, so a workload team requests a landing zone and receives a governed, connected subscription without a platform engineer performing the steps by hand. You need it when the rate of new workloads rises to the point where manual placement becomes a bottleneck and an inconsistency risk. Early in an estate’s life, creating and placing a subscription by hand is fine because the volume is low. As the organization scales and many teams need subscriptions, hand placement makes the platform team the constraint and invites the small errors that manual work produces. Vending is the mechanism that lets the foundation scale to many workloads while keeping every new subscription consistent, and it is the natural maturation of the onboarding sequence once volume justifies automating it.

Q: How does a landing zone align with the Cloud Adoption Framework?

The Cloud Adoption Framework is Microsoft’s published guidance for adopting Azure at scale, walking an organization from cloud strategy through planning, readiness, governance, and management. The landing zone is the concrete environment that the readiness phase produces. The framework defines eight design areas a complete environment must address: the billing and Entra tenant arrangement, identity and access management, management group and subscription organization, network topology and connectivity, security, management, governance, and platform automation with DevOps. A landing zone is the implementation that addresses all eight. The framework also ships a reference accelerator, sometimes still called enterprise-scale, as Bicep and Terraform that deploys the full hierarchy, policies, and platform structure. So when you build a landing zone you are implementing the framework’s readiness guidance, which is why the hierarchy shape, the design areas, and the platform-application split all trace back to it rather than being invented locally.

Q: What is the difference between the Cloud Adoption Framework and the Well-Architected Framework here?

The two frameworks answer different questions and complement each other. The Cloud Adoption Framework tells you what foundation to build and in what order, supplying the design areas, the reference hierarchy, and the readiness guidance that produces a landing zone. The Well-Architected Framework tells you how to judge whether a design is sound, through its pillars of reliability, security, cost optimization, operational excellence, and performance efficiency. A landing zone is the Cloud Adoption Framework’s output, but the landing zone’s own choices are subject to the Well-Architected pillars: the cost of platform subscriptions, the resilience of central connectivity, the clarity of the access model. Designing a landing zone well means applying both, using the Cloud Adoption Framework for the structure and order, and the Well-Architected Framework as the quality bar that holds the foundation to the same standard as any production system. A foundation built without the first is improvised; built without the second it is structured but not necessarily sound.

Q: Can I build a landing zone for a small organization, or is it only for enterprises?

You can and should build a right-sized landing zone for a small organization, but not the full enterprise structure. The reference architecture, with its multi-branch hierarchy, several platform subscriptions, and an estate-wide policy baseline, fits an organization running many workloads with compliance obligations and distinct teams. A startup with one product and three subscriptions does not need that and would experience it as overhead without payoff. The Cloud Adoption Framework supports a start-small approach: establish a minimal but correct foundation (an intermediate root, a basic platform-and-application split, a connectivity subscription, a management subscription, and a few universal policies in audit mode) and expand it as the estate grows. The judgment is not whether to have structure but how much, and the answer scales with the trajectory. A light foundation costs little and prevents the worst sprawl, while the full architecture deployed in anticipation of growth that may not arrive wastes effort and frustrates a team that wanted to ship.

Q: How do I migrate an existing sprawl of ungoverned subscriptions into a landing zone?

Bring an ungoverned estate into a landing zone incrementally rather than in a single disruptive cutover. First build the hierarchy and the platform foundation alongside the existing subscriptions without moving anything, so the structure exists. Then introduce governance in audit mode, assigning the baseline policies at the management groups so you measure how compliant the existing subscriptions are without blocking anything, which reveals the scope of the problem. Move subscriptions into their correct positions in the hierarchy one branch at a time, watching each pick up its inherited governance as it lands, and remediate the deviations the audit surfaced. Only after the estate is measured and remediated do you graduate the critical policies from audit to deny, so enforcement does not break workloads that were non-compliant before they had a chance to fix it. The connectivity migration, repeering workloads into the central hub, is the slowest part and is done workload by workload. The pattern is structure first, measure second, remediate third, enforce last.

Q: What are the most common mistakes when building an Azure landing zone?

The recurring mistakes share a root, which is structure deferred or misapplied. Subscription sprawl is the baseline failure, creating subscriptions ad hoc with no hierarchy, governance, or clear ownership. Per-subscription policy is the half-measure that does not scale, repeating assignments until drift makes the estate a patchwork. Mixing platform and application concerns in one subscription couples a shared service’s lifecycle, access, and cost to a single workload. Building a hierarchy too deep, modeling the org chart instead of governance differences, produces a tree nobody can reason about. Assigning everything at the root or everything per subscription throws away the inheritance the hierarchy was built to provide. Building a beautiful foundation and assigning nobody to own it lets the policies and access decay. And building a structure misaligned with the organization’s actual operating model creates a foundation that fights the people it serves. The remedy in every case is to build deliberately, keep the hierarchy shallow and governance-driven, and align the structure with how the organization actually works.

Q: Where does monitoring and logging fit in a landing zone?

Monitoring and logging live in the platform’s management subscription, centralized so the organization has one place to query posture and investigate incidents rather than a workspace per subscription that nobody correlates. A central Log Analytics workspace receives platform diagnostic logs, activity logs, and the security signals Defender for Cloud generates. The mechanism that routes telemetry there is the diagnostic setting on each resource, and the landing zone typically enforces those settings through a deployIfNotExists policy assigned at a management group, so no subscription can quietly opt out of logging. Centralizing observability this way is both an operational-excellence asset, because incident investigation has a single coherent view, and a security asset, because the posture across the whole estate is visible in one place. The design choice to enforce diagnostics through inherited policy rather than to trust each workload to configure its own logging is what makes the central view complete rather than full of gaps wherever a team forgot.

Q: How does a landing zone help with security and compliance?

A landing zone makes security and compliance structural rather than aspirational by centralizing the controls that enforce them. Governance guardrails assigned at the management group level inherit to every subscription, so compliance requirements such as allowed regions, required encryption settings, denied public access, and mandatory diagnostics apply by inheritance rather than by per-subscription effort that decays. Identity is anchored in Entra ID with least-privilege role assignments scoped by position in the hierarchy, so a compromised workload is contained to its own subscription. Connectivity routes through a central firewall so traffic is inspected and filtered at a controlled point. Monitoring aggregates into a central workspace so the security posture across the estate is visible in one place. For regulated industries, the policy baseline can encode the specific controls a regime requires and assign them at the branch where they apply, so compliance is enforced and auditable by design. The landing zone does not make security automatic, but it makes the controls consistent, inherited, and visible, which is the difference between a posture you can defend and one you hope holds.

Q: How long does it take to build an Azure landing zone?

The honest answer is that it depends on scope and on whether you build by hand or from the accelerator. A minimal foundation for a small estate, an intermediate root, a basic platform-and-application split, a connectivity subscription, a management subscription, and a handful of universal policies in audit mode, is the work of days rather than weeks when deployed from the Bicep or Terraform accelerator Microsoft ships, because the accelerator encodes the hierarchy, the policies, and the platform structure into reusable modules. Building the full enterprise structure by hand, designing the hierarchy, authoring the policy baseline, wiring the connectivity, and configuring identity and monitoring, takes longer, often several weeks of design and deployment plus the time to align the operating model. The variable that dominates is not the deployment but the decisions: agreeing on the hierarchy shape, the policy baseline, and the platform-versus-application boundaries is the part that takes deliberation, and the deployment is fast once those decisions are settled. Treat the design as the long pole and the deployment as the short one.

Q: Should production and non-production workloads share a subscription?

Generally no, and the landing zone pattern points toward separate subscriptions per environment for a real workload. The reason is that production deserves stricter policy, tighter access, and a different blast radius than development or testing, and a subscription is the boundary where those differences attach cleanly. Put production and development in the same subscription and you either apply development’s looser controls to production, which is a risk, or production’s stricter controls to development, which slows the iteration development exists to enable. Separate subscriptions let the production environment inherit a stricter policy set, restrict access to a smaller group, and isolate its blast radius so a mistake in development cannot touch it. The cost is more subscriptions to manage, which is exactly what subscription vending and the management group hierarchy are designed to absorb. For a throwaway experiment a shared sandbox subscription is fine, but for a workload that matters, the environment boundary belongs at the subscription level.

Q: What is the difference between enterprise-scale and the Azure landing zone accelerator?

The terms overlap and the naming has shifted over time, which causes confusion. Enterprise-scale was the original name Microsoft gave to the opinionated reference architecture and the deployment assets that implement the Cloud Adoption Framework’s landing zone guidance at scale. The Azure landing zone accelerator is the deployment mechanism, the Bicep and Terraform modules and the portal-based deployment experience, that stands up that reference architecture in a tenant. In practice both names point at the same thing: a prescriptive, automated way to deploy the full management group hierarchy, the policy baseline, the platform subscriptions, and the connectivity that the framework recommends. When you read enterprise-scale in older material and accelerator in newer material, treat them as describing the same reference implementation rather than two different products. What matters is that you are deploying the framework’s opinionated default rather than inventing a structure from scratch, and the accelerator is the supported path to do that reproducibly, with the modules maintained as the guidance evolves so your foundation stays current with the reference.