The practice of building Terraform landing zones for Azure is rooted in the need to translate Microsoft’s Cloud Adoption Framework principles into repeatable, code-driven foundations. Organizations that adopt a Terraform-driven blueprint seek to separate shared platform capabilities from workload-specific application capabilities while enforcing governance, security, and operational efficiency through Infrastructure as Code. The resulting patterns combine platform landing zones that deliver centrally managed services with application landing zones that provide dedicated, pre-provisioned subscriptions for individual workloads. The entire lifecycle is supported by Azure Verified Modules, an IaC accelerator, and opinionated reference architectures such as the AI Landing Zone.
The approach described by author David Wright provides an opinionated view on how to use a Terraform-driven blueprint for designing, deploying, and governing Azure landing zones for both shared-services platform subscriptions and application specific subscriptions, all aligned to Azure’s Cloud Adoption Framework. The document establishes clear roles, policies, and automation patterns using HCP Terraform, Vault, Sentinel, Packer so platform teams can build a secure, scalable foundation and application teams can consistently onboard workloads with guardrails and GitOps-style workflows.
Platform Landing Zone versus Application Landing Zone
Platform landing zones provide shared, centrally managed services such as identity, connectivity, and governance to all application workloads. Defined and deployed via Terraform modules, these subscriptions, for example Identity, Management, Connectivity, belong to central teams and enforce global policies to improve consistency and operational efficiency.
The impact of this separation is that platform teams retain control over the foundational controls that affect every workload while application teams gain speed. Central teams can update policy definitions, networking connectivity, and identity foundations without modifying application code. Application teams inherit the guardrails automatically through management group hierarchy.
Application landing zones provide dedicated subscriptions for individual applications. You pre-provision them through Terraform code and govern them via management-group-level policy assignments. In reference architectures, you will often see multiple application zones, for example “A1” and “A2” subscriptions, each defined by its own Terraform configuration, with tailored resources and policies.
The real-world consequence is isolation and accountability. Each application lands in its own subscription boundary with its own resource limits, cost allocation tags, and security posture. Pre-provisioning through Terraform removes manual subscription requests and ensures that every new workload starts from a known baseline.
They leverage the platform landing zone’s shared services and integrate additional application-specific resources, tagging, networking, secrets, and deployments through Terraform code, GitOps workflows, and service-mesh tooling such as Consul, Vault CSI, Flux/ArgoCD.
This integration layer connects the central platform to the workload. Terraform code declares the application-specific resources. GitOps workflows provide auditability and repeatable deployments. Service-mesh tooling provides secure secret distribution and consistent deployment patterns across applications.
The document provides prescriptive guidance on architecting Azure Landing Zones, including recommendations for structuring subscriptions and management groups. It emphasizes the importance of aligning with the Azure Cloud Adoption Framework to ensure best practices across all design areas.
Key aspects covered include structuring subscriptions and management groups to support different environments and business units, and designing secure, scalable, and compliant environments using Terraform and HCP.
Terraform Modules and Azure Verified Modules
Terraform is presented as a good tool to use if you are interested in deploying Azure landing zones. The steps outlined in tutorials, including setting up and authenticating Terraform for Azure, will help you build a well-managed foundation on which to deploy your workloads. Reading and understanding the module will allow you to build and deploy a complex but well-managed landing zone.
Azure landing zones are well-architected environments that adhere to Microsoft’s best practices for Azure cloud architecture. They provide scalability and facilitate cloud adoption by providing a well-managed foundation for teams to run their workloads.
What are Azure landing zones?
Azure landing zones provide scalability and facilitate cloud adoption. They provide a well-managed foundation for teams to run their workloads. A landing zone includes a standard set of resources and configurations for security, governance and compliance.
Azure landing zones have several key benefits you can take advantage of:
- Scalability. Azure landing zones are designed to scale with your organization’s needs. This allows for easy expansion and adaptation as your cloud footprint grows.
- Security and compliance. Built-in security controls and compliance policies protect workloads and ensure they meet regulatory requirements.
- Operational efficiency
Based on continuous feedback from the community, a more modular approach to deploying Azure landing zone with Terraform has been adopted. This new approach is based on Azure Verified Modules and is designed to be more flexible.
With the move to using Azure Verified Modules, new branding is used to describe the new offerings:
Azure Verified Modules (AVM) for Platform landing zone (ALZ) - Terraform
The community feedback that drove the change included the request to be able to fully customize the configuration of each component. Examples included defining a custom management group hierarchy, or setting specific settings (and names!) on resources.
The modular approach changes how platform teams interact with the codebase. Instead of a monolithic deployment, components can be selected, parameterized, and versioned independently. Custom management group hierarchies can be expressed as variables. Resource names and settings can be overridden per environment without forking the module.
To construct a landing zone via Terraform, critical focus areas must align with Microsoft Cloud Adoption Framework for Azure best practices across:
- Account Principles
- Architecture Type
- Resource Organisation
- Management Group Hierarchy
- Security and Compliance
- Automation and DevOps
These focus areas form a checklist for design reviews. Account Principles define who can create subscriptions and how billing is consolidated. Architecture Type determines whether a greenfield or brownfield approach is used. Resource Organisation defines naming conventions and tagging strategy. Management Group Hierarchy defines the inheritance path for policies. Security and Compliance defines baseline controls. Automation and DevOps defines how Terraform runs are triggered, approved, and audited.
IaC Accelerator Bootstrap and Continuous Delivery
Welcome to the Azure landing zone IaC Accelerator for Bicep and Terraform.
The Azure Verified Modules for Platform landing zone (ALZ) Terraform and Bicep modules provide an opinionated approach for deploying and managing the core platform capabilities of Azure landing zone architecture using Bicep or Terraform.
Head to the relevant section to get started:
- 0 - Planning - Skip this if you already know what you want to deploy
- 1 - Prerequisites
- 2 - Bootstrap
- 3 - Run
The accelerator supports both Azure DevOps and GitHub. Only the hosted versions of these services are supported.
If you are using self-hosted versions of these services or another VCS, you can still use the accelerator to produce the landing zone code by using the alz_local bootstrap module, but you will need to configure the VCS manually or with your own automation.
The accelerator bootstraps a continuous delivery environment for you. It supports both Azure DevOps and GitHub version control system (VCS). It uses the ALZ PowerShell module to gather required user input and apply a Terraform module to configure the bootstrap environment.
Note for Bicep users, the accelerator uses Terraform to bootstrap the environment only.
The bootstrap process creates the pipelines, service connections, and initial management group scaffolding required for safe production use. The ALZ PowerShell module gathers required user input, which reduces manual errors in naming and scope. Applying a Terraform module to configure the bootstrap environment ensures the initial state is codified and reproducible.
The approval is done in Azure DevOps at the Service Connection, under Approval and Checks.
This approval gate provides a human checkpoint before Terraform can authenticate to production subscriptions. Service connections are created with least privilege and checked through Azure DevOps approvals to prevent unauthorized infrastructure changes.
The Azure Landing Zone Terraform Accelerator offers a robust foundation for organizations looking to implement a well-architected Azure environment.
Through this article, the following has been explored:
- Bootstrap your environment with automation using the ALZ PowerShell module
- Configure and deploy Platform Landing Zone components using Infrastructure as Code (Terraform)
- Establish governance through management groups, policies, and controlled Azure DevOps pipelines.
The next steps after deployment are practical and operational.
Once your Platform Landing Zone is established, consider these follow-up activities:
- Document your environment: Create detailed documentation explaining your Landing Zone design choices and customizations (make sure to checkout alzlibtool)
- Establish operational procedures: Define processes for managing the environment, including approvals and adjustments to the platform
- Plan your Application Landing Zones: Design the specific landing zones for your workloads based on your organization’s needs and investigate Subscription vending.
Documenting design choices preserves institutional knowledge. Operational procedures codify who can request changes and how approvals flow. Planning application landing zones translates the platform foundation into workload-specific subscriptions with appropriate policy assignments.
AI Landing Zone as Application Pattern
The AI Landing Zone provides an enterprise-scale production ready reference architecture with implementation (Portal, Bicep & Terraform) to deploy secure and resilient AI Apps & Agents workloads in Azure.
The AI Landing Zone is an application landing zone meant to act as a foundation for various use cases, scenarios and patterns of AI Apps & Agents based workloads which can be deployed with or without platform landing zone.
The IaC implementations of the AI Landing Zone i.e. Bicep and Terraform are based on Azure Verified Modules.
The AI Landing Zone focuses on AI on Azure Platform.
This pattern demonstrates how an application landing zone can be built on top of, or independently from, a platform landing zone. The AI Landing Zone codifies the networking, security, and operational requirements specific to AI workloads while still reusing the governance model provided by Azure Verified Modules. Organizations can adopt the AI Landing Zone as a template for other workload types.
Governance, Automation and DevOps Integration
This document provides a comprehensive guide to designing, deploying, and operationalising Azure Landing Zones using Terraform and the HashiCorp Cloud Platform (HCP). It serves as a structured, opinionated methodology for establishing secure, scalable, and compliant cloud environments.
The deployment process details how to use Terraform for setting up the necessary infrastructure.
The combination of HCP Terraform with Vault, Sentinel, and Packer provides a complete automation pattern. HCP Terraform centralizes state and provides policy enforcement. Vault supplies secrets management for service principals and certificates. Sentinel provides policy-as-code checks before applies. Packer builds immutable images for the platform.
GitOps-style workflows ensure that changes to application landing zones are proposed as pull requests, reviewed, and applied automatically. The platform landing zone’s shared services are updated centrally, and those changes propagate to application zones through management group policy inheritance.
The benefits of this model are measurable in operational terms.
The table below summarizes the relationship between landing zone type and management responsibility.
| Landing Zone Type | Subscription Example | Owner | Provisioning Method | Governance Mechanism |
| Platform | Identity, Management, Connectivity | Central platform team | Terraform modules | Global policies, management group inheritance |
| Application | A1, A2 | Application team | Terraform code per zone | Management-group-level policy assignments |
The table shows how responsibilities are split. Platform subscriptions are owned centrally and provisioned via shared Terraform modules. Application subscriptions are owned by application teams and provisioned via dedicated Terraform configurations, all governed by policies inherited from the management group hierarchy.
Resources for Continued Learning
For continued learning, the following resources are referenced:
- AWESOME Azure Architecture
- Azure Landing Zones Library
- Azure landing zone design areas and conceptual architecture
- Azure Management Guide
- Azure Verified Modules
- Enterprise-scale architecture GitHub repo
For GitHub repos, reviewing Issues and Pull Requests provides insight into community challenges and evolving patterns.
Conclusion
Terraform-driven Azure landing zones represent a convergence of platform governance and application autonomy. Platform landing zones deliver shared services through Terraform modules, while application landing zones provide dedicated, pre-provisioned subscriptions governed by management group policies. The shift to Azure Verified Modules for Platform landing zone with Terraform enables customization of management group hierarchies and resource settings while preserving a modular, community-vetted foundation.
The IaC Accelerator reduces the operational overhead of bootstrapping continuous delivery with Azure DevOps or GitHub, using the ALZ PowerShell module to gather input and Terraform to configure the bootstrap environment. This creates a repeatable path from planning through prerequisites, bootstrap, and run.
The AI Landing Zone illustrates how the same patterns apply to specialized workloads, providing a production-ready reference architecture for AI Apps & Agents built on Azure Verified Modules and deployable with or without a platform landing zone.
Long-term success depends on documenting design choices, establishing operational procedures for approvals and adjustments, and planning application landing zones with subscription vending. When these practices are combined with Cloud Adoption Framework alignment across Account Principles, Architecture Type, Resource Organisation, Management Group Hierarchy, Security and Compliance, and Automation and DevOps, organizations achieve a scalable, secure, and compliant foundation for cloud workloads.