AWS TGW vs Azure vWAN vs GCP NCC: Multi-Cloud Backbone Wars 2026

Choosing a multi-cloud network backbone in 2026 is less about brand loyalty and more about architectural fit and TCO. AWS Transit Gateway (TGW), Azure Virtual WAN (vWAN), and Google Cloud Network Connectivity Center (NCC) all offer hub-and-spoke and mesh-like capabilities, but their underlying architectures, pricing models, and integration points differ substantially. This analysis focuses on raw technical capabilities and economic implications for large enterprises.

Architectural Philosophies and Scale Limits

AWS TGW, particularly when augmented by Cloud WAN for global mesh connectivity, provides a fundamentally object-oriented approach. Each TGW is a regional construct, supporting up to 5000 attachments (VPC/VPN/Direct Connect Gateway). Cloud WAN orchestrates multiple TGWs into a global network, managing routing policies and segmentation across regions and accounts. The default TGW scale limits are critical: 5000 routes per route table, 100 TGW attachments and 20 TGW route tables per TGW are common bottlenecks for very large deployments. Inter-region peering between TGWs relies on inter-region VPC peering capabilities, now largely superseded by Transit Gateway Inter-Region Peering, offering higher bandwidth and lower latency than traditional VPNs.

Azure Virtual WAN is a Microsoft-managed service acting as a hub for various connectivity types (VPN, ExpressRoute, VNet peering). It employs a global, centrally managed architecture. Standard hubs support up to 2000 VNet connections. Each ExpressRoute Gateway within a vWAN hub can support up to 10 Gbps and VPN Gateways up to 10 Gbps (scale unit dependent). A key differentiator is the concept of a 'Secure Hub' integrated with Azure Firewall Manager, allowing centralized enforcement of security policies (IDP/IPS, URL filtering) for all traffic transiting the hub, including VNet-to-VNet and on-premises-to-VNet. Azure's routing intent allows granular control over ingress and egress traffic flows within the hub, a feature often requiring BGP community manipulation or complex route table associations in AWS.

GCP Network Connectivity Center (NCC) is conceptually similar to a global fabric, focusing on connecting on-premises sites, VPCs, and even other cloud providers (via Cross-Cloud Interconnect). NCC hubs centrally manage spokes (VPC networks, VPN tunnels, Partner Interconnect, Cross-Cloud Interconnect) globally. Unlike TGW or vWAN, NCC presents as a single global entity, simplifying multi-region deployment. It supports up to 1000 spokes per hub. The design emphasizes simplicity for connecting diverse workloads and locations to a unified network. Cross-Cloud Interconnect, a relatively newer offering, directly connects GCP with AWS, offering predictable latency and throughput, a capability not natively available to the same degree between AWS and Azure's native backbone without a direct circuit or vendor overlay.

Routing, Segmentation, and BGP Integration

AWS TGW relies heavily on route tables attached to specific VPCs and Direct Connect Gateways. Segmentation is achieved by assigning attachments to different TGW route tables and configuring propagation and association rules. Cross-account routing is managed via TGW Resource Share. BGP is fundamental for VPN and DX Gateway attachments, with TGW advertising its routes and learning routes from your on-premises routers. Each TGW can function as a dynamic routing peer. Cloud WAN extends this with automatic route propagation and policy-based routing across regions defined in a global network policy. Routing between arbitrary TGW route tables requires explicit static routes or policy-based routing within Cloud WAN.

Azure vWAN hubs expose routing tables that can be associated with various connections. Routing Intent and Routing Policies allow administrators to dictate how traffic flows, for instance, forcing Internet-bound traffic through a Secure Hub's firewall or routing VNet-to-VNet traffic directly. BGP is extensively used for ExpressRoute and VPN Gateway connections into the vWAN hub. ExpressRoute circuits typically peer with the Microsoft enterprise edge (MSEE), which then injects routes into the vWAN hub. For hybrid environments, vWAN simplifies route aggregation and advertising, significantly reducing the BGP complexity seen with traditional Azure hub-and-spoke models using UDRs.

GCP NCC uses a global routing capability similar to Google Cloud's overall network. Spokes attached to an NCC hub exchange routes automatically. Each spoke gets a route table, and routes are propagated. BGP is employed for VPN and Interconnect attachments. For Cross-Cloud Interconnect, BGP sessions are established directly with the peer cloud provider (e.g., AWS Direct Connect Gateway) at the interconnect location, allowing route exchange between cloud environments. NCC's strength lies in its unified global route advertising and learning, removing the need for explicit inter-regional routing configuration or complex transitive routing setups usually required for other multi-region connectivity.

Throughput, Latency, and Inter-Region Performance

AWS TGW maximum throughput per attachment is typically 50 Gbps, with an aggregation of up to 100 Gbps per TGW across multiple attachments for inter-VPC traffic. Inter-Region TGW Peering offers significantly higher bandwidth than VPN, often exceeding 5 Gbps per peer connection but can scale up to 50 Gbps depending on demand and regional capacity, with latency comparable to raw VPC peering between regions. For on-premises, Direct Connect connections up to 100 Gbps can terminate on a Direct Connect Gateway, which then attaches to a TGW. Performance is excellent provided the TGW is not overwhelmed by the volume of VPCs and routes.

Azure vWAN hub throughput capacity is dynamic; VPN gateways scale up to 10 Gbps and ExpressRoute gateways up to 20 Gbps (multiple ExpressRoutes can terminate). Aggregate vWAN hub throughput between VNets is often quoted around 100 Gbps for large hubs. Inter-region VNet-to-VNet traffic through vWAN leverages Microsoft's global backbone, delivering high-speed, low-latency connectivity within the Azure network. Secure Hubs with Azure Firewall can introduce latency depending on the firewall SKU and inspection load. Performance between regions is generally strong due to the highly optimized Microsoft global network.

GCP NCC leverages Google's highly performant global private network. VPC-to-VPC traffic and on-premises connectivity (VPN/Interconnect) benefit from Google's low-latency, high-bandwidth backbone. Cross-Cloud Interconnect can achieve up to 10 Gbps per link to AWS, with multiple links for higher capacity. The latency between Google Cloud regions is consistently among the lowest in the industry, which translates directly to NCC's performance characteristics. This is a significant advantage for latency-sensitive applications spanning multiple cloud regions or requiring seamless multi-cloud communication.

SD-WAN Appliance Integration and Security Services

Integrating SD-WAN into AWS TGW typically involves establishing IPsec VPNs from SD-WAN branch devices or virtual appliances (e.g., FortiGate-VM, Palo Alto Networks VM-Series, Cisco Catalyst 8000V) in spokes directly to the TGW. AWS Network Manager provides a centralized dashboard to monitor global networks including TGWs, Cloud WAN, and on-premises sites connected via VPN or Direct Connect. While it doesn't host security capabilities natively, TGW can steer traffic to 'inspection VPCs' containing virtual firewalls for centralized security policy enforcement. This requires explicit route manipulation and often involves ECMP or Active/Standby firewall configurations, such as Transit Gateway VPN ECMP for symmetrical routing.

Azure vWAN offers integrated SD-WAN capabilities. Many leading SD-WAN vendors (e.g., Fortinet, Versa, VMware, Cisco Viptela) have integrated their solutions with vWAN, simplifying branch office connectivity. A managed virtual appliance can be deployed directly into a vWAN hub, simplifying the deployment and reducing the operational overhead compared to a separate VNet. The Secure Hub functionality with Azure Firewall Manager (employing FortiGate-VM or Palo Alto VM-Series instead of Azure Firewall is also possible but requires a separate VNet) is a major selling point for enforced centralized security. This direct integration streamlines the process of directing all branch, VNet, and internet traffic through a common security inspection point.

GCP NCC's integration story with SD-WAN is evolving. For now, it largely follows the VPN-to-spoke model, where SD-WAN appliances establish IPsec VPNs to a VPN gateway in a VPC spoke, which is then attached to NCC. While major vendors like Fortinet and Palo Alto offer robust virtual appliances for GCP, NCC doesn't (yet) have the same deep integration as vWAN's Secure Hub or native SD-WAN support. However, NCC does facilitate connecting on-premises SD-WAN deployments to Google Cloud services and other cloud environments via its various spoke types, centralizing the management of these connections without dictating the SD-WAN solution itself. The upcoming Private Service Connect integration with NCC promises further simplification for accessing SaaS and partner services.

Cost Models: Egress and Attachments

Feature	AWS Transit Gateway (TGW)	Azure Virtual WAN (vWAN)	GCP Network Connectivity Center (NCC)
Hourly Cost per Hub	$0.05/hour per TGW + $0.05/hour per inter-region peering connection	Standard Hub: $0.25/hour. Secure Hub: $0.35/hour + Azure Firewall costs.	$0.025/hour per hub unit (regional, 1000 spokes)
Per-Attachment Cost	$0.05/GB processed inbound/outbound (data processed charge)	No direct per-attachment charge. VPN/ExpressRoute gateway charges apply.	Spoke Unit hour: $0.0025/hour per spoke. Data processed: $0.02/GB for all data transiting NCC.
Inter-Region Data Transfer	$0.02/GB - $0.09/GB (depending on regions)	Varies by region pair, typically $0.02/GB - $0.08/GB	$0.02/GB - $0.12/GB (varies across regions, specific for Cross-Cloud)
Example: 50 VPCs/VNets/Spokes (approx)	~50 VPCs * $0.05/GB (data processed) + TGW hourly. Total ~0.05 * 24 * 30 = $36/month (TGW only). Data at 100TB/month: 100 * 1024 * 0.05 = $5120.	Standard Hub ~0.25 * 24 * 30 = $180/month. No direct spoke charges. Data via ExpressRoute/VPN.	NCC Hub Unit ~0.025 * 24 * 30 = $18/month. 50 Spoke Units ~50 * 0.0025 * 24 * 30 = $90/month. Data at 100TB/month: 100 * 1024 * 0.02 = $2048.
Example: 500 VPCs/VNets/Spokes (approx)	~500 VPCs * $0.05/GB (data processed) + TGW hourly. Multiple TGWs likely needed in large regions due to limits. Data at 500TB/month: 500 * 1024 * 0.05 = $25600.	Standard Hub ~0.25 * 24 * 30 = $180/month. Routing Intent may add fees. Data fees.	NCC Hub Unit ~0.025 * 24 * 30 = $18/month. 500 Spoke Units ~500 * 0.0025 * 24 * 30 = $900/month. Data at 500TB/month: 500 * 1024 * 0.02 = $10240.

The cost models are significantly different. AWS TGW charges per GB of data 'processed' (inbound or outbound to any attachment). This means east-west traffic within a TGW incurs a charge. Azure vWAN charges primarily hourly for the hub itself and for any ExpressRoute or VPN Gateways deployed within it. Data egress charges apply to traffic leaving Azure for the Internet, but VNet-to-VNet traffic within a vWAN hub does not incur additional per-GB charges for the vWAN service itself (standard VNet peering charges still apply if not using vWAN for VNet to VNet). GCP NCC charges a low hourly fee for the hub unit and an hourly fee per 'spoke unit'. Like TGW, it charges for data processed (transiting) through NCC. However, for intra-NCC data, GCP charges a lower per-GB rate compared to TGW's flat $0.05/GB, which can be significant at scale.

For a scenario with 500 VPCs/VNets/Spokes and 500TB/month of aggregate internal traffic, AWS could quickly become the most expensive due to its $0.05/GB data processed charge. GCP's $0.02/GB data processed in NCC is more competitive. Azure's model, which largely abstracts VNet-to-VNet data charges internal to the hub, can be highly attractive for organizations with massive internal data flows. However, this is largely true for traffic staying within the vWAN hub's regional scope. Multi-region Azure vWAN traffic will incur inter-region data transfer fees, similar to AWS and GCP.

Observability and Troubleshooting

AWS provides CloudWatch metrics for TGW (e.g., BytesIn/Out, Packet Drop). Flow Logs for TGW attachments enable granular traffic visibility, allowing integration with services like VPC Flow Logs to S3, CloudWatch Logs, or third-party SIEMs. AWS Network Manager gives a topological view and connectivity status for TGW and associated connections. Troubleshooting routing issues often involves inspecting TGW route tables, propagation settings, and attachment associations, along with BGP session status for VPN/DX.

Azure vWAN offers comprehensive monitoring through Azure Monitor, providing metrics for hub utilization, gateway throughput, and VPN/ExpressRoute connection status. Network Watcher components like NSG Flow Logs (for Secure Hubs) and connection monitor help visualize traffic patterns and diagnose connectivity issues. The global nature of vWAN's management console simplifies cross-regional troubleshooting, providing a single pane of glass for all hub connections and routes. Azure Firewall logs within a Secure Hub offer deep traffic inspection and security event logging.

GCP NCC also integrates with Cloud Monitoring for metrics and Cloud Logging for audit and flow logs. VPC Flow Logs for spokes provide detailed traffic records. Google Cloud Network Intelligence Center provides topology views, performance monitoring, and insights into network health across attached spokes. Given GCP's strong emphasis on observability, troubleshooting NCC typically leverages familiar Cloud Console tools and the Stackdriver suite. BGP session monitoring for Interconnects is robust, providing detailed status and advertised routes.

Configuration Snippets and Real-world Example

AWS TGW attachment to VPC with route propagation:

resource "aws_ec2_transit_gateway_vpc_attachment" "example" {
  vpc_id                        = aws_vpc.example.id
  transit_gateway_id            = aws_ec2_transit_gateway.example.id
  subnet_ids                    = [
    aws_subnet.example_az1.id,
    aws_subnet.example_az2.id,
  ]
  tags = {
    Name = "Example-VPC-Attachment"
  }
}

resource "aws_ec2_transit_gateway_route_table_association" "example" {
  transit_gateway_attachment_id  = aws_ec2_transit_gateway_vpc_attachment.example.id
  transit_gateway_route_table_id = aws_ec2_transit_gateway_route_table.example.id
}

resource "aws_ec2_transit_gateway_route_table_propagation" "example" {
  transit_gateway_attachment_id  = aws_ec2_transit_gateway_vpc_attachment.example.id
  transit_gateway_route_table_id = aws_ec2_transit_gateway_route_table.example.id
}

This Terraform snippet demonstrates attaching a VPC to an AWS TGW and then associating and propagating its routes to a specific TGW route table, which is foundational for segmentation and connectivity. For large-scale deployments, Cloud WAN policies manage these associations and propagations dynamically across multiple TGWs.

Verdict

AWS TGW (with Cloud WAN) wins when:

• You are an AWS-native organization with 90%+ of your infrastructure in AWS.
• You require fine-grained control over routing propagation and association across a complex multi-account, multi-region AWS environment.
• You need to integrate existing Direct Connects and a large number of VPNs, especially with specific BGP community requirements.
• Your internal east-west data flow is moderate, as the $0.05/GB data processing charge can quickly escalate at high volumes.

Azure Virtual WAN wins when:

• You have a Microsoft-centric hybrid environment, heavily leveraging ExpressRoute and Azure services.
• Centralized security enforcement via Secure Hubs and Azure Firewall Manager is a critical requirement for regulatory compliance and simplified management.
• You are deploying a global SD-WAN overlay and prefer deep integration and management with the cloud backbone.
• Your VNet-to-VNet traffic within a region is exceedingly high, as the hub-based pricing can be more predictable than per-GB processing for this traffic type.

GCP Network Connectivity Center (NCC) wins when:

• You are leading with GCP for the majority of your cloud footprint but also need efficient, high-performance connectivity to AWS or other clouds via Cross-Cloud Interconnect.
• Simplicity in global network management is a top priority, offering a single global construct rather than regional TGWs or explicit inter-region peerings.
• Your organization values Google's highly optimized global backbone for low-latency, high-bandwidth connectivity across regions.
• Cost efficiency for high internal data transfer volumes is crucial, given NCC's lower data processing charge ($0.02/GB) compared to AWS TGW for internal traffic.

Related reading

• AWS Network Firewall vs Palo Alto VM-Series 2025
• Azure ExpressRoute Strategies for Global Enterprises 2025
• GCP Cloud VPN vs Interconnect Performance Deep Dive
• Fortinet SD-WAN Multi-Cloud Integration