splithorizon
// infographic
Download PNG
Download SVG
SPLITHORIZON // CLOUD NETWORKING
Transit Gateway vs. Virtual WAN vs. NCC
Three hub-and-spoke fabrics. One question: who actually transits regions?
Verified against AWS / Microsoft / Google docs — June 2026
01 / HUB SCOPE & ARCHITECTURE
AWS
Transit Gateway
Hub scope: REGIONAL
One regional router per TGW. No global
control plane — every region stands alone.
INTER-REGION TRANSIT
Manual peering — static routes only
3RD-PARTY APPLIANCE
TGW Connect — GRE + BGP overlay
4 peers · 5 Gbps each · 20 Gbps total cap
VPC → HUB ROUTES
Internal API — not BGP
Peering links per TGW pair:
1 (hard limit)
AZURE
Virtual WAN
Hub scope: REGIONAL HUB
Managed hub router per region; hubs in the
same vWAN auto-mesh to each other.
INTER-REGION TRANSIT
Automatic — hub-to-hub BGP full mesh
3RD-PARTY APPLIANCE
NVA-in-hub BGP peering
Direct-connect VNet only · 16-bit ASN only
VPC → HUB ROUTES
BGP (hub router)
Hub router throughput:
50 Gbps shared
GOOGLE CLOUD
Connectivity Center
Hub scope: GLOBAL
One hub spans every region. No separate
inter-region object — it's just the hub.
INTER-REGION TRANSIT
Native — same global hub, no extra step
3RD-PARTY APPLIANCE
Router Appliance spoke / NCC Gateway
GCE VM + Cloud Router BGP · 8 per spoke
VPC → HUB ROUTES
BGP (dynamic route exchange)
Topology locked at creation:
mesh or star
02 / SCALE LIMITS THAT BITE
LIMIT
AWS TGW
AZURE vWAN
GCP NCC
Hubs / accounts
5 per account
global vWAN container
quota-based per project
Spokes / attachments per hub
5,000
~500 minus hub count
250 active / 1,000 total
Combined route table size
10,000 routes
10,000 routes
quota-based dynamic routes
Peering / cross-hub links
1 per TGW pair (hard)
auto full-mesh
n/a — single global hub
Throughput ceiling
~100 Gbps / VPC attach / AZ
50 Gbps shared per hub router
scales with Cloud Router / VMs
VPN BGP route cap
100 (hard — session resets)
per ExpressRoute circuit limits
quota-based per hub
3rd-party appliance throughput
4 Connect peers, 20 Gbps cap
NVA peers as branch attach
8 router appliance VMs/spoke
ASN support
32-bit (standard BGP)
16-bit ASN only (hub router)
32-bit (Cloud Router standard)
03 / BGP ROUTE SHARING — THE REAL DIFFERENTIATOR
CAPABILITY
AWS TGW
AZURE vWAN
GCP NCC
Hub-to-hub route propagation
Static only — no BGP
BGP, automatic
BGP, automatic (1 hub)
On-prem → hub propagation
BGP (VPN/DX/Connect)
BGP (VPN/ER/NVA)
BGP (VPN/Interconnect/RA)
Per-spoke route filtering
route table assoc / prop
route table + labels
export filters, 16 CIDRs/spoke
ECMP
same attach type/path only
implicit, hub router
implicit, Cloud Router
IPv6 dynamic route exchange
Yes (on Connect)
Not supported
Not supported
Static-route-only edge design
Not possible — BGP mandatory
discouraged, breaks selection
not supported (preview adds-on)
MTU (fabric / VPN)
8500 / 1500 bytes
platform-managed
platform-managed
THE MENTAL MODEL THAT MATTERS
TGW is a regional box you peer by hand. vWAN auto-meshes regional hubs over BGP.
NCC skips the regional layer entirely — the hub
is
the global fabric.
Pick based on how your org already thinks about regions and route ownership — not the spoke count on a slide.
04 / DESIGN CHECKLIST
AWS-ANCHORED
Budget for TGW-peering static-route
overhead — it scales with region-pairs,
not spoke count. One peering link max
per TGW pair — no ECMP across it.
→ consider Cloud WAN to abstract this
AZURE-ANCHORED
Routing Intent changes NVA BGP rules —
peering needs a secured hub. Size against
the 600 address-space ceiling per hub,
not raw VNet count.
→ check prefix count, not connection count
GCP-ANCHORED
Global hub means a routing mistake's
blast radius is global by default. Mesh
vs. star topology is locked at creation —
get it right the first time.
→ use export filters for overlapping CIDRs
splithorizon
Decoding the modern network — from enterprise to AI.
Source data verified against AWS / Microsoft / Google documentation, June 2026 · Quotas are adjustable — treat as sizing baselines, not hard ceilings.
CLOUD NETWORKING · ROUTING · THE JOURNEY