The Azure landing zone is the governance foundation for all enterprise Azure deployments. It establishes identity, networking, security, resource governance, and operations controls before any workloads arrive. EPC Group has deployed enterprise-scale landing zones for Fortune 500, healthcare, financial services, and federal government clients. Our Bicep/Terraform automation compresses 6–12 weeks of architect time into 4–7 days. HIPAA, FedRAMP, SOC 2, and CMMC compliant from day one.

Key Facts

Landing zones solve five problems at once: identity, networking, security, resource governance, and operations.
EPC Group deployment time: 4–7 days with Bicep/Terraform automation (vs. 6–12 weeks manually).
Microsoft Cloud Adoption Framework (CAF) Enterprise-scale is the recommended architecture for large organizations.
Compliance frameworks supported: HIPAA, FedRAMP, SOC 2, CMMC, PCI DSS, GDPR, NIST CSF.
Hub-spoke network topology with Azure Firewall and Private Link by default.
EPC Group: 29 years Microsoft consulting, 11,000+ enterprise engagements. Fortune 500, federal, and regulated-industry clients.

Azure Architecture

Azure Landing Zone Architecture: The Definitive Enterprise Deployment Guide for 2026

By Errin O'Connor

18 min read

February 2026

Azure Landing Zone Architecture Guide 2026

The Azure landing zone serves as the governance foundation for all enterprise Azure deployments. It sets up identity, networking, security, resource governance, and operations controls before any workloads are added.

EPC Group has implemented enterprise-scale landing zones for:

Fortune 500 companies
Healthcare organizations
Financial services
Federal government clients

Our Bicep/Terraform automation reduces architect time from 6–12 weeks to just 4–7 days. We ensure compliance with HIPAA, FedRAMP, SOC 2, and CMMC from day one.

Key facts

Landing zones solve five problems at once: identity, networking, security, resource governance, and operations.
EPC Group deployment time: 4–7 days with Bicep/Terraform automation (vs. 6–12 weeks manually).
Microsoft Cloud Adoption Framework (CAF) Enterprise-scale is the recommended architecture for large organizations.
Compliance frameworks supported: HIPAA, FedRAMP, SOC 2, CMMC, PCI DSS, GDPR, NIST CSF.
Hub-spoke network topology with Azure Firewall and Private Link by default.
EPC Group: 29 years Microsoft consulting, 11,000+ enterprise engagements. Fortune 500, federal, and regulated-industry clients.

What Problem Does a Landing Zone Solve?

Without a landing zone, enterprises end up with Azure sprawl — subscriptions without governance, security configurations that drift, and costs that exceed projections by 200–400%.

The landing zone solves five problems simultaneously:

Identity governance — Who can access what resources, under what conditions, from what devices.
Network topology — How resources communicate with each other and with on-premises systems.
Security baseline — What controls are enforced by default across every subscription and resource.
Resource governance — What can be deployed, in which regions, with what mandatory configuration.
Operational management — How you monitor, patch, back up, and respond to incidents across hundreds of subscriptions.

Enterprise-Scale Landing Zone Components

The enterprise-scale landing zone deploys these components in one automated run:

Management groups — Hierarchical container for subscriptions. Governance policies apply at the management group level and inherit down.
Hub VNet — Shared networking: Azure Firewall, VPN Gateway, ExpressRoute Gateway, Private DNS zones, and Azure Bastion.
Spoke VNets — Per-workload or per-team VNets, peered to the hub. All egress routed through hub Firewall.
Azure Policy initiative assignments — HIPAA, FedRAMP, SOC 2, and NIST policy sets assigned to management groups at deployment.
Azure Monitor and Log Analytics workspace — Centralized logging for all subscriptions. Required for compliance audit trails.
Microsoft Sentinel — SIEM for threat detection and incident response. Wired into Log Analytics from day one.
Microsoft Defender for Cloud — Continuous compliance scoring against regulatory frameworks.

HIPAA Landing Zone Controls

EPC Group enforces HIPAA controls through Azure Policy assignments on the landing zone. Key controls required for HIPAA compliance:

Encryption at rest and in transit — enforced on all data stores that may touch PHI.
Access logging — required for all resources with PHI access, retained for 6 years.
Network isolation — Private endpoints and NSG restrictions enforced. No PHI over public internet.
Azure Key Vault — Required for encryption key management with HSM backing.
Incident response — Documented plan stored in Azure DevOps with tested failover procedures.

FedRAMP Landing Zone Design

Federal and defense clients require a modified landing zone with additional controls. EPC Group implements FedRAMP Moderate/High and IL4/IL5 configurations:

Azure Government or GCC High tenants — required for IL4/IL5 data classification.
CMMC Level 2/3 management group — separate from non-CMMC workloads.
Deny public internet for CUI — policy enforces private connectivity for all Controlled Unclassified Information.
PAW (Privileged Access Workstation) requirement — Conditional Access forces administrative access only from compliant PAW devices.
Continuous monitoring — Azure Sentinel analytics rules map to NIST SP 800-53 controls.

PCI DSS Landing Zone Design

PCI workloads run in dedicated subscriptions under a PCI-specific management group. Additional policy controls for the cardholder data environment (CDE):

Deny all public internet access in CDE subscriptions.
Enforce WAF (Web Application Firewall) on all ingress points.
Require Azure SQL with TDE and Always Encrypted for cardholder data storage.
Mandate vulnerability scanning with Qualys or Defender for Cloud on all CDE systems.
Require file integrity monitoring on all CDE VMs.
Restrict administrative access to PAW devices via Conditional Access.

Cost Management Architecture

Landing zone cost governance uses seven controls. EPC Group configures all seven at deployment time:

Tagging governance — Cost-center, owner, and environment tags mandatory on all resources.
Budget alerts — Subscription and resource group budgets with alerts at 50%, 80%, and 100%.
Azure Advisor weekly reviews — Rightsizing, Reserved Instance candidates, and idle resources.
Management group cost scope — Aggregate costs across all landing zones from a single management group view.
Reserved Instances and Savings Plans — 1-year or 3-year commits for predictable workloads. Target 30–60% savings.
Auto-shutdown policies — Dev/test subscriptions shut down outside business hours automatically.
Deny expensive SKUs — Azure Policy blocks high-cost VM sizes in non-production subscriptions.

EPC Group Landing Zone Delivery

Errin O'Connor, EPC Group founder and Chief AI Architect, has led Azure landing zone deployments for Fortune 500 organizations across healthcare, financial services, and federal government for 29 years. His view:

Organizations that invest in the landing zone foundation before deploying workloads complete migrations faster, pass audits on first attempt, and spend 40–60% less on operational remediation than those that deploy first and govern later.

EPC Group's landing zone engagement process:

Week 1–2: Discovery — Document current Azure footprint, workload requirements, and compliance obligations.
Week 2–3: Architecture design — Design management group hierarchy, VNet topology, and Azure Policy assignments.
Week 3–4: Deployment — Run Bicep/Terraform automation to deploy the full landing zone.
Week 4–6: Validation — Compliance testing, application team onboarding, and governance documentation.

Frequently asked questions

What is an Azure landing zone?

An Azure landing zone is a pre-configured Azure environment with governance, networking, security, and identity controls in place before any application workloads are deployed. It solves five problems at once: identity, networking, security, resource governance, and operational management.

How long does an Azure landing zone take to deploy?

EPC Group's Bicep/Terraform automation reduces deployment time to just 4–7 days. In contrast, without automation, it can take 6–12 weeks. This significant difference comes from our pre-built Infrastructure as Code (IaC) modules.

These modules incorporate:

29 years of governance knowledge
Compliance expertise
Automated deployment scripts

What is the Microsoft Cloud Adoption Framework?

The Microsoft Cloud Adoption Framework (CAF) is Microsoft's guidance for cloud strategy, planning, readiness, and governance. The Enterprise-scale landing zone is the CAF-recommended architecture for organizations deploying Azure at enterprise scale.

Does an Azure landing zone support FedRAMP?

Yes, EPC Group creates FedRAMP Moderate/High and IL4/IL5 landing zones in Azure Government and GCC High tenants. Our services include:

CMMC Level 2/3 management groups
PAW-enforced administrative access
NIST SP 800-53 Sentinel analytics rules

How much does an Azure landing zone cost to implement?

EPC Group landing zone engagements are offered at a fixed fee. A standard enterprise landing zone, which includes a single region and one compliance framework, starts at $25,000.

For multi-region or multi-framework engagements, such as those involving FedRAMP, HIPAA, and CMMC, costs typically range from $75,000 to $150,000.

What happens after the landing zone is deployed?

Application teams onboard their workloads into spoke subscriptions. EPC Group offers the following support:

Onboarding documentation
Azure Policy exemption workflows
30 days of post-deployment support

Optional managed services are also available for ongoing governance monitoring.

Build your enterprise landing zone

Talk to an EPC Group Azure architect about landing zone design, compliance, and automation. Call (888) 381-9725 or request a 30-minute discovery call.

What Is an Azure Landing Zone?

An Azure landing zone is a scalable, multi-subscription Azure environment built on the Cloud Adoption Framework. It is not just one resource or template. Instead, it includes a complete set of Azure platform services, configurations, policies, and access controls.

This full set forms the operational backbone for every workload your organization deploys to Azure.

The CAF defines two implementation scales. The start small and expand approach uses a minimal landing zone. It iterates as requirements arise. This method is suitable for organizations with fewer than 10 subscriptions and a single compliance domain.

The enterprise-scale approach deploys the complete reference architecture from day one. It includes:

Full management group hierarchy
Centralized networking
Comprehensive policy baselines

This guide focuses on the enterprise-scale approach because organizations with regulated workloads, hybrid connectivity requirements, or more than 20 planned Azure subscriptions will inevitably need the full architecture and it is far less expensive to build it correctly upfront than to refactor later.

The Azure landing zone addresses five key issues at once:

Identity governance: This defines who can access what and under what conditions.
Network topology: This explains how resources communicate with each other and with on-premises systems.
Security baseline: This outlines the controls that are enforced by default.
Resource governance: This specifies what can be deployed, where, and with what configuration.
Operational management: This covers how to monitor, patch, back up, and respond to incidents across hundreds of subscriptions.

Management Group Hierarchy and Subscription Organization

The management group hierarchy is crucial for your Azure landing zone. Each Azure AD tenant has one Tenant Root Group at the top.

Below this group, you create an intermediate root management group. This group should be named after your organization. It serves as the anchor for:

All policy assignments
RBAC definitions

The intermediate root is necessary because the Tenant Root Group needs elevated permissions for modifications. It should be treated as unchangeable after the initial setup.

Below the intermediate root, the CAF prescribes two primary branches: Platform and Landing Zones. The Platform branch contains three subscriptions that host shared infrastructure:

Identity subscription — hosts Active Directory Domain Controllers (if extending on-premises AD), Azure AD Connect servers, and any identity-related resources that must persist regardless of workload changes.
Management subscription — hosts the central Log Analytics workspace, Azure Automation accounts, Microsoft Defender for Cloud configuration, Azure Monitor resources, and any centralized management tooling.
Connectivity subscription — hosts the hub virtual network, Azure Firewall (or approved third-party NVA), VPN Gateway or ExpressRoute Gateway, Azure DNS Private Zones, and Azure Bastion for secure administrative access.

The Landing Zones branch has two main divisions: Corp and Online. The Corp division is for internal workloads connected to the corporate network. The Online division is for internet-facing workloads with public endpoints.

Each workload team gets one or more subscriptions under the right management group. The hierarchy also includes two additional groups:

Sandbox: This group is for experimentation, with no corporate connectivity and relaxed policies.
Decommissioned: Subscriptions are moved here before deletion. This group has deny-all policies that prevent new deployments.

Limit the hierarchy to a maximum of four levels. Going deeper increases the complexity of policy evaluation and makes troubleshooting harder. If your organization has different business units that need unique governance, create management groups at the Landing Zones level. For example, use Landing Zones > Business Unit A > Corp / Online instead of adding unnecessary depth.

Recommended Management Group Hierarchy

Tenant Root Group

|-- Organization Root (org-wide policies)

|-- Platform

|-- Identity (AD DS, Entra ID Connect)

|-- Management (Log Analytics, Defender, Automation)

|-- Connectivity (Hub VNet, Firewall, Gateways)

|-- Landing Zones

|-- Corp (internal workloads, private connectivity)

|-- Online (internet-facing workloads)

|-- Sandbox (experimentation, no hybrid connectivity)

|-- Decommissioned (deny-all, pre-deletion)

Azure Policy Governance at Scale

Azure Policy acts as the enforcement engine for your landing zone. These policies are JSON-based rules that assess resource properties during creation and ongoing compliance checks.

When assigned at a management group, policies automatically apply to every subscription and resource group below it. This ensures consistent governance without the need for manual intervention.

The landing zone policy architecture operates in three tiers.

At the organization root, assign broad baseline policies: enforce diagnostic settings to the central Log Analytics workspace, require mandatory tags (CostCenter, Environment, Owner, Application), deny deployment to unapproved Azure regions, apply the Azure Security Benchmark initiative, and enforce encryption at rest for all storage accounts and databases.

At the Platform level, assign network-specific policies: deny public IP creation, enforce network security group attachment, require private endpoints for PaaS services (Azure SQL, Storage, Key Vault), and restrict virtual network gateway configurations.

At the Landing Zones level, assign workload-tier policies: allowed VM SKU sizes for cost control, required Azure Key Vault for secrets management, compliance initiatives (HIPAA HITRUST, PCI-DSS v4, or FedRAMP Moderate/High depending on the workload classification), and allowed resource types per management group.

Policy effects determine the outcome when a resource breaks a rule. There are several options for handling these violations:

Audit: Logs the violation without blocking deployment. This is useful during the initial rollout.
Deny: Completely blocks the creation or modification of the resource.
DeployIfNotExists: Automatically fixes drift by deploying a diagnostic setting to every new resource.
Modify: Adds or changes resource tags or properties during deployment.

The best practice is to deploy all policies in audit mode first. Review compliance results for 7 to 14 days, fix any false positives, and then switch to deny or deployIfNotExists for production enforcement.

Organizations that need custom policies beyond the built-in library can use Azure Policy. It supports custom definitions written in JSON with Bicep or Terraform wrappers for Infrastructure as Code (IaC) management.

EPC Group offers a library of over 80 custom policies for enterprise clients. These policies cover:

Naming conventions
Network segmentation rules
Data residency restrictions
Cost guardrails

These custom policies enhance the built-in Azure Security Benchmark.

Network Topology: Hub-Spoke vs. Virtual WAN

Networking is the most consequential design decision in your landing zone because it is the hardest to change after workloads are deployed. The CAF supports two reference topologies, and the choice depends on your organization's scale, hybrid connectivity requirements, and operational model.

Hub-Spoke Topology

The hub-spoke model features a central virtual network known as the hub. This hub provides shared network services, including:

Azure Firewall for traffic inspection
VPN Gateway or ExpressRoute Gateway for hybrid connectivity
Azure Bastion for secure RDP/SSH access
Azure DNS Private Zones for name resolution

Workload virtual networks, referred to as spokes, connect to the hub. They route traffic through the firewall using user-defined routes (UDRs).

The hub-spoke model provides complete control over firewall sizing, routing logic, and network virtual appliance selection. You can:

Deploy Azure Firewall Premium for IDPS and TLS inspection.
Use a third-party NVA like Palo Alto or Fortinet.

All spoke-to-spoke communication passes through the hub firewall. This design enables centralized traffic inspection and logging. However, it also raises operational overhead.

You will need to manage:

All peering relationships
Route tables
Gateway failover manually

Hub-spoke is recommended for organizations with fewer than 50 spoke VNets, a single primary Azure region, existing investment in third-party network appliances, or teams with deep Azure networking expertise who want maximum control.

Virtual WAN Topology

Azure Virtual WAN is a Microsoft-managed networking service. It offers automated hub deployment and any-to-any transit routing. The service also integrates branch connectivity options, including SD-WAN, VPN, and ExpressRoute, along with built-in Azure Firewall Manager integration.

Virtual WAN hubs are deployed in each region. Spoke VNets connect to the nearest hub. Routing is automated between hubs, spokes, and on-premises branches through the Virtual WAN routing infrastructure.

Virtual WAN is highly effective for multi-region deployments. Inter-hub routing is automatic over the Microsoft backbone, which streamlines branch connectivity. This is especially beneficial for organizations with 20 or more offices.

Integrates with SD-WAN partners like VMware, Cisco, and Barracuda.
Offers reduced customization options.
Only allows deployment of Azure Firewall or select NVA partners in the hub.
Routing policies are managed through Virtual WAN constructs, not traditional UDRs.

For most enterprise clients, I recommend starting with hub-spoke in the primary region and evaluating Virtual WAN at the point where you need three or more regional hubs or automated SD-WAN integration. Both topologies support the same landing zone governance model; the difference is purely in the networking layer. See our cloud migration services for help designing the right network topology for your environment.

Identity and Access Management with Microsoft Entra ID

Identity is the control plane for your landing zone. Microsoft Entra ID (formerly Azure Active Directory) provides the authentication and authorization layer for all Azure resources, management tasks, and workload access decisions.

The landing zone identity architecture must cover four key areas:

Administrative access to Azure resources (RBAC)
Workload identity for applications and services
Hybrid identity for on-premises integration
Privileged access management for break-glass scenarios

RBAC (Role-Based Access Control) is assigned at different levels for various teams. Platform teams, including networking, security, and identity, receive built-in roles for their platform subscriptions.

Workload teams are assigned Contributor or custom roles for their landing zone subscriptions.

It is important to note that you should never assign the Owner role below the organization root management group. The Owner role allows modifications to RBAC assignments, which can lead to privilege escalation risks.

Entra ID Privileged Identity Management (PIM) is essential for enterprise landing zones. All privileged roles, including Global Administrator, Subscription Owner, and Security Administrator, should be eligible instead of permanently assigned. This setup requires just-in-time activation with Multi-Factor Authentication (MFA), approval workflows, and time-limited sessions.

PIM activation logs are integrated into the central Log Analytics workspace. This integration supports both auditing and alerting.

Conditional Access policies enforce context-aware access controls. They require MFA for all Azure management operations and block legacy authentication protocols. Additionally, they restrict access from non-compliant devices using Intune device compliance. These policies also enforce location-based restrictions for sensitive management operations and require phishing-resistant authentication (FIDO2, Windows Hello) for privileged accounts.

These policies apply to both the Azure portal and programmatic access through:

Azure CLI
PowerShell
REST APIs

For hybrid environments, deploy Azure AD Connect (or Entra Connect Cloud Sync) in the Identity subscription to ensure high availability. Enable password hash synchronization as a backup authentication method. This is important even if you use federation (AD FS) or pass-through authentication.

This setup guarantees that Azure access stays available during on-premises Active Directory outages.

Security Baseline and Threat Protection

The security baseline includes the controls that every resource in your landing zone automatically inherits. It starts with Microsoft Defender for Cloud enabled across all subscriptions. This includes the following plans:

Defender for Servers
Defender for Storage
Defender for SQL
Defender for Key Vault
Defender for Containers

Defender for Cloud offers continuous security assessment, vulnerability scanning, and threat detection. It also provides automatic alerts sent to the SOC team through Log Analytics and Azure Sentinel (Microsoft Sentinel).

Network security relies on a defense-in-depth strategy. Azure Firewall Premium examines all traffic types:

East-west (spoke-to-spoke)
North-south (internet-to-workload, workload-to-internet)

It uses IDPS signatures and performs TLS inspection for encrypted traffic.

Key components of network security include:

Network Security Groups (NSGs): These provide micro-segmentation at the subnet and NIC level. They feature deny-all default rules and explicit allow rules for each workload.
Azure DDoS Protection Standard: This is enabled on the hub VNet and all internet-facing spoke VNets.
Azure Private Link and Private Endpoints: These eliminate public internet exposure for PaaS services such as Storage, SQL, Key Vault, Event Hub, and Service Bus. This ensures that data never traverses the public internet.

Data protection includes several important measures. First, encryption at rest is essential. You can use either Microsoft-managed or customer-managed keys in Azure Key Vault.

Second, encryption in transit is enforced through Azure Policy. This policy mandates a minimum of HTTPS/TLS 1.2 for all endpoints.

Additionally, Azure Key Vault is set up for each subscription. It includes:

Soft delete and purge protection enabled
RBAC-based access control
Diagnostic logging to the central workspace

Importantly, secrets, certificates, and encryption keys never exist outside of Key Vault.

Microsoft Sentinel (Azure Sentinel) collects logs from various sources. These include landing zone resources, Entra ID sign-in and audit logs, Microsoft 365 Defender alerts, and on-premises sources through Azure Arc.

Custom analytics rules identify specific threats in the landing zone. These threats include:

Unauthorized management group changes
Policy exemption creation
Cross-subscription lateral movement
Anomalous resource deployments

Sentinel playbooks automate incident response. They can isolate compromised VMs, revoke credentials, or notify the security team through Teams and PagerDuty.

Cost Management and FinOps Integration

CFOs often tell me that uncontrolled cloud spending is their top concern after the first year in Azure. Landing zones address this issue by integrating cost governance into the architecture. This approach prevents the need to add it after budgets have been exceeded. The cost management strategy consists of five layers.

Tagging policy enforcement is essential for effective management. Azure Policy mandates specific tags for every resource group and resource. These tags include:

CostCenter
Environment (Dev, Test, Staging, Production)
Owner (email)
Application
BusinessUnit

Tags help generate cost allocation reports that link Azure spending to internal cost centers, business units, and projects. Without consistent tagging, it becomes impossible to attribute costs at scale.

Azure Budgets and alerts are set up for each subscription and management group. Alerts activate at:

50 percent (informational)
75 percent (warning)
90 percent (critical)

Action groups inform the subscription owner and the FinOps team. They can also trigger an Azure Function to shut down non-production resources if budgets are exceeded.

Azure Reservations and Savings Plans are bought at the enrollment or billing account level. This means discounts apply to all subscriptions in the landing zone.

For predictable workloads, such as:

Production VMs
Databases
App Service plans

One-year or three-year reservations can cut costs by 30 to 72 percent compared to pay-as-you-go pricing. Azure Savings Plans offer flexible compute discounts that automatically apply to any VM family, region, or OS combination.

Azure Advisor and cost anomaly detection continuously identify rightsizing opportunities (oversized VMs), idle resources (unattached disks, unused public IPs), and optimization recommendations. Microsoft Cost Management anomaly detection alerts the FinOps team when daily spending deviates significantly from historical patterns.

Policy-enforced cost guardrails prevent expensive mistakes before they happen. Azure Policy denies deployment of GPU VMs outside the ML workspace subscription, restricts premium SSD usage to production workloads, blocks creation of ExpressRoute circuits without FinOps approval, and enforces auto-shutdown schedules for non-production VMs.

Monitoring and Observability with Azure Monitor

Centralized monitoring is set up in the Management subscription. It collects telemetry from all resources in the landing zone. The system is based on a central Log Analytics workspace. This workspace gathers diagnostic logs, metrics, and activity logs from every subscription.

Azure Policy uses the DeployIfNotExists effect. This feature automatically configures diagnostic settings for each new resource. As a result, it removes the risk of unmonitored blind spots.

Azure Monitor offers four key pillars of observability:

Metrics: Provides real-time data on CPU, memory, disk IOPS, and network throughput. It includes configurable alerts and autoscale triggers.
Logs: Aggregates structured telemetry into Log Analytics. This allows for KQL-based querying across the entire estate.
Application Insights: Delivers APM (application performance monitoring) for web applications. It features distributed tracing, dependency mapping, and availability tests.
Azure Monitor Workbooks: Enables the creation of custom dashboards. These dashboards combine metrics, logs, and external data sources into visualizations suitable for executives.

For landing zone operations, configure alerts for platform-level events: management group changes, policy assignment modifications, RBAC role assignments at management group scope, hub firewall health degradation, ExpressRoute circuit down, and DNS resolution failures. Workload teams configure additional alerts for their application-specific metrics within their subscription scope.

Network monitoring uses Azure Network Watcher for connection troubleshooting, NSG flow logs for traffic analysis, and Traffic Analytics for visualization of network flows across the landing zone. Azure Monitor Network Insights provides a single-pane view of VNet health, peering status, gateway connectivity, and firewall throughput across all subscriptions.

CI/CD Pipelines with Azure DevOps and GitHub Actions

The landing zone is built using infrastructure as code. Each management group, policy assignment, RBAC definition, virtual network, firewall rule, and diagnostic setting is defined in Bicep modules or Terraform configurations. These are stored in a Git repository.

No changes are made through the Azure portal in production. The portal is read-only for platform operations.

The CI/CD pipeline architecture follows a two-stage approach. The validation stage occurs with every pull request. It includes:

Bicep/Terraform linting
What-if/plan previews that show which resources will be created, modified, or destroyed
Policy compliance pre-checks
Cost estimation using Infracost or Azure Pricing Calculator API calls

The deployment stage takes place when merging to the main branch. This stage involves:

Sequential deployment from management groups to policies
Networking
Subscription vending

Approval gates are included between stages for production environments.

Service principals used by CI/CD pipelines authenticate with federated credentials (workload identity federation) instead of client secrets. This approach reduces the risk of secret rotation.

Pipeline service principals are granted minimal RBAC scopes:

The platform pipeline service principal has Contributor access on the Platform management group.
Workload pipeline service principals have Contributor access only on their specific subscription.

Drift detection is crucial for keeping landing zone integrity. A scheduled pipeline runs daily. It checks the actual Azure state against the desired state defined in code. Any manual changes made outside the pipeline are flagged. These changes can also be automatically fixed if necessary.

This process helps prevent configuration drift, which can accumulate over time. Such drift may lead to compliance failures during audits.

Multi-Region Resilience and Disaster Recovery

Enterprise landing zones must consider regional failures from the start. Azure regions are paired (e.g., East US / West US, North Europe / West Europe). This pairing ensures data residency and prioritized recovery during outages.

Your landing zone design should:

Designate a primary region
Designate a secondary region
Deploy platform infrastructure in both regions

In the hub-spoke model, deploy a hub VNet in each region. Use VNet peering between hubs for cross-region transit. Each hub includes Azure Firewall instances that have synchronized rule sets.

These rule sets are managed through Azure Firewall Policy. This policy consists of a global policy along with regional overrides.

ExpressRoute circuits in each region connect to various peering locations. This design provides geographic redundancy. In the Virtual WAN model, you should deploy a hub in each region. Virtual WAN automatically handles inter-hub routing across the Microsoft global backbone.

For workloads that need multi-region active-active or active-passive deployment, use Azure Traffic Manager or Azure Front Door for global load balancing. Azure Site Recovery offers VM replication and automated failover for IaaS workloads.

PaaS services, such as Azure SQL, utilize geo-replication or auto-failover groups.
Azure Cosmos DB supports multi-region writes for globally distributed applications.

The Management subscription resources include Log Analytics, Defender for Cloud, and Sentinel. These are deployed in the primary region and feature cross-region data export for resilience.

Global resources such as Azure Policy assignments and management group hierarchy can withstand regional failures. It is essential to conduct quarterly disaster recovery drills. These drills should test:

Workload failover
DNS cutover
Operational runbook execution

Hybrid Connectivity: ExpressRoute, VPN, and Azure Arc

Most enterprises maintain on-premises data centers during and after cloud migration. The landing zone Connectivity subscription provides the bridge between Azure and on-premises infrastructure through three connectivity options that can be combined based on workload requirements.

Azure ExpressRoute offers private and dedicated connections between on-premises networks and Azure. This is done through a connectivity provider such as Equinix, Megaport, or AT&T. ExpressRoute circuits provide:

Predictable latency
Higher bandwidth (up to 100 Gbps with ExpressRoute Direct)
SLA-backed availability

For enterprise landing zones, deploy ExpressRoute with:

Microsoft peering for Microsoft 365 and Azure public services
Private peering for VNet connectivity

Additionally, use ExpressRoute Global Reach to connect on-premises sites in different locations through the Microsoft backbone, avoiding hairpinning through Azure.

Site-to-site VPN offers encrypted connectivity over the public internet at a lower cost than ExpressRoute. It supports BGP routing for dynamic route advertisement and allows for active-active configurations, ensuring high availability.

VPN is ideal for:

Branch offices
Disaster recovery connectivity
Backup paths when ExpressRoute fails

You can configure both ExpressRoute and VPN in the same hub for automatic failover.

Azure Arc allows you to manage on-premises and multi-cloud resources using Azure. Arc-enabled servers appear as Azure resources. They gain advantages such as:

Azure Policy compliance
Microsoft Defender for Cloud monitoring
Azure Monitor agent telemetry

Arc-enabled Kubernetes clusters can run Azure services, including:

Azure App Service
Azure Functions
Azure API Management

This capability is available on-premises or in other clouds. For organizations using a hybrid landing zone strategy, Azure Arc offers unified governance across Azure, on-premises, AWS, and GCP from a single control plane.

Compliance Blueprints: HIPAA, PCI-DSS, and FedRAMP

Regulated enterprises need to align their landing zone controls with specific compliance frameworks. Azure offers built-in regulatory compliance initiatives in Defender for Cloud. These initiatives assess your environment against:

HIPAA
HITRUST
PCI-DSS v4
NIST 800-53 (FedRAMP)
CIS Benchmarks
Dozens of other standards

The landing zone architecture speeds up compliance by enforcing controls at the infrastructure layer. This approach reduces the need for workload teams to implement controls individually.

HIPAA (Healthcare)

Healthcare organizations must execute a Microsoft BAA (Business Associate Agreement) before storing PHI in Azure. The landing zone enforces HIPAA controls through Azure Policy. These controls include:

Encryption at rest and in transit for all data stores
Access logging for all resources handling PHI
Network isolation via private endpoints and NSG restrictions
Azure Key Vault for encryption key management with HSM backing
Retention policies that meet the six-year HIPAA retention requirement

Additionally, Microsoft Defender for Cloud HIPAA HITRUST assessment offers a compliance dashboard. This dashboard maps controls to HIPAA requirements and provides remediation guidance for any gaps.

PCI-DSS (Financial Services)

PCI-DSS v4.0 requires network segmentation to isolate the cardholder data environment (CDE) from other workloads. In the landing zone, PCI workloads operate in dedicated subscriptions under a PCI-specific management group. This setup includes several important policies:

Deny all public internet access
Enforce WAF on all ingress points
Require Azure SQL with TDE and Always Encrypted for cardholder data
Enable vulnerability scanning with Qualys or Defender for Cloud
Mandate file integrity monitoring
Restrict administrative access to dedicated PAW (Privileged Access Workstation) devices

FedRAMP (Government)

FedRAMP High and Moderate baselines align with NIST 800-53 controls. The landing zone operates in Azure Government regions, including:

US Gov Virginia
US Gov Texas
US Gov Arizona

These regions are physically separate from commercial Azure and managed by screened US personnel. FedRAMP landing zones enforce:

FIPS 140-2 validated encryption modules
STIG-hardened VM images
Centralized logging with 90-day online retention and one-year archive
Continuous monitoring (ConMon) reporting through Defender for Cloud
PIV/CAC authentication for all administrative access

The landing zone IaC templates encode NIST 800-53 controls so that new subscriptions automatically inherit the full FedRAMP control baseline. EPC Group has deployed FedRAMP-aligned consulting expertise landing zones for federal agencies managing IL4 and IL5 workloads in Azure Government.

Real Enterprise Migration Scenarios

Theory matters, but enterprises learn from seeing how landing zones work in practice. These scenarios reflect patterns from real-world engagements (with details generalized for confidentiality).

Scenario 1: Healthcare System with 300+ Applications

A Fortune 500 healthcare system operates 12 hospitals and manages 300 applications across two on-premises data centers. They needed to migrate 60 percent of their workloads to Azure while ensuring HIPAA compliance and uninterrupted patient care.

The solution involved deploying a landing zone with a hub-spoke topology. This included:

ExpressRoute in two Azure regions: East US 2 and Central US
Encrypted cross-hub peering

PHI workloads were handled in dedicated Corp subscriptions that followed HIPAA HITRUST policy initiatives. Non-PHI workloads, such as HR, finance, and public websites, were managed in separate Online subscriptions with standard security baselines.

The management group structure kept clinical systems separate from administrative systems. This led to different RBAC assignments for clinical IT and corporate IT teams.

Key security measures included:

Azure Policy: Denied any storage account creation without encryption and customer-managed keys.
Microsoft Sentinel: Provided SIEM with custom detection rules for unauthorized PHI access patterns.

The migration took nine months and occurred in four waves, with zero HIPAA compliance incidents.

Scenario 2: Financial Services Firm Restructuring 150 Subscriptions

A global financial services firm created 150 Azure subscriptions over five years. These subscriptions were set up randomly by various departments. Each subscription had its own networking and inconsistent security settings. Additionally, there was no centralized monitoring.

The annual Azure spending exceeded $8 million, with no reliable cost attribution by business unit. The landing zone project addressed these issues by:

Reorganizing all subscriptions under a CAF-aligned management group hierarchy.
Consolidating eight independent hub VNets into a single hub-spoke topology with Azure Firewall Premium.
Deploying organization-wide policies for tagging, encryption, and allowed VM SKUs.

PCI-DSS workloads were moved to separate subscriptions within a PCI management group. This included dedicated firewall rules and network segmentation. Cost allocation tags were retroactively applied to all existing resources using Azure Policy remediation tasks.

Within six months, the firm achieved a 28 percent reduction in Azure spending, amounting to $2.2 million annually. This was accomplished through:

Rightsizing resources
Making reservation purchases based on usage data
Eliminating 40 percent of idle resources identified during consolidation

Scenario 3: Federal Agency Deploying FedRAMP High Landing Zone

A federal civilian agency needed a FedRAMP High authorized Azure environment. This was for a new application that processes personally identifiable information (PII) at the IL4 level.

The landing zone was fully deployed in Azure Government. It used US Gov Virginia as the primary site and US Gov Texas for disaster recovery (DR). Terraform modules encoded all 421 NIST 800-53 Rev 5 High controls as Azure Policy definitions and assignments.

The identity architecture used PIV/CAC authentication through Entra ID. It featured Conditional Access policies that mandated compliant government-issued devices.

ExpressRoute linked to the agency's TIC (Trusted Internet Connection) compliant network.

All VM images were DISA STIG hardened.
Continuous monitoring automated monthly POA&M (Plan of Action and Milestones) reporting.
Vulnerability scanning and configuration drift alerts were also implemented.

The JAB granted the P-ATO within 14 months from the project's start.

Azure Well-Architected Framework Alignment

The Azure Well-Architected Framework (WAF) provides five pillars that every landing zone must satisfy. Your landing zone is the vehicle for ensuring that every workload deployed on top of it inherits compliance with these pillars by default.

Reliability: Multi-region deployment, availability zone distribution for platform services (firewall, gateway, management tools), automated failover for hybrid connectivity, and SLA-backed Azure services.
Security: Defense-in-depth from Entra ID Conditional Access at the identity layer through Azure Firewall at the network layer to Defender for Cloud at the resource layer, with Sentinel providing SIEM/SOAR across all layers.
Cost Optimization: Tagging enforcement, budget alerts, reservation management, and policy-based cost guardrails preventing expensive resource deployment without approval.
Operational Excellence: Infrastructure as code for all platform resources, CI/CD pipelines with drift detection, centralized monitoring with Azure Monitor, and documented operational runbooks for incident response.
Performance Efficiency: Network topology optimized for latency-sensitive workloads, Azure Firewall sized for throughput requirements, ExpressRoute bandwidth matching workload needs, and allowed VM SKU policies ensuring right-sized compute.

EPC Group conducts Well-Architected Framework reviews as part of every landing zone engagement, producing a prioritized findings report with remediation guidance aligned to the five pillars. This review serves as both a validation checkpoint and a roadmap for continuous improvement. Learn more about our approach through our Azure cloud consulting services.

Frequently Asked Questions

Azure Landing Zone FAQs

What is an Azure landing zone and why does my enterprise need one?

An Azure landing zone is a pre-configured, governed Azure environment that follows Microsoft Cloud Adoption Framework (CAF) best practices. It provides the foundational architecture for identity, networking, security, governance, and management that every workload you deploy will inherit. Enterprises need landing zones because deploying workloads ad-hoc results in inconsistent security postures, uncontrolled spending, compliance gaps, and operational complexity. A well-architected landing zone ensures every subscription, resource group, and resource inherits a consistent baseline of policies, RBAC roles, network connectivity, and monitoring from day one. Organizations with 50 or more Azure subscriptions that lack a landing zone typically spend 30-40 percent more on cloud operations due to duplicated effort and security remediation.

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

A full enterprise-scale Azure landing zone deployment typically takes 8 to 16 weeks depending on complexity. Using the Azure Landing Zone Accelerator with Bicep or Terraform modules, a basic deployment with management group hierarchy, policies, and hub-spoke networking can be operational in 4 to 6 weeks. Adding custom compliance blueprints for HIPAA or FedRAMP, hybrid connectivity via ExpressRoute, and CI/CD pipelines extends the timeline to 10 to 16 weeks. Organizations migrating from unstructured Azure environments to a proper landing zone should plan an additional 4 to 8 weeks for subscription reorganization and workload migration. EPC Group has deployed landing zones for Fortune 500 clients with over 200 subscriptions in as few as 10 weeks using proven accelerator templates.

What is the difference between hub-spoke and Virtual WAN network topologies?

Hub-spoke uses a central Azure Virtual Network (hub) connected to workload VNets (spokes) via VNet peering. You deploy your own firewalls, VPN gateways, and route tables. It offers maximum control and works well for organizations with 1 to 50 spokes. Virtual WAN is a Microsoft-managed networking service that automates hub creation, branch connectivity, and any-to-any transit routing. It scales better for organizations with 50-plus spoke VNets, multiple on-premises branches, or SD-WAN integration. Hub-spoke costs less at small scale because you control NVA sizing, but Virtual WAN reduces operational overhead at scale. Most enterprises EPC Group works with start with hub-spoke for their first Azure region, then evaluate Virtual WAN when expanding to three or more regions or connecting more than 20 branch offices.

How does Azure Policy enforce governance in a landing zone?

Azure Policy enforces governance by automatically auditing, denying, or remediating non-compliant resource configurations. In a landing zone, policies are assigned at the management group level so they cascade to every subscription and resource beneath them. Common landing zone policies include denying public IP creation on VMs, requiring encryption at rest for storage accounts, enforcing specific VM SKUs to control costs, requiring diagnostic settings for all resources, and mandating tags for cost allocation. Policy initiatives (groups of related policies) such as the Azure Security Benchmark or CIS Microsoft Azure Foundations Benchmark provide pre-built compliance baselines. Custom policies can enforce organization-specific rules. DeployIfNotExists policies automatically remediate drift, for example ensuring every new storage account has HTTPS-only transport enabled without manual intervention.

Can Azure landing zones support HIPAA and FedRAMP compliance requirements?

Yes. Azure landing zones are specifically designed to support regulatory compliance at scale. For HIPAA, you assign the HIPAA HITRUST policy initiative at the management group level, restrict PHI workloads to compliant subscriptions, enforce encryption in transit and at rest, enable Azure Defender for all resources, configure diagnostic logging to a centralized Log Analytics workspace, and restrict data residency to approved regions. For FedRAMP, you deploy the landing zone in Azure Government regions, apply FedRAMP High or Moderate policy baselines (mapped to NIST 800-53 controls), implement continuous monitoring with Microsoft Defender for Cloud, and enforce IL4 or IL5 isolation for DoD workloads. Both frameworks require a Microsoft BAA for HIPAA or a PA-ATO for FedRAMP, proper identity governance via Entra ID Privileged Identity Management, and audit logging to tamper-proof storage. EPC Group has implemented HIPAA-compliant landing zones for health systems managing over 500,000 patient records.

What management group hierarchy should enterprises use?

Microsoft recommends a four-tier hierarchy starting with a single root management group, then platform and workload layers. The standard enterprise hierarchy is: Tenant Root Group at the top, then an intermediate root (e.g., Contoso) for organization-wide policies, then Platform (containing Identity, Management, and Connectivity subscriptions) and Landing Zones (containing Corp for internal workloads and Online for internet-facing workloads), plus Decommissioned and Sandbox groups for lifecycle management. Do not exceed four levels of depth because deeply nested hierarchies create policy evaluation complexity and troubleshooting difficulty. Assign broad security policies at the intermediate root level, network policies at the Platform level, and workload-specific policies at the Landing Zones level. This structure allows different teams to manage their workloads independently while inheriting consistent governance from parent management groups.

How do Azure landing zones handle cost management and optimization?

Landing zones implement cost governance through several layers. First, Azure Policy enforces allowed VM SKUs, prevents oversized resources, and requires cost allocation tags on all resources. Second, Azure Budgets are configured per subscription and management group with automated alerts at 50, 75, and 90 percent thresholds. Third, Microsoft Cost Management dashboards provide real-time visibility by business unit, project, and environment. Fourth, Azure Reservations and Savings Plans are applied at the enrollment or management group level to maximize discounts across all subscriptions. Fifth, Azure Advisor recommendations are aggregated across the landing zone to identify rightsizing and idle resource opportunities. Organizations that implement these cost controls during landing zone deployment typically reduce Azure spending by 20 to 35 percent compared to unmanaged environments. Custom Azure Policy rules can also prevent deployment of expensive resource types without explicit approval.

Should we use Bicep or Terraform for landing zone infrastructure as code?

Both are production-ready for landing zone deployment, but the choice depends on your organization. Bicep is the native Azure IaC language, has first-class support in the Azure Landing Zone Accelerator (ALZ-Bicep modules), requires no state file management, and integrates directly with Azure Resource Manager. It is the better choice for Azure-only organizations with developers already familiar with ARM templates. Terraform has the advantage of multi-cloud support (if you also manage AWS or GCP), a mature ecosystem of providers and modules (the Azure CAF Terraform module is well-maintained), and strong community adoption. It requires state file management (typically in Azure Storage with state locking) but provides a more declarative and plan-preview workflow that many DevOps teams prefer. EPC Group recommends Bicep for Azure-only enterprises seeking the fastest path to deployment, and Terraform for multi-cloud organizations or teams with existing Terraform expertise. Regardless of choice, all landing zone code should live in a Git repository with pull request reviews, automated testing, and CI/CD pipelines via Azure DevOps or GitHub Actions.

Ready to Build Your Enterprise Azure Landing Zone?

EPC Group has deployed Azure landing zones for Fortune 500 organizations in healthcare, financial services, and government. Our accelerator templates reduce deployment time by 50 percent while ensuring HIPAA, PCI-DSS, and FedRAMP compliance from day one.

Schedule a Landing Zone Assessment View Cloud Migration Services

About Errin O'Connor

Chief AI Architect & CEO, EPC Group | Microsoft Press Author (4 books) | 29 Years Enterprise Consulting

Errin O'Connor is the Chief AI Architect and CEO of EPC Group. He specializes in enterprise Azure architecture, cloud migrations, and compliance-driven infrastructure design.

With 29 years of experience in the Microsoft ecosystem, Errin is the author of four Microsoft Press bestsellers. These books cover:

Power BI
SharePoint
Azure
Large-scale migrations

Errin has led Azure landing zone deployments for Fortune 500 clients in sectors such as healthcare, financial services, and federal government. His approach combines the Cloud Adoption Framework methodology with extensive regulatory compliance experience, including:

HIPAA
PCI-DSS
SOC 2
FedRAMP

Learn more about EPC Group

‌
‌
‌

‌
‌