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 is the governance foundation for all enterprise Azure deployments. It establishes key elements before adding any workloads. These elements include:

Identity
Networking
Security
Resource governance
Operations controls

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 is the founder and Chief AI Architect of EPC Group. He has led Azure landing zone deployments for Fortune 500 companies for 29 years. His experience spans various sectors, including:

Healthcare
Financial services
Federal government

His insights are invaluable in these industries.

Organizations that create a solid landing zone foundation before deploying workloads enjoy many advantages. They complete migrations more quickly and pass audits on their first try.

Moreover, they spend 40–60% less on operational remediation than those who 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. It includes governance, networking, security, and identity controls before deploying any application workloads.

This setup addresses five key issues:

Identity
Networking
Security
Resource Governance
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, the process 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) provides guidance on cloud strategy, planning, readiness, and governance. It helps organizations effectively transition to the cloud.

The Enterprise-scale landing zone is the recommended architecture for organizations deploying Azure at enterprise scale. Key features include:

Comprehensive security and compliance
Scalability to meet growing demands
Best practices for governance and management

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. It is built on the Cloud Adoption Framework. This setup is more than just one resource or template.

It includes:

A complete set of Azure platform services
Configurations
Policies
Access controls

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

The CAF describes two implementation scales. The start small and expand approach begins with a basic landing zone. It grows as new needs arise. This method is ideal 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 emphasizes an enterprise-scale approach. Organizations with regulated workloads, hybrid connectivity needs, or over 20 planned Azure subscriptions will require a complete architecture.

Building this architecture correctly from the start is more cost-effective than making changes 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 handles internal workloads linked to the corporate network. In contrast, the Online division manages internet-facing workloads that have 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 complicates policy evaluation and makes troubleshooting harder. If your organization has multiple business units that need unique governance, consider creating management groups at the Landing Zones level.

For example, use Landing Zones > Business Unit A > Corp / Online.
Avoid 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, set clear baseline policies. These include:

Enforcing diagnostic settings to the central Log Analytics workspace.
Requiring mandatory tags such as CostCenter, Environment, Owner, and Application.
Denying deployment to unapproved Azure regions.
Applying the Azure Security Benchmark initiative.
Enforcing encryption at rest for all storage accounts and databases.

At the Platform level, you can assign specific policies for your network. These include:

Denying public IP creation
Enforcing network security group attachment
Requiring private endpoints for PaaS services like Azure SQL, Storage, and Key Vault
Restricting virtual network gateway configurations

At the Landing Zones level, you should assign workload-tier policies. These include:

Allowed VM SKU sizes for cost control
Required Azure Key Vault for secrets management
Compliance initiatives such as HIPAA HITRUST, PCI-DSS v4, or FedRAMP Moderate/High, depending on the workload classification
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.

It is best to deploy all policies in audit mode first. Review compliance results for 7 to 14 days. Fix any false positives before switching to deny or deployIfNotExists for production enforcement.

Organizations needing custom policies beyond the built-in library can use Azure Policy. This service allows for custom definitions written in JSON.

Additionally, it supports Bicep and Terraform wrappers for managing Infrastructure as Code (IaC).

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 a key design choice in your landing zone. It is also the hardest part to change after workloads are deployed. The Cloud Adoption Framework (CAF) provides two reference topologies. Your selection will depend on:

Your specific business needs
The types of workloads you plan to run
Your security and compliance requirements

Your organization's scale
Hybrid connectivity needs
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

The hub-spoke model is ideal for organizations that meet any of the following criteria:

Have fewer than 50 spoke VNets
Operate in a single primary Azure region
Have existing investments in third-party network appliances
Possess teams with strong Azure networking expertise and desire maximum control

Virtual WAN Topology

Azure Virtual WAN is a networking service managed by Microsoft. It provides automated hub deployment and any-to-any transit routing. The service includes various branch connectivity options:

SD-WAN
VPN
ExpressRoute

Additionally, it features built-in integration with Azure Firewall Manager.

Virtual WAN hubs are set up in each region. Spoke VNets connect to the closest hub. Routing is automated through the Virtual WAN routing infrastructure. This includes:

Connections between hubs
Connections to spokes
Connections to on-premises branches

Virtual WAN is very effective for multi-region deployments. It offers automatic inter-hub routing over the Microsoft backbone. This feature simplifies branch connectivity.

This is particularly advantageous 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 serves as the control plane for your landing zone. Microsoft Entra ID (formerly Azure Active Directory) offers the authentication and authorization layer for:

All Azure resources
Management tasks
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.

Never assign the Owner role below the organization root management group. This role allows changes to RBAC assignments. Such changes can lead to risks of privilege escalation.

Entra ID Privileged Identity Management (PIM) is essential for enterprise landing zones. Privileged roles should be eligible instead of permanently assigned. This includes:

Global Administrator
Subscription Owner
Security Administrator

This configuration needs:

Just-in-time activation
Multi-Factor Authentication (MFA)
Approval workflows
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 access controls based on context. They require Multi-Factor Authentication (MFA) for all Azure management operations. Additionally, these policies:

Block legacy authentication protocols
Restrict access from non-compliant devices using Intune device compliance

Furthermore, they impose location-based restrictions for sensitive management operations. They also require phishing-resistant authentication methods, such as FIDO2 and 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. This ensures high availability.

Enable password hash synchronization as a backup authentication method. This step is crucial even if you use federation with 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 consists of controls that every resource in your landing zone automatically inherits. It begins with Microsoft Defender for Cloud enabled for all subscriptions. This includes:

Microsoft Defender for Cloud Free
Microsoft Defender for Cloud Standard
Microsoft Defender for Cloud Premium

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

Defender for Cloud provides key security features for organizations. It includes continuous security assessment, vulnerability scanning, and threat detection.

Additionally, it sends automatic alerts to the SOC team via 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) gathers logs from multiple sources. These sources include:

Landing zone resources
Entra ID sign-in and audit logs
Microsoft 365 Defender alerts
On-premises sources via 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 say that uncontrolled cloud spending is their biggest worry after the first year in Azure. Landing zones address this issue by integrating cost governance into the architecture. This approach removes the need to implement governance after budgets have been surpassed.

The cost management strategy includes five layers:

Layer 1: Governance
Layer 2: Cost Tracking
Layer 3: Budgeting
Layer 4: Reporting
Layer 5: Optimization

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

Making reservations for one year or three years can lower costs by 30 to 72 percent compared to pay-as-you-go pricing. Azure Savings Plans offer flexible compute discounts. These discounts automatically apply to any VM family, region, or OS combination.

Azure Advisor and cost anomaly detection help identify opportunities for rightsizing, including oversized VMs. They also find idle resources, such as:

Unattached disks
Unused public IPs

Furthermore, they offer recommendations for optimization.

Microsoft Cost Management anomaly detection alerts the FinOps team when daily spending varies greatly from historical patterns.

Policy-enforced cost guardrails help avoid costly errors before they occur. Azure Policy includes several key restrictions:

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.
Enforces auto-shutdown schedules for non-production VMs.

Monitoring and Observability with Azure Monitor

Centralized monitoring is set up in the Management subscription. It gathers telemetry from all resources in the landing zone. The system uses a central Log Analytics workspace. This workspace collects:

Performance data
Usage metrics
Error logs

Diagnostic logs
Metrics
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, it is important to configure alerts for key platform-level events. These include:

Management group changes
Policy assignment modifications
RBAC role assignments at management group scope
Hub firewall health degradation
ExpressRoute circuit down
DNS resolution failures

Additionally, workload teams should set up alerts for their specific application metrics within their subscription scope.

Network monitoring utilizes several Azure tools for effective management. These include:

Azure Network Watcher for connection troubleshooting.
NSG flow logs for traffic analysis.
Traffic Analytics for visualizing network flows across the landing zone.

Additionally, Azure Monitor Network Insights offers a comprehensive 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 created with infrastructure as code. Each component is defined in Bicep modules or Terraform configurations. These components include:

Management groups
Policy assignments
RBAC definitions
Virtual networks
Firewall rules
Diagnostic settings

All configurations 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 essential for maintaining landing zone integrity. A scheduled pipeline runs every day. It compares the actual Azure state to the desired state defined in code.

Any manual changes made outside the pipeline are flagged. If needed, these changes can also be automatically fixed.

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 should account for regional failures from the beginning. Azure regions are paired, such as:

East US / West US
North Europe / West Europe

This pairing guarantees data residency and improves 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 contains Azure Firewall instances with 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 link to different peering locations. This setup offers geographic redundancy. In the Virtual WAN model, you should set up a hub in each region.

Virtual WAN automatically manages inter-hub routing through the Microsoft global backbone.

For workloads requiring multi-region active-active or active-passive deployment, consider using:

Azure Traffic Manager for global load balancing.
Azure Front Door for global load balancing.

Additionally, Azure Site Recovery provides 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

Many enterprises maintain on-premises data centers during and after migrating to the cloud. The landing zone Connectivity subscription provides a connection between Azure and on-premises infrastructure. It offers three connectivity options that can be combined based on your workload requirements.

Azure ExpressRoute offers private and dedicated connections between on-premises networks and Azure. You can connect using a provider such as Equinix, Megaport, or AT&T.

High reliability and low latency
Increased security for data transfer
Consistent performance for applications

Reliable and secure connections
Consistent performance
Direct access to Azure services

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 provides secure connections over the public internet. It is more affordable than ExpressRoute.

This solution supports:

BGP routing for dynamic route advertisement
Active-active configurations for 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 both on-premises and in other clouds. Azure Arc provides unified governance for organizations using a hybrid landing zone strategy.

It allows management across:

Azure
On-premises
AWS
GCP

All of this is managed 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 through Defender for Cloud. These initiatives assess your environment based on the following criteria:

Security posture
Risk management
Regulatory requirements

Industry standards
Government regulations
Best practices

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 within a PCI-specific management group. This setup includes several important policies:

Dedicated subscriptions for PCI workloads
Isolation of the cardholder data environment
Management group tailored for PCI compliance

Isolation of the cardholder data environment
Dedicated subscriptions for PCI workloads
Management group tailored for PCI compliance

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 include NIST 800-53 controls. This ensures that new subscriptions automatically inherit the complete FedRAMP control baseline.

EPC Group has implemented FedRAMP-aligned consulting expertise landing zones for federal agencies. These zones support the management of 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 plan to migrate 60 percent of their workloads to Azure. This migration must uphold HIPAA compliance and guarantee continuous 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 managed in dedicated Corp subscriptions. These subscriptions followed HIPAA and HITRUST policy initiatives. Non-PHI workloads, such as HR, finance, and public websites, were managed in separate Online subscriptions.

These Online subscriptions followed 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 transferred to distinct subscriptions within a PCI management group. This process involved setting up dedicated firewall rules and implementing network segmentation.

Additionally, cost allocation tags were applied retroactively to all existing resources. This was achieved through 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 completely set up in Azure Government. The primary site was US Gov Virginia, while US Gov Texas served as the disaster recovery (DR) site.

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) consists of five essential pillars. Each landing zone must meet these pillars to ensure compliance.

Reliability
Security
Cost Optimization
Operational Excellence
Performance Efficiency

Cost Optimization
Operational Excellence
Performance Efficiency
Reliability
Security

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 implemented Azure landing zones for Fortune 500 companies in healthcare, financial services, and government sectors. Our accelerator templates cut deployment time by 50 percent.

These templates also ensure compliance with:

HIPAA
PCI-DSS
FedRAMP

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 across different sectors. These include healthcare, financial services, and federal government. His approach follows the Cloud Adoption Framework methodology and emphasizes regulatory compliance. His experience includes:

Healthcare regulations
Financial services compliance
Federal government standards

Healthcare regulations
Financial services compliance
Federal government standards

HIPAA
PCI-DSS
SOC 2
FedRAMP

Learn more about EPC Group

‌
‌
‌

‌
‌