TL;DR
An Azure landing zone is the governed, multi-subscription foundation, spanning management groups, identity, network topology, and policy, that Microsoft’s Cloud Adoption Framework recommends building before a single workload lands in Azure. Get the management group hierarchy, subscription vending model, and policy guardrails right first, and every workload that follows inherits governance instead of fighting it.
Key Takeaways An Azure landing zone is a governed multi-subscription environment made of two parts, a platform landing zone for shared services and application landing zones where workload teams operate, per Microsoft’s Cloud Adoption Framework. The management group hierarchy is the governance backbone. Microsoft recommends keeping it to three or four levels so policy inheritance and role assignments stay manageable at scale. Subscription vending automates how new subscriptions get provisioned with policy, networking, and ownership already attached, replacing manual requests that create unmanaged sprawl. Network topology comes down to two real choices, hub-and-spoke for moderate complexity or Azure Virtual WAN for organizations spanning many regions and branch sites. Landing zone failures rarely trace back to missing Azure skills. They trace back to governance decisions skipped before subscriptions multiplied past the point anyone could clean them up. Kanerika, a Microsoft Solutions Partner for Data & AI holding the Azure Data Warehouse Migration Specialization, used a unified governance framework on an Azure to Microsoft Fabric migration to cut a global packaging enterprise’s cloud and data costs by 30 percent. Watch on YouTube
Azure Cloud Migration for Enterprises: Services & Costs
A practical look at what enterprises actually pay for and plan around when moving workloads onto Azure, the same territory a landing zone has to be governed for before migration starts.
The Eight-Month Review Nobody Wanted to Run Picture a cloud architecture review, eight months into a rushed Azure rollout. An outside team came in to take stock of what a mid-market enterprise had actually built. Forty-three subscriptions existed. Twelve had no owner anyone in the room could name. Three different resource naming conventions were in active use, sometimes on the same day, by the same engineer.
Nothing in that scene involves a shortage of Azure talent. It is what happens when subscriptions get created one request at a time, with no shared management group hierarchy, no policy inheritance, and no answer to who owns network connectivity once a third team asks for a VNet. Microsoft built the Azure landing zone model specifically to prevent this pattern, and enterprises that design one before scaling spend a lot less time unwinding it later.
What Is an Azure Landing Zone? An Azure landing zone is a proven, flexible architecture for governing, securing, and scaling a multi-subscription Azure environment. It is not a single subscription, a resource group, or a deployed application. It is the entire governed environment, spanning identity, networking, policy, and management structure, that a workload lands inside the moment it deploys.
Microsoft’s Cloud Adoption Framework defines two components that make up a complete landing zone. The platform landing zone is the centralized foundation that establishes governance, security, and shared resources for every Azure workload. Application landing zones are the environments where workload teams deploy and operate their own resources, inheriting the guardrails the platform landing zone already put in place.
That distinction matters because it separates two different jobs. A platform team owns identity, connectivity, and policy once, centrally. Application teams own their own resource groups, their own release cycles, and their own data architecture decisions, without needing platform-level permissions to ship anything. Readers who want the fuller picture of Azure’s service catalog, migration paths, and cost structure beyond landing zone design can find that in Kanerika’s broader guide to Microsoft Azure for enterprises .
Azure Landing Zone Architecture, the Enterprise Design Model A landing zone is built from a small set of layers that repeat across every enterprise deployment regardless of industry. At the top sits the Microsoft Entra tenant and billing hierarchy. Below that, a management group tree organizes every subscription and applies governance consistently. Subscriptions themselves hold the actual cloud infrastructure , split between platform subscriptions (identity, connectivity, management) and application subscriptions where workloads run.
Every layer inherits from the one above it. A policy assigned at a management group applies automatically to every subscription and resource beneath it, which is the entire point. Nobody has to remember to reconfigure a new subscription by hand, because the subscription is born already governed.
The table below shows what changes when an organization moves from an ad hoc Azure footprint to an actual landing zone architecture.
Dimension Ad hoc Azure setup Azure landing zone architecture Governance Applied manually, subscription by subscription, after the fact Inherited automatically through management group policy Ownership Unclear once the original requester leaves the project Defined at subscription creation through subscription vending Security Inconsistent baselines across subscriptions A single security baseline enforced tenant-wide Scalability Every new subscription is a manual, ad hoc project New subscriptions provision through a repeatable, automated process Network design Point-to-point connections added as needed A defined hub-and-spoke or Virtual WAN topology from the start
Designing the Management Group Hierarchy The management group hierarchy is where Azure governance actually lives. It sits above subscriptions in Azure’s resource hierarchy, and every Azure Policy, every role assignment scoped above the subscription level, and every cost boundary an organization cares about gets defined here first.
Microsoft’s landing zone design area guidance recommends a baseline structure with a root group, a Platform group split into Identity, Management, and Connectivity, and a Landing Zones group split into Corp and Online, plus Sandbox and Decommissioned groups for experimentation and offboarding. That structure is a starting point, not a mandate. What matters more than the exact names is a principle Microsoft states plainly, the hierarchy should represent governance requirements, not the company’s org chart.
Teams that build management groups to mirror reporting lines end up rebuilding the entire tree every time the org chart changes, which defeats the purpose of the exercise. A hierarchy built around governance needs (which subscriptions need PCI controls, which need HIPAA controls, which are internal sandboxes) stays stable even as the business reorganizes around it.
Depth is the other lever worth watching. Microsoft’s own guidance keeps the recommended hierarchy to roughly three or four levels. Every additional level adds a place where policy inheritance and role-based access control can get tangled, and Kanerika’s data governance engagements consistently find that deep, custom hierarchies are harder to operate than they were to design.
Subscription Design and Subscription Vending Subscriptions are the real isolation boundary in a large Azure estate. Resource groups organize resources within a subscription, but billing, many policy assignments, and most resource quotas apply at the subscription level, which is why enterprise landing zones typically end up with dozens of subscriptions rather than a handful.
The question that trips up most platform teams is not how many subscriptions to create, but how to create them without turning the platform team into a ticket queue. That is what subscription vending solves. It is an automated workflow where an application team requests a subscription, a platform team’s predefined business logic approves it, and the subscription gets provisioned already carrying the right management group placement, policy assignments, network connectivity, and named owner. Microsoft’s own architecture guidance and the open-source Azure Verified Modules subscription vending module on the Terraform Registry both converge on the same pattern. Automate the request-to-handoff pipeline, or governance erodes one manual subscription at a time.
The comparison below shows why manual subscription creation stops scaling somewhere around the second or third team asking for one.
Approach Manual subscription creation Automated subscription vending Turnaround time Days to weeks, depending on platform team backlog Minutes to hours through a defined pipeline Policy consistency Depends on the engineer’s memory that day Applied automatically from the product line template Ownership tracking Often undocumented after the original request Captured at intake as a required field Shadow IT risk High, teams route around a slow process Low, self-service replaces the incentive to route around it
Self-service is the part enterprises get nervous about, understandably. The fix is not to slow the process back down. It is to make the guardrails part of the automation itself, so a team requesting a subscription cannot accidentally provision one outside the governance model even if they wanted to.
Identity and Access Management Design Every landing zone decision eventually runs into identity. Microsoft Entra ID is the control plane for who can do what, across every subscription in the hierarchy, and getting its design wrong early is one of the more expensive mistakes to unwind later.
A well-designed landing zone separates platform administrators, who manage identity, connectivity, and policy at the management group level, from application team members, who need permissions scoped tightly to their own subscription and resource groups. Role-based access control assigned at the management group level should stay narrow and auditable. Privileged access, the kind that can change policy or touch the connectivity hub, belongs behind Privileged Identity Management with time-bound activation rather than standing assignments.
The most common IAM mistakes Kanerika’s architecture reviews turn up are not exotic. They are excessive Owner or Contributor roles granted at a management group scope instead of a subscription scope, service principals created for a one-time migration and never cleaned up, and inconsistent role assignments where two subscriptions doing the same job have completely different access models. None of these require sophisticated tooling to fix. They require someone to actually look, which is what a landing zone review is designed to force before the sprawl gets worse. Kanerika’s work on Microsoft Purview-based governance, including a data governance engagement for a regulated banking client , follows the same principle, access control decisions made once, centrally, beat access control decisions made ad hoc by whoever provisioned a resource first.
Case Study
Revolutionizing Data Governance for a Leading Bank with Microsoft Purview
How Kanerika built a centralized Microsoft Purview governance model for a regulated banking client, the same access-control discipline a landing zone’s identity design is meant to enforce from day one.
Read the Case Study → Network Topology, Hub-and-Spoke vs Azure Virtual WAN Network design in a landing zone comes down to two real architectures. Hub-and-spoke uses a central hub virtual network, typically holding a firewall, DNS, and VPN or ExpressRoute gateways, connected to spoke VNets through peering. Azure Virtual WAN replaces that single hub with a managed, Microsoft-operated networking backbone that can host multiple regional hubs and connect them automatically.
Neither one is universally correct. Hub-and-spoke is simpler to reason about, easier to troubleshoot, and fits organizations with a handful of regions and moderate connectivity needs. Virtual WAN earns its added operational complexity once an organization has many regions, a large number of branch or site connections, or growth plans that would eventually require chaining multiple hubs together manually under a hub-and-spoke model anyway.
Factor Hub-and-spoke Azure Virtual WAN Complexity Lower, self-managed hub VNet Higher initial setup, Microsoft-managed backbone Best fit Single region or a few regions, moderate scale Many regions, large branch or site count Branch connectivity Manual VPN or ExpressRoute configuration per hub Built-in any-to-any connectivity across hubs Operational control Full control over every network component Less granular control, more automation
Kanerika typically recommends starting clients on hub-and-spoke, since it is what most Microsoft reference architectures default to, and migrating to Virtual WAN only once regional count or connectivity demand genuinely justifies it. Building for a scale the organization has not reached yet just adds operational overhead nobody is using.
Policy-Driven Governance, Guardrails Without Blocking Teams Azure Policy is what turns a management group hierarchy from an org chart into an enforcement mechanism. Policies assigned at a management group scope inherit down to every subscription and resource beneath it, covering things like allowed regions, required tags, approved SKUs, and encryption requirements.
There are two kinds of controls worth distinguishing, and most landing zones need both. Preventive controls, deployed as “deny” policies, stop a non-compliant resource from being created in the first place. Detective controls, deployed as “audit” policies, flag existing non-compliant resources without blocking anything, which is useful for rolling out a new standard without breaking whatever teams already built.
The failure mode to watch for is treating governance and velocity as opposites. A landing zone with too many preventive controls turns every application team request into a support ticket, and teams find workarounds. A landing zone with only detective controls catches problems after they ship. The right balance uses preventive controls for anything genuinely non-negotiable, like encryption at rest or approved regions for data sovereignty requirements, and detective controls for standards that are important but not worth blocking a deployment over.
Resource Organization, Tagging, and Cost Management Resource groups, naming conventions, and tags are the least glamorous part of landing zone design and the part that determines whether anyone can actually operate the environment a year later. A resource with no owner tag, no cost center, and a name that gives no hint what it does becomes technical debt the moment its creator moves to a different project.
A workable enterprise tagging framework usually covers a small, consistent set of fields, applied through policy rather than convention alone so tags cannot silently go missing.
Application or workload owner, the team accountable for the resource Environment, distinguishing production, test, and development Cost center or business unit, for chargeback and FinOps reporting Compliance classification, flagging anything subject to regulatory controls Poor resource organization is not a cosmetic problem. It is the reason cloud cost reviews take weeks instead of hours, and it is a direct contributor to the wasted spend that shows up in industry cost surveys year after year. Flexera’s 2026 State of the Cloud Report found that wasted cloud spend rose to 29 percent in 2026, reversing five years of steady decline, driven partly by the complexity that new AI and PaaS services add on top of an already under-governed environment. A landing zone with enforced tagging does not eliminate waste by itself, but it gives a FinOps team the data needed to find it.
Security Baseline for an Azure Landing Zone Security in a landing zone is centralized by design rather than bolted on per subscription. Microsoft Defender for Cloud provides posture management and threat protection across every subscription in the hierarchy, and Microsoft Sentinel aggregates logs into a single security operations view instead of forcing a security team to check dozens of subscriptions individually.
A dedicated security or management subscription typically hosts these centralized tools, with policy ensuring every other subscription forwards its logs and diagnostic data there automatically. That pattern extends naturally to zero trust principles, verifying identity explicitly, using least privilege access, and assuming breach, across identity, network, data, and workload layers rather than relying on network perimeter alone.
Regulated industries feel the value of this most directly. A healthcare or banking organization running dozens of application landing zones cannot audit each one by hand for HIPAA or PCI compliance. A centralized security baseline, enforced through policy and monitored through one pane of glass, is what makes that kind of audit tractable at all.
Kanerika Service
Azure Cloud Solutions from Kanerika
A Microsoft Solutions Partner for Data & AI helping enterprises design, secure, and govern Azure environments that hold up to HIPAA, PCI, and other regulatory audits.
Explore Azure Cloud Solutions Platform Landing Zone vs Application Landing Zones The split between platform and application responsibilities is what keeps a landing zone from becoming a bottleneck as an organization scales past a handful of workloads. Most organizations should have only one platform landing zone per Microsoft Entra tenant, owned by a central platform team, while every workload gets its own application landing zone built on top of it.
Responsibility Platform landing zone Application landing zone Owned by Central platform or cloud center of excellence team Individual workload or application team Covers Identity, connectivity, management, security, shared services Workload resources, code, and environments (dev, test, production) Changes how often Rarely, changes affect every workload Frequently, changes are scoped to one team Typical scope One per Microsoft Entra tenant One per workload, often several subscriptions
This is also where data and AI workloads enter the picture. A Microsoft Fabric deployment, a Databricks workspace, or a Snowflake environment running on Azure infrastructure lands inside an application landing zone exactly like any other workload, inheriting network and identity controls from the platform below it rather than requiring a separate governance model. That is precisely why landing zone design matters to data teams even when nobody on the data team touches a management group directly.
Watch on YouTube
Kanerika on Microsoft Fabric: AI Insights with Karl + Faster Azure Migration
How Fabric workloads inherit the governance built into the Azure platform underneath them, and what that means for teams planning a faster migration.
Implementation Approaches, Accelerator, Custom Build, or Partner-Led Microsoft offers several accelerators, using Bicep or Terraform with Azure Verified Modules, that deploy a working platform landing zone in a matter of days using recommended defaults. For most organizations, an accelerator is the fastest path to a deployment that already follows Microsoft’s tested patterns, and the Azure Landing Zones reference implementation on GitHub is the canonical source for that code.
Custom builds make sense when an organization’s compliance requirements, existing Azure footprint, or organizational structure genuinely do not fit the accelerator’s assumptions. The mistake to avoid is customizing everything by default. Every deviation from the reference architecture is something Kanerika’s engineering teams have to document, test, and maintain going forward, so custom decisions should map to a real requirement, not a preference.
Infrastructure as code is not optional at this scale regardless of which path an organization chooses. A landing zone deployed by hand through the Azure portal cannot be reliably reproduced, audited, or rolled back, and repeatable, code-defined infrastructure is what makes a landing zone something a platform team can actually operate rather than something that only the original architect understands.
On-Demand Webinar
Modernize Your Data Stack with Intelligent Migration Accelerators
An on-demand session on using accelerators to modernize a data stack without every deviation from the reference pattern becoming a maintenance burden.
Watch the Webinar → Common Azure Landing Zone Design Mistakes The same handful of mistakes show up across enterprise Azure architecture reviews, regardless of industry or company size.
Creating subscriptions without governance controls attached. A subscription provisioned outside the vending process starts life ungoverned and stays that way until someone notices.Over-engineering the management group hierarchy. Deep, highly customized trees are harder to operate than the flat structure Microsoft recommends, and they rarely earn their complexity.Centralizing too much in the platform team. Routing every application-level decision through a central team turns the platform into a bottleneck and pushes teams toward workarounds.Treating the landing zone as a one-time project. Design areas need to evolve as workload types, regulatory requirements, and Azure’s own service catalog change.Skipping the sandbox. Without an isolated environment for experimentation, teams test new services directly in shared subscriptions, which is exactly the kind of unmanaged growth a landing zone exists to prevent.How Kanerika Builds Governed Azure Foundations for Data and AI Workloads Kanerika approaches landing zone work as the foundation for whatever comes after it, not as a standalone infrastructure project. That sequencing matters because most of Kanerika’s Azure engagements start from a data modernization or AI enablement goal , and a governed landing zone is what determines whether that goal ships in weeks or gets stuck reconciling access requests six months in.
The delivery model follows five stages that stay consistent across engagements, adjusted to the client’s actual Azure footprint.
Assess. An architecture review of the existing Azure estate, mapping current subscriptions, identity configuration, and network topology against Microsoft’s Cloud Adoption Framework design areas to find governance gaps before they become production incidents.Design. A management group hierarchy, subscription model, and network topology sized to the organization’s actual regional footprint and compliance requirements, not a default template applied without adjustment.Build and automate. Infrastructure as code deployment of the platform landing zone, plus subscription vending automation so new application landing zones provision through a repeatable pipeline instead of manual tickets.Govern. Policy-driven guardrails delivered through Kanerika’s kanSuite governance services, kanGovern for policy strategy, kanComply for regulatory frameworks, and kanGuard for access control enforcement, all built on Microsoft Purview .Enable. Workload teams onboarded into application landing zones for the data and AI platforms they actually need, whether that is Fabric, Databricks, Snowflake, or a custom application footprint.That governance-first approach is exactly what played out in Kanerika’s work with a global packaging solutions enterprise migrating off fragmented Azure Data Factory and Synapse workflows. The client’s challenge was not unique, scattered pipelines across Azure Data Factory and Synapse, an intermediate Parquet conversion step causing latency and failures, and no unified governance model, which meant inconsistent setups and redundant processes every time a new pipeline shipped.
Kanerika migrated the client’s Azure assets to Microsoft Fabric using a proprietary migration utility, then established a unified governance framework standardizing naming conventions, version control, and documentation across the environment, the same governance discipline a landing zone is meant to enforce from day one. The result was a 30 percent reduction in cloud and data costs, a 50 percent improvement in data pipeline performance, and 80 percent faster business insights and reporting. The full engagement is documented in Kanerika’s Azure to Microsoft Fabric migration case study .
Case Study
80% Faster Insights with Azure to Microsoft Fabric
A global packaging enterprise cut cloud and data costs 30 percent and sped up reporting 80 percent after Kanerika replaced fragmented Azure pipelines with a unified governance framework.
Read the Case Study → Kanerika holds the Microsoft Advanced Specialization for Data Warehouse Migration to Microsoft Azure, earned in December 2025, and was placed as a Major Contender in Everest Group’s Microsoft Azure Services PEAK Matrix Assessment 2026 , alongside credentials as a Microsoft Solutions Partner for Data & AI . For enterprises modernizing off Azure Data Factory specifically, Kanerika’s Azure to Fabric migration accelerator , delivered through the FLIP platform , has cut migration timelines by up to 80 percent and required 65 percent fewer resources on comparable engagements. See the full case study archive for more examples across industries, or start with Kanerika’s AI maturity assessment to see where a landing zone review would have the most impact.
Azure Landing Zone Design Checklist for Cloud Architects Before deploying a platform landing zone, cloud architects and platform teams can use this checklist to confirm every design area has an actual decision behind it, not a default nobody reviewed.
Checklist
Microsoft Azure Checklist
A practical checklist for confirming every Azure landing zone design area actually has a decision behind it before you deploy.
Get the Checklist → Management group hierarchy defined around governance requirements, kept to three or four levels Subscription model decided (by environment, by team, or a hybrid) with a vending process to provision new ones Identity design complete, including RBAC boundaries and Privileged Identity Management for platform-level access Network topology chosen (hub-and-spoke or Virtual WAN) sized to actual regional and connectivity needs Policy assignments mapped, with preventive controls for non-negotiables and detective controls for everything else Tagging standard enforced through policy, covering owner, environment, cost center, and compliance classification Security baseline deployed, including Defender for Cloud, Sentinel, and centralized log aggregation Sandbox management group available for experimentation outside of governed subscriptions Application landing zone template ready for the first workload team to onboard, including data engineering and analytics workloads specifically Frequently Asked Questions
What is the recommended Azure landing zone management group hierarchy? Microsoft recommends a hierarchy built around a root group with a Platform group split into Identity, Management, and Connectivity, and a Landing Zones group split into Corp and Online, plus Sandbox and Decommissioned groups. Keeping the hierarchy to three or four levels deep is the guidance Microsoft gives to avoid the policy inheritance and access control complexity that comes with deeper trees. The structure should mirror governance requirements, not the company’s org chart.
How many Azure subscriptions should an enterprise create? There is no fixed number. Subscriptions typically get split by environment, by workload team, or by Azure’s own resource-level limits, and most enterprise landing zones end up with dozens of subscriptions once vending is automated. That is normal, not a sign of sprawl, as long as every subscription has a clear owner and inherits policy from its management group.
What is the difference between an Azure landing zone and a subscription? A subscription is a billing and access boundary inside Azure. A landing zone is the entire governed environment around it, the management group hierarchy, identity model, network topology, and policies that a subscription inherits automatically the moment it gets created. A subscription without a landing zone is just an empty account with no guardrails attached.
Should enterprises use hub-and-spoke or Azure Virtual WAN for a landing zone? Hub-and-spoke fits organizations with a handful of regions and moderate network complexity, since it is simpler to operate and troubleshoot. Azure Virtual WAN fits organizations with many regions or a large volume of branch and site connectivity. Kanerika typically starts clients on hub-and-spoke and migrates to Virtual WAN only once regional count or connectivity demand justifies the added complexity.
How does an Azure landing zone handle security and compliance requirements? Security gets enforced through Azure Policy assigned at the management group level, centralized monitoring through Microsoft Defender for Cloud and Microsoft Sentinel, and identity controls through Microsoft Entra ID. Because policy inherits down automatically, compliance requirements apply to new workloads by default instead of depending on each application team to configure them correctly.
Can Azure landing zones support Microsoft Fabric, Databricks, and AI workloads? Yes. Data and AI workloads deploy into application landing zones the same way any other workload does, inheriting identity, network, and policy guardrails from the platform landing zone underneath. Microsoft designs the model to support new workload types, including AI, without requiring architectural changes, which is why enterprises build the landing zone before starting a Fabric or Databricks rollout rather than after.
Should application teams manage their own Azure subscriptions? Application teams should own the resources inside their own application landing zone subscriptions, but not platform-level services like connectivity, identity, and core policy, which stay with a central platform team. That split lets application teams move quickly inside their own environment while keeping governance consistent across the organization.
How long does it take to implement an Azure landing zone? A platform landing zone built from a Microsoft accelerator with standard design choices can deploy in a few weeks. Timelines extend to two or three months when an enterprise has custom compliance requirements, existing subscriptions that need to be brought under governance, or a hybrid identity migration running alongside it.
