An Azure landing zone is the foundation that every enterprise workload sits on. Get it right and your teams deploy faster, governance scales without friction, and costs stay predictable. Get it wrong and you spend the next two years untangling subscription sprawl, firewall misconfigurations, and identity gaps that auditors flag on every review cycle.
The short answer: follow the Cloud Adoption Framework (CAF) reference architecture, deploy it as code with the Azure Landing Zones IaC accelerator (Bicep or Terraform, built on Azure Verified Modules), and customize only where your requirements force you to. The practices that matter most:
| Best practice | Why it matters |
|---|---|
| Use the CAF management group hierarchy (Platform, Landing zones, Sandbox, Decommissioned) | Policy inheritance does the governance work for you |
| Group workloads by archetype (Corp, Online, Local), not by environment | Microsoft explicitly recommends against dev/test/prod management groups |
| One subscription per workload environment, created by subscription vending | Clean blast radius, RBAC, and cost attribution |
| Assign Azure Policy at management groups; RBAC for workload teams at subscription scope | Guardrails without gatekeepers |
| Pick hub-and-spoke or Virtual WAN before the first workload lands | Networking is the hardest decision to reverse |
| Deploy and change the platform only through IaC and pull requests | Prevents drift and makes the landing zone auditable |
This guide walks through each of these in detail for 2026, including what changed recently (the deprecation of ALZ-Bicep classic and the original Terraform module, and the retirement of Azure Blueprints), a step-by-step implementation path, and a checklist you can use for an Azure landing zone review. If you are weighing Azure against other providers, our Azure vs AWS vs GCP comparison provides broader context on platform strengths.
What Is an Azure Landing Zone?
Microsoft’s Cloud Adoption Framework defines an Azure landing zone as a proven, flexible architecture for governing, securing, and scaling a multi-subscription Azure environment. It has two parts:
- Platform landing zone: the centralized foundation. It holds the management group hierarchy, Azure Policy assignments, and shared services such as hub networking, central logging, security tooling, and identity. Most organizations should have exactly one per Microsoft Entra tenant.
- Workload landing zones (Microsoft used to call these application landing zones): the subscriptions where workload teams deploy and run their resources, inside the guardrails the platform sets. Each workload gets one workload landing zone containing all of its environments (dev, test, production), and each environment is one or more subscriptions.
Think of it as building codes for a commercial building. Individual tenants (workload teams) build out their spaces, but the foundation, wiring, plumbing, and fire exits are standardized and non-negotiable.
Why Landing Zones Matter
Without a landing zone, cloud adoption follows a pattern most organizations recognize:
- A team spins up a subscription for a proof of concept
- The POC goes to production without governance review
- A second team creates another subscription with different naming conventions, different networking, and no connection to the first
- Security discovers both subscriptions six months later during an audit
- The organization spends more time remediating than it would have spent building the foundation
Landing zones prevent this cycle by establishing consistent patterns from the start. They provide guardrails without gatekeepers: workload teams can deploy freely within defined boundaries, and platform teams keep visibility and control without becoming bottlenecks.
What Are the Azure Landing Zone Design Areas?
CAF organizes landing zone decisions into eight design areas. Work through them before you choose an implementation option, because the answers change how you configure the accelerator.
| Design area | Type | The decision you are making |
|---|---|---|
| Azure billing and Microsoft Entra tenant | Environment | EA or MCA enrollment, tenant strategy, billing ownership |
| Identity and access management | Environment | Entra ID design, hybrid identity, RBAC model, PIM |
| Resource organization | Environment | Management group hierarchy, subscription design, naming and tagging |
| Network topology and connectivity | Environment | Hub-and-spoke vs Virtual WAN, hybrid links, DNS, IP plan |
| Security | Compliance | Defender for Cloud, Sentinel, encryption, key management |
| Management | Compliance | Monitoring, logging, backup, patching, operational baseline |
| Governance | Compliance | Azure Policy, cost controls, compliance enforcement |
| Platform automation and DevOps | Compliance | IaC tooling, pipelines, team topology for the platform |
The environment design areas are hard to change later. The compliance design areas are where you iterate as new workloads and regulations show up.
Azure Landing Zone Architecture: Management Group Hierarchy
Subscription and management group design is the first architectural decision and one of the hardest to change later. Azure subscriptions are both a billing boundary and a management boundary, so how you organize them has downstream effects on cost attribution, access control, and policy enforcement.
Management groups sit above subscriptions and let you apply policies and access controls to groups of subscriptions instead of managing each one. The current CAF management group guidance recommends this hierarchy:
Tenant Root Group
|-- Intermediate root (e.g. "contoso")
|-- Platform
| |-- Security (Sentinel, SIEM tooling)
| |-- Management (Log Analytics, monitoring)
| |-- Identity (AD DS or Entra Domain Services)
| |-- Connectivity (hub VNet or Virtual WAN, Firewall, DNS)
|-- Landing zones
| |-- Corp (needs private connectivity to the hub)
| |-- Online (internet-facing, may not need a VNet)
| |-- Local (Azure Local clusters and their workloads)
|-- Sandbox (isolated experimentation)
|-- Decommissioned (cancelled subscriptions awaiting deletion)Key design decisions:
- Never build directly on the Tenant Root Group. Create an intermediate root management group and keep policy assignments at the tenant root to a minimum. Inherited policies from the root are painful to debug.
- Separate platform from workloads. Platform subscriptions are owned by central IT. Workload subscriptions sit under Landing zones and are owned by application teams.
- Group by archetype, not by environment. This is the most common mistake we see in older landing zones. Microsoft’s guidance is explicit: do not create management groups for production, testing, and development. Put dev, test, and prod in separate subscriptions under the same archetype (Corp or Online) and vary policy with parameters or subscription-level assignments where you must.
- Keep it flat. Azure supports six levels of depth below the root, but CAF recommends no more than three or four. Do not mirror your org chart.
- Do not model regions as management groups. The only exception is a genuine data residency or sovereignty requirement.
- Lock down the hierarchy. By default any user can create management groups. Turn on RBAC authorization for management group operations and set a default management group (Sandbox is a good choice) so new subscriptions never land under the root.
- Use Sandbox for experimentation. Sandbox subscriptions have no connectivity to corporate networks and a looser policy set, so teams can explore without introducing risk.
Subscription Vending
Rather than creating subscriptions by hand, mature organizations implement subscription vending: an automated process that provisions a new workload landing zone with standardized configuration. This typically includes:
- Placing the subscription in the correct management group (Corp, Online, or Local)
- Creating a spoke VNet and connecting it to the hub or virtual hub
- Allocating a non-overlapping address range from your IPAM
- Configuring diagnostic settings and budgets
- Granting the workload team RBAC roles at subscription scope (not at management group scope)
The Azure Verified Modules include a subscription vending pattern module for both Bicep and Terraform. The goal is that a new team goes from request to fully configured subscription in hours, not weeks.
How Do You Deploy an Azure Landing Zone in 2026?
Microsoft’s implementation options page now lists two paths for the platform landing zone:
| Option | What it is | Best for |
|---|---|---|
| Azure Landing Zones IaC Accelerator (recommended) | Bootstraps a repo and CI/CD pipelines in GitHub or Azure DevOps, then deploys the platform with Bicep or Terraform built on Azure Verified Modules (AVM) | Any team that will run the platform long term |
| Platform landing zone portal accelerator | A guided “Deploy to Azure” experience in the portal | Teams with no IaC skills who need a reference deployment fast |
Microsoft is clear that the portal option is harder to update and version, and recommends moving to IaC when you can.
What Changed: ALZ-Bicep, the Terraform Module, and Blueprints
If you are reading older guides (or inherited an older landing zone), three changes matter:
- ALZ-Bicep (now “classic”) is being retired. With the Bicep AVM implementation generally available and the default in the accelerator, the classic starter module was removed from the accelerator on February 16, 2026. The ALZ-Bicep repository gets bug fixes and policy refreshes until it is archived on February 16, 2027.
- The original Terraform module (
caf-enterprise-scale) is deprecated. Its repository states it will no longer receive updates and is not recommended for new deployments. New Terraform deployments should use the AVM platform landing zone modules, and Microsoft publishes a migration guide. - Azure Blueprints is retiring. Per the Blueprints retirement FAQ, the phased retirement began July 31, 2026, and the service is fully retired on January 31, 2027, when Blueprint locks (deny assignments) are removed. Microsoft recommends Deployment Stacks, with template specs as an option. If anyone suggests an “Azure landing zone blueprint” built on Azure Blueprints, that is no longer a viable path.
Choosing between Bicep and Terraform for the accelerator comes down to your team’s existing skills and whether you manage other clouds. Our Terraform vs Bicep vs ARM templates comparison covers the trade-offs.
Azure Landing Zone Setup, Step by Step
This is the sequence we follow on client engagements. Steps 4 to 7 map to the accelerator’s own phases (planning, prerequisites, bootstrap, run).
- Settle billing and tenant. Confirm the EA or MCA billing structure and that you are building in the right Entra tenant.
- Make the design area decisions. In particular: networking topology, primary and secondary regions, IP address plan, and which management groups beyond Corp and Online you actually need.
- Create break-glass accounts and PIM. Before any automation gets privileged access.
- Choose Bicep or Terraform and your VCS (GitHub or Azure DevOps).
- Create the platform subscriptions (management, connectivity, identity, security) and the identity the pipelines will use.
- Run the accelerator bootstrap. It creates the repo, pipelines, state storage (for Terraform), and managed identities.
- Customize the configuration and deploy. Start with the defaults; change policy assignments, networking, and archetypes through pull requests.
- Vend the first workload landing zone and migrate a low-risk workload into it to prove the path end to end.
- Review against the checklist at the end of this article, then iterate.
A basic deployment takes days. A customized enterprise landing zone with hybrid networking and custom policy typically takes 4 to 8 weeks.
Governance Guardrails
Governance in a landing zone is not about blocking deployments. It is about creating boundaries that stop misconfigurations from reaching production. Azure Policy is the primary mechanism, and the accelerator ships with a large default set of policy assignments per archetype.
Essential Azure Policies
Start with these policy categories and expand over time:
Security policies:
- Require encryption at rest for storage accounts
- Deny public IP addresses on VMs in Corp landing zones (force traffic through the hub firewall or Azure Bastion)
- Require network security groups on subnets
- Enable Microsoft Defender for Cloud plans on every subscription
- Deny storage accounts with public blob access
Cost governance policies:
- Restrict allowed VM SKUs to prevent oversized instances
- Require resource tags (CostCenter, Owner, Environment) for cost allocation
- Deny expensive SKUs in non-production subscriptions
Operational policies:
- Require diagnostic settings that route to the central Log Analytics workspace
- Enforce naming conventions with deny or modify policies
- Restrict allowed regions to meet data residency requirements
For a deeper look at policy design, exemptions, and initiative structure, see our guide to Azure Policy best practices for governance at scale. For the broader operating model around it, see our cloud governance guide. For cost guardrails specifically, see 10 ways to cut your Azure bill.
Policy Assignment Strategy
Assign policies at the highest appropriate management group and use exemptions sparingly:
- Organization-wide baselines at the intermediate root (not the Tenant Root Group)
- Workload-agnostic guardrails at Landing zones
- Archetype-specific controls at Corp (deny public endpoints, require private DNS integration) and Online
- A relaxed set at Sandbox (allow public IPs, broader SKUs, but no connectivity to Corp)
Roll out new policies in audit mode first, review compliance, then switch to deny. Use DeployIfNotExists and Modify policies to remediate automatically rather than just flagging. For example, a policy can enable Defender for Cloud on every new subscription without anyone remembering to do it.
RBAC Design
Role-based access control in a landing zone follows least privilege:
- Platform team: elevated roles on platform subscriptions, granted just in time through PIM rather than as standing access
- Workload teams: Contributor (or a custom role) on their own subscriptions only, assigned during subscription vending
- Security team: Security Reader across the estate, Security Admin where needed
- Network team: Network Contributor on the connectivity subscription
Do not grant workload teams roles at management group scope; inherited permissions are how over-permissioning creeps in. Use Entra ID groups rather than individual assignments so access reviews stay manageable. Microsoft’s RBAC best practices guide covers custom roles and scope in more detail.
Networking Topology
Networking is where landing zone decisions have the most long-term impact. Changing topology after workloads are deployed is painful, expensive, and risky.
Hub-and-Spoke vs Azure Virtual WAN
CAF supports two reference topologies:
| Feature | Hub-and-Spoke | Azure Virtual WAN |
|---|---|---|
| Hub | You build and run the hub VNet | Microsoft-managed virtual hub |
| Cost model | Pay for the gateways, firewall, and peering you deploy | Hub hourly fee plus gateway scale units, connection units, and data processing |
| Branch connectivity | VPN or ExpressRoute gateway you deploy in the hub | Integrated S2S, P2S, and ExpressRoute with SD-WAN partner automation |
| Spoke-to-spoke | UDRs through a firewall, or Azure Virtual Network Manager | Transitive by default in a Standard Virtual WAN |
| Best for | One or two regions, specific third-party NVAs, maximum routing control | Many regions, many branches, lean network teams |
Hub-and-spoke remains the right choice for most mid-market organizations. You deploy a hub VNet with shared services (Azure Firewall, VPN or ExpressRoute gateway, Azure Bastion, DNS Private Resolver) and connect each workload spoke to it. Virtual WAN suits organizations with several regions, lots of branch offices, or SD-WAN. We compare both in depth, including costs, routing intent, and a decision table, in Azure landing zone networking: hub-and-spoke vs Virtual WAN.
Hub Network Design
A well-designed hub includes:
- Azure Firewall or a third-party NVA: centralized inspection for east-west (spoke-to-spoke) and north-south (internet) traffic. Azure Firewall comes in Basic (up to 250 Mbps), Standard (up to 30 Gbps), and Premium (up to 100 Gbps, adds TLS inspection, IDPS, and URL filtering).
- VPN Gateway: site-to-site tunnels to data centers or branches. Use the zone-redundant AZ SKUs; Microsoft stopped allowing new non-AZ VpnGw1 to 5 gateways in November 2025.
- ExpressRoute Gateway: private connectivity for latency-sensitive or high-bandwidth workloads.
- Azure Bastion: RDP and SSH to VMs without public IPs. Our guide to jumpboxes, bastion hosts, and Azure Bastion covers the options.
- DNS Private Resolver: conditional forwarding between on-premises DNS and Azure Private DNS zones.
Subnet sizing tip: over-allocate address space in the hub. Running out of addresses in the hub is a common and painful problem. A /22 or /21 is reasonable even if current needs look smaller. (If you choose Virtual WAN, Microsoft recommends a /23 or larger for the virtual hub and requires a /22 if Azure Firewall runs in it.)
Spoke Network Design
Each spoke VNet connects to the hub and typically contains application subnets, data subnets, and a subnet for Private Endpoints. In hub-and-spoke, use user-defined routes to force spoke traffic through the hub firewall; without them, any direct spoke-to-spoke path bypasses inspection. Azure Virtual Network Manager can now push hub-and-spoke connectivity, security admin rules, and UDRs to every spoke from one place, which takes most of the manual work out of large hub-and-spoke estates.
For organizations running hybrid cloud strategies, the hub is where on-premises and cloud networks meet. Getting IP planning, DNS, and routing right there prevents headaches in every spoke.
DNS Architecture
DNS needs careful planning, especially for Private Endpoints:
- Central DNS management: host Azure Private DNS zones in the connectivity subscription and link them to the VNets that need resolution
- On-premises resolution: use Azure DNS Private Resolver with forwarding rules so on-premises clients can resolve Private Endpoint FQDNs
- Automation: create Private Endpoint DNS records with Azure Policy (DeployIfNotExists) rather than by hand; the accelerator includes these policies
Identity Integration
Identity is the control plane of your landing zone. Every deployment, data access, and configuration change goes through Microsoft Entra ID (formerly Azure Active Directory).
Tenant Design
Most organizations should use a single Entra tenant. Multi-tenant designs add significant complexity to collaboration, Conditional Access, and cross-tenant access. One tenant with good management group and subscription boundaries provides enough isolation for most scenarios, and CAF recommends one platform landing zone per tenant.
Hybrid Identity
For organizations with on-premises Active Directory, Microsoft Entra Connect Sync or Entra Cloud Sync synchronizes identities to Entra ID. Key decisions:
- Password hash sync (PHS): simplest, keeps working if on-premises AD is down. Recommended as the primary method.
- Pass-through authentication (PTA): validates passwords against on-premises AD in real time. Useful when policy prohibits storing password hashes in the cloud, but adds an on-premises dependency.
- Federation (AD FS): routes authentication to on-premises federation servers. Adds infrastructure and complexity; only use it when PHS and PTA cannot meet a specific requirement.
If you are mid-migration, our guide to migrating Active Directory to Entra ID covers the sequencing.
Conditional Access
Conditional Access policies are your identity-layer firewall. Baselines for a landing zone:
- Require MFA for all users, with phishing-resistant methods (FIDO2 keys, Windows Hello for Business) for administrators
- Block legacy authentication protocols
- Require compliant devices for sensitive applications
- Restrict the Azure management plane (portal, CLI, PowerShell) to compliant devices or named locations
Our Conditional Access setup guide walks through each policy.
Privileged Identity Management (PIM)
Entra Privileged Identity Management provides just-in-time access to administrative roles. Instead of permanently assigning Owner or Contributor, users activate the role when needed, with approval and a time limit. This is also how CAF suggests handling platform team access at management group scope.
Platform Automation
A landing zone is only as good as the automation that maintains it. Manual configuration drifts, introduces inconsistencies, and does not scale.
Infrastructure as Code
Use Infrastructure as Code for every landing zone component:
- Bicep: Azure-native, first-party support, and the AVM-based accelerator path. Pairs with Deployment Stacks for lifecycle management and deny settings.
- Terraform: multi-cloud, large provider ecosystem, mature state management, and its own AVM-based accelerator path. A strong choice for organizations running DevOps infrastructure practices across platforms.
- Pulumi: general-purpose languages instead of a DSL, but no first-party ALZ accelerator, so you build more yourself.
Store the code in Git with pull request workflows. Every landing zone change goes through review, automated validation (what-if or plan), and approval before deployment.
CI/CD for Platform Changes
Platform changes (policy updates, networking changes, new subscriptions) should deploy through pipelines, never from a laptop:
# Example: deploying landing zone policy at management group scope with Bicep
az deployment mg create \
--management-group-id "contoso-landingzones" \
--location "eastus" \
--template-file ./policies/main.bicep \
--parameters ./policies/parameters/landingzones.bicepparamUse separate pipelines for platform and workload deployments. Platform pipelines need higher-privilege identities (use workload identity federation, not stored secrets) and extra approval gates.
Monitoring and Observability
A landing zone needs centralized monitoring from day one:
- Log Analytics workspace: one workspace (or a few regional ones) in the management subscription collecting logs from all subscriptions
- Azure Monitor: metrics, alerts, and diagnostic settings, enforced by policy
- Microsoft Defender for Cloud: posture management and threat detection across subscriptions
- Microsoft Sentinel: SIEM in the security subscription if you need it
- Azure Service Health: alerts for platform incidents that affect your resources
For troubleshooting, see our guide on diagnosing missing metrics in Azure Monitor.
Azure CAF vs AWS and Google Cloud Landing Zones
All three major clouds use the “landing zone” idea, but the building blocks differ:
| Azure | AWS | Google Cloud | |
|---|---|---|---|
| Isolation unit | Subscription | Account | Project |
| Hierarchy | Management groups | Organizational units (AWS Organizations) | Folders under an organization |
| Guardrails | Azure Policy | Service control policies and Control Tower controls | Organization policies |
| Managed setup | ALZ IaC accelerator or portal accelerator | AWS Control Tower, extended with Landing Zone Accelerator on AWS | Enterprise foundations blueprint |
So yes, Azure has a direct equivalent to the AWS Landing Zone Accelerator: the Azure Landing Zones IaC accelerator. The practical difference is that Azure’s is delivered as code you own and run in your own pipelines, while AWS centers on Control Tower as a managed service with Landing Zone Accelerator layered on top.
Common Pitfalls
Over-Engineering the Initial Design
The landing zone does not need to handle every future scenario on day one. Start with the CAF defaults, customize for immediate needs, and iterate. Organizations that spend six months designing the “perfect” landing zone often find their requirements have changed by the time they finish.
Environment Management Groups
Splitting Landing zones into Production and Non-Production management groups was common in early designs. It leads to duplicated policy sets and awkward moves when a subscription changes purpose. Current guidance is to group by archetype and separate environments by subscription.
Ignoring Network Address Planning
Running out of IP space is one of the most disruptive problems in a cloud environment. Plan for 3 to 5 years of growth and use a central IPAM process (Azure Virtual Network Manager includes IPAM) to prevent overlaps between on-premises, hub, and spoke ranges.
Treating the Landing Zone as a One-Time Project
A landing zone is a living platform. It needs ongoing investment: policy updates as new services launch, accelerator and module upgrades, networking changes as the organization grows, and RBAC reviews as teams change. Assign a platform team, even a small one, to own it.
Staying on Deprecated Tooling
If your landing zone was built with ALZ-Bicep classic, caf-enterprise-scale, or Azure Blueprints, put the migration on the roadmap now. Running on unsupported modules means no new policy definitions and no fixes.
Skipping the Sandbox
Without a sandbox, teams experiment in production or non-production subscriptions, creating shadow IT and compliance risk. An isolated sandbox is cheap insurance.
Azure Landing Zone Checklist
Use this checklist to validate a new landing zone or run an Azure landing zone review of an existing one. Microsoft also publishes a free Azure Landing Zone Review in Microsoft Assessments that scores you against the design areas.
Resource organization:
- Intermediate root management group under the Tenant Root Group
- Platform (Security, Management, Identity, Connectivity), Landing zones (Corp, Online), Sandbox, and Decommissioned groups created
- No environment-based management groups
- Default management group set for new subscriptions; RBAC authorization required for management group changes
- Subscription vending automated
Identity:
- Entra Connect Sync or Cloud Sync configured with password hash sync
- Conditional Access baseline deployed
- PIM configured for administrative roles
- Break-glass accounts created, excluded correctly, and monitored
Networking:
- Topology chosen (hub-and-spoke or Virtual WAN) and documented
- Hub deployed with adequate address space
- Azure Firewall (right SKU) or NVA deployed and inspecting east-west and north-south traffic
- Zone-redundant VPN or ExpressRoute gateway connected to on-premises
- DNS Private Resolver and Private DNS zones configured, with policy-driven record creation
- Non-overlapping IP plan managed centrally
Governance:
- Azure Policy assigned at management group level, audited before deny
- Tagging policy enforced (CostCenter, Owner, Environment)
- Allowed regions policy configured
- Budgets and cost alerts on every subscription
- Resource locks or Deployment Stack deny settings on critical platform resources
Security and management:
- Central Log Analytics workspace deployed
- Diagnostic settings enforced by policy
- Defender for Cloud enabled on all subscriptions
- Alert rules for critical platform events and Service Health
Automation:
- Platform deployed with the AVM-based accelerator (or an equivalent IaC codebase) in Git
- CI/CD with approvals for policy and networking changes
- No dependency on ALZ-Bicep classic,
caf-enterprise-scale, or Azure Blueprints
Frequently Asked Questions
What is an Azure landing zone?
An Azure landing zone is Microsoft’s recommended architecture for governing, securing, and scaling a multi-subscription Azure environment. It combines a platform landing zone (management group hierarchy, policy, and shared services like networking and logging) with workload landing zones where application teams deploy their resources within those guardrails.
What are the Azure landing zone design areas?
There are eight: Azure billing and Microsoft Entra tenant, identity and access management, resource organization, network topology and connectivity, security, management, governance, and platform automation and DevOps. The first four shape the environment and are hard to change later; the last four are refined continuously.
How long does it take to deploy an Azure landing zone?
A basic landing zone using the Azure Landing Zones accelerator can be deployed in a few days. A customized enterprise landing zone with CI/CD, custom policies, and hybrid networking typically takes 4 to 8 weeks. The investment pays for itself by avoiding months of remediation later.
What is the Azure landing zone accelerator?
It is Microsoft’s tool for deploying the platform landing zone. The recommended version is the Azure Landing Zones IaC accelerator, which bootstraps a repository and pipelines in GitHub or Azure DevOps and deploys the platform with Bicep or Terraform modules from Azure Verified Modules. There is also a portal accelerator for teams without infrastructure as code experience.
Is ALZ-Bicep deprecated?
Yes. Classic ALZ-Bicep was removed from the accelerator on February 16, 2026, and its repository will be archived on February 16, 2027. The replacement is the Bicep implementation built on Azure Verified Modules. The original Terraform module, caf-enterprise-scale, is also deprecated in favor of the Terraform Azure Verified Modules.
Can I retrofit a landing zone onto existing Azure subscriptions?
Yes, with planning. Create the management group hierarchy, move existing subscriptions into the right archetype, apply policies in audit mode first, and connect existing VNets to a new hub. It is more work than greenfield but far less than living without governance.
Should I use one subscription per workload or per environment?
CAF recommends one workload landing zone per workload, with a separate subscription for each environment (for example, App A Production and App A Development). This gives clean blast radius isolation, independent RBAC, and clear cost attribution. Smaller organizations can start with shared subscriptions per environment and split later.
What is the difference between an Azure landing zone and Azure Blueprints?
A landing zone is an architecture. Azure Blueprints was a service for packaging policies, role assignments, and templates. Blueprints is being retired, with the phased retirement starting July 31, 2026 and full retirement on January 31, 2027. Microsoft recommends Deployment Stacks and template specs instead, and landing zones should be deployed with the Bicep or Terraform accelerator.
Does Azure have an equivalent to the AWS Landing Zone Accelerator?
Yes. The Azure Landing Zones IaC accelerator plays the same role, deploying a best-practice multi-subscription foundation with governance controls. The main difference is delivery: Azure’s accelerator produces Bicep or Terraform code you own and run in your pipelines, while AWS builds on Control Tower as a managed service.
How do landing zones work with multi-region deployments?
Deploy a hub VNet per region and peer the hubs, or use Virtual WAN with a virtual hub per region. Spokes connect to their regional hub. Keep the same management group structure for all regions; CAF advises against creating management groups per region unless you have data residency requirements.
Do small businesses need an Azure landing zone?
Small businesses benefit from landing zone principles, but the implementation can be much lighter. At minimum, set up a management group hierarchy, a basic policy set (tagging, allowed regions, no public IPs on VMs), central logging, and MFA with Conditional Access. You can grow into the full reference architecture.
How Exodata Helps
We design, deploy, and run Azure landing zones for organizations that want the CAF foundation without a six-month project: design area workshops, accelerator deployment in Bicep or Terraform, migration off ALZ-Bicep classic or Blueprints, and ongoing platform operations. Exodata’s cloud engineering team can build a landing zone sized for your organization, regulatory requirements, and growth plans. Talk to an engineer. No sales pitch, just answers.