August 29, 2026
12 min read
Table of Contents
By Kokil Thapa | Last reviewed: August 2026
When you run production workloads across AWS, Azure, and GCP, the first architectural fork is network topology. Hub-and-Spoke vs Mesh Multi-Cloud Networking is not an abstract certification question—it determines whether your Laravel API in one region can reach a PostgreSQL replica in another cloud without routing through five hops, whether a payment webhook from Khalti times out, and whether your monthly cloud bill includes Rs 80,000 (~USD 600) in unnecessary transit fees. I've seen small teams inherit a full mesh they cannot operate, and larger deployments suffocate inside a single hub that becomes a single point of failure. This guide compares both models with concrete routing, security, and cost criteria you can apply on your next multi-cloud architecture project.
Quick answer: Hub-and-spoke multi-cloud networking routes all inter-cloud traffic through a central hub (transit gateway, NVA, or SD-WAN appliance), simplifying policy and inspection. Full mesh connects every cloud VPC/VNet directly, reducing latency but multiplying tunnels, routes, and operational burden as clouds grow.
What is hub-and-spoke multi-cloud networking?
Hub-and-spoke multi-cloud networking treats one network segment as the central exchange point—the hub—and connects every cloud environment as a spoke. Traffic between AWS and Azure does not go direct; it flows AWS spoke → hub → Azure spoke. The hub is usually a dedicated VPC on AWS with a Transit Gateway, an Azure Virtual WAN hub, a GCP Network Connectivity Center hub, or a third-party network virtual appliance (NVA) running on a neutral provider.
In practice, the hub carries shared services that every environment needs: centralized egress through a NAT gateway or firewall, DNS forwarding, VPN concentrators, intrusion detection, and sometimes a bastion or jump host for admin access. Spokes hold application workloads—your Laravel app on EC2, a WooCommerce store on DigitalOcean, a staging cluster on Azure App Service.
Core components
- Hub VPC/VNet: A dedicated network segment with no application workloads, only networking appliances and shared services.
- Spoke VPCs/VNets: One per cloud account, region, or environment (production, staging, DR).
- Transit attachment: AWS Transit Gateway peering, Azure Virtual WAN connection, GCP VLAN attachment, or IPsec/WireGuard tunnels to an NVA.
- Route tables: Spokes point default or selective routes to the hub; the hub maintains a full routing table for all spokes.
- Centralized security stack: Firewall rules, WAF, and logging applied once at the hub instead of per-spoke.
A pattern I use on client projects with three or fewer cloud footprints: pick AWS as the hub because Transit Gateway peering and Site-to-Site VPN are mature, attach Azure via Virtual WAN or a VPN to the hub NVA, and attach GCP through Partner Interconnect or a high-throughput IPsec tunnel. Shared services—centralized logging, Prometheus scrapers, HashiCorp Vault—live in the hub. Application teams deploy only to spokes.
What is mesh multi-cloud networking?
Mesh multi-cloud networking connects every network segment directly to every other segment that needs to communicate. If you have AWS production, AWS staging, Azure production, and GCP analytics, a full mesh creates a tunnel or peering link between each pair. With four segments, that is six bidirectional connections; with six segments, fifteen.
Partial mesh is more common in production: you mesh only the segments with high cross-talk—production API and production database—while keeping staging isolated behind a hub or a single VPN. Full mesh shines when latency between specific pairs matters more than operational simplicity, such as real-time replication between PostgreSQL primaries and read replicas across regions and clouds.
Mesh connection types
- Cloud-native peering: AWS VPC peering (same region), Azure VNet peering, GCP VPC peering—fast, private, but limited to one cloud.
- Cross-cloud VPN: IPsec tunnels between cloud VPN gateways; works everywhere but adds encryption overhead and per-tunnel management.
- Private interconnects: AWS Direct Connect, Azure ExpressRoute, GCP Cloud Interconnect, cross-connected at a colocation facility for predictable latency.
- Overlay networks: WireGuard mesh (Tailscale, Netbird), Cloudflare Tunnel, or Consul Connect service mesh at L7 rather than L3.
On a production Laravel application with Redis-backed queues and a cross-cloud read replica, I've used partial mesh: direct AWS-to-GCP tunnel for database replication (latency-sensitive), while admin traffic and CI/CD runners route through a hub. That hybrid is normal—purist full mesh or pure hub-and-spoke is rare at scale.
How do hub-and-spoke vs mesh multi-cloud networking compare?
The comparison comes down to four engineering constraints: operational complexity, latency, security posture, and cost. Neither model wins on every axis.
| Criterion | Hub-and-Spoke | Full Mesh |
|---|---|---|
| Tunnel count (N clouds) | N tunnels (each spoke → hub) | N(N−1)/2 tunnels |
| Latency | Extra hop through hub (+2–15 ms typical) | Direct path, lowest possible |
| Security inspection | Single choke point—easy to enforce | Per-link or per-segment policy required |
| Blast radius | Hub failure isolates all spokes | Single tunnel failure affects one pair |
| Route table complexity | Simple at spokes; complex at hub | Complex everywhere |
| Egress cost | Centralized—predictable, sometimes cheaper | Per-link data transfer charges add up |
| Best team size | Small ops teams (1–3 engineers) | Dedicated network/platform team |
| Scales to | 10+ spokes with one hub pair (HA) | ~5 segments before pain; partial mesh beyond |
For a Nepal-based SaaS with production on AWS ap-south-1 (Mumbai), staging on Hetzner, and backups on Azure—hub-and-spoke through an AWS Transit Gateway hub costs roughly Rs 12,000–25,000/month (~USD 90–185) in gateway attachment and data processing fees. A full mesh across the same three segments adds two extra VPN tunnels, duplicate route maintenance, and roughly 30% more engineer time during incidents. Unless you measure replication lag in milliseconds and lose money on it, hub-and-spoke is the default I'd recommend.
When should you choose hub-and-spoke over mesh?
Choose hub-and-spoke when your team is small, your compliance requirements demand centralized inspection, or you have more than four cloud segments. Choose mesh—or partial mesh—when two specific segments exchange high-volume, latency-sensitive traffic and you have staff to maintain redundant tunnels.
Hub-and-spoke fits these scenarios
- Regulated workloads: PCI-DSS, ISO 27001, or client contracts requiring all east-west traffic through an inspected path.
- Centralized egress: One NAT gateway and one set of allowlisted IPs for third-party API callbacks (payment gateways, SMS providers).
- Multi-tenant SaaS: Each customer environment is a spoke; hub enforces tenant isolation policies.
- Small platform teams: One Terraform module attaches a new spoke; no N² tunnel matrix to update.
- Shared services concentration: Vault, CI runners, log aggregators, and Prometheus/Grafana live in the hub.
Mesh fits these scenarios
- Database replication: PostgreSQL streaming replication or MySQL semi-sync across clouds where every millisecond of lag matters.
- Real-time APIs: WebSocket backends, Livewire apps with cross-region session affinity, or inventory sync between eCommerce and ERP.
- Two-cloud only: AWS + GCP with one production path—mesh is just one tunnel.
- Edge-heavy workloads: K3s clusters at branch offices meshed with WireGuard overlay; no central hub near the edge.
How do you implement hub-and-spoke multi-cloud networking in practice?
Implementation starts with picking the hub cloud and defining CIDR blocks that never overlap. A common mistake is deploying AWS 10.0.0.0/16 and Azure 10.0.0.0/16—routing cannot distinguish them. Plan CIDRs before provisioning anything.
Step 1: Plan address space
Hub VPC (AWS): 10.255.0.0/16
AWS Production spoke: 10.10.0.0/16
AWS Staging spoke: 10.20.0.0/16
Azure Production spoke: 10.30.0.0/16
GCP Analytics spoke: 10.40.0.0/16
On-prem office: 192.168.0.0/16Step 2: Deploy the hub Transit Gateway
Using Terraform with multi-cloud state management keeps hub and spoke modules versioned together:
resource "aws_ec2_transit_gateway" "hub" {
description = "multi-cloud-hub"
default_route_table_association = "disable"
default_route_table_propagation = "disable"
vpn_ecmp_support = "enable"
tags = {
Name = "multi-cloud-hub-tgw"
}
}
resource "aws_ec2_transit_gateway_vpc_attachment" "hub_vpc" {
subnet_ids = aws_subnet.hub_private[*].id
transit_gateway_id = aws_ec2_transit_gateway.hub.id
vpc_id = aws_vpc.hub.id
}
resource "aws_ec2_transit_gateway_vpc_attachment" "prod_spoke" {
subnet_ids = var.prod_private_subnet_ids
transit_gateway_id = aws_ec2_transit_gateway.hub.id
vpc_id = var.prod_vpc_id
}Step 3: Attach Azure via VPN to the hub
Azure Virtual WAN can peer with AWS Transit Gateway through a third-party NVA or a VPN tunnel between Azure VPN Gateway and AWS Virtual Private Gateway attached to the Transit Gateway. For a detailed cross-cloud walkthrough, see the AWS-to-GCP networking guide—the IPsec parameters (IKEv2, AES-256, DH group 14) apply equally to Azure attachments.
resource "azurerm_virtual_network_gateway" "hub_vpn" {
name = "hub-vpn-gateway"
location = azurerm_resource_group.hub.location
resource_group_name = azurerm_resource_group.hub.name
type = "Vpn"
vpn_type = "RouteBased"
sku = "VpnGw2"
active_active = true
ip_configuration {
name = "vnetGatewayConfig"
public_ip_address_id = azurerm_public_ip.vpn.id
private_ip_address_allocation = "Dynamic"
subnet_id = azurerm_subnet.gateway.id
}
}Step 4: Configure route tables and security
Spoke route tables send inter-cloud CIDRs to the Transit Gateway attachment. The hub route table knows all spoke CIDRs. Network ACLs and security groups at the hub enforce allowlists—only port 5432 from 10.10.0.0/16 to 10.30.0.0/16, for example. Enable flow logs on every attachment; ship them to a central S3 bucket or Azure Log Analytics.
Step 5: High availability for the hub
A single hub is a single point of failure. Run the hub across two availability zones minimum. For Transit Gateway, use appliance mode on attachments that need symmetric routing through an NVA. Deploy a standby hub in a second region with BGP failover if your RTO is under 15 minutes. Document the failover in your disaster recovery runbook before you need it at 2 a.m.
What are common mistakes when designing multi-cloud network topology?
These failures show up repeatedly on projects I audit or inherit.
Overlapping CIDR blocks
You cannot route 10.0.0.0/16 to two different destinations. Plan IPAM before the first terraform apply. Use a spreadsheet or NetBox; assign /16 blocks per cloud account and environment.
Building full mesh "for performance" without measuring
A hub adds 3–8 ms in the same continent. Payment gateway callbacks tolerate 200 ms. Unless you have measured cross-cloud RTT as a bottleneck, mesh complexity is wasted. Run mtr or CloudWatch Network Monitor before committing to topology.
Ignoring asymmetric routing through NVAs
Traffic enters through the hub firewall but return traffic shortcuts direct because a spoke route table has a more specific prefix. TCP breaks silently. Enable appliance mode on AWS Transit Gateway attachments and verify with bi-directional flow logs.
No hub redundancy
A single Transit Gateway in one AZ is not HA. Hub maintenance becomes a company-wide outage. Budget for dual-AZ hub NVAs and test failover quarterly.
Treating overlay mesh as a replacement for cloud routing
Tailscale and Cloudflare Tunnel excel for admin access and service-to-service calls at L7. They do not replace VPC routing for database replication or bulk data transfer. Use overlay for operator access; use cloud-native hub-and-spoke for data-plane traffic. Compare tunnel options in the Cloudflare Tunnel vs VPN article if your team is evaluating zero-trust overlays.
Hard-coded routes instead of Infrastructure as Code
Manual console changes to route tables drift within weeks. Every attachment, route propagation, and security group rule belongs in Terraform or OpenTofu with CI validation. Pin provider versions and run terraform plan on every merge request.
Practical default for 2026: Start with hub-and-spoke on your primary cloud. Add partial mesh links only after you have production metrics proving hub latency is a problem. Revisit topology when you exceed five spokes or when compliance mandates change.
Pick the topology your team can operate—not the one that looks best on a whiteboard
Hub-and-Spoke vs Mesh Multi-Cloud Networking is a trade-off between simplicity and latency, not a moral choice. Hub-and-spoke wins for most small and mid-size teams running Laravel, WordPress, or eCommerce across two or three clouds: fewer tunnels, centralized security, predictable costs. Mesh—or a hybrid with one direct link—wins when measured replication lag or API round-trip time directly hits revenue. Draw your CIDR plan first, deploy an HA hub with Terraform, enable flow logs on day one, and add mesh links surgically rather than by default.
If you are planning a multi-cloud deployment for a Nepal-based business and want the network layer designed alongside application architecture, get in touch—I help teams ship production topologies they can maintain after launch, not diagrams that fall apart on the first failover test.
Frequently Asked Questions
Hub-and-spoke is a topology where a central hub network connects to multiple cloud or on-premise spokes. Traffic between spokes typically routes through the hub, giving you one place to enforce firewalls, VPN termination, DNS, and routing policy. AWS Transit Gateway, Azure Virtual WAN, and GCP Network Connectivity Center are common hub implementations. I've seen this pattern on production setups where a single EC2-hosted hub handles site-to-site VPNs and peering into AWS, Azure, and a Kathmandu office network without meshing every environment directly.
Mesh networking connects every cloud environment and site directly to every other one, with no mandatory central router. Each node peers with all peers, so east-west traffic can take the shortest path. Full mesh scales poorly manually, so teams use dynamic routing via BGP through cloud routers, SD-WAN overlays, or tools like Aviatrix and Cilium Cluster Mesh. Mesh suits low-latency workloads where direct cloud-to-cloud paths matter and central inspection is handled per link rather than forced through one hub.
Hub-and-spoke routes inter-spoke traffic through a central hub; mesh connects spokes directly to each other. Hub-and-spoke simplifies policy and monitoring but adds hop latency and creates a single choke point. Mesh reduces latency and hub bottlenecks but multiplies tunnels, routes, and firewall rules. Most real deployments I've maintained are hybrid: a hub for north-south and admin access, with selective mesh links between high-traffic cloud pairs like AWS and GCP for database replication.
Choose hub-and-spoke when you need centralized security inspection, consistent egress IP, simplified audit logging, or a small ops team managing one routing domain. It fits regulated workloads, shared services hubs, and hybrid setups where on-prem VPN terminates once. Pick mesh when latency between specific clouds dominates cost, when the hub becomes a bandwidth or availability bottleneck, or when autonomous cloud teams refuse a shared transit account. On budget-sensitive Nepal client projects, hub-and-spoke usually wins because one Ubuntu-based VPN hub on a Rs 8,000/month VPS (~USD 60) is cheaper than four managed cloud interconnects.
Roughly Rs 15,000–80,000/month (~USD 110–600) for small setups; enterprise hub-and-spoke often runs Rs 2–10 lakh/month (~USD 1,500–7,500).
Costs scale with N×(N−1) links: three clouds need three peering paths; six need fifteen. Expect Rs 25,000–2 lakh+/month (~USD 185–1,500+) depending on data transfer volume, plus SD-WAN or transit licenses.
Yes. AWS Transit Gateway is a native AWS hub for VPC peering, VPN, and Direct Connect attachment, but it does not directly attach to Azure or GCP. For true multi-cloud hub-and-spoke, you terminate partner-cloud VPN or dedicated interconnect at the Transit Gateway edge, or place a third-party virtual router or SD-WAN appliance in a central VPC. I've used Transit Gateway as the AWS spoke aggregator while a Linux strongSwam/FRR instance or vendor appliance in the same VPC handled cross-cloud BGP sessions to Azure Virtual WAN or GCP Cloud VPN.
Hub-and-spoke gives one enforcement point for firewall rules, IDS/IPS, DNS filtering, and egress NAT. All inter-environment traffic passes a known inspection zone, which simplifies compliance logging and reduces accidental lateral movement between clouds. You can deny spoke-to-spoke paths entirely and force everything through policy. The trade-off is that a compromised hub exposes all spokes, so harden the hub VPC, restrict admin access with MFA and bastion-only SSH, patch the router OS regularly, and run hub components in separate accounts with least-privilege IAM.
Mesh expands the attack surface because every cloud has direct routes to every other cloud. A misconfigured security group in one spoke can expose databases in another. Route propagation errors can leak internal subnets across boundaries. Without centralized logging, east-west traffic is harder to audit. Mitigate with micro-segmentation, explicit deny-by-default network ACLs, mutual TLS between services, and centralized SIEM forwarding from each cloud. Never assume VPC peering or VNet peering implies trust; treat each link as untrusted and filter at both ends.
Start by defining an IP plan with non-overlapping RFC1918 ranges per cloud and on-prem. Deploy a hub: Azure Virtual WAN, AWS Transit Gateway plus a VPN appliance, or a neutral colo router. Create site-to-site IPsec or dedicated interconnect from each cloud spoke to the hub. Advertise spoke CIDRs via BGP where supported; static routes where not. Configure hub route tables so spokes can reach each other only if policy allows. Test with traceroute and tcpdump from a bastion in each cloud. Document failover: if the hub dies, which spokes lose all cross-cloud connectivity?
Hairpin routing is the usual culprit: traffic from AWS Mumbai to GCP Mumbai may route through a hub in Singapore or on-prem Kathmandu, adding 40–120 ms per hop. Oversubscribed hub instances or Transit Gateway attachment limits also throttle throughput. Fix by measuring actual paths with mtr, adding regional hub replicas, or creating selective mesh shortcuts for latency-sensitive pairs like database replication. Right-size hub VPN appliances to expected Mbps and enable jumbo frames only end-to-end. For Nepal offices on Vianet or WorldLink, also account for international upstream congestion during peak hours.
Work layer by layer. Confirm tunnel status on both ends: AWS VPN connection state, Azure VPN Gateway, GCP HA VPN. Verify BGP neighbors are established and expected prefixes are advertised and received. Check for overlapping CIDR blocks, which silently break peering. Validate security groups, NSGs, and firewall rules allow the destination port. Use tcpdump on the VPN appliance and cloud flow logs to see whether packets leave the source, arrive at the destination, or get dropped mid-path. Keep a runbook with each spoke's tunnel IPs, BGP ASNs, and advertised prefixes; missing documentation causes most multi-hour outages I've seen.
Hub-and-spoke is usually better for hybrid multi-cloud because your on-prem firewall or SD-WAN edge becomes the natural hub. One IPsec tunnel from the office to a cloud hub is simpler than meshing on-prem to AWS, Azure, and GCP separately. Mesh from on-prem makes sense only for large enterprises with multiple data centers and dedicated MPLS or SD-WAN already connecting sites. For typical Nepal SMB setups with one office and two clouds, a single hub VPN through FortiGate, pfSense, or a managed Virtual WAN saves hours of route maintenance.
Cloud-native options include Azure Virtual WAN mesh, AWS Cloud WAN, and GCP Network Connectivity Center, each partially multi-cloud via partner integrations. Third-party platforms like Aviatrix, Alkira, Prosimo, and Cato Networks provide true multi-cloud transit and mesh with centralized policy. Open-source approaches combine FRRouting or BIRD on Linux with Terraform modules for VPN and BGP. Kubernetes teams sometimes use Cilium Cluster Mesh or Istio multi-cluster for application-layer mesh, which is orthogonal to VPC mesh but solves service-to-service connectivity. Pick based on whether ops wants a single pane or per-cloud native tooling.
The most common mistake is overlapping IP address space across clouds and on-prem, discovered only at peering time. Second is treating the hub as unlimited bandwidth without HA: a single t3.medium VPN instance becomes a outage domain and throughput ceiling. Third is enabling spoke-to-spoke routing without firewall policy, which negates the security benefit. Plan non-overlapping /16 blocks per environment upfront, deploy hub components in active-passive or managed HA, and use separate route tables for inspection vs direct paths. Review quarterly as new SaaS VPCs and partner integrations add routes you forgot about.
