Azure Landing Zones And The Cloud Adoption Framework: A Practical Guide
Dominic Tarn
Head Writer - ReVerb
10.23.2026
Meta description: Learn what an Azure landing zone is, how it fits the Cloud Adoption Framework, the eight design areas, deployment options, sizing advice and mistakes to avoid.
An Azure landing zone is Microsoft’s reference architecture for running a governed, secure, multi-subscription Azure environment, built during the Ready phase of the Azure Cloud Adoption Framework. It has two parts: a platform landing zone that holds shared governance, networking, identity and management, and workload landing zones where application teams deploy inside those guardrails. For most organizations, Microsoft now recommends deploying it with its infrastructure as code accelerator using Bicep or Terraform modules from Azure Verified Modules.
This guide explains how the pieces fit together, what each design area decides, which implementation option to pick, how to size the design for a small team versus an enterprise, and where projects usually go wrong. Facts are checked against Microsoft Learn as of October 2026.
What The Cloud Adoption Framework Is
The Cloud Adoption Framework for Azure is Microsoft’s free body of guidance for moving an organization onto Azure in an orderly way. It covers business strategy, planning, the technical foundation, migration and modernization, and ongoing operations. It is not a product you buy or a tool you install. Think of it as a playbook with templates, checklists and reference architectures.
Microsoft reorganized the framework over the past two years, so older blog posts and slide decks often list phases that no longer match. The current Microsoft Learn overview organizes Azure adoption into seven methodologies:
Strategy: decide what Azure adoption should achieve for the business.
Plan: work out how the organization will prepare, including skills, people and the digital estate.
Ready: build the Azure landing zone.
Adopt: migrate, modernize and build workloads.
Govern: control the Azure environment through policy and cost management.
Secure: protect the environment across its lifecycle.
Manage: operate and optimize Azure over time.
The first four run roughly in sequence. Govern, Secure and Manage are continuous and start as soon as the first resources exist. The landing zone sits in Ready, but its design choices reach into the last three: the policies you assign enforce governance, the security subscription feeds your monitoring, and the management baseline is how operations teams see the estate.
The Cloud Adoption Framework has a sibling, the Azure Well-Architected Framework, which covers the quality of individual workloads rather than the environment as a whole. The two are designed to work together. Our Azure Well-Architected Framework guide explains its five pillars and how workload reviews differ from landing zone design.
What An Azure Landing Zone Is
Microsoft defines an Azure landing zone as a proven, flexible architecture for governing, securing and scaling a multi-subscription environment. In practical terms, it is the set of decisions and deployed resources that exist before any application arrives: who can sign in and with what rights, how subscriptions are grouped, which policies apply automatically, how networks connect to each other and to on-premises sites, where logs go, and how new subscriptions get created.
Without a landing zone, teams usually create subscriptions ad hoc, give themselves Owner rights, open public endpoints, and send logs nowhere in particular. That works for a pilot and becomes expensive to unwind at fifty subscriptions. A landing zone puts the guardrails in place first so that each new workload inherits them instead of reinventing them.
Platform Landing Zone
The platform landing zone is the centralized foundation. It consists of the management group hierarchy plus shared resources that many workloads need. In Microsoft’s reference architecture those shared resources sit in dedicated platform subscriptions for management (logging and automation), connectivity (hub networking, firewalls, DNS, gateways), identity (domain controllers or other identity services when needed) and security (SIEM tooling such as Microsoft Sentinel). Microsoft advises centralizing a capability only when it brings clear governance, operational or cost benefits across multiple workloads.
Microsoft Learn also states that most organizations should have only one platform landing zone per Microsoft Entra tenant. A central platform or cloud center of excellence team usually owns it.
Workload (Application) Landing Zones
Older documentation calls these application landing zones. Current Microsoft Learn pages call them workload landing zones, and the terms mean the same thing. A workload landing zone is the subscription, or set of subscriptions, where a workload team deploys and runs its resources. Each workload gets one landing zone that holds all of its environments, such as development, test and production, usually split across separate subscriptions.
Workload subscriptions are placed under one of the default child management groups beneath Landing Zones: Corp for workloads that connect to the corporate network through the hub, Online for workloads that face the internet directly or need no virtual network, and Local for Azure Local clusters. The subscriptions inherit Azure Policy assignments from the hierarchy, so a workload team gets a compliant starting point without having to configure it.
The Default Management Group Hierarchy
Under the tenant root, Microsoft’s default design adds an intermediate root named for your organization. Beneath it sit Platform (with Management, Connectivity, Identity and Security), Landing Zones (with Corp, Online and Local), Sandboxes for experimentation under looser policies, and Decommissioned for subscriptions being retired. Microsoft recommends keeping the tree fairly flat, ideally three to four levels, and warns against creating management groups for dev, test and production or for every region.
The Azure Landing Zone Design Areas
Before building the platform, Microsoft asks you to settle your requirements across eight design areas. Microsoft groups them into environment design areas (the first four) and compliance design areas (the last four). The table summarizes what each one decides.
Design Area
Group
Key Decisions
Typical Owner
Azure billing and Microsoft Entra tenant
Environment
Agreement type (EA, Microsoft Customer Agreement or CSP), billing hierarchy, number of tenants
Management group hierarchy, subscription design, naming and tagging standards
Cloud platform team
Network topology and connectivity
Environment
Hub and spoke or Virtual WAN, IP address plan, on-premises links, DNS, firewall, private endpoints
Network team
Security
Compliance
Microsoft Defender for Cloud plans, Microsoft Sentinel, encryption and key management, zero trust controls
Security team
Management
Compliance
Log Analytics workspace design, monitoring and alerting, backup and disaster recovery, patching
Operations team
Governance
Compliance
Azure Policy assignments, cost management and budgets, regulatory compliance reporting
Cloud center of excellence
Platform automation and DevOps
Compliance
Infrastructure as code language, repositories, CI/CD pipelines, subscription vending
Platform engineering
Billing And Tenant
This comes first because it is the hardest to change later. Your agreement type shapes how subscriptions are created and billed, and moving between tenants is a project in its own right. Most organizations should run a single Entra tenant for production Azure. If you buy through a Cloud Solution Provider, confirm early how subscription creation and support will work, since that affects subscription vending later. Our explainer on what Microsoft CSP is covers the tradeoffs.
Identity And Access Management
Identity is the main security boundary in the cloud. Decide which Entra groups map to which Azure roles, who holds standing versus just-in-time access, and how emergency accounts are protected. Microsoft’s guidance is to grant workload teams access at subscription or resource group scope, not at management group scope, and to keep platform team access to management groups behind Privileged Identity Management.
Resource Organization
Management groups exist mainly to assign policy and access at scale. Subscriptions are the unit of isolation, billing and scale limits. Tags carry cost center, owner and environment data. Set a default management group for new subscriptions (Sandboxes is a common choice) so nothing lands under the tenant root, and turn on the hierarchy setting that restricts who can create management groups.
Network Topology And Connectivity
The two common patterns are a traditional hub and spoke network that you manage yourself, and Azure Virtual WAN, where Microsoft runs the hub. Either way, the IP address plan is the decision people most regret rushing. Reserve non-overlapping ranges for every region and every spoke you might need, and decide how private DNS zones will be centralized before the first private endpoint is created.
Security, Management And Governance
These three overlap heavily. Security sets the controls (Defender for Cloud, Sentinel, key management). Management decides where logs and metrics go and how backup and recovery work. Governance turns your rules into Azure Policy assignments so that, for example, resources outside approved regions are denied and diagnostic settings are deployed automatically. Start with Microsoft’s default policy set, run new policies in audit mode first, and limit assignments at the root management group.
Platform Automation And DevOps
This design area decides how the landing zone itself is built and changed: which infrastructure as code language, which repository and pipeline tooling, and how new workload subscriptions get requested and delivered. That repeatable process is called subscription vending. It can start as a manual ticket and checklist, but automation matters more as request volume grows.
Implementation Options In 2026
Microsoft offers accelerators for both platform and workload landing zones, and also supports a custom build designed internally or with a partner. For the platform landing zone, the current implementation options page lists three routes.
Infrastructure As Code Accelerator (Recommended)
The Azure Landing Zones IaC Accelerator is Microsoft’s preferred approach. You choose Bicep or Terraform, and the accelerator deploys a platform landing zone built from Azure Verified Modules (AVM). It runs in four phases: planning (pick the language and version control system), prerequisites (credentials and subscriptions), bootstrap (a PowerShell module sets up the Azure environment and your repositories and pipelines), and run (customize the code and let CI/CD deploy it). It supports both Azure DevOps and GitHub. The result is a landing zone that lives in source control, can be reviewed through pull requests, and can be redeployed or upgraded predictably.
Azure Verified Modules Used Directly
The same Bicep and Terraform AVM modules can be used without the accelerator if you already have your own pipelines and conventions. This suits teams with mature platform engineering practices that want to compose the modules into an existing codebase.
Portal Accelerator
The portal accelerator deploys a platform landing zone through a guided Azure portal experience. Microsoft positions it for organizations without infrastructure as code skills or that prefer a visual approach. The tradeoff is that updates and version control are hard to manage afterward, and Microsoft advises moving to an IaC approach when you can. It is a reasonable way to stand up a first landing zone quickly, as long as you plan the move to code.
Retired Options To Watch For
Two older codebases still appear in many tutorials. The classic ALZ-Bicep starter was removed from the accelerator on February 16, 2026, and Microsoft’s migration documentation says the ALZ-Bicep repository is scheduled for archival on February 16, 2027, receiving only bug, security and policy fixes until then. The Terraform enterprise-scale module (terraform-azurerm-caf-enterprise-scale) is deprecated and its repository was archived on September 15, 2026. Existing deployments keep working, but new builds should use the AVM-based modules, and existing ones should plan a migration.
Sizing A Landing Zone: Small Teams Versus Enterprises
Microsoft’s reference architecture is the same for everyone, but you do not have to deploy every component on day one. The accelerators let you switch features on or off, and the guidance itself says to centralize only what brings clear benefit. The notes below are practical judgment rather than Microsoft rules.
Small And Midsize Organizations
If you run a handful of workloads with a small IT team, keep the management group hierarchy as Microsoft ships it, since it costs nothing and avoids rework later. Be selective about paid shared resources. A hub firewall, VPN or ExpressRoute gateways, and a dedicated identity subscription with domain controllers each add a monthly bill, so deploy them when a workload actually needs them. A single Log Analytics workspace, the default policy set, Defender for Cloud and a simple subscription request process cover most needs. Use the IaC accelerator if anyone on the team can maintain the code; otherwise the portal accelerator with a documented plan to move to code is acceptable.
Enterprises And Regulated Organizations
Large estates benefit from the full design: separate platform subscriptions, centralized hub networking in each region (often Virtual WAN at scale), Sentinel in a dedicated security subscription, automated subscription vending tied to an internal request portal, and policy-driven compliance reporting against frameworks your auditors care about. Expect to add archetypes for specific needs such as data residency, but expand horizontally rather than nesting deeper. Plan for a standing platform team, because the landing zone needs regular updates as Microsoft releases new policies and module versions.
Greenfield Versus Brownfield
A new tenant with nothing in it is the easy case. Most organizations already have subscriptions running. Microsoft documents brownfield transition paths, including duplicating a landing zone management group with policies in audit-only mode so you can see what would break before enforcing anything. Moving existing subscriptions into the new hierarchy is usually done workload by workload, and it pairs naturally with a migration program. Our Azure migration checklist covers the sequencing.
Common Landing Zone Mistakes
Mirroring the org chart in management groups. Departments and environments belong in subscriptions and tags, not in a deep hierarchy. Deep trees create policy exclusions and confusion.
Skipping the IP address plan. Overlapping ranges block peering and hybrid connectivity, and fixing them means rebuilding networks.
Treating the landing zone as a one-time project. Policies, modules and Microsoft guidance change. Without an owner and a pipeline, the landing zone drifts within a year.
Enforcing deny policies on existing workloads without an audit period. Run new policies in audit mode, review the findings, then enforce.
Giving workload teams Owner at management group scope. Grant access at subscription or resource group level, and use Privileged Identity Management for platform roles.
Deploying every paid component by default. Firewalls, gateways and DDoS protection have real running costs. Turn them on when a workload needs them, and set budgets from the start. Our Azure cost optimization guide covers the controls.
Following outdated tutorials. Guides built on ALZ-Bicep classic or the Terraform enterprise-scale module describe code paths Microsoft has retired.
When To Use A Partner
A team with solid Azure, networking and infrastructure as code skills can deploy a landing zone with the accelerator on its own. A partner earns its fee when you lack one of those skills, have a brownfield estate to untangle, face regulatory requirements that need mapping to policy, or need to move fast because a migration or data center exit is already scheduled. Partners also help set up the operating model, which is often harder than the code.
Questions worth asking a prospective partner:
Will you deploy with the Microsoft IaC accelerator and Azure Verified Modules, or with your own framework? If your own, how do we take in Microsoft updates?
Do you hold the Solutions Partner for Infrastructure (Azure) designation or relevant specializations, and can we verify it in Microsoft’s partner directory?
How do you handle existing subscriptions and workloads during the transition?
What will our team be able to run alone at handover: code ownership, pipelines, runbooks and training?
Which shared resources do you recommend we defer, and what will the platform cost to run each month?
No. It is an architecture and a set of free Microsoft templates. You pay only for the Azure resources it deploys, such as Log Analytics data ingestion, firewalls, gateways and Defender for Cloud plans, which is why choosing which shared components to enable matters.
How Long Does A Landing Zone Take To Build?
The accelerator can deploy the code in a day. The design decisions take longer: billing, identity, IP planning and policy choices usually need several weeks of workshops with security, network and finance stakeholders, and brownfield transitions take longer still.
Should I Use Bicep Or Terraform?
Both are supported by the IaC accelerator and built on Azure Verified Modules. Pick Bicep if your team works only in Azure and prefers native tooling. Pick Terraform if you already use it for other clouds or SaaS, or if your engineers know it better. Skills on your team matter more than the language.
What Is The Difference Between The Cloud Adoption Framework And The Well-Architected Framework?
The Cloud Adoption Framework covers the organization and the environment: strategy, planning, the landing zone, governance and operations. The Well-Architected Framework covers individual workloads, judged on reliability, security, cost optimization, operational excellence and performance efficiency.
Can I Change My Landing Zone Later?
Yes, and you should expect to. Policies, archetypes and network components can be added as needs grow, especially if the landing zone is managed as code. The decisions that are hardest to reverse are the tenant, the billing agreement and the IP address plan, so spend the most time on those.
Conclusion
Azure landing zones and the Cloud Adoption Framework: a practical guide comes down to a few points. Settle the eight design areas before deploying, use the IaC accelerator with Azure Verified Modules unless you have a strong reason not to, deploy only the shared components your workloads need, and give the platform a permanent owner. A small team can run a lean version of Microsoft’s design; an enterprise will need the full model plus automated subscription vending.
