Hub-and-spoke or Virtual WAN? Routing decides, not the diagram

The choice between a classic hub-and-spoke and Virtual WAN is often presented as a decision about the architecture diagram. In practice it is a decision about how much control over routing the network team wants to keep — and whether the hub should contain an appliance that team already operates.

What actually differs

A classic hub-and-spoke is an ordinary virtual network in which everything is explicit: gateways, route tables, peerings and appliances. Nothing happens without an entry you can show to an auditor.

Virtual WAN moves part of that responsibility into a managed service. The hub maintains its own route tables, propagation and branch-to-branch connectivity, and routing intent lets a single setting steer private and internet traffic through an inspection appliance. You gain scale and operational simplicity, and give up some room for manual correction.

Routing is the right criterion

Before the topology is chosen, a few questions are worth answering:

• Is full control over route tables required? In a classic hub every route is defined by you — including more specific routes, exceptions for individual flows and disabling gateway route propagation. In Virtual WAN some of those decisions are made by the service.
• How many on-premises sites and regions are there? With dozens of branches across several regions, maintaining a full mesh of routes by hand becomes expensive. This is the strongest argument for Virtual WAN.
• What does prefix filtering look like? BGP sessions with a data centre should rarely accept everything the other side advertises. The accepted prefix range and the way it is summarised must be agreed regardless of the topology.
• Is forced tunnelling required? Sending internet-bound traffic through the data centre changes the default route design, and is usually the hardest element to reconcile with PaaS services.

Custom NVAs: where the line sits

Institutions with a security standard built around a specific firewall vendor normally want to keep it in the cloud as well. There are three sensible options:

1. An NVA in a classic hub. Complete configuration freedom, high availability provided by an internal load balancer, and path symmetry enforced by explicit routes on both sides of a flow.
2. An NVA integrated into the Virtual WAN hub. Selected vendors can be deployed directly inside the hub and take part in routing intent. Convenient, but limited to the supported list.
3. An NVA in a dedicated spoke. A compromise that keeps Virtual WAN as the backbone while inspection stays inside a network you manage — at the cost of extra routes and careful design of the return path.

Whichever option is chosen, one rule holds: a stateful appliance must see both sides of a session. Most of the problems that reach us as “connections dropping at random” turn out to be asymmetric traffic created by adding a single route in a single place.

What the diagram does not show

Two things are worth calculating early. First, cost: a Virtual WAN hub is billed for existing and for the data it processes, so in a small estate it can be more expensive than a plain virtual network with a gateway. Second, limits: connections per hub, routes per table and the throughput of scale units are hard boundaries that are better checked before a migration than during one.

Conclusion

Virtual WAN is a good choice where scale and the number of sites dominate, and the organisation accepts a managed routing model. A classic hub-and-spoke remains the right answer where the network team has to keep its own appliances and full control over every route. In the projects we run, both models coexist — the decision follows the traffic flow matrix and the inspection requirements, not a preference about the diagram.