Build Azure Virtual WAN hub, VPN site, and VNet connection configurations.
Last verified: May 2026
Build Virtual WAN hub, VPN site, and VNet connection configurations.
Required Fields
nameresourceGrouptypevirtualHubsvirtualHubs[0].namevirtualHubs[0].addressPrefixOutput will appear here...Azure Virtual WAN is a networking service that provides optimized and automated branch-to-branch, branch-to-Azure, and Azure-to-Azure connectivity through a Microsoft-managed hub-and-spoke architecture. A Virtual WAN can contain multiple hubs across regions, each supporting VPN gateways (site-to-site and point-to-site), ExpressRoute gateways, and VNet connections. The Virtual WAN Config Builder helps you design hub configurations with gateway settings, VPN site definitions, VNet connections, and routing preferences for enterprise-scale network architectures.
In a traditional hub-and-spoke, you deploy and manage your own hub VNet, NVAs, VPN gateways, and route tables. Virtual WAN provides a Microsoft-managed hub with built-in gateway redundancy, automated spoke-to-spoke routing, and integration with SD-WAN partners. Virtual WAN hubs support transitive routing by default (any spoke can reach any other spoke), whereas traditional hub-and-spoke requires NVAs or route tables for transitive connectivity. Virtual WAN also supports inter-hub routing across regions automatically.
The Basic SKU supports only site-to-site VPN connections and is intended for simple branch connectivity. The Standard SKU supports site-to-site VPN, point-to-site VPN, ExpressRoute, inter-hub transit, VNet-to-VNet transit, Azure Firewall integration, and NVA hosting. Most enterprise deployments require the Standard SKU. You can upgrade from Basic to Standard but cannot downgrade. Per-hub costs include the hub fee plus data processing charges for traffic flowing through the hub.
Your team is consolidating 30 spoke VNets across 3 regions onto a Virtual WAN. The builder generates: Virtual WAN Standard with 3 hubs (one per region), each hub with VPN + ExpressRoute gateways, all 30 spoke VNets connected via VNet connections, separate route tables for prod/dev/shared-services. Inter-hub transit means the team's Tokyo-region devs can connect to US-region prod via the WAN backbone automatically. Networking management consolidates from 30 individual VNet peerings + 6 NVAs to a single Virtual WAN definition. Operational simplification: substantial.
The builder constructs Virtual WAN configurations: Virtual WAN resource (name, type: Standard or Basic), Hub resources (per region, with address space and gateway settings), VPN gateway config (scale units, BGP enable, custom IPsec policy), ExpressRoute gateway config, hub VNet connections, and route tables for traffic isolation. Output is generated as az network vwan + az network vhub commands and Terraform azurerm_virtual_wan + azurerm_virtual_hub resources.
Virtual WAN Standard SKU is the right choice for any non-trivial deployment. Basic only supports site-to-site VPN — most enterprises need ExpressRoute, point-to-site, or VNet transit. The cost difference is small at scale; the feature gap is enormous.
Inter-hub transit (spoke-to-spoke routing across regions) is a Virtual WAN killer feature. Traditional hub-and-spoke requires NVAs or careful UDR config to route between regions. Virtual WAN does this automatically — Microsoft routes spoke-A in eastus to spoke-B in westeurope through their global backbone with no extra config.
Virtual WAN charges per-hub fee + data processing. For organizations with <5 spoke VNets and simple requirements, traditional hub-and-spoke can be cheaper. The breakpoint where Virtual WAN wins is roughly 10+ spokes or multi-region requirements — at that scale, the operational simplification justifies the per-hub fees.
Was this tool helpful?
Disclaimer: This tool runs entirely in your browser. No data is sent to our servers. Always verify outputs before using them in production. AWS, Azure, and GCP are trademarks of their respective owners.