The short answer
Hub and spoke sends traffic between networks through a central hub. Full mesh connects every network to every other network directly. Both join VPCs, VNets, on-premises sites, and shared services across one or more clouds. The choice affects routing, security, failure scope, and how much work each new network adds.
Pick hub and spoke when you need central control. Pick full mesh when direct paths matter more than central inspection and the number of networks stays small. Many designs blend the two: a hub for shared services and inspection, plus direct peer links for a few high-volume pairs.
| Aspect | Hub and spoke | Full mesh |
|---|---|---|
| Path between networks | Traffic goes through a central hub, often with a hairpin between spokes. | Each pair has a direct path with no central hop. |
| Routing complexity | One transit layer with route tables per segment; new spokes attach to the hub. | Every pair needs routes and policy; link count grows fast with each network. |
| Security inspection | Central firewall and logging see spoke traffic once. | Policy sits on each pair or in each network; consistent inspection takes extra design. |
| Failure scope | A hub fault can affect many paths; regional hubs reduce the blast radius. | One link failure affects only that pair, but many links need monitoring. |
| Adding a network | Attach once to the hub and inherit route policy. | Create a link to every existing network or use an overlay. |
| Best fit | Many accounts, central egress, hybrid links, and audit needs. | A small number of networks with heavy or latency-sensitive traffic. |
How hub and spoke works
The hub is a VPC or VNet that attaches to every spoke. In AWS, a transit gateway attaches VPCs, VPNs, and Direct Connect gateways. In Azure, Virtual WAN or a hub VNet with Azure Firewall does the same job. In Google Cloud, Network Connectivity Center or a central VPC with Cloud VPN can play the hub role. Spokes have route tables that point remote traffic to the hub. The hub decides whether to forward, inspect, or drop it.
Spoke to spoke traffic often goes spoke, hub, spoke. That hairpin is the point: a firewall, intrusion detection system, or egress proxy in the hub sees the flow once. Shared services such as DNS, Active Directory, logging, and artifact stores sit in the hub or a shared services spoke. You can also give a spoke a local internet path for SaaS traffic while keeping private traffic on the hub.
Watch hub capacity and route limits. Transit gateways and virtual WAN hubs have attachment quotas, route table quotas, and bandwidth limits per attachment. Plan CIDRs so spokes do not overlap, and use separate route tables for production, development, and on-premises paths. Check that return traffic follows the same path. Asymmetric routing appears when a spoke has a local firewall and a default route to the hub. Test failover for the hub, not just for one spoke.
How full mesh works
Full mesh creates a direct path between each pair of networks. In AWS you use VPC peering. In Azure you use VNet peering. Across clouds or to sites you can run IPsec VPNs or a private overlay from an SD-WAN or network appliance. Each pair needs its own route entries and security policy on both sides. The result is short paths and no central hop for east-west traffic.
The catch is arithmetic. Ten networks need 45 links. Twenty need 190. AWS VPC peering and Azure VNet peering are non-transitive: a peer of a peer is not reachable unless you add that link. Some services, such as AWS Transit Gateway peering, Azure Virtual WAN hubs, or a third-party overlay, can cut the link count while keeping near-direct paths. That is a hybrid, not pure full mesh.
Security is distributed. Each VPC or VNet needs security groups, network security groups, firewall rules, and logging that match the pair. A change to one application may need edits in several places. Troubleshooting means checking both ends of a link and the route tables between them. Use consistent naming, IP address management, and automated tests for every new peer.
When to choose hub and spoke
Choose hub and spoke when you have many accounts, environments, or business units. A central hub makes shared services, egress control, and audit simpler. Security teams get one place to inspect traffic to and from the internet and on-premises. New spokes inherit the same route policy, which cuts setup errors.
It also fits hybrid designs. Site-to-site VPNs and private circuits land in the hub, then reach every spoke. That keeps on-premises route tables small. If you run several clouds, a hub per cloud with inter-hub links is easier to govern than a mesh across every VPC and VNet.
The trade-offs are an extra hop, hub bandwidth limits, and a central failure domain. You can soften them with a hub per region, active-active hubs, and direct peering for a few chatty pairs. Do not put every packet through one appliance if the hub cannot scale with the workload.
When to choose full mesh
Choose full mesh when the number of networks is small and traffic between them is heavy. Examples include a few production VPCs running a distributed database, a set of analytics VNets exchanging large files, or a multi-account setup with tight latency between application tiers. Direct links avoid the hairpin and the hub throughput ceiling.
Full mesh also suits teams that want failure isolation by pair. One broken link does not stop traffic between unrelated networks. It can be simpler when each team owns its network and wants explicit, auditable links to specific partners.
Keep it small and automate it. Track the link count, use a central IP address management system, and generate route and firewall changes from code. Add a hub for internet egress and shared services even if private traffic is meshed. That gives you short paths without rebuilding inspection for every pair.
Costs and effort to consider
Compare the full cost of links, not just the topology. Hub and spoke adds transit gateway or virtual WAN attachment charges, firewall or appliance capacity, and data processing at the hub. Full mesh adds per-peer charges where they exist, more route table entries, and more security policy changes. Both need IP address management, monitoring, and someone to own routing.
Operations matter more than the diagram. Hub and spoke centralizes changes, which lowers the skill needed per team but creates a queue and a shared failure point. Full mesh distributes changes, which can be faster for small teams but raises the chance of drift. Count how many places a new subnet or firewall rule must be updated before you choose.
Test the design with real traffic. Measure the extra hop, check route limits, and run a hub failure drill. If you need a second opinion before committing, the Expert architecture session from Cloudverg, a one-time $450 package, is one option among others: a 90-minute call, a pre-read, and a written summary. A small pilot with two or three networks will teach you more than a large diagram.
Frequently asked questions
Is full mesh more secure than hub and spoke?
Neither is automatically more secure. Hub and spoke gives you one inspection point, which is easier to enforce. Full mesh needs policy on every pair, so consistency depends on automation and review. Choose based on where you can apply and verify controls.
Can I mix hub and spoke with full mesh?
Yes. A common pattern is a hub for internet egress, shared services, and on-premises links, plus direct peering for a few high-volume pairs. Document which paths bypass the hub and inspect those pairs another way. Keep the exceptions short and reviewed.
How many networks before full mesh becomes hard to manage?
There is no fixed number. The link count and the number of policy changes matter more than the raw count. If every new network needs links to many others, or if your team cannot test every pair, move to a hub or an overlay. Automate peer creation before you reach that point.