Enterprise deployment guide covering CAF, governance, networking, identity, and compliance
Every enterprise Azure migration eventually reaches the same inflection point: ad-hoc subscriptions become ungovernable, network topologies diverge across teams, security policies are applied inconsistently, and cloud costs spiral without accountability. The Azure landing zone is Microsoft's answer to this problem. It is a pre-architected, policy-driven environment that establishes the foundational guardrails for identity, networking, governance, security, and operations before a single production workload is deployed. After leading Azure landing zone deployments for Fortune 500 organizations across healthcare, financial services, and federal government sectors, I can state definitively that the organizations that invest in this foundation first spend less, move faster, and face fewer security incidents than those that try to retrofit governance after the fact.
This guide walks through every layer of enterprise Azure landing zone architecture. Whether you are planning your initial cloud adoption or restructuring an existing environment that has grown unwieldy, the principles here follow the Microsoft Cloud Adoption Framework (CAF) and Azure Well-Architected Framework, supplemented by real-world patterns from EPC Group's 25+ years of enterprise Azure cloud consulting experience.
An Azure landing zone is a scalable, multi-subscription Azure environment architected according to the Cloud Adoption Framework. It is not a single resource or template; rather, it is the full set of Azure platform services, configurations, policies, and access controls that form the operational backbone for every workload your organization deploys to Azure.
The CAF defines two implementation scales. The start small and expand approach deploys a minimal landing zone and iterates as requirements emerge, 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, with full management group hierarchy, centralized networking, and 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.
At its core, the Azure landing zone solves five problems simultaneously: identity governance (who can access what, under what conditions), network topology (how resources communicate with each other and on-premises systems), security baseline (what controls are enforced by default), resource governance (what can be deployed, where, and with what configuration), and operational management (how you monitor, patch, back up, and respond to incidents across hundreds of subscriptions).
The management group hierarchy is the spine of your Azure landing zone. Every Azure AD tenant has a single Tenant Root Group at the top. Beneath it, you create an intermediate root management group (named for your organization) that becomes the anchor for all policy assignments and RBAC definitions. This intermediate root exists because the Tenant Root Group itself requires elevated permissions to modify and should be treated as immutable after 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:
The Landing Zones branch divides into Corp (for internal-facing workloads connected to the corporate network) and Online (for internet-facing workloads with public endpoints). Each workload team receives one or more subscriptions under the appropriate management group. Two additional sibling groups round out the hierarchy: Sandbox (for experimentation with no corporate connectivity and relaxed policies) and Decommissioned (where subscriptions are moved before deletion, with deny-all policies preventing new deployments).
Keep the hierarchy to a maximum of four levels deep. Deeper nesting creates policy evaluation complexity and makes troubleshooting difficult. If your organization has distinct business units requiring different governance, add management groups at the Landing Zones level (e.g., Landing Zones > Business Unit A > Corp / Online) rather than creating arbitrary depth.
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 is the enforcement engine of your landing zone. Policies are JSON-based rules that evaluate resource properties during creation and ongoing compliance scans. When assigned at a management group, policies cascade to every subscription and resource group beneath it, providing consistent governance without 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 what happens when a resource violates a rule. Audit logs the violation without blocking deployment, useful during initial rollout. Deny blocks the resource creation or modification entirely. DeployIfNotExists automatically remediates drift, for example deploying a diagnostic setting to every new resource. Modify adds or changes resource tags or properties during deployment. Best practice is to deploy all policies in audit mode first, review compliance results for 7 to 14 days, remediate false positives, then switch to deny or deployIfNotExists for production enforcement.
For organizations requiring custom policies beyond the built-in library, Azure Policy supports custom definitions written in JSON with Bicep or Terraform wrappers for IaC-driven management. EPC Group maintains a library of over 80 custom policies for enterprise clients covering naming conventions, network segmentation rules, data residency restrictions, and cost guardrails that extend the built-in Azure Security Benchmark.
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.
In the hub-spoke model, a central virtual network (the hub) hosts shared network services: Azure Firewall for traffic inspection, VPN Gateway or ExpressRoute Gateway for hybrid connectivity, Azure Bastion for secure RDP/SSH access, and Azure DNS Private Zones for name resolution. Workload virtual networks (spokes) peer to the hub and route traffic through the firewall via user-defined routes (UDRs).
Hub-spoke gives you full control over firewall sizing, routing logic, and network virtual appliance selection. You can deploy Azure Firewall Premium for IDPS and TLS inspection or substitute a third-party NVA like Palo Alto or Fortinet. Spoke-to-spoke communication always transits the hub firewall, enabling centralized traffic inspection and logging. The downside is operational overhead: you manage all peering relationships, route tables, and 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.
Azure Virtual WAN is a Microsoft-managed networking service that provides automated hub deployment, any-to-any transit routing, branch connectivity integration (SD-WAN, VPN, ExpressRoute), and built-in Azure Firewall Manager integration. Virtual WAN hubs are deployed per region, and spoke VNets connect to the nearest hub. Routing between hubs, between spokes, and to on-premises branches is automated through the Virtual WAN routing infrastructure.
Virtual WAN excels in multi-region deployments because inter-hub routing is automatic over the Microsoft backbone. It simplifies branch connectivity for organizations with 20 or more offices by integrating with SD-WAN partners (VMware, Cisco, Barracuda). The tradeoff is reduced customization: you cannot deploy arbitrary NVAs in the hub (only Azure Firewall or select NVA partners), and routing policies are managed through Virtual WAN constructs rather than 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 is the control plane for your landing zone. Microsoft Entra ID (formerly Azure Active Directory) provides the authentication and authorization layer for every Azure resource, management operation, and workload access decision. The landing zone identity architecture must address four domains: administrative access to Azure resources (RBAC), workload identity for applications and services, hybrid identity for on-premises integration, and privileged access management for break-glass scenarios.
RBAC (Role-Based Access Control) is assigned at the management group level for platform teams and at the subscription or resource group level for workload teams. Platform teams (networking, security, identity) receive built-in roles scoped to their platform subscriptions. Workload teams receive Contributor or custom roles scoped to their landing zone subscriptions. Never assign Owner at any scope below the organization root management group; Owner includes the ability to modify RBAC assignments, creating privilege escalation risk.
Entra ID Privileged Identity Management (PIM) is non-negotiable for enterprise landing zones. All privileged roles (Global Administrator, Subscription Owner, Security Administrator) must be eligible rather than permanently assigned, requiring just-in-time activation with MFA, approval workflows, and time-limited sessions. PIM activation logs feed into the central Log Analytics workspace for audit and alerting.
Conditional Access policies enforce context-aware access controls: require MFA for all Azure management operations, block legacy authentication protocols, restrict access from non-compliant devices using Intune device compliance, 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 via Azure CLI, PowerShell, and REST APIs.
For hybrid environments, deploy Azure AD Connect (or Entra Connect Cloud Sync) in the Identity subscription with high availability. Enable password hash synchronization as a backup authentication method even if you use federation (AD FS) or pass-through authentication. This ensures Azure access remains available during on-premises Active Directory outages.
The security baseline is the set of controls that every resource in your landing zone inherits automatically. It begins with Microsoft Defender for Cloud enabled across all subscriptions with the Defender for Servers, Defender for Storage, Defender for SQL, Defender for Key Vault, and Defender for Containers plans activated. Defender for Cloud provides continuous security assessment, vulnerability scanning, and threat detection with automatic alerts routed to the SOC team via Log Analytics and Azure Sentinel (Microsoft Sentinel).
Network security enforces defense in depth. Azure Firewall Premium inspects all east-west (spoke-to-spoke) and north-south (internet-to-workload, workload-to-internet) traffic with IDPS signatures and TLS inspection for encrypted traffic. Network Security Groups (NSGs) provide micro-segmentation at the subnet and NIC level, with deny-all default rules and explicit allow rules per workload. Azure DDoS Protection Standard is enabled on the hub VNet and all internet-facing spoke VNets. Azure Private Link and Private Endpoints eliminate public internet exposure for PaaS services (Storage, SQL, Key Vault, Event Hub, Service Bus), ensuring data never traverses the public internet.
Data protection requires encryption at rest (using Microsoft-managed or customer-managed keys in Azure Key Vault) for all storage accounts, databases, and managed disks. Encryption in transit is enforced via Azure Policy requiring HTTPS/TLS 1.2 minimum for all endpoints. Azure Key Vault is deployed per subscription with soft delete and purge protection enabled, RBAC-based access control, and diagnostic logging to the central workspace. Secrets, certificates, and encryption keys never exist outside Key Vault.
Microsoft Sentinel (Azure Sentinel) aggregates logs from all landing zone resources, Entra ID sign-in and audit logs, Microsoft 365 Defender alerts, and on-premises sources via Azure Arc. Custom analytics rules detect landing-zone-specific threats: unauthorized management group changes, policy exemption creation, cross-subscription lateral movement, and anomalous resource deployments. Sentinel playbooks automate incident response by isolating compromised VMs, revoking credentials, or notifying the security team via Teams and PagerDuty.
Uncontrolled cloud spending is the number one complaint I hear from CFOs after their organization's first year in Azure. Landing zones solve this by building cost governance into the architecture rather than bolting it on after budgets have been exceeded. The cost management strategy has five layers.
Tagging policy enforcement is the foundation. Azure Policy requires mandatory tags on every resource group and resource: CostCenter, Environment (Dev, Test, Staging, Production), Owner (email), Application, and BusinessUnit. Tags enable cost allocation reports that map Azure spending to internal cost centers, business units, and projects. Without consistent tagging, cost attribution is impossible at scale.
Azure Budgets and alerts are configured per subscription and per management group. Alerts trigger at 50 percent (informational), 75 percent (warning), and 90 percent (critical) of the monthly budget. Action groups notify the subscription owner, the FinOps team, and optionally invoke an Azure Function to shut down non-production resources when budgets are exceeded.
Azure Reservations and Savings Plans are purchased at the enrollment or billing account scope so discounts apply across all subscriptions in the landing zone. For predictable workloads (production VMs, databases, App Service plans), one-year or three-year reservations reduce costs by 30 to 72 percent compared to pay-as-you-go pricing. Azure Savings Plans provide 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.
Centralized monitoring is deployed in the Management subscription and consumes telemetry from every resource across the landing zone. The architecture centers on a central Log Analytics workspace that receives diagnostic logs, metrics, and activity logs from all subscriptions. Azure Policy with the DeployIfNotExists effect automatically configures diagnostic settings on every new resource, eliminating the possibility of unmonitored blind spots.
Azure Monitor provides four pillars of observability. Metrics deliver real-time numerical data (CPU, memory, disk IOPS, network throughput) with configurable alerts and autoscale triggers. Logs aggregate structured telemetry into Log Analytics for KQL-based querying across the entire estate. Application Insights provides APM (application performance monitoring) for web applications with distributed tracing, dependency mapping, and availability tests. Azure Monitor Workbooks create custom dashboards combining metrics, logs, and external data sources into executive-ready visualizations.
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.
The landing zone itself is infrastructure as code. Every management group, policy assignment, RBAC definition, virtual network, firewall rule, and diagnostic setting is defined in Bicep modules or Terraform configurations 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 uses a two-stage approach. The validation stage runs on every pull request: Bicep/Terraform linting, what-if/plan previews showing exactly which resources will be created, modified, or destroyed, policy compliance pre-checks, and cost estimation using Infracost or Azure Pricing Calculator API calls. The deployment stage runs on merge to the main branch: sequential deployment from management groups to policies to networking to subscription vending, with approval gates between stages for production environments.
Service principals used by CI/CD pipelines authenticate using federated credentials (workload identity federation) rather than client secrets, eliminating secret rotation risk. Pipeline service principals receive minimal RBAC scopes: the platform pipeline service principal has Contributor on the Platform management group, while workload pipeline service principals have Contributor only on their specific subscription.
Drift detection is critical for landing zone integrity. A scheduled pipeline runs daily, comparing the actual Azure state to the desired state in code. Any manual changes made outside the pipeline are flagged and optionally auto-remediated. This prevents configuration drift that accumulates over time and causes compliance failures during audits.
Enterprise landing zones must account for regional failure from day one. Azure regions are grouped into pairs (e.g., East US / West US, North Europe / West Europe) with guaranteed data residency and prioritized recovery during outages. Your landing zone design should designate a primary and secondary region and deploy platform infrastructure in both.
In the hub-spoke model, deploy a hub VNet in each region with VNet peering between hubs for cross-region transit. Both hubs host Azure Firewall instances with synchronized rule sets managed through Azure Firewall Policy (global policy with regional overrides). ExpressRoute circuits in each region connect to different peering locations for geographic redundancy. In the Virtual WAN model, deploy a hub in each region; Virtual WAN handles inter-hub routing automatically over the Microsoft global backbone.
For workloads requiring multi-region active-active or active-passive deployment, configure Azure Traffic Manager or Azure Front Door for global load balancing. Azure Site Recovery provides VM replication and automated failover for IaaS workloads. PaaS services like Azure SQL use geo-replication or auto-failover groups. Azure Cosmos DB provides multi-region writes for globally distributed applications.
The Management subscription resources (Log Analytics, Defender for Cloud, Sentinel) are deployed in the primary region with cross-region data export for resilience. Azure Policy assignments and management group hierarchy are global resources that survive regional failures. Conduct quarterly disaster recovery drills that test workload failover, DNS cutover, and operational runbook execution.
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 provides private, dedicated connectivity between on-premises networks and Azure through a connectivity provider (Equinix, Megaport, AT&T). ExpressRoute circuits deliver predictable latency, higher bandwidth (up to 100 Gbps with ExpressRoute Direct), and SLA-backed availability. For enterprise landing zones, deploy ExpressRoute with Microsoft peering for Microsoft 365 and Azure public services, and private peering for VNet connectivity. Use ExpressRoute Global Reach to connect on-premises sites in different geographies through the Microsoft backbone without hairpinning through Azure.
Site-to-site VPN over the public internet provides encrypted connectivity at lower cost than ExpressRoute. VPN Gateway supports BGP routing for dynamic route advertisement and active-active configurations for high availability. VPN is suitable for branch offices, disaster recovery connectivity, or as a backup path when ExpressRoute fails. Configure both ExpressRoute and VPN in the same hub for automatic failover.
Azure Arc extends Azure management to on-premises and multi-cloud resources. Arc-enabled servers appear as Azure resources with Azure Policy compliance, Microsoft Defender for Cloud monitoring, and Azure Monitor agent telemetry. Arc-enabled Kubernetes clusters can run Azure services (Azure App Service, Azure Functions, Azure API Management) on-premises or in other clouds. For organizations pursuing a hybrid landing zone strategy, Azure Arc provides unified governance across Azure, on-premises, AWS, and GCP from a single control plane.
Regulated enterprises must map their landing zone controls to specific compliance frameworks. Azure provides built-in regulatory compliance initiatives in Defender for Cloud that assess your environment against HIPAA HITRUST, PCI-DSS v4, NIST 800-53 (FedRAMP), CIS Benchmarks, and dozens of other standards. The landing zone architecture accelerates compliance by enforcing controls at the infrastructure layer rather than relying on workload teams to implement them individually.
Healthcare organizations must execute a Microsoft BAA (Business Associate Agreement) before storing PHI in Azure. The landing zone enforces HIPAA controls through Azure Policy: encryption at rest and in transit for all data stores, access logging for all resources touching PHI, network isolation via private endpoints and NSG restrictions, Azure Key Vault for encryption key management with HSM backing, and retention policies meeting the six-year HIPAA retention requirement. Microsoft Defender for Cloud HIPAA HITRUST assessment provides a compliance dashboard mapping controls to HIPAA requirements, with remediation guidance for any gaps.
PCI-DSS v4.0 requires network segmentation isolating the cardholder data environment (CDE) from all other workloads. In the landing zone, PCI workloads run in dedicated subscriptions under a PCI-specific management group with additional 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, and restrict administrative access to dedicated PAW (Privileged Access Workstation) devices.
FedRAMP High and Moderate baselines map to NIST 800-53 controls. The landing zone deploys in Azure Government regions (US Gov Virginia, US Gov Texas, US Gov Arizona) which are physically isolated from commercial Azure and operated by screened US persons. 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, and 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-authorized landing zones for federal agencies managing IL4 and IL5 workloads in Azure Government.
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).
A regional healthcare system with 12 hospitals and 300 applications in two on-premises data centers needed to migrate 60 percent of workloads to Azure while maintaining HIPAA compliance and uninterrupted patient care. The landing zone deployed a hub-spoke topology with ExpressRoute in two Azure regions (East US 2 and Central US) with encrypted cross-hub peering. PHI workloads ran in dedicated Corp subscriptions with HIPAA HITRUST policy initiatives, while non-PHI workloads (HR, finance, public websites) ran in separate Online subscriptions with standard security baselines.
The management group hierarchy separated clinical systems from administrative systems, with different RBAC assignments for clinical IT and corporate IT teams. 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 executed over nine months in four waves, with zero HIPAA compliance incidents.
A global financial services firm had grown to 150 Azure subscriptions created ad-hoc by different departments over five years. Each subscription had independent networking, inconsistent security configurations, and no centralized monitoring. Annual Azure spend exceeded $8 million with no reliable cost attribution by business unit. The landing zone project reorganized all subscriptions under a CAF-aligned management group hierarchy, consolidated eight independent hub VNets into a single hub-spoke topology with Azure Firewall Premium, and deployed organization-wide policies for tagging, encryption, and allowed VM SKUs.
PCI-DSS workloads moved to isolated subscriptions under a PCI management group with 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 reduced Azure spend by 28 percent ($2.2 million annually) through rightsizing, reservation purchases informed by usage data, and elimination of 40 percent of idle resources identified during the consolidation.
A federal civilian agency required a FedRAMP High authorized Azure environment for a new citizen-facing application processing personally identifiable information (PII) at the IL4 level. The landing zone was deployed entirely in Azure Government (US Gov Virginia as primary, US Gov Texas as DR) using Terraform modules that 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 with Conditional Access policies requiring compliant government-issued devices. ExpressRoute connected 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. The P-ATO was granted by the JAB within 14 months from project initiation.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
Chief AI Architect & CEO, EPC Group | Microsoft Press Author (4 books) | 25+ Years Enterprise Consulting
Errin O'Connor is Chief AI Architect and CEO of EPC Group, specializing in enterprise Azure architecture, cloud migrations, and compliance-driven infrastructure design. With 25+ years of Microsoft ecosystem expertise and author of four Microsoft Press bestsellers covering Power BI, SharePoint, Azure, and large-scale migrations, Errin has led Azure landing zone deployments for Fortune 500 clients across healthcare, financial services, and federal government sectors. His approach combines Cloud Adoption Framework methodology with deep regulatory compliance experience spanning HIPAA, PCI-DSS, SOC 2, and FedRAMP.
Learn more about EPC Group