Building Azure Landing Zones with Terraform: Management Groups, Policy, and Hub-Spoke Networking

What Is an Azure Landing Zone?

An Azure Landing Zone is a pre-configured, governed cloud environment that serves as the foundation for all workloads deployed into Azure. Rather than letting teams create subscriptions ad hoc with inconsistent configurations, a landing zone establishes standardized guardrails for networking, security, identity, governance, and operations from the very first deployment.

The concept originates from the Azure Cloud Adoption Framework (CAF), which defines a reference architecture and set of principles for enterprise-scale cloud adoption. The CAF landing zone architecture specifies a management group hierarchy, centralized networking, policy-driven governance, and platform-level shared services that every workload subscription inherits automatically.

At Citadel Cloud Management, I have deployed landing zones for organizations ranging from mid-market enterprises to large-scale global deployments. The key insight from this experience is that the landing zone is not a one-time project; it is a living platform that evolves with the organization. Terraform, with its declarative state management and modular architecture, is the ideal tool for building and maintaining this platform over time.

My terraform-azure-hub-spoke-network module provides the networking backbone for these landing zones, implementing hub-spoke topology with Azure Firewall, route tables, and VNet peering in a reusable, parameterized module that can be customized for any organization's requirements.

Management Group Hierarchy Design

Management groups are the organizational backbone of an Azure landing zone. They create a hierarchy above subscriptions that allows you to apply governance controls (Azure Policy, RBAC) at scale. Policies assigned to a management group are automatically inherited by all child management groups and subscriptions, eliminating the need to configure each subscription individually.

The CAF Recommended Hierarchy

The CAF enterprise-scale architecture recommends a specific management group hierarchy: a root Tenant Root Group, an intermediate root (often the organization name), and then functional branches for Platform (containing Identity, Management, and Connectivity subscriptions), Landing Zones (containing Corp and Online sub-groups), Decommissioned, and Sandbox environments.

Terraform Implementation

The following Terraform configuration creates the management group hierarchy with policy assignments at each level:

# Management Group Hierarchy with Policy Assignments
# Root management group
resource "azurerm_management_group" "root" {
  display_name               = "Contoso"
  parent_management_group_id = data.azurerm_management_group.tenant_root.id
}

# Platform management group
resource "azurerm_management_group" "platform" {
  display_name               = "Platform"
  parent_management_group_id = azurerm_management_group.root.id
}

# Platform sub-groups
resource "azurerm_management_group" "identity" {
  display_name               = "Identity"
  parent_management_group_id = azurerm_management_group.platform.id
  subscription_ids           = [var.identity_subscription_id]
}

resource "azurerm_management_group" "management" {
  display_name               = "Management"
  parent_management_group_id = azurerm_management_group.platform.id
  subscription_ids           = [var.management_subscription_id]
}

resource "azurerm_management_group" "connectivity" {
  display_name               = "Connectivity"
  parent_management_group_id = azurerm_management_group.platform.id
  subscription_ids           = [var.connectivity_subscription_id]
}

# Landing Zones management group
resource "azurerm_management_group" "landing_zones" {
  display_name               = "Landing Zones"
  parent_management_group_id = azurerm_management_group.root.id
}

resource "azurerm_management_group" "corp" {
  display_name               = "Corp"
  parent_management_group_id = azurerm_management_group.landing_zones.id
}

resource "azurerm_management_group" "online" {
  display_name               = "Online"
  parent_management_group_id = azurerm_management_group.landing_zones.id
}

# Sandbox and Decommissioned
resource "azurerm_management_group" "sandbox" {
  display_name               = "Sandbox"
  parent_management_group_id = azurerm_management_group.root.id
}

resource "azurerm_management_group" "decommissioned" {
  display_name               = "Decommissioned"
  parent_management_group_id = azurerm_management_group.root.id
}

# Policy assignment: Enforce allowed regions at root level
resource "azurerm_management_group_policy_assignment" "allowed_regions" {
  name                 = "allowed-regions"
  display_name         = "Allowed Regions"
  management_group_id  = azurerm_management_group.root.id
  policy_definition_id = "/providers/Microsoft.Authorization/policyDefinitions/e56962a6-4747-49cd-b67b-bf8b01975c4c"
  enforce              = true

  parameters = jsonencode({
    listOfAllowedLocations = {
      value = var.allowed_regions
    }
  })
}

# Policy assignment: Require tags on resource groups
resource "azurerm_management_group_policy_assignment" "require_tags" {
  name                 = "require-rg-tags"
  display_name         = "Require Tags on Resource Groups"
  management_group_id  = azurerm_management_group.landing_zones.id
  policy_definition_id = "/providers/Microsoft.Authorization/policyDefinitions/96670d01-0a4d-4649-9c89-2d3abc0a5025"
  enforce              = true

  parameters = jsonencode({
    tagName = {
      value = "CostCenter"
    }
  })
}

# Policy assignment: Deny public IP on VMs in Corp landing zone
resource "azurerm_management_group_policy_assignment" "deny_public_ip" {
  name                 = "deny-vm-public-ip"
  display_name         = "Deny Public IP on VMs"
  management_group_id  = azurerm_management_group.corp.id
  policy_definition_id = "/providers/Microsoft.Authorization/policyDefinitions/83a86a26-fd1f-447c-b59d-e51f44264114"
  enforce              = true
}

This configuration establishes the full CAF hierarchy and applies foundational policies. The allowed regions policy at the root level ensures resources can only be deployed in approved geographic locations, while the tag requirement and public IP denial are scoped to the appropriate management groups.

Azure Policy Governance at Scale

Azure Policy is the engine that transforms a management group hierarchy from an organizational chart into an enforcement framework. Policies can audit, deny, modify, or deploy resources based on compliance rules. For landing zones, policies fall into several categories: security baselines, cost controls, naming conventions, networking restrictions, and operational standards.

Policy Initiative Strategy

Rather than assigning individual policies, group related policies into Policy Initiatives (also called Policy Sets). This simplifies management and provides cohesive compliance reporting. For example, create initiatives for "Security Baseline," "Network Restrictions," "Cost Management," and "Operational Standards," then assign each initiative to the appropriate management group.

The terraform-azure-security-center module deploys Microsoft Defender for Cloud with auto-provisioning and ties security policies to the landing zone management group hierarchy, ensuring that every subscription automatically receives security monitoring and vulnerability assessment.

Essential Policy Categories

Security policies should enforce encryption at rest for storage accounts and databases, require HTTPS for web applications, mandate network security groups on subnets, enable Azure Defender on subscriptions, and deny the creation of classic (non-ARM) resources. Networking policies should deny public IP addresses in corporate landing zones, require private endpoints for PaaS services, enforce route table associations, and restrict VNet peering to the hub network only. Operational policies should require diagnostic settings on all resources, enforce resource locks on production subscriptions, mandate backup policies for VMs and databases, and require specific tag key-value pairs for cost allocation.

Hub-Spoke Networking Architecture

Hub-spoke is the recommended networking topology for Azure landing zones. The hub VNet contains shared networking services (Azure Firewall, VPN/ExpressRoute gateways, Azure Bastion, DNS resolvers), while spoke VNets host workloads. Spokes connect to the hub via VNet peering and route traffic through the hub for centralized inspection and control.

Hub VNet Design

The hub VNet typically includes subnets for the Azure Firewall (AzureFirewallSubnet, minimum /26), Gateway (GatewaySubnet, recommended /27), Azure Bastion (AzureBastionSubnet, minimum /26), DNS resolvers, and shared services like domain controllers. The hub is deployed in the Connectivity subscription and managed by the platform team.

My terraform-azure-virtual-network module handles VNet creation with configurable subnets, NSGs, route tables, and service endpoints, serving as the building block for both hub and spoke networks in the landing zone.

Spoke VNet Connectivity

Each spoke VNet peers with the hub, enabling communication with shared services and other spokes (through the hub firewall). User Defined Routes (UDRs) on spoke subnets direct all traffic to the Azure Firewall's private IP, ensuring that all egress and inter-spoke traffic passes through the centralized inspection point. This is critical for maintaining visibility and enforcing network security policies.

IP Address Planning

Effective IP address management (IPAM) is one of the most underestimated aspects of landing zone design. Plan for growth from day one. Use non-overlapping RFC 1918 address spaces, allocate large enough CIDR blocks for each spoke to accommodate future growth, and document IP allocations centrally. A common pattern is to use 10.0.0.0/16 for the hub, 10.1.0.0/16 through 10.255.0.0/16 for spokes, and reserve 172.16.0.0/12 for on-premises connectivity.

Azure Firewall and Network Security

Azure Firewall sits at the center of the hub-spoke topology, providing centralized network and application rule enforcement. Azure Firewall Premium adds TLS inspection, IDPS (Intrusion Detection and Prevention), URL filtering, and web categories, making it suitable for enterprise security requirements.

Firewall Policy Design

Use Azure Firewall Manager with a hierarchical firewall policy structure. Create a base policy at the root level with rules that apply to all environments (such as allowing DNS, NTP, and Azure management traffic), then create child policies for development and production environments with environment-specific rules. This inheritance model mirrors the management group hierarchy and keeps firewall policies maintainable as the environment grows.

Forced Tunneling Considerations

When you configure UDRs to route all spoke traffic through the firewall (forced tunneling), you must carefully handle asymmetric routing for Azure PaaS services. Use service tags in UDRs to avoid routing Azure management traffic through the firewall, and leverage Azure Firewall's built-in support for Azure service endpoints and private endpoints.

Azure Bastion and Secure Connectivity

Azure Bastion provides secure RDP/SSH access to VMs without exposing public IP addresses. In a landing zone architecture, deploy a single Azure Bastion instance in the hub VNet. With VNet peering and proper routing, Bastion can connect to VMs in any spoke VNet, eliminating the need for jump boxes or VPN connections for administrative access.

Azure Bastion Standard SKU supports native client connections (using the Azure CLI), file transfer, and shareable links, making it a comprehensive replacement for traditional bastion hosts. Combined with Just-In-Time (JIT) VM access from Microsoft Defender for Cloud, this provides a zero-trust approach to infrastructure administration.

Subscription Vending Automation

Subscription vending is the process of automating the provisioning of new Azure subscriptions with pre-configured governance, networking, and security. When a team requests a new workload environment, the vending process creates a subscription, places it in the appropriate management group, creates and peers a spoke VNet, configures route tables to send traffic through the firewall, applies baseline RBAC assignments, enables diagnostic settings, and registers the subscription with Microsoft Defender for Cloud.

Terraform-Based Vending Pipeline

The vending pipeline is typically implemented as a CI/CD pipeline (GitHub Actions, Azure DevOps, GitLab CI) triggered by a pull request to a configuration repository. Teams submit a YAML file describing their requirements, the platform team reviews and approves the PR, and the pipeline runs Terraform to provision the subscription and all associated resources.

My multi-cloud-landing-zone module provides a reference implementation for this pattern, supporting both Azure and AWS landing zone deployments from a single configuration repository with environment-specific variable files.

Identity and Access Management

Azure landing zones leverage Microsoft Entra ID (formerly Azure AD) as the identity provider. The Identity subscription hosts domain controllers (if needed for hybrid scenarios), Entra ID Connect servers, and identity-related services. RBAC assignments should follow the principle of least privilege, using built-in roles wherever possible and creating custom roles only when no built-in role matches the requirement.

Privileged Identity Management

For elevated access to production environments, implement Privileged Identity Management (PIM) with just-in-time activation, approval workflows, and time-limited role assignments. This ensures that standing admin access to production is eliminated, and all privileged operations are logged and auditable.

Centralized Logging and Monitoring

The Management subscription hosts centralized Log Analytics workspaces, Azure Monitor, and diagnostic storage accounts. All resources across all subscriptions send diagnostic logs and metrics to the central workspace using Azure Policy-driven diagnostic settings. This provides a single pane of glass for security monitoring, operational alerts, and compliance reporting.

Deploy Azure Sentinel (Microsoft Sentinel) on the central Log Analytics workspace for SIEM/SOAR capabilities. Configure data connectors for Microsoft Entra ID sign-in logs, Azure Activity logs, Microsoft Defender for Cloud alerts, and network flow logs from Azure Firewall and NSGs.

Top 10 Azure Landing Zone Best Practices

Azure Landing Zone Approaches Comparison

Frequently Asked Questions