--- title: Build Azure Landing Zones That Prevent Cloud Sprawl description: Build governed Azure landing zones end to end with the IaC accelerator: management group hierarchies, the eight design areas, Terraform and Bicep deployments, plus policy, security, and networking. canonical: https://adamtheautomator.com/build-azure-landing-zones/ --- # Build Azure Landing Zones That Prevent Cloud Sprawl > Build governed Azure landing zones end to end with the IaC accelerator: management group hierarchies, the eight design areas, Terraform and Bicep deployments, plus policy, security, and networking. Source: https://adamtheautomator.com/build-azure-landing-zones/ --- - Build Azure Landing Zones That Prevent Cloud Sprawl Tap to hide Home - Tutorials - Guidebooks - Instructors - Get Paid to Write - Advertising - Recommended Resources - About Adam Search for: - - - - # Build Azure Landing Zones That Prevent Cloud Sprawl Published:31 August 2026 - 14 min. read - Azure - Infrastructure as Code - Networking - Terraform [](https://adamtheautomator.com/author/adam-bertram/) [Adam Bertram](https://adamtheautomator.com/author/adam-bertram/) Read [more tutorials](https://adamtheautomator.com/author/adam-bertram/) by Adam Bertram! - - [](https://specopssoft.com/product/specops-password-auditor/?utm_source=adamtheautomator&utm_medium=referral&utm_campaign=adamtheautomator_referral_na&utm_content=display) Audit Active Directory for stale users, weak passwords, and other security risks with [Specops Password Auditor](https://specopssoft.com/product/specops-password-auditor/?utm_source=adamtheautomator&utm_medium=referral&utm_campaign=adamtheautomator_referral_na&utm_content=text). Table of Contents - What Is an Azure Landing Zone? - How the Architecture Fits TogetherPlatform vs. Application Landing Zones - The Management Group Hierarchy - Subscriptions as Scale Units - The Eight Design AreasEnvironment Design Areas - Compliance Design Areas - Prerequisites - Build the Platform Landing Zone with Terraform - Build the Platform Landing Zone with Bicep - Compare the Deployment Options - Governance, Security, and IdentityPolicy-Driven Governance - Security Baseline - Identity and Access - Networking and Subscription VendingHub-and-Spoke or Virtual WAN - Corp, Online, and Connectivity - Subscription Vending - Operating Your Landing ZoneCost Management and FinOps - Keep the Platform Current - Common Failures and Fixes - Frequently Asked Questions - Next Steps: Land Your First Workload XFacebookLinkedIn A developer somewhere in your company just created an Azure subscription, and you never approved it. It carries no policies or budget alerts, and its owner left months ago. It costs you money every hour, and you'll learn about it the way you learn about everything else: the monthly bill. This is a structural problem, and it will keep happening until every workload has a governed place to land. That place is an Azure landing zone, the target architecture at the heart of the [landing zone guidance in the Cloud Adoption Framework](https://learn.microsoft.com/en-us/azure/cloud-adoption-framework/ready/landing-zone/). In this tutorial, you'll build one end to end. First, you'll learn what a landing zone is and how its management group hierarchy works. Then you'll deploy a platform landing zone through the Infrastructure-as-Code accelerator with [Terraform](https://developer.hashicorp.com/terraform/docs) or [Bicep](https://learn.microsoft.com/en-us/azure/azure-resource-manager/bicep/overview), and finish with the governance, security, networking, and cost practices that keep it healthy for years, and if you want structured training to go with the build, [Pluralsight's Azure Administration and Automation track](https://www.anrdoezrs.net/links/7627660/type/dlg/sid/ata-ps-azure-administration-and-automation-track/https://www.pluralsight.com/search?q=Azure%20Administration%20and%20Automation%20Track) is a strong place to start. ## What Is an Azure Landing Zone? An Azure landing zone is a proven, flexible architecture for running a governed multi-subscription Azure environment at scale. Microsoft defines it as the target architecture of the Ready phase in the Cloud Adoption Framework. It's a set of architecture patterns, design principles, and implementation options that gives an organization a repeatable foundation for everything it deploys. The model splits your estate into two complementary pieces. The platform landing zone is the centralized foundation: a management group hierarchy, shared resources for connectivity, identity, security, and management, plus a repeatable process for handing governed environments to workload teams. Application landing zones are where workload teams deploy and operate their resources inside those guardrails, with one landing zone per workload holding all of its environments. The architecture is deliberately technology-agnostic: from a line-of-business app to an AI workload, anything new deploys into an application landing zone without re-architecting the platform. You can implement a landing zone with Microsoft-provided accelerators that deploy recommended practices as infrastructure as code, or with a custom build designed internally or with a partner. Most organizations get the fastest path from the accelerator, and this tutorial follows that path. ## How the Architecture Fits Together Before you deploy anything, you need the mental model, because every decision in this post hangs off it. ### Platform vs. Application Landing Zones The platform landing zone is the central governance foundation. It provides a management group hierarchy that organizes every subscription and applies standards to them, centralized resources shared only where there is a clear governance, operational, or economic benefit, and a distribution process so every new environment inherits the same baseline. Most organizations run exactly one platform landing zone per [Microsoft Entra](https://learn.microsoft.com/en-us/entra/fundamentals/whatis) tenant. Workloads sit in application landing zones grouped by characteristics: Online, Internal (Corp), or Local. ### The Management Group Hierarchy Management groups are what make "configure once, govern everywhere" possible: governance applied to a management group cascades by inheritance to every nested management group, subscription, resource group, and resource beneath it, per the [management group documentation](https://learn.microsoft.com/en-us/azure/governance/management-groups/overview). Know the limits before you design: a directory supports up to 10,000 management groups, and a tree supports six levels of depth. Every directory has one root management group, its ID is your Entra tenant ID, and it cannot be moved or deleted. New subscriptions land in the root by default, which is why Microsoft says root-scope assignments should be "must have" only: anything you assign there applies to every resource in the directory, including ones that don't exist yet. The baseline hierarchy maps each platform group to a dedicated subscription: Security, Management, Identity, and Connectivity, with Corp, Local, Online, Decommissioned, and Sandbox for workloads. The diagram above is the shape you should see after a successful deployment. ### Subscriptions as Scale Units The resource organization design area treats subscriptions as policy and management boundaries and scale units. Environments are separated at the subscription level, not the resource group level, because subscription boundaries give cleaner governance and a lower blast radius: a dev experiment gone sideways shouldn't share a subscription with production data. This separation enables subscription democratization, the first of the five [landing zone design principles](https://learn.microsoft.com/en-us/azure/cloud-adoption-framework/ready/landing-zone/design-principles): teams get subscriptions as units of management, and the platform scales by adding subscriptions, no reconfiguration required. ## The Eight Design Areas The design areas are the checklist Microsoft wants you to walk before choosing any implementation, documented in the [design areas reference](https://learn.microsoft.com/en-us/azure/cloud-adoption-framework/ready/landing-zone/design-areas). They are not a strict gate; they are a process that simplifies designing complex environments, and you can implement them over time as you grow into your cloud operating model. ### Environment Design Areas Four environment areas shape your tenant: - Azure billing and Entra tenant setup comes first, because enrollment errors are painful to unwind. - Identity and access management is called out by Microsoft as a primary security boundary in the public cloud, so tenant, Conditional Access, and role strategy anchor everything else. - Resource organization covers subscription design, the management group hierarchy, and naming and tagging conventions. - Network topology and connectivity aligns your cloud network design with your adoption plans, including hybrid and multicloud connectivity. ### Compliance Design Areas Four compliance areas keep the environment honest over time: - Security covers the controls that protect it, including Zero Trust and advanced network security. - Management defines an operations baseline with visibility, operational compliance, and protect-and-recover capabilities. - Governance automates auditing and enforcement of policies. - Platform automation and DevOps covers the tooling that deploys the landing zone, with infrastructure as code and continuous delivery as the explicit expectation. Work through all eight before you pick an implementation path. Teams that skip it discover their networking or identity constraints after the platform is deployed, when changes cost the most. ## Prerequisites To follow along hands-on, you'll need: - An Azure agreement that supports management groups: an Enterprise Agreement or a Microsoft Customer Agreement. A pay-as-you-go subscription can't create management groups, so confirm this first. - A Microsoft Entra tenant, since the hierarchy lives inside one tenant and the root group is tied to its ID. An existing tenant is all you need. - Permissions to create management groups and subscriptions at the tenant root: the accelerator requires Owner on the parent management group and Owner on each of the four platform subscriptions, and the Bicep path additionally requires User Access Administrator at the root. If you are not the tenant administrator, find a sponsor now, because the accelerator needs this on day one. - A GitHub or Azure DevOps organization to host the repositories, pipelines, and approval environments that deploy the platform. - Familiarity with Bicep or Terraform syntax, optional but helpful, since the accelerator generates the module code for you, and if you want to validate your Azure administration skills before you start, MeasureUp's AZ-104 practice test is a solid way to check your readiness. ## Build the Platform Landing Zone with Terraform The [IaC accelerator](https://azure.github.io/Azure-Landing-Zones/accelerator/) runs in four phases: planning, prerequisites, bootstrap, and run. Planning picks your IaC language and version control; prerequisites configures credentials and the subscriptions the accelerator needs. Bootstrap runs the Azure Landing Zone (ALZ) PowerShell module, which creates the state and identity resource groups plus user-assigned managed identities with federated credentials for plan and apply. It also provisions repositories, pipeline templates, branch policies, and CI/CD pipelines with separate plan and apply environments and approval groups. Everything authenticates with OpenID Connect and workload identity federation, so no long-lived secrets sit in your pipeline. The Terraform starter module is driven by a single platform-landing-zone.tfvars file, documented in the [starter module documentation](https://azure.github.io/Azure-Landing-Zones/accelerator/starter-terraform/). Copy the example configuration for your scenario into the file and update it like this: # platform-landing-zone.tfvars starter_locations = ["eastus", "westus2"] defender_email_security_contact = "[[email protected]](/cdn-cgi/l/email-protection)" Two settings matter. The scenario comes from the example configuration you copied in, not a setting in this file — multi-region-hub-and-spoke-vnet-with-azure-firewall is one of the documented examples. starter_locations defines the Azure regions for your platform resources, so pick the regions your organization actually operates in. defender_email_security_contact is the email [Microsoft Defender for Cloud](https://learn.microsoft.com/en-us/azure/defender-for-cloud/defender-for-cloud-introduction) uses for security alerts. Change the default placeholder before you deploy, or your first security finding goes to nobody. Once you commit the file, the pipeline takes over: a plan environment validates, an apply environment deploys, and a human approves the promotion between them. Every later change flows through the same reviewable path. After the deployment finishes, verify before you call it done: the hierarchy matches the reference architecture, policies landed at the intermediate root, and Defender for Cloud is enabled with the Microsoft cloud security benchmark assigned. The Azure CLI can show you the hierarchy directly: az account management-group list --query "[].{name:name, displayName:displayName}" -o table You should see the platform and workload groups from the reference architecture. If you see only the tenant root, the bootstrap didn't complete; check the pipeline logs. ## Build the Platform Landing Zone with Bicep The Bicep path deploys the same architecture with Azure-native tooling: the [Bicep starter module](https://azure.github.io/Azure-Landing-Zones/accelerator/starter-bicep/) is built on [Azure Verified Modules](https://azure.github.io/Azure-Verified-Modules/), the Microsoft-validated module library and the recommended choice for new deployments. Its core modules cover governance, the management group structure and policy assignments, centralized logging, and networking for traditional hub-and-spoke or Virtual WAN. The configuration lives in a platform-landing-zone.yaml file with two inputs that matter: the network type and the module versions: # platform-landing-zone.yaml network_type: 'hubNetworking' starter_module_version: 'latest' network_type accepts hubNetworking, vwanConnectivity, or none, and it is the most consequential decision in the deployment because it fixes your network topology for the life of the platform. Choose hubNetworking if you run [Azure Firewall](https://learn.microsoft.com/en-us/azure/firewall/overview) and [ExpressRoute](https://learn.microsoft.com/en-us/azure/expressroute/expressroute-introduction) or VPN gateways in a traditional hub. Choose vwanConnectivity for Microsoft's managed [Virtual WAN](https://learn.microsoft.com/en-us/azure/virtual-wan/virtual-wan-about). Choose none only if you already run networking you plan to integrate later, which means building connectivity on your own. Pin the module versions in production: module updates are how new governance lands in your environment, and reviewable releases are how those changes should arrive. Pro Tip: The Bicep accelerator still bootstraps with Terraform. The bootstrap phase that creates your repositories, pipelines, and state storage runs on Terraform even when you deploy the platform itself with Bicep. That is by design, and you only need to understand it when you read the bootstrap pipeline code. From there the flow matches the Terraform path: commit the parameters, let CI validate, approve the apply, and verify the same hierarchy, policy, Defender, and logging checkpoints. ## Compare the Deployment Options Weigh the recommended path against the alternatives, because "deploy the accelerator" is not right for every organization, and knowing when the others win is what makes the recommendation trustworthy. Option Best When The Tradeoff IaC accelerator with Terraform Your team already lives in Terraform and HashiCorp tooling You own module updates and HCL knowledge IaC accelerator with Bicep You want Azure-native IaC built on Azure Verified Modules You must pin and manage module versions as Azure evolves Portal accelerator You need a working baseline today with no IaC skills No version control, painful updates Custom build You have requirements the accelerators cannot express You own every design decision, including the mistakes The [portal accelerator](https://aka.ms/alz/portal) is the odd one out. It deploys the reference architecture graphically in a few clicks, a legitimate starting point when you have no IaC experience. The problem is what happens after: updates and version control are difficult without code, which limits the portal to a starting point. The [implementation options page](https://learn.microsoft.com/en-us/azure/cloud-adoption-framework/ready/landing-zone/implementation-options) makes the same point more diplomatically. You will also hear the term Enterprise Scale in older material; it is the earlier name for this architecture, with the same design principles and design areas. ## Governance, Security, and Identity The accelerator gives you a governed baseline. The practices in this section are what you do with it, and each prevents a specific failure mode. ### Policy-Driven Governance [Azure Policy](https://learn.microsoft.com/en-us/azure/governance/policy/overview) is the enforcement engine of the landing zone. Policy definitions are business rules in JSON, initiatives group rules, and assignments apply them to management groups, subscriptions, resource groups, or individual resources. Resources are evaluated on create and update, on assignment lifecycle events, and in a standard compliance cycle every 24 hours. The effects matter more than the definitions. Deny blocks a change, Audit logs it, and Append and Modify alter it. DeployIfNotExists deploys a compliant resource, and DenyAction blocks a request based on the action it intends to perform: only the DELETE action is currently supported, so you can stop critical resources from being deleted. DenyAction does not consider who makes the request, and no Azure Policy effect requires MFA. Policy complements RBAC: RBAC controls who can act, and Policy controls whether the resulting resource state complies, regardless of who changed it. The ALZ reference implementation assigns policies at an intermediate root management group, never at the tenant root, and the [ALZ policy assignments](https://aka.ms/alz/policies) include DeployIfNotExists initiatives that configure Defender for Cloud, deploy Microsoft Defender for Endpoint, and route diagnostic logs to Log Analytics. ***Warning: Keep tenant root assignments to "must have" only.*** A policy or role assignment at the tenant root applies to every resource in the directory, including everything deployed after it. The ALZ automation deliberately avoids that scope. If you assign at the root because it is convenient, you are building the exact governance trap the landing zone exists to prevent. ### Security Baseline [Microsoft Defender for Cloud](https://learn.microsoft.com/en-us/azure/defender-for-cloud/defender-for-cloud-introduction) is a Cloud Native Application Protection Platform, or CNAPP, combining cloud security posture management for continuous assessment, DevSecOps for code-level security across pipelines, and cloud workload protection for VMs, containers, storage, databases, and serverless. Its default policy initiative, the [Microsoft cloud security benchmark](https://learn.microsoft.com/en-us/security/benchmark/azure/overview), ships as part of the ALZ default assignments. Centralize security logs. Export activity logs to [Azure Monitor Logs](https://learn.microsoft.com/en-us/azure/azure-monitor/logs/data-platform-logs) for long-term retention, and route default resource configurations to the central [Log Analytics](https://learn.microsoft.com/en-us/azure/azure-monitor/logs/log-analytics-workspace-overview) workspace. When volume justifies it, bring in [Microsoft Sentinel](https://learn.microsoft.com/en-us/azure/sentinel/overview) as your SIEM; the ALZ architecture dedicates a Management subscription to Log Analytics, Sentinel, and dashboards for that reason. ### Identity and Access Identity is the primary security boundary in the cloud, and the landing zone model leans on RBAC inheritance: assign VM Contributor at a management group and it applies across every VM in every subscription beneath it. That power is the risk: the recommendation is least privilege with Microsoft Entra ID controls: Conditional Access, Privileged Identity Management for just-in-time access with recurring reviews, and MFA everywhere. Start from the ALZ baseline roles and add only what compliance demands. ## Networking and Subscription Vending Networking is central to almost everything inside a landing zone, and the ALZ conceptual architecture separates workloads by traffic profile to keep the attack surface small. ### Hub-and-Spoke or Virtual WAN The [hub-and-spoke topology the Cloud Adoption Framework recommends](https://learn.microsoft.com/en-us/azure/architecture/networking/architecture/hub-spoke) is the default starting point. The hub virtual network hosts the shared services: the cross-premises gateway for VPN or ExpressRoute, Azure Firewall as the primary egress point, [Azure Bastion](https://learn.microsoft.com/en-us/azure/bastion/bastion-overview) for remote access without public IPs, routing, and DNS. Spoke virtual networks isolate workloads and peer to a single hub in the same region. The critical constraint is that a hub is regional, so you get one hub per region, never one hub for everything. Azure Virtual WAN is the Microsoft-managed alternative that automates this topology, and the ALZ modules support both. Above is the standard reference deployment: spokes peer to the regional hub, and hybrid connectivity terminates at the hub's gateways. ### Corp, Online, and Connectivity The management group design maps traffic profiles to groups. Connectivity hosts platform networking: Virtual WAN or hub virtual networks, gateways, Azure Firewall, and private DNS zones. Corp hosts internal-facing workloads that route through the hub and share the corporate routing domain. Online isolates public-facing workloads from internal resources, which is the point: a compromised public web app cannot pivot straight into your internal network. If Online workloads need to reach Corp, traffic goes through the hub and Azure Firewall, where you can inspect and control it. ### Subscription Vending Subscription vending gives the architecture a delivery mechanism: a self-service request, approval, and automated provisioning pipeline, typically [Azure Pipelines](https://learn.microsoft.com/en-us/azure/devops/pipelines/get-started/what-is-azure-pipelines) or [GitHub Actions](https://docs.github.com/en/actions), that issues governed subscriptions to teams. The cloud center of excellence defines the business logic and approval process, application teams submit requests with budget, ownership, networking, and criticality information, and platform teams configure networking, place the subscription in the right management group, apply cost tags, and hand it over. The [subscription vending guidance](https://learn.microsoft.com/en-us/azure/cloud-adoption-framework/ready/landing-zone/design-area/subscription-vending) is explicit about the failure this prevents: when distribution is slow and ungoverned, teams create subscriptions through alternative billing accounts. That is shadow IT, and it's how the subscription from the introduction happens. ## Operating Your Landing Zone Deployment is the easy part. The practices below determine whether your landing zone is still a landing zone in two years. ### Cost Management and FinOps The search results barely mention FinOps for landing zones, which is odd, because the architecture multiplies both your subscription count and your cost surfaces. The controls belong in the platform, not on each team. Set budgets and alerts in [Microsoft Cost Management](https://learn.microsoft.com/en-us/azure/cost-management-billing/cost-management-billing-overview) at the management group scope so every subscription beneath it inherits them. Enforce a tagging standard with append-mode policies so cost allocation by department, workload, and environment works, then charge costs back with tag-based allocation. Layer reservations and savings plans on stable workloads. A dedicated FinOps team is optional. The platform enforces the tagging and budget baseline, and that enforcement is a policy problem, not a finance problem. ***Key Insight: The platform is code, so its costs are code too.*** Treat the landing zone like the application software you already review: versioned and tested, with every change flowing through pull requests. Budgets, tagging policies, and module versions all flow through the same pipeline you built in this tutorial. ### Keep the Platform Current The ALZ policy library updates on a cadence, and drifting from it slowly erodes your governance. Track the [ALZ policy library releases](https://github.com/Azure/Azure-Landing-Zones-Library) and apply them through your pipelines, not ad hoc. Tools like the [Azure Governance Visualizer](https://github.com/JulianHayward/Azure-MG-Sub-Governance-Reporting) and the policy version checker show what is assigned and how far behind you are. Review assignments quarterly against the regulatory requirements you actually have. A policy that exists but is never enforced is worse than none, because it gives you a false sense of coverage. ### Common Failures and Fixes - Known after apply values. Some resources, like management group IDs, are only known after the plan runs, so chained deployments can fail on the first apply. Re-run the pipeline once state exists, and read the plan before you approve. - Policy conflicts between assignments. Two assignments with opposite effects on the same scope fight each other, and neither one reports the conflict. Check the compliance view and evaluation details before adding new initiatives. - Overlapping IP address spaces. Two spokes in the same routing domain with overlapping ranges break peering and hybrid connectivity. Plan addressing up front with an IPAM tool, because no policy fixes this. - The portal-first trap. The portal accelerator feels done on day one and becomes unmanageable by month six. If you started there, migrate to the IaC accelerator while the environment is still small enough to rebuild. ## Frequently Asked Questions Do I need a landing zone if my organization has five subscriptions? Five subscriptions can still be managed manually, but the moment teams start creating their own, you've already lost. The landing zone is less about size and more about whether the platform controls the flow of new environments. Can I run more than one platform landing zone? You should run one platform landing zone per Entra tenant. The ALZ hierarchy supports a canary model with multiple hierarchies under the same tenant root, but multiple full platforms each duplicate governance. How many subscriptions do I need to start? Start small: Identity, Connectivity, Management, and Security for the platform, plus one application landing zone for your first workload. The design scales by adding subscriptions, so you don't need to predict the future on day one. Is Azure Blueprints involved? No. [Azure Blueprints](https://learn.microsoft.com/en-us/azure/governance/blueprints/overview) is being retired: the phased retirement began July 31, 2026, and ends January 31, 2027, with Microsoft recommending Deployment Stacks and Template Specs as the migration path. If you see Blueprints in older material, ignore it and follow the deployment options in this post. How long does a full deployment take? The bootstrap creates the pipelines and hierarchy in under an hour; the platform deployment typically completes within a couple of hours after you approve the apply. ## Next Steps: Land Your First Workload You now have the full picture: a platform landing zone built from the eight design areas, deployed with Terraform or Bicep, governed by policy, secured by Defender for Cloud, and operated with budgets and versioned code. Pick one real workload, stand up its application landing zone through your vending process, and watch the platform do what you built it for. For a working reference, the [ALZ-Bicep repository](https://github.com/Azure/ALZ-Bicep) and the [Terraform module repository](https://github.com/Azure/terraform-azurerm-caf-enterprise-scale) are the canonical implementations behind the accelerator. The subscription from the introduction will still get created someday. With a landing zone in place, it will land in a governed spot, and you'll find out about it from the policy compliance report, not the bill. Hate ads? Want to support the writer? Get many of our tutorials packaged as an ATA Guidebook. [Explore ATA Guidebooks](https://adamtheautomator.com/ata-guidebooks/) ## More from ATA Learning and Partners - ### Recommended Resources! Recommended Resources for Training, Information Security, Automation, and more! - ### Get Paid to Write! ATA Learning is always seeking instructors of all experience levels. Regardless if you’re a junior admin or system architect, you have something to share. Why not write on a platform with an existing audience and share your knowledge with the world? - ### ATA Learning Guidebooks ATA Learning is known for its high-quality written tutorials in the form of blog posts. Support ATA Learning with ATA Guidebook PDF eBooks available offline and with no ads! ## Categories - IT Ops - Cloud - DevOps - Home Ops - Information Security - Software Development ## Site - Home - Tutorials - Guidebooks - Instructors - Get Paid to Write - Advertising - Recommended Resources - About Adam Copyright 2026© ATA Learning | [Privacy Policy](https://adamtheautomator.com/privacy/) Don't be left behind with the ATA Learning Newsletter! Looks like you're offline!