Azure Landing Zone Architecture
Enterprise deployment guide covering CAF, governance, networking, identity, and compliance
Founded 1997 · in our 30th year11,000+ enterprise engagementsMicrosoft Press bestselling author
Enterprise deployment guide covering CAF, governance, networking, identity, and compliance
By Errin O'Connor, Founder & Chief AI Architect, EPC Group
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. EPC Group's Azure consulting practice designs and deploys enterprise-scale landing zones on this reference architecture, with governance and Entra ID as the first workstream.
The Azure landing zone is the governance foundation for all enterprise Azure deployments. It establishes key elements before adding any workloads. These elements include:
EPC Group has implemented enterprise-scale landing zones for:
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.
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:
The enterprise-scale landing zone deploys these components in one automated run:
EPC Group enforces HIPAA controls through Azure Policy assignments on the landing zone. Key controls required for HIPAA compliance:
Federal and defense clients require a modified landing zone with additional controls. EPC Group implements FedRAMP Moderate/High and IL4/IL5 configurations:
PCI workloads run in dedicated subscriptions under a PCI-specific management group. Additional policy controls for the cardholder data environment (CDE):
Landing zone cost governance uses seven controls. EPC Group configures all seven at deployment time:
Errin O'Connor is the founder and Chief AI Architect of EPC Group. He has led Azure landing zone deployments for Fortune 500 companies since 1997. His experience spans various sectors, including:
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:
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:
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:
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:
Yes, EPC Group creates FedRAMP Moderate/High and IL4/IL5 landing zones in Azure Government and GCC High tenants. Our services include:
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.
Application teams onboard their workloads into spoke subscriptions. EPC Group offers the following support:
Optional managed services are also available for ongoing governance monitoring.
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.
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:
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:
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:
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:
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:
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:
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.
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 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:
At the Platform level, you can assign specific policies for your network. These include:
At the Landing Zones level, you should assign workload-tier policies. These include:
Policy effects determine the outcome when a resource breaks a rule. There are several options for handling these violations:
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:
These custom policies enhance the built-in Azure Security Benchmark.
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:
The hub-spoke model features a central virtual network known as the hub. This hub provides shared network services, including:
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:
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:
The hub-spoke model is ideal for organizations that meet any of the following criteria:
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:
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:
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:
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 serves as the control plane for your landing zone. Microsoft Entra ID (formerly Azure Active Directory) offers the authentication and authorization layer for:
The landing zone identity architecture must cover four key areas:
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:
This configuration needs:
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:
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:
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.
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:
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:
It uses IDPS signatures and performs TLS inspection for encrypted traffic.
Key components of network security include:
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:
Importantly, secrets, certificates, and encryption keys never exist outside of Key Vault.
Microsoft Sentinel (Azure Sentinel) gathers logs from multiple sources. These sources include:
Custom analytics rules identify specific threats in the landing zone. These threats include:
Sentinel playbooks automate incident response. They can isolate compromised VMs, revoke credentials, or notify the security team through Teams and PagerDuty.
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:
Tagging policy enforcement is essential for effective management. Azure Policy mandates specific tags for every resource group and resource. These tags include:
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:
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:
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:
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:
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:
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:
For landing zone operations, it is important to configure alerts for key platform-level events. These include:
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:
Additionally, Azure Monitor Network Insights offers a comprehensive view of VNet health, peering status, gateway connectivity, and firewall throughput across all subscriptions.
The landing zone is created with infrastructure as code. Each component is defined in Bicep modules or Terraform configurations. These components include:
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:
The deployment stage takes place when merging to the main branch. This stage involves:
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:
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.
Enterprise landing zones should account for regional failures from the beginning. Azure regions are paired, such as:
This pairing guarantees data residency and improves recovery during outages.
Your landing zone design should:
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:
Additionally, Azure Site Recovery provides VM replication and automated failover for IaaS workloads.
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:
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.
For enterprise landing zones, deploy ExpressRoute with:
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:
VPN is ideal for:
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:
Arc-enabled Kubernetes clusters can run Azure services, including:
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:
All of this is managed from a single control plane.
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:
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.
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:
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 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:
FedRAMP High and Moderate baselines align with NIST 800-53 controls. The landing zone operates in Azure Government regions, including:
These regions are physically separate from commercial Azure and managed by screened US personnel. FedRAMP landing zones enforce:
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.
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 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:
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:
The migration took nine months and occurred in four waves, with zero HIPAA compliance incidents.
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:
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:
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.
The JAB granted the P-ATO within 14 months from the project's start.
The Azure Well-Architected Framework (WAF) consists of five essential pillars. Each landing zone must meet these pillars to ensure compliance.
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 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:
Founder & Chief AI Architect, EPC Group | Microsoft Press Author (4 books) | Enterprise Consulting Since 1997
Errin O'Connor is the Founder & Chief AI Architect. He specializes in enterprise Azure architecture, cloud migrations, and compliance-driven infrastructure design.
With experience in the Microsoft ecosystem since 1997, Errin is the author of four bestsellers for Microsoft Press and Sams. These books cover:
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:
AI assistant — not human