allenstech.io
← Back
·3 min read

Extending an Azure Landing Zone into a new region with vWAN

How to add a Central US region to an existing Azure Landing Zone that already has a vWAN hub in East US 2, using Terraform and AVM modules without redeploying the hub.

The existing Azure Landing Zone (ALZ) in East US 2 already deployed a vWAN hub‑spoke topology. I needed to extend connectivity into Central US without rebuilding the entire hub. The solution was to build the Central US resources in Terraform, reference the existing vWAN via a data source, and attach the new hub to that instance.

Why extend instead of rebuild

  • Cost – Re‑creating the hub would duplicate resources that already exist, driving up spend.
  • Time – Redeploying the hub requires re‑configuring all spokes, which is a lengthy process.
  • Risk – A rebuild could introduce configuration drift and break existing traffic flows.
  • Consistency – Extending preserves the established policy and routing configuration that the East US 2 hub already enforces.

Data source pattern for cross‑module references

Terraform allows a module to reference resources created outside its scope using a data source. In this case the existing vWAN was deployed with an AVM resource module. The new Central US module pulls the vWAN ID with:

data "azurerm_virtual_wan" "existing" {
  name     = "eastus2-vwan"
  location = "East US 2"
}

The data.azurerm_virtual_wan.existing.id value is then used as the virtual_wan_id for the new hub, ensuring the Central US hub attaches to the same vWAN instance.

Terraform implementation

The Central US resources are defined in a dedicated module that uses AVM modules for each component.

module "centralus_vwan" {
  source  = "Azure/avm-resources-virtualwan/azurerm"
  version = "0.1.0"

  name                = "centralus-vwan"
  location            = "Central US"
  virtual_wan_id      = data.azurerm_virtual_wan.existing.id
  tags                = var.tags
}

module "centralus_firewall" {
  source  = "Azure/avm-resources-firewall/azurerm"
  version = "0.1.0"

  name                = "centralus-fw"
  location            = "Central US"
  virtual_hub_id      = module.centralus_vwan.virtual_hub_id
  sku                 = "Premium"
  tags                = var.tags
}

module "centralus_vpn_gateway" {
  source  = "Azure/avm-resources-vpngateway/azurerm"
  version = "0.1.0"

  name                = "centralus-vpn-gateway"
  location            = "Central US"
  virtual_hub_id      = module.centralus_vwan.virtual_hub_id
  tags                = var.tags
}

module "centralus_dns_resolver" {
  source  = "Azure/avm-resources-dnsresolver/azurerm"
  version = "0.1.0"

  name                = "centralus-dns-resolver"
  location            = "Central US"
  virtual_hub_id      = module.centralus_vwan.virtual_hub_id
  tags                = var.tags
}

Each module pulls the virtual_hub_id from the vWAN module, which in turn references the existing vWAN via the data source. This keeps the Central US hub in sync with the global vWAN configuration.

vWAN hub‑spoke topology across regions

  • The vWAN hub in East US 2 remains the central routing point for all spokes in that region.
  • The new Central US hub is added as a spoke to the same vWAN, allowing traffic to flow between East US 2 and Central US without additional peering.
  • Azure Firewall Premium, VPN Gateway, and DNS Private Resolver are deployed within the Central US hub, providing security, connectivity, and name resolution for resources in that region.
  • All hubs share the same global vWAN, so policies and routing rules apply consistently across regions.

Summary

By referencing the existing vWAN with a Terraform data source, I avoided redeploying the hub and preserved the established routing and policy configuration. The AVM modules made it straightforward to spin up the necessary Central US resources, and the hub‑spoke topology naturally extended across regions. This approach saves cost, time, and reduces the risk of configuration drift in a multi‑region Azure Landing Zone.

Tagged with:

AzureTerraformNetworkingALZvWAN