Azure Virtual WAN Terraform Guide

What is this Azure Virtual WAN Terraform page?

This page is a provider-specific Terraform implementation guide for Azure Virtual WAN. Instead of giving only a tiny snippet, it explains the actual Azure concepts you work with in production: virtual WAN, virtual hub, hub connection, routing, and the optional gateway services that make the platform useful at enterprise scale.

Why use Terraform for Azure Virtual WAN?

Azure Virtual WAN usually appears in larger environments where consistency matters. Teams may need multiple hubs, repeated connection patterns, secure routing, and predictable deployment workflows. Terraform helps you declare the topology once and reuse it across regions, environments, or business units.

Azure Virtual WAN explained with the 5 Ws

Core Azure Virtual WAN components in Terraform

A strong Azure page should explain provider-specific terms, not generic cloud language. These are the core pieces you should understand before using the code.

How Azure Virtual WAN works in practice

At a high level, Azure Virtual WAN acts like a managed transit backbone. Instead of creating separate independent gateways for many networks, you centralize connectivity into one or more virtual hubs.

1. Create a resource group to contain the networking resources.
2. Create a Virtual WAN as the top-level WAN container.
3. Create a Virtual Hub in a chosen Azure region with its own hub address prefix.
4. Create a spoke VNet for workloads.
5. Connect the spoke VNet to the hub using Virtual Hub Connection.
6. Optionally add VPN Gateway, ExpressRoute Gateway, or Azure Firewall secured hub.
7. Control routing behavior so workloads, branches, and security services communicate correctly.

Simple Azure Virtual WAN architecture diagram

This diagram reflects the Terraform example on this page. It starts with the most practical base pattern and can later be extended with a VPN gateway, ExpressRoute gateway, or secured hub design.

                         +--------------------------------------+
                         |          Azure Virtual WAN           |
                         |          (global construct)          |
                         +-------------------+------------------+
                                             |
                                             |
                           +-----------------v-----------------+
                           |          Azure Virtual Hub        |
                           |       Region: South Africa North  |
                           |       Hub Prefix: 10.250.0.0/24   |
                           +-----------------+-----------------+
                                             |
                    +------------------------+------------------------+
                    |                                                 |
                    |                                                 |
        +-----------v-----------+                         +-----------v-----------+
        |   Spoke VNet          |                         |   Optional Services   |
        |   10.10.0.0/16        |                         | - VPN Gateway         |
        |   App subnets         |                         | - ExpressRoute GW     |
        |   Workloads           |                         | - Azure Firewall      |
        +-----------------------+                         +-----------------------+

Azure Virtual WAN Terraform example

This example creates a resource group, Virtual WAN, Virtual Hub, spoke VNet, and hub connection. It is intentionally clean and production-friendly so you can extend it into modules later.

terraform {
  required_version = ">= 1.5.0"

  required_providers {
    azurerm = {
      source  = "hashicorp/azurerm"
      version = ">= 3.100.0"
    }
  }
}

provider "azurerm" {
  features {}
}

locals {
  project             = "cn-vwan"
  location            = "South Africa North"
  resource_group_name = "rg-cn-vwan-san-1"

  tags = {
    environment = "lab"
    workload    = "networking"
    owner       = "cloudnetworking-io"
    managed_by  = "terraform"
  }
}

resource "azurerm_resource_group" "this" {
  name     = local.resource_group_name
  location = local.location
  tags     = local.tags
}

resource "azurerm_virtual_wan" "this" {
  name                = "vwan-cn-san-1"
  resource_group_name = azurerm_resource_group.this.name
  location            = azurerm_resource_group.this.location

  type = "Standard"

  tags = local.tags
}

resource "azurerm_virtual_hub" "this" {
  name                = "vhub-cn-san-1"
  resource_group_name = azurerm_resource_group.this.name
  location            = azurerm_resource_group.this.location
  virtual_wan_id      = azurerm_virtual_wan.this.id
  address_prefix      = "10.250.0.0/24"

  tags = local.tags
}

resource "azurerm_virtual_network" "spoke" {
  name                = "vnet-cn-spoke-san-1"
  location            = azurerm_resource_group.this.location
  resource_group_name = azurerm_resource_group.this.name
  address_space       = ["10.10.0.0/16"]

  subnet {
    name           = "apps"
    address_prefix = "10.10.1.0/24"
  }

  subnet {
    name           = "data"
    address_prefix = "10.10.2.0/24"
  }

  tags = local.tags
}

resource "azurerm_virtual_hub_connection" "spoke_connection" {
  name                      = "conn-vhub-to-spoke-san-1"
  virtual_hub_id            = azurerm_virtual_hub.this.id
  remote_virtual_network_id = azurerm_virtual_network.spoke.id

  internet_security_enabled = false

  routing {
    associated_route_table_id = azurerm_virtual_hub.this.default_route_table_id

    propagated_route_table {
      labels = ["default"]
    }
  }
}

output "resource_group_name" {
  value = azurerm_resource_group.this.name
}

output "virtual_wan_name" {
  value = azurerm_virtual_wan.this.name
}

output "virtual_hub_name" {
  value = azurerm_virtual_hub.this.name
}

output "spoke_vnet_name" {
  value = azurerm_virtual_network.spoke.name
}

output "hub_connection_name" {
  value = azurerm_virtual_hub_connection.spoke_connection.name
}

# Optional if you later refactor into variables
location            = "South Africa North"
resource_group_name = "rg-cn-vwan-san-1"
virtual_wan_name    = "vwan-cn-san-1"
virtual_hub_name    = "vhub-cn-san-1"
spoke_vnet_name     = "vnet-cn-spoke-san-1"
hub_address_prefix  = "10.250.0.0/24"
spoke_address_space = ["10.10.0.0/16"]

terraform init
terraform fmt
terraform validate
terraform plan -out tfplan
terraform apply tfplan

What the Terraform code is doing

Real-world Azure Virtual WAN Terraform use cases

The strongest resource pages connect concepts to actual engineering scenarios. These are the kinds of situations where Virtual WAN becomes more appropriate than plain peering.

Azure Virtual WAN vs VNet peering vs traditional gateway design

This section helps avoid one of the biggest mistakes: choosing Virtual WAN when a simpler pattern would do, or choosing a simpler pattern when operations will later become painful.

Azure Virtual WAN Terraform best practices

• Plan address space early. Hub prefixes, spoke prefixes, branch CIDRs, and future region expansion must not overlap.
• Use Standard where appropriate. Enterprise WAN designs usually depend on Standard-level capability rather than entry-level assumptions.
• Keep naming consistent. Use region and purpose in names such as vhub-san-prod or conn-vhub-app1.
• Tag everything. Cost ownership, environment, workload, compliance, and operations tags help later.
• Modularize after the first clean deployment. Build a working reference first, then convert to reusable modules.
• Be intentional with routing. Do not leave route behavior vague when multiple spokes, branch sites, or security services exist.
• Document security posture. If using secured hubs, document which traffic should be inspected and where exceptions apply.
• Validate Azure provider support. Some Virtual WAN features evolve over time, so pin tested provider versions in production repositories.

Common mistakes engineers make with Azure Virtual WAN

Frequently asked questions about Azure Virtual WAN Terraform

Related Azure networking pages

Internal linking helps this page feel like part of a real documentation portal and improves navigation across related Azure networking topics.