Quick take: Hub-and-spoke gives you full control but makes you the network manager. Virtual WAN hands the routing matrix to the cloud provider and is unbeatable when you have many regions, branches, and VPNs to connect.
LogiFlow ran their Azure estate as a collection of VNet peerings. Every new spoke required peering back to the hub and transitive routing through an NVA firewall. As they expanded to five regions and added 50 branches, route tables became unmanageable. They evaluated Virtual WAN and found it collapsed branch, site-to-site, and any-to-any routing into a single managed backbone.
The problem it solves
Traditional hub-and-spoke works until scale breaks it: too many peerings, complex route tables, transitive routing headaches, and firewall sandwich designs that become brittle. Managed transit solutions like Azure Virtual WAN and AWS Transit Gateway solve this by providing a cloud-managed routing backbone with native any-to-any connectivity, global reach, and simplified branch on-ramp.
Core concepts
| Concept | What it means in practice |
|---|---|
| Hub VNet | Central network holding shared services: firewall, DNS, VPN/ER gateways. |
| Spoke VNet | Workload network peered to the hub. |
| VNet peering | Direct link between two VNets; not transitive by default. |
| Virtual WAN hub | Managed regional hub that routes traffic between spokes, branches, and gateways. |
| Transit routing | Spoke-to-spoke traffic via the hub. |
| NVA | Network Virtual Appliance — third-party firewall or router in the hub. |
Architecture
How it works
The trade-off is control vs convenience
In hub-and-spoke you own every route table, firewall rule, and peering. In Virtual WAN the provider manages the routing matrix, but you must fit your design into the hub’s model.
Real-world scenario
LogiFlow had three Azure regions and branches in 12 countries. Their hub-and-spoke design required:
- A hub VNet in every region.
- NVAs in each hub for inspection.
- Manual route propagation for spoke-to-spoke traffic.
Migrating to Virtual WAN replaced the regional hubs with managed hubs, used the native secured hub option for firewalling, and connected branches through the integrated VPN gateway. Spoke-to-spoke traffic across regions routed automatically over the Microsoft backbone.
Advantages
- Hub-and-spoke: full control, mature firewall integration, predictable costs for small estates.
- Virtual WAN: massive scale, automated routing, built-in branch connectivity, global transit.
Disadvantages
- Hub-and-spoke: route-table sprawl, non-transitive peering, operational toil at scale.
- Virtual WAN: less granular control, vendor lock-in to cloud routing semantics, can be expensive for high bandwidth.
When to use it (and when not to)
Use hub-and-spoke when you have a small number of VNets, strong NVA requirements, or a network team that wants full control.
Use Virtual WAN or Transit Gateway when you have many regions, many branches, heavy spoke-to-spoke traffic, or you want the provider to manage routing.
Best practices
- Keep the hub workload-free except for shared network services.
- Use Azure Firewall Manager or AWS Network Manager for centralized firewall policy.
- Avoid overlapping IP spaces across spokes and regions.
- Design egress points deliberately; do not let every spoke reach the internet directly.
- Document the decision between hub-and-spoke and managed transit; revisit it every 12 months as scale changes.
- Use BGP where possible so routes propagate automatically.
The right topology is the one your team can operate reliably at your current scale.
