Article

Hub-and-Spoke vs Full-Mesh — Picking a Network Topology

10 May 2026·6 min read·VantagePoint Networks

Pick the wrong topology and you live with the consequences for years — surprise costs, slow inter-site traffic, or the entire estate going dark when one site fails.

This is the practical decision guide for UK multi-site businesses choosing between hub-and-spoke, full-mesh, and partial-mesh topology. No marketing, just the trade-offs that actually matter.

The three topologies in one sentence each

Hub-and-spoke: every site has a tunnel to a central HQ, but no direct tunnels between sites.

Full mesh: every site has a tunnel to every other site.

Partial mesh: most sites are hub-and-spoke, but a few high-traffic pairs have direct tunnels.

Hub-and-spoke — when it wins

Hub-and-spoke is the default for most UK multi-site businesses. It wins on three things: simplicity, cost, and operational visibility.

You only have one set of inbound rules to manage at the hub. Bandwidth investment concentrates at HQ where you can centralise security inspection, web filtering, and threat intelligence. Adding a new site means one new tunnel, not N new tunnels.

It loses on inter-site latency (every packet between sites traverses the hub) and on hub failure resilience (if the hub goes down, all sites are isolated from each other and from anything HQ-hosted).

Best fit: most businesses with a strong HQ, predominantly outbound internet traffic, low inter-site traffic.
Common pitfall: backhauling SaaS through the hub adds 20–40ms to every Microsoft 365 or Salesforce session.

Full mesh — when it wins

Full mesh wins when sites need direct, low-latency communication or when no single site can act as a reliable hub.

It loses on operational complexity. With N sites you have N×(N−1)/2 tunnels — a 20-site full mesh is 190 tunnels. Adding a new site means setting up 20 new tunnels and updating 20 existing sites.

Best fit: small estates (under 8 sites) with heavy inter-site traffic; or any deployment using SD-WAN where the platform automates mesh management.
Common pitfall: trying to manage a 50-tunnel mesh manually with vanilla IPsec configs. Use SD-WAN or accept partial mesh.

Partial mesh — the practical answer

Most networks above 10 sites end up partial mesh in practice. The pattern: hub-and-spoke as the baseline, plus direct tunnels between specific high-traffic site pairs.

Common direct-tunnel pairs include: production sites that exchange large data flows, regional clusters where 80% of traffic stays local, or DR-paired sites where replication latency matters.

Designed deliberately, partial mesh delivers the operational simplicity of hub-and-spoke for most paths and the latency benefits of full mesh where they matter.

How SD-WAN changes the picture

SD-WAN platforms manage the topology decision for you. The control plane is logically hub-and-spoke (centralised policy, monitoring, key distribution), but the data plane can mesh dynamically — a tunnel only forms between two sites when there's actual traffic between them, then tears down when idle.

This means an SD-WAN deployment gets the simplicity of hub-and-spoke management with the latency benefits of full mesh where it counts. For estates above 10 sites, SD-WAN is essentially the only sane way to run mesh.

Quick decision matrix

Use this rough framework:

Under 5 sites with heavy inter-site traffic: full mesh, manual IPsec is fine.
Under 10 sites, predominantly HQ-hub workflows: hub-and-spoke.
10–50 sites: SD-WAN with dynamic mesh.
50+ sites: SD-WAN, no real alternative.
Sites with heterogeneous regional density (clusters of high-traffic sites separated by quieter sites): SD-WAN with regional hubs.

Frequently asked

Can hub-and-spoke handle SaaS traffic well?

Only if you enable local internet breakout at each spoke. Backhauling SaaS through the central hub adds latency and saturates HQ uplinks. Most modern SD-WAN and SASE platforms allow split-tunnelling — SaaS goes direct, internal-app traffic goes via the hub.

Is full mesh inherently more secure?

No. Both topologies use the same encryption (IPsec, WireGuard) on the tunnels themselves. Mesh has more tunnels to manage, which can mean more configuration drift and more attack surface if managed manually. Hub-and-spoke is easier to govern centrally.

How does the topology decision affect resilience?

Hub-and-spoke has a single point of failure at the hub — if HQ's router fails, everything stops. Common mitigations: HA pair at the hub, dual-hub design (active/active), or a backup hub at a secondary site. Full mesh has no central failure point but does have N×(N-1) tunnel pairs to monitor.

What about cloud as the hub?

Increasingly common — Azure Virtual WAN, AWS Cloud WAN, and Cloudflare Magic WAN all act as cloud hubs replacing on-prem HQ. Benefits: HQ failure doesn't take down the network, and SaaS-heavy workloads stay close to where the apps live. Trade-off is recurring cloud bandwidth costs.

Can topology change without re-cabling?

Yes — topology lives at the routing/tunnel layer, not the cabling layer. The same fibre and circuits can carry hub-and-spoke today and partial mesh tomorrow. Migration usually means new tunnel configurations and possibly an SD-WAN platform layer, not new cables.

Design your own network

VP Compass is a free interactive topology designer. Pick a template, customise, export.

Open VP Compass →