Hub-spoke networking places shared connectivity, DNS, firewall, and hybrid gateways in a hub while workload VNets use spokes. Azure Virtual WAN provides a Microsoft-managed global transit architecture with virtual hubs for branch, VPN, ExpressRoute, routing, and security integration. Choose from scale, topology, operations, partner support, routing control, and cost.
The hub normally lives in a connectivity subscription. Workload teams own spokes/application subscriptions. VNet peering is non-transitive, so user-defined routes and gateway transit/firewall behavior must be explicit.
Evaluate Virtual WAN when many regions, branches, remote users, VPN/ExpressRoute connections, and transitive routing need a managed backbone. A secured virtual hub can integrate Azure Firewall. Virtual WAN reduces custom route-server/appliance work but introduces its own routing intent, hub, scale-unit, feature, and cost model.
Do not choose it only because “enterprise” appears in the project name. Compare a concrete route matrix and operating process.
Ways to build
Choose the Azure tool you want to use. The underlying resource stays the same.
Create hub and spoke VNets, open Peerings on each VNet, and create both directions with the correct forwarded-traffic and gateway-transit settings. Deploy the approved firewall, gateway, and DNS resolver; associate route tables and NSGs; then test each allowed and denied flow.
Maintain a source/destination/port/next-hop matrix. Use effective routes, Network Watcher connection troubleshoot, firewall logs, NSG flow logs, VPN/ExpressRoute route views, and actual application probes. Test failure paths: firewall unavailable, route withdrawn, secondary region, DNS resolver loss.
Avoid broad 0.0.0.0/0 routes without understanding platform service traffic and asymmetric paths. Route tables change next hop; they do not authorize traffic.
Bicep/Terraform modules should separate connectivity platform from workload spokes. A subscription-vending workflow creates the spoke, peers/connects it, associates route/DNS/policy, and delegates application subnets. Workload teams should not be able to remove central inspection routes without an approved process.
Use Azure Virtual Network Manager where its connectivity/security-admin configuration fits a large fleet. Review scope and rollout in audit/test groups before broad application.
Include peering transfer, firewall hourly/data processing, gateways, Virtual WAN hubs/scale, Private Link, DNS resolver, DDoS plan, public IPs, and logs. A central hub can become a shared failure domain; use zone-resilient services, regional hubs, capacity planning, and tested failover.