🏛️ What Is a Landing Zone?
A landing zone is the foundational Azure environment — subscriptions, networking, identity, governance, and security controls — into which workloads are deployed. Getting the landing zone right before any workloads land is the single highest-leverage architectural decision you can make for a hybrid deployment.
For organizations with existing on-premises infrastructure, the landing zone must do more than define cloud boundaries. It must seamlessly extend governance, identity, and network controls to on-premises infrastructure without creating duplicate management overhead or inconsistent policy enforcement.
🔗 Hybrid-Specific Considerations
Pure cloud landing zones are well-documented in the Microsoft Cloud Adoption Framework. Hybrid landing zones have additional requirements that the standard CAF guidance under-emphasizes:
- Extended network topology: On-premises datacenters must be treated as additional "regions" in your hub-spoke design, connected via ExpressRoute or site-to-site VPN with defined routing policies
- Arc-projected resources: Non-Azure servers, Kubernetes clusters, and databases managed through Azure Arc appear as resources in Azure — your subscription hierarchy and RBAC model must account for them
- Dual identity plane: Most EMEA enterprises maintain Active Directory on-premises alongside Microsoft Entra ID. Your landing zone design must accommodate both and define clear rules for which identity source is authoritative
- Compliance boundary alignment: GDPR and country-specific data residency requirements may require workload placement rules that span on-premises and cloud — Azure Policy must enforce these across both planes
🌐 Connectivity Architecture
The connectivity layer is where hybrid landing zones most commonly fail in practice. The three common patterns, with honest assessments:
| Pattern | Connectivity | Bandwidth | SLA | Best For |
|---|---|---|---|---|
| VPN Gateway (active/active) | IPSec over Internet | Up to 10 Gbps | 99.95% | Dev/test, SMB, backup workloads |
| ExpressRoute (standard) | Private MPLS circuit | 50 Mbps–10 Gbps | 99.95% | Production workloads, latency-sensitive apps |
| ExpressRoute + VPN failover | Private + encrypted backup | Circuit speed | 99.99%+ | Mission-critical hybrid workloads |
EMEA field reality: ExpressRoute availability and pricing vary significantly across EMEA. In markets where ExpressRoute is unavailable or prohibitively expensive (parts of Africa, the Middle East), a properly designed active/active VPN with SD-WAN overlay can be an acceptable alternative for non-mission-critical workloads.
🔐 Identity & Access
The hybrid identity model in 2025 revolves around Microsoft Entra ID as the authoritative identity source, with Active Directory serving as a compatibility layer for legacy applications that cannot be modernized. Entra Connect Sync (formerly Azure AD Connect) bridges the two directories.
# Check sync status
Get-ADSyncConnectorStatistics |
Select-Object ConnectorName, NumberOfImports, NumberOfExports
# Check for sync errors
Get-ADSyncCSObject -ConnectorName "yourdomain.com" |
Where-Object {$_.SyncRule -ne $null -and $_.SyncError -ne $null} |
Select-Object DistinguishedName, SyncError |
Format-List📋 Governance & Policy
Azure Policy can enforce governance across Azure resources, Arc-enabled servers, and Arc-enabled Kubernetes clusters from a single policy definition. A well-designed hybrid landing zone uses initiative definitions (policy sets) that apply identically to cloud and on-premises resources.
Recommended policy initiatives for hybrid environments:
- Security baseline: CIS benchmarks enforced via Guest Configuration policy on all servers (cloud and Arc-enabled)
- Tagging enforcement: Require cost center, environment, and owner tags on all resources including Arc-projected resources
- Update compliance: Enforce a maximum patch age on all servers using Azure Update Manager
- Defender for Cloud: Require Defender plan assignment on all subscriptions covering both cloud and Arc resources
⚙️ Common Hybrid Patterns
Pattern 1: Azure Local as an Extension of Azure
Treat Azure Local clusters as additional "availability zones" in a multi-region architecture. Workloads can fail over between on-premises and Azure using Azure Site Recovery, with consistent networking through ExpressRoute and consistent identity through Entra ID.
Pattern 2: Cloud-Burst Architecture
Run steady-state workloads on-premises for predictable cost, burst to Azure for peak demand. This requires carefully designed network address spaces that don't overlap between on-premises, hub VNet, and spoke VNets, with BGP routing that allows seamless traffic flow during burst events.
📚 CAF Alignment
The Microsoft Cloud Adoption Framework's Ready methodology provides reference architectures for enterprise-scale landing zones. For hybrid deployments, extend the connectivity subscription with an additional on-premises connectivity resource group that contains:
- ExpressRoute circuit and gateway resources
- Azure Route Server (for dynamic BGP routing between on-premises and Azure)
- Azure Firewall Policy that covers both North-South (internet) and East-West (on-premises ↔ Azure) traffic
- Private DNS zones with auto-registration for both Azure resources and on-premises registered names