Azure Landing Zones: Architecture Best Practices [2026]

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.

Microsoft defines a landing zone as the output of a multi-subscription Azure environment that accounts for scale, security, governance, networking, and identity. In practice, it is the set of architecture decisions you make before a single VM or container is deployed — decisions that become exponentially harder to change later.

This guide walks through the architecture best practices for Azure landing zones in 2026, covering subscription organization, governance guardrails, networking topology, identity integration, and the operational patterns that separate mature cloud environments from reactive ones. 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?

An Azure landing zone is a pre-configured environment that follows Azure’s Cloud Adoption Framework (CAF) design principles. It includes the foundational infrastructure — management groups, subscriptions, policies, networking, and identity — that workloads depend on.

Think of it as the equivalent of 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 that 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 maintain visibility and control without becoming bottlenecks.

Subscription Organization

Subscription design is the first architectural decision and one of the hardest to change later. Azure subscriptions serve as 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 Group Hierarchy

Azure management groups provide a layer of scope above subscriptions. They let you apply policies, access controls, and budgets to groups of subscriptions rather than managing each one individually.

The CAF recommends a hierarchy that looks like this:

Tenant Root Group
  |-- Platform
  |     |-- Management (Log Analytics, Automation)
  |     |-- Identity (Domain Controllers, Azure AD Connect)
  |     |-- Connectivity (Hub networking, DNS, Firewall)
  |-- Landing Zones
  |     |-- Production
  |     |-- Non-Production
  |-- Sandbox (experimental, no connectivity to corp network)
  |-- Decommissioned (subscriptions being retired)

Key design decisions:

Separate platform from workloads. Platform subscriptions (management, identity, connectivity) are owned by central IT and contain shared infrastructure. Workload subscriptions sit under Landing Zones and are owned by application teams.
Split production from non-production. Different policy assignments (for example, enforcing encryption at rest in production but not in dev sandboxes) map cleanly to this separation.
Use Sandbox for experimentation. Sandbox subscriptions have no network peering to production. Teams can experiment freely without introducing risk to production workloads.

Subscription Vending

Rather than manually creating subscriptions, mature organizations implement subscription vending — an automated process that provisions a new subscription with standardized configuration. This typically includes:

Assigning the subscription to the correct management group
Applying baseline Azure Policies
Creating default resource groups (networking, monitoring, security)
Configuring diagnostic settings to route logs to the central Log Analytics workspace
Peering the subscription’s VNet to the hub network
Granting the workload team appropriate RBAC roles

Tools like Terraform, Bicep, or the Azure Landing Zone accelerator can automate subscription vending. The goal is that a new team can go from request to fully configured subscription in hours, not weeks.

Governance Guardrails

Governance in a landing zone is not about blocking deployments — it is about creating boundaries that prevent misconfigurations from reaching production. Azure Policy is the primary mechanism.

Essential Azure Policies

Start with these policy categories and expand over time:

Security policies:

Require encryption at rest for all storage accounts
Deny public IP addresses on VMs (force traffic through the hub firewall or Azure Bastion)
Require network security groups on all subnets
Enforce Azure Defender (Microsoft Defender for Cloud) on all subscriptions
Deny storage accounts with public blob access

Cost governance policies:

Restrict allowed VM SKUs to prevent teams from deploying oversized instances
Require resource tags (CostCenter, Owner, Environment) for cost allocation
Deny deployment of expensive SKUs in non-production environments

Operational policies:

Require diagnostic settings on all resources to route to Log Analytics
Enforce naming conventions using deny policies or append policies
Require specific Azure regions to prevent data residency issues

For a deeper look at cost governance specifically, see our guide on 10 ways to cut your Azure bill.

Policy Assignment Strategy

Assign policies at the highest appropriate management group level and use exemptions sparingly. For example:

Security baseline policies at the Tenant Root Group level (applies everywhere)
Production-specific policies (stricter SKU restrictions, mandatory backups) at the Production management group
Relaxed policies at the Sandbox level (allow public IPs, allow any VM SKU)

Use DeployIfNotExists policies to automatically remediate non-compliant resources rather than just flagging them. For instance, a policy can automatically enable Azure Defender on any new subscription, ensuring security coverage without requiring manual intervention.

RBAC Design

Role-Based Access Control in a landing zone follows the principle of least privilege:

Platform team: Owner or Contributor on platform subscriptions, Reader on workload subscriptions
Workload teams: Contributor on their own subscription, no access to other subscriptions
Security team: Security Reader across all subscriptions, Security Admin on security-related resources
Network team: Network Contributor on connectivity subscription, Reader on workload subscriptions

Use Azure AD groups rather than individual user assignments. This makes access reviews manageable and reduces the risk of orphaned permissions when employees change roles. Microsoft’s RBAC best practices guide provides additional detail on custom role definitions and scope management.

Networking Topology

Networking is where landing zone decisions have the most long-term impact. Changing your networking topology after workloads are deployed is painful, expensive, and risky.

Hub-Spoke vs Azure Virtual WAN

Azure supports two primary networking topologies for landing zones:

Feature	Hub-Spoke	Azure Virtual WAN
Complexity	Lower — you manage your own hub VNet	Higher — Microsoft manages the hub infrastructure
Cost	Pay for NVAs/firewalls you deploy	Pay for vWAN hub + routing units
Branch connectivity	Requires VPN gateway in hub	Built-in support for site-to-site, point-to-site, ExpressRoute
Scale	Manual spoke peering management	Automatic spoke-to-spoke routing
Best for	Single-region, fewer than 30 spokes	Multi-region, 30+ spokes, SD-WAN integration
Control	Full control over routing and NVAs	Less control, relies on Microsoft’s routing

Hub-spoke is the right choice for most mid-market organizations. You deploy a hub VNet containing shared services — Azure Firewall, VPN Gateway, Azure Bastion, DNS Private Resolver — and peer spoke VNets (one per workload subscription) to the hub. All inter-spoke and internet-bound traffic routes through the hub firewall.

Azure Virtual WAN is better suited for large enterprises with multiple regions, hundreds of spokes, or complex branch office connectivity requirements. It abstracts away much of the routing complexity but gives you less control over traffic flows.

Hub Network Design

A well-designed hub VNet includes:

Azure Firewall (or third-party NVA): Centralized traffic inspection and filtering for east-west (spoke-to-spoke) and north-south (internet-bound) traffic
VPN Gateway: Site-to-site VPN tunnels to on-premises data centers or branch offices
ExpressRoute Gateway: Private connectivity to on-premises for latency-sensitive or high-bandwidth workloads
Azure Bastion: Secure RDP/SSH access to VMs without exposing public IPs
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 IP addresses in the hub VNet is a common and painful problem. A /22 or /21 for the hub is reasonable even if your current needs seem smaller.

Spoke Network Design

Each spoke VNet is peered to the hub and typically contains:

Application subnets for VMs, containers, or App Services
Data subnets for databases and storage
A subnet for Private Endpoints (Azure Private Link)

Use User-Defined Routes (UDRs) to force all spoke traffic through the hub firewall. Without UDRs, spoke-to-spoke traffic bypasses the firewall entirely, creating a blind spot in your security posture.

For organizations running hybrid cloud strategies, hub networking is where on-premises and cloud networks intersect. Getting the IP address planning, DNS resolution, and routing right at this level prevents headaches across every spoke.

DNS Architecture

DNS in a landing zone requires careful planning, especially for Private Endpoints:

Central DNS management: Host Azure Private DNS Zones in the connectivity subscription and link them to all spoke VNets
On-premises resolution: Use Azure DNS Private Resolver with forwarding rules so on-premises clients can resolve Azure Private Endpoint FQDNs
Automation: Automate DNS record creation for Private Endpoints using Azure Policy (DeployIfNotExists) to prevent manual errors

Identity Integration

Identity is the control plane of your Azure landing zone. Every action — every deployment, every data access, every configuration change — goes through Azure Active Directory (now Microsoft Entra ID).

Azure AD Tenant Design

Most organizations should use a single Azure AD tenant. Multi-tenant designs add significant complexity to collaboration, conditional access, and cross-tenant resource access. A single tenant with proper management group and subscription boundaries provides adequate isolation for most scenarios.

Hybrid Identity with Azure AD Connect

For organizations with on-premises Active Directory, Azure AD Connect (or the newer Azure AD Connect Cloud Sync) synchronizes identities to Azure AD. Key decisions:

Password Hash Sync (PHS): Synchronizes a hash of the password hash to Azure AD. Simplest option, works even if on-premises AD is unavailable. Recommended as the primary method.
Pass-Through Authentication (PTA): Validates passwords against on-premises AD in real-time. Useful when regulatory requirements prohibit storing password hashes in the cloud, but adds a dependency on on-premises infrastructure.
Federation (ADFS): Routes authentication to on-premises federation servers. Adds complexity and infrastructure. Only recommended when you need features that PHS and PTA do not support (such as smart card authentication).

Conditional Access

Conditional access policies are your identity-layer firewall. In a landing zone context, baseline policies should include:

Require MFA for all users, with phishing-resistant methods (FIDO2 keys, Windows Hello) for administrators
Block legacy authentication protocols (IMAP, SMTP, POP3)
Require compliant devices for access to sensitive applications
Restrict access to Azure management plane (portal, CLI, PowerShell) to named locations or compliant devices

Privileged Identity Management (PIM)

Azure AD Privileged Identity Management provides just-in-time access for administrative roles. Instead of permanently assigning Owner or Contributor, users activate the role when needed, with approval workflows and time-limited access windows. This significantly reduces the standing privilege footprint in your environment.

Platform Automation

A landing zone is only as good as the automation that maintains it. Manual configuration drifts over time, introduces inconsistencies, and does not scale.

Infrastructure as Code

Use Infrastructure as Code (IaC) for all landing zone components. Common choices:

Bicep: Azure-native, first-party support, lower learning curve for teams already familiar with ARM templates
Terraform: Multi-cloud support, large provider ecosystem, mature state management. A strong choice for organizations using DevOps infrastructure practices across multiple platforms.
Pulumi: General-purpose programming languages (Python, TypeScript, Go) instead of domain-specific languages

Store IaC in a Git repository with pull request workflows. Every change to the landing zone goes through code review, automated validation, and approval before deployment.

CI/CD for Platform Changes

Platform changes — policy updates, networking modifications, new subscription provisioning — should deploy through the same CI/CD pipelines that application teams use. This means:

# Example: Deploying landing zone policies with Azure CLI and Bicep
az deployment mg create \
  --management-group-id "LandingZones" \
  --location "eastus" \
  --template-file ./policies/main.bicep \
  --parameters ./policies/parameters/production.json

Use separate pipelines for platform (networking, policies, identity) and workload (application infrastructure) deployments. Platform pipelines typically require higher-privilege service principals and additional approval gates.

Monitoring and Observability

A landing zone must include centralized monitoring from day one:

Log Analytics workspace: A single workspace (or a small number of regional workspaces) in the management subscription that collects logs from all subscriptions
Azure Monitor: Metric collection, alerting, and diagnostic settings for all Azure resources
Microsoft Defender for Cloud: Security posture management and threat detection across all subscriptions
Azure Service Health: Alerts for Azure platform issues that affect your resources

For troubleshooting guidance on monitoring configuration, see our guide on diagnosing missing metrics in Azure Monitor.

Common Pitfalls

Even well-planned landing zones can go wrong. These are the mistakes we see most often:

Over-Engineering the Initial Design

The landing zone does not need to account for every possible future scenario on day one. Start with the CAF reference architecture, customize it for your immediate needs, and iterate. Organizations that spend six months designing the “perfect” landing zone often find that their requirements have changed by the time they finish.

Ignoring Network Address Planning

Running out of IP address space is one of the most disruptive problems in a cloud environment. Plan your address space for 3-5 years of growth, even if it feels like over-allocation today. Use a centralized IPAM (IP Address Management) process to prevent overlaps between on-premises, hub, and spoke networks.

Treating Landing Zones as a One-Time Project

A landing zone is a living platform. It needs ongoing investment — policy updates as new Azure services launch, networking changes as the organization grows, and RBAC reviews as teams change. Assign a dedicated platform team (even if it is a small one) to own and evolve the landing zone.

Skipping the Sandbox

Without a sandbox environment, teams will experiment in production or non-production subscriptions, creating shadow IT and compliance risks. A sandbox with no connectivity to the corporate network is cheap insurance against this pattern.

Landing Zone Implementation Checklist

Use this checklist to validate your landing zone before deploying workloads:

Management group hierarchy:

Root management group configured with baseline policies
Platform, Landing Zones, Sandbox, and Decommissioned groups created
Production and Non-Production groups under Landing Zones

Identity:

Azure AD Connect configured with Password Hash Sync
Conditional access baseline policies deployed
PIM configured for administrative roles
Break-glass accounts created and secured

Networking:

Hub VNet deployed with adequate address space
Azure Firewall or NVA deployed and configured
VPN or ExpressRoute gateway connected to on-premises
DNS Private Resolver configured for hybrid resolution
Private DNS Zones created for common Azure services

Governance:

Azure Policies assigned at management group level
Tagging policy enforced (CostCenter, Owner, Environment)
Allowed regions policy configured
Resource locks on critical platform resources

Monitoring:

Central Log Analytics workspace deployed
Diagnostic settings policy configured
Microsoft Defender for Cloud enabled on all subscriptions
Alert rules configured for critical platform events

Automation:

Landing zone IaC stored in Git with PR workflows
Subscription vending pipeline operational
CI/CD pipeline for policy and networking changes

Frequently Asked Questions

How long does it take to deploy an Azure landing zone?

A basic landing zone using the Azure Landing Zone accelerator can be deployed in a few days. A fully customized enterprise landing zone with CI/CD automation, custom policies, and hybrid networking typically takes 4-8 weeks. The time investment pays for itself by eliminating months of remediation later.

Can I retrofit a landing zone onto existing Azure subscriptions?

Yes, but it requires careful planning. You can reorganize existing subscriptions into a management group hierarchy, apply policies incrementally (starting with audit-only mode), and peer existing VNets to a new hub network. This is more complex than a greenfield deployment but avoidable only if you are starting from scratch.

Should I use one subscription per workload or per environment?

The CAF recommends one subscription per workload per environment (for example, separate subscriptions for App A Production and App A Non-Production). This provides clean blast radius isolation, independent RBAC, and clear cost attribution. For smaller organizations, one subscription per environment (shared across workloads) is a reasonable starting point.

What is the difference between Azure Landing Zone and Azure Blueprint?

Azure Blueprints was a service for packaging policies, RBAC, and ARM templates into reusable deployment artifacts. Microsoft has deprecated Blueprints in favor of more flexible tools like Bicep, Terraform, and the Azure Deployment Environments service. New landing zone implementations should use IaC tools rather than Blueprints.

How do landing zones work with multi-region deployments?

For multi-region deployments, you typically deploy a hub VNet in each region and peer them together (or use Azure Virtual WAN with regional hubs). Spoke VNets peer to their regional hub. This keeps traffic local within a region for performance while providing cross-region connectivity for disaster recovery and global services.

Do small businesses need an Azure landing zone?

Even small businesses benefit from landing zone principles, though the implementation can be simpler. At minimum, establish a management group hierarchy, a basic set of Azure Policies (enforce tagging, restrict regions, deny public IPs), and centralized logging. You do not need every component of the enterprise reference architecture — start small and grow into it.

Next Steps

Building a well-architected Azure landing zone does not have to be overwhelming. Exodata’s cloud engineering team can help you design and deploy a landing zone that fits your organization’s size, regulatory requirements, and growth trajectory. Talk to an engineer today — no sales pitch, just answers.

← Back to Blog