Every multi-cloud network design eventually runs into the same question: how do you stop building a mesh of point-to-point connections and start building a transit fabric? All three hyperscalers answer this with a hub-and-spoke construct — Transit Gateway, Virtual WAN, and Network Connectivity Center — but the backend architectures diverge sharply once you get past the marketing diagrams. Those divergences show up exactly where they hurt: regional scope, inter-region transitivity, third-party appliance peering, and BGP route control.
This is a practitioner’s pass at the three, current as of mid-2026, with the numbers checked against each vendor’s published quotas rather than memory.
1. Core Constructs
AWS Transit Gateway (TGW)
TGW is a regional managed router. You deploy one (or more) per AWS Region, attach VPCs, VPNs, Direct Connect Gateways, and peering connections to it, and it switches packets between attachments using transit gateway route tables. There’s no global control plane — a TGW in eu-west-1 and one in us-east-1 are entirely separate resources that you stitch together with TGW peering, a point-to-point construct, not a mesh fabric.
Key building blocks:
- Attachments: VPC, VPN, Direct Connect Gateway, TGW Connect, peering
- Route tables: up to 20 per TGW, each holding up to 10,000 combined static/dynamic routes
- TGW Connect: a GRE+BGP overlay for bringing SD-WAN/NVA appliances in as native attachments, riding on top of an existing VPC or DX attachment as transport
Azure Virtual WAN (vWAN)
vWAN’s organizing unit is the virtual hub, deployed per-region inside a vWAN resource (which is itself a global container object). Each hub runs a Microsoft-managed hub router that does BGP-based route management between everything attached to it — VPN gateway, ExpressRoute gateway, P2S gateway, NVAs, and VNet connections. Multiple hubs in the same vWAN are automatically full-mesh connected to each other (hub-to-hub), giving you transitive any-to-any reachability across regions natively, without you configuring peering links one at a time.
Key building blocks:
- Virtual hub: regional, contains the BGP router + optional gateways
- Hub route tables: support route propagation/association with labels for logical grouping (e.g., the built-in
Defaultlabel) - Routing Intent: policy-based construct to force traffic through a security NVA/firewall for inter-hub or internet-bound flows
- NVA-in-hub BGP peering: lets a third-party appliance in a directly connected spoke VNet peer with the hub router itself
GCP Network Connectivity Center (NCC)
NCC is architecturally the outlier: the hub is a global resource, not regional. A single hub can hold spokes from many regions simultaneously, and dynamic (BGP) routes are propagated globally across the hub’s route table by default — there’s no separate “inter-region peering” object to provision. You pick a topology (mesh or star) at hub-creation time and it’s immutable afterward.
Key building blocks:
- Hub: global; topology is
mesh(any-to-any) orstar(center/edge groups, edge-to-edge is blocked) - VPC spokes: attach whole VPC networks (same or cross-project/cross-org)
- Hybrid spokes: HA VPN tunnels, Cloud Interconnect VLAN attachments, or Router Appliance VMs (the GCP analog to TGW Connect/NVA-in-hub — a GCE VM running a 3rd-party routing stack, peered via Cloud Router/BGP)
- Producer VPC spokes: lets Private Service Connect–fronted managed services be reachable through the hub
- NCC Gateway: a newer regional spoke type purpose-built for inserting third-party Security Service Edge (SSE) inspection into Cross-Cloud Network traffic
2. Backend Architecture: Regional Box vs. Global Fabric
This is the single biggest conceptual difference between the three, and it should drive your topology decisions more than any feature checkbox.
| TGW | vWAN | NCC | |
|---|---|---|---|
| Hub scope | Regional | Regional (hub), global (vWAN container) | Global |
| Cross-region transitivity | Manual TGW peering (static routes only) | Automatic hub-to-hub full mesh | Native — same hub, no extra object |
| Inter-region route propagation | Not supported — peering attachments don’t propagate routes via BGP; you write static routes | Dynamic, automatic between hubs | Dynamic, automatic, global by default |
AWS’s stance here is deliberate and well-documented: peering attachments between transit gateways do not support route propagation. You must create static routes pointing at the peering attachment in each TGW’s route table. This is a meaningful operational tax at scale — every new spoke VPC CIDR added behind TGW-A needs a corresponding static route added in TGW-B’s table, every time, in both directions. There’s also no ECMP across TGW peering links, since peering doesn’t run dynamic routing.
Azure and Google both took the “make multi-region transitive by default” position, just at different layers: Azure does it by auto-meshing hub routers within a vWAN, Google does it by not having regional hubs at all. If your design center is “many regions, one routing domain,” NCC’s model removes a whole category of static-route bookkeeping that both TGW and (to a lesser extent) vWAN still carry.
3. Scale Limits That Actually Bite
Numbers pulled directly from current vendor documentation (June 2026):
AWS Transit Gateway
| Limit | Default | Adjustable |
|---|---|---|
| TGWs per account | 5 | Yes |
| Attachments per TGW | 5,000 | Yes |
| Peering attachments per TGW | 50 | Yes |
| TGW-to-TGW (or TGW-to-Cloud WAN CNE) peering attachments | 1 | No |
| TGW route tables per TGW | 20 | Yes |
| Combined routes per TGW (all route tables) | 10,000 | Contact SA/TAM |
| Direct Connect gateways per TGW | 20 | No |
| TGWs per Direct Connect gateway | 6 | No |
| VPN BGP routes (per attachment) | 100 (hard) | No — exceeding resets the BGP session |
| Connect peers per Connect attachment | 4 (≤20 Gbps total) | No |
| Bandwidth per VPC attachment per AZ | up to 100 Gbps each direction | Contact SA/TAM |
That 100-route BGP hard limit on VPN attachments is the one that catches people migrating from Transit VPC/Cisco CSR designs — those older architectures could summarize spoke CIDRs before advertising on-prem; native TGW VPN attachments don’t, so your on-prem route budget needs to assume one prefix per spoke VPC, not a summarized aggregate.
Azure Virtual WAN
| Limit | Value |
|---|---|
| VNet connections per hub (no Routing Intent) | 500 minus total hubs in the vWAN |
| Address spaces across all VNets per hub (Routing Intent / private routing enabled) | 600 |
| VPN (branch) connections per hub | 1,000 |
| ExpressRoute circuits per hub | 8 |
| P2S users per hub | 100,000 |
| Hub router aggregate throughput (VNet-to-VNet transit) | 50 Gbps |
| Hub router default capacity | 2 routing infrastructure units = 3 Gbps / 2,000 VMs (scales up) |
| Total routes a hub will accept from connected resources | 10,000 |
| Hub router ASN | 16-bit only |
The hub router’s 50 Gbps aggregate VNet-to-VNet ceiling is a real design constraint for high-throughput east-west workloads — it’s a shared resource across every VNet attached to that hub, not a per-attachment number like TGW’s 100 Gbps per VPC attachment per AZ. If you’re consolidating large, chatty workloads, this pushes you toward more hubs sooner than TGW would.
GCP Network Connectivity Center
| Limit | Value |
|---|---|
| Active VPC spokes per hub | 250 |
| Total VPC spokes per hub (active + inactive) | 1,000 |
| VPN tunnels per spoke | 8 |
| VLAN attachments per spoke | 6 |
| Router appliance instances per spoke | 8 |
| Export/exclude CIDR filters per spoke | 16 |
| Routing VPC networks per hub | Quota-based (default low; request increase) |
NCC’s numbers look smaller on paper (250 active VPC spokes vs. TGW’s 5,000 attachments), but that’s not a fair apples-to-apples comparison — a single NCC VPC spoke already represents transitive connectivity across every region that VPC spans, since GCP VPCs are global by default. A 250-spoke NCC hub can architecturally cover more physical footprint than the spoke count suggests, whereas TGW’s 5,000 is per-region and you need a fresh budget (and fresh peering) for every region.
4. Third-Party Appliance / NVA Peering
This is where the platforms genuinely differ in capability, not just terminology.
AWS — TGW Connect. GRE+BGP overlay attachment riding on top of a VPC or DX attachment as transport. Any appliance speaking standard GRE/BGP works (SD-WAN partners are explicitly certified, but it’s not a closed list). Static routing is not supported on Connect — BGP is mandatory. Per-Connect-peer throughput caps at 5 Gbps, up to 4 peers per Connect attachment (20 Gbps ceiling), with ECMP available across peers/attachments but not across BGP sessions of the same peer.
Azure — NVA-in-hub BGP peering with the virtual hub router. The hub router can peer directly with an NVA, but only one deployed in a VNet that’s directly connected to that hub — you cannot peer the hub router with an on-prem NVA, and you cannot peer it with an Azure Route Server. The hub router only supports 16-bit ASNs, which is worth checking against any appliance using 4-byte private ASNs. NVA BGP connections are treated like an on-prem branch (ExpressRoute/VPN) for route table association purposes. If you’re running Routing Intent (policy-based steering through a firewall), NVA BGP peering is only supported when Routing Intent is configured on a secured hub — it’s unsupported on a non-secured hub with no routing intent.
GCP — Router Appliance spokes (and now NCC Gateway). A Router Appliance is a GCE VM acting as the BGP/dataplane endpoint, peered to a Cloud Router in the same region, then attached to the hub as a hybrid spoke. Up to 8 router appliance instances per spoke. The newer NCC Gateway spoke type is purpose-built for inserting third-party SSE/inspection vendors into Cross-Cloud Network traffic flows — a more explicit “security service insertion” primitive than either TGW Connect or vWAN’s NVA peering currently offer out of the box.
5. BGP Route Sharing — The Real Differentiator
| Capability | TGW | vWAN | NCC |
|---|---|---|---|
| VPC→hub route propagation | Internal API, not BGP | BGP (hub router) | BGP (dynamic route exchange) |
| On-prem→hub propagation | BGP (VPN/DX/Connect) | BGP (VPN/ER/NVA) | BGP (VPN/Interconnect/Router Appliance) |
| Hub-to-hub (inter-region) route propagation | Static only — no BGP over peering attachments | BGP, automatic | BGP, automatic (single global hub) |
| Per-prefix route filtering at the spoke | Route table association/propagation rules | Route table + label-based propagation | Export filters: per-spoke include/exclude CIDR lists (up to 16) |
| ECMP | Yes, within same attachment type/ASN path; not across peering or attachment types | Implicit via hub router’s path selection | Implicit via Cloud Router multipath |
| IPv6 dynamic routes | Supported on Connect | Not supported in hub/gateways at all | Subnet routes yes; dynamic IPv6 route exchange not supported |
| Static route support across the fabric | Required for inter-TGW peering, optional elsewhere | Supported, but discouraged from re-injecting into BGP unpredictably | Static routes (preview) layered on top of dynamic — but can’t replace dynamic route exchange between VPC spokes |
A subtlety worth flagging for solution designs: none of the three let you do pure static-route-only transit at hub scale. TGW VPN/Connect attachments mandate BGP; NCC explicitly states static route exchange across VPC spokes isn’t supported (static routes, in preview, are additive, not a replacement); vWAN technically allows static routes in route tables but warns against re-advertising Azure-BGP-community-tagged routes back into the fabric, since it breaks route selection. If a design depends on static-route-only on-prem routers, all three platforms push you toward at least a BGP speaker at the edge.
The NCC export filter model deserves a callout: it’s the most granular per-spoke control of the three, letting you selectively suppress or whitelist CIDRs per spoke before they ever land in the hub’s route table — useful for overlapping-CIDR remediation or deliberately asymmetric reachability in a mesh topology, without needing separate route tables per consumer like TGW or per-label propagation like vWAN.
6. Design Considerations Worth Writing Down
If you’re an AWS-anchored shop spanning many regions: budget for the TGW-peering static-route operational overhead early. It scales linearly with spoke count and direction count (N regions → manage routes for each pair), and there’s a hard limit of one peering attachment between any two TGWs — you can’t load-balance across multiple peering links. AWS Cloud WAN exists specifically to abstract this away if you’re hitting this wall; it wasn’t in scope here but is worth a follow-up post.
If you’re Azure-anchored: Routing Intent fundamentally changes your BGP peering options for NVAs (secured-hub-only for BGP peering with routing intent configured), and the 600-address-space ceiling per hub bites VNets-with-many-address-spaces designs faster than VNet-count alone suggests — check actual prefix counts, not connection counts, when sizing.
If you’re GCP-anchored: the global hub means your blast radius for a routing mistake (e.g., overlapping CIDRs without export filters) is global by default, not contained to a region. The mesh-vs-star choice is immutable per hub — get it right at creation, since switching means rebuilding.
Across all three: none of them solve cross-cloud transit on their own — they’re each strictly intra-cloud fabrics. Tying AWS TGW, Azure vWAN, and GCP NCC together into one fabric still means VPN/Interconnect/Direct Connect at the edges, with all the BGP route limit and MTU mismatch considerations (TGW’s 8500-byte MTU vs. 1500 over VPN, for instance) that implies.
Quick-Reference Summary
| AWS TGW | Azure vWAN | GCP NCC | |
|---|---|---|---|
| Hub scope | Regional | Regional hub / global container | Global hub |
| Auto inter-region transit | No (static peering) | Yes (hub mesh) | Yes (native) |
| Max practical spokes/region | 5,000 attachments | ~500 VNets/hub (minus hub count) | 250 active VPC spokes/hub |
| 3rd-party appliance model | TGW Connect (GRE+BGP) | NVA-in-hub BGP peering | Router Appliance spoke / NCC Gateway |
| BGP route filtering granularity | Route table assoc/prop | Route table + labels | Per-spoke export filters (16 CIDRs) |
| IPv6 dynamic routing | Yes (Connect) | No | No (subnet routes only) |
| Aggregate hub throughput | ~100 Gbps per VPC attachment/AZ | 50 Gbps shared per hub router | Not separately published (scales with Cloud Router/VM-based spokes) |
Each of these is a genuinely capable transit fabric — the choice usually isn’t “which is best” but “which operational model matches how your organization already thinks about regions, route ownership, and who’s allowed to touch the BGP table.” Pick based on that, validate the limits against your actual topology math, and revisit Cloud WAN, Azure’s hub-to-hub-over-ExpressRoute preview, and GCP’s NCC Gateway roadmap before locking in a multi-year design — all three vendors are actively closing gaps in this space.
Numbers and capabilities checked against AWS, Microsoft, and Google documentation as of June 2026. Quotas are frequently adjustable via support request — treat defaults as a starting point for sizing conversations, not hard ceilings.
Written by Paul Carvill
Enterprise → cloud → AI networking. I write the breakdowns I wish I’d had. New field notes roughly twice a month.