AWS TGW vs Azure vWAN vs GCP NCC: Las Guerras del Backbone Multi-Cloud 2026

En 2026, elegir un backbone de red multi-cloud no se trata tanto de la lealtad a la marca, sino más bien del ajuste arquitectónico y el TCO. AWS Transit Gateway (TGW), Azure Virtual WAN (vWAN) y Google Cloud Network Connectivity Center (NCC) ofrecen capacidades de hub-and-spoke y tipo mesh, pero sus arquitecturas subyacentes, modelos de precios y puntos de integración difieren sustancialmente. Este análisis se centra en las capacidades técnicas brutas y las implicaciones económicas para grandes empresas.

Filosofías Arquitectónicas y Límites de Escala

AWS TGW, particularmente cuando se complementa con Cloud WAN para conectividad mesh global, proporciona un enfoque fundamentalmente orientado a objetos. Cada TGW es un constructo regional, que soporta hasta 5000 attachments (VPC/VPN/Direct Connect Gateway). Cloud WAN orquesta múltiples TGWs en una red global, gestionando políticas de enrutamiento y segmentación a través de regiones y cuentas. Los límites de escala predeterminados de TGW son críticos: 5000 rutas por tabla de rutas, 100 attachments de TGW y 20 tablas de rutas de TGW por TGW son cuellos de botella comunes para despliegues muy grandes. El peering interregional entre TGWs se basa en las capacidades de peering de VPC interregional, ahora en gran medida reemplazadas por Transit Gateway Inter-Region Peering, que ofrece mayor ancho de banda y menor latencia que las VPNs tradicionales.

Azure Virtual WAN es un servicio gestionado por Microsoft que actúa como hub para varios tipos de conectividad (VPN, ExpressRoute, VNet peering). Emplea una arquitectura global y administrada centralmente. Los hubs Standard soportan hasta 2000 conexiones VNet. Cada ExpressRoute Gateway dentro de un hub de vWAN puede soportar hasta 10 Gbps y los VPN Gateways hasta 10 Gbps (dependiendo de la unidad de escala). Un diferenciador clave es el concepto de 'Secure Hub' integrado con Azure Firewall Manager, que permite la aplicación centralizada de políticas de seguridad (IDP/IPS, filtrado de URL) para todo el tráfico que transita por el hub, incluyendo VNet-a-VNet y on-premises-a-VNet. La intención de enrutamiento de Azure permite un control granular sobre los flujos de tráfico de entrada y salida dentro del hub, una característica que a menudo requiere manipulación de BGP community o asociaciones complejas de tablas de rutas en AWS.

GCP Network Connectivity Center (NCC) es conceptualmente similar a un fabric global, centrándose en conectar sitios on-premises, VPCs e incluso otros proveedores de cloud (a través de Cross-Cloud Interconnect). Los hubs de NCC gestionan centralmente los spokes (redes VPC, túneles VPN, Partner Interconnect, Cross-Cloud Interconnect) a nivel global. A diferencia de TGW o vWAN, NCC se presenta como una única entidad global, simplificando el despliegue multirregional. Soporta hasta 1000 spokes por hub. El diseño enfatiza la simplicidad para conectar diversas cargas de trabajo y ubicaciones a una red unificada. Cross-Cloud Interconnect, una oferta relativamente más reciente, conecta directamente GCP con AWS, ofreciendo latencia y throughput predecibles, una capacidad no disponible de forma nativa en el mismo grado entre el backbone nativo de AWS y Azure sin un circuito directo o un overlay de proveedor.

Enrutamiento, Segmentación e Integración BGP

AWS TGW depende en gran medida de las tablas de rutas adjuntas a VPCs y Direct Connect Gateways específicas. La segmentación se logra asignando attachments a diferentes tablas de rutas de TGW y configurando reglas de propagación y asociación. El enrutamiento entre cuentas se gestiona a través de TGW Resource Share. BGP es fundamental para los attachments de VPN y DX Gateway, con TGW anunciando sus rutas y aprendiendo rutas de sus routers on-premises. Cada TGW puede funcionar como un dynamic routing peer. Cloud WAN extiende esto con propagación automática de rutas y enrutamiento basado en políticas a través de regiones definidas en una política de red global. El enrutamiento entre tablas de rutas de TGW arbitrarias requiere rutas estáticas explícitas o enrutamiento basado en políticas dentro de Cloud WAN.

Los hubs de Azure vWAN exponen tablas de rutas que pueden asociarse con varias conexiones. Routing Intent y Routing Policies permiten a los administradores dictar cómo fluye el tráfico, por ejemplo, forzando el tráfico saliente a Internet a través del firewall de un Secure Hub o enrutando el tráfico VNet-a-VNet directamente. BGP se usa extensivamente para conexiones ExpressRoute y VPN Gateway en el hub de vWAN. Los circuitos ExpressRoute normalmente hacen peering con el Microsoft enterprise edge (MSEE), que luego inyecta rutas en el hub de vWAN. Para entornos híbridos, vWAN simplifica la agregación y el anuncio de rutas, reduciendo significativamente la complejidad de BGP vista con los modelos tradicionales de hub-and-spoke de Azure que utilizan UDRs.

GCP NCC utiliza una capacidad de enrutamiento global similar a la red general de Google Cloud. Los spokes adjuntos a un hub de NCC intercambian rutas automáticamente. Cada spoke obtiene una tabla de rutas y las rutas se propagan. BGP se emplea para los attachments de VPN e Interconnect. Para Cross-Cloud Interconnect, las sesiones BGP se establecen directamente con el proveedor de cloud peer (por ejemplo, AWS Direct Connect Gateway) en la ubicación de Interconnect, permitiendo el intercambio de rutas entre entornos cloud. La fortaleza de NCC radica en su anuncio y aprendizaje unificado de rutas globales, eliminando la necesidad de una configuración de enrutamiento interregional explícita o configuraciones complejas de enrutamiento transitivo que normalmente se requieren para otra conectividad multi-región.

Throughput, Latencia y Rendimiento Interregional

El throughput máximo de AWS TGW por attachment es típicamente de 50 Gbps, con una agregación de hasta 100 Gbps por TGW a través de múltiples attachments para el tráfico inter-VPC. El Inter-Region TGW Peering ofrece un ancho de banda significativamente mayor que las VPNs, a menudo superando los 5 Gbps por conexión peer, pero puede escalar hasta 50 Gbps dependiendo de la demanda y la capacidad regional, con una latencia comparable al peering de VPC puro entre regiones. Para on-premises, las conexiones Direct Connect de hasta 100 Gbps pueden terminar en un Direct Connect Gateway, que luego se conecta a un TGW. El rendimiento es excelente siempre que el TGW no esté saturado por el volumen de VPCs y rutas.

La capacidad de throughput del hub de Azure vWAN es dinámica; los VPN Gateways escalan hasta 10 Gbps y los ExpressRoute Gateways hasta 20 Gbps (se pueden terminar múltiples ExpressRoutes). El throughput agregado del hub de vWAN entre VNets a menudo se cotiza alrededor de 100 Gbps para hubs grandes. El tráfico interregional VNet-a-VNet a través de vWAN aprovecha el backbone global de Microsoft, entregando conectividad de alta velocidad y baja latencia dentro de la red de Azure. Los Secure Hubs con Azure Firewall pueden introducir latencia dependiendo del SKU del firewall y la carga de inspección. El rendimiento entre regiones es generalmente sólido debido a la red global de Microsoft altamente optimizada.

GCP NCC aprovecha la red privada global de alto rendimiento de Google. El tráfico VPC-a-VPC y la conectividad on-premises (VPN/Interconnect) se benefician del backbone de baja latencia y alto ancho de banda de Google. Cross-Cloud Interconnect puede alcanzar hasta 10 Gbps por enlace a AWS, con múltiples enlaces para mayor capacidad. La latencia entre las regiones de Google Cloud es consistentemente una de las más bajas de la industria, lo que se traduce directamente en las características de rendimiento de NCC. Esta es una ventaja significativa para aplicaciones sensibles a la latencia que abarcan varias regiones de cloud o que requieren una comunicación multi-cloud sin interrupciones.

Integración de Appliance SD-WAN y Servicios de Seguridad

La integración de SD-WAN en AWS TGW típicamente implica el establecimiento de VPNs IPsec desde dispositivos SD-WAN de sucursal o virtual appliances (por ejemplo, FortiGate-VM, Palo Alto Networks VM-Series, Cisco Catalyst 8000V) en spokes directamente al TGW. AWS Network Manager proporciona un dashboard centralizado para monitorear redes globales, incluyendo TGWs, Cloud WAN y sitios on-premises conectados a través de VPN o Direct Connect. Aunque no aloja capacidades de seguridad de forma nativa, TGW puede dirigir el tráfico a 'inspection VPCs' que contienen firewalls virtuales para la aplicación centralizada de políticas de seguridad. Esto requiere manipulación explícita de rutas y a menudo implica configuraciones de firewall ECMP o Active/Standby, como Transit Gateway VPN ECMP para enrutamiento simétrico.

Azure vWAN ofrece capacidades integradas de SD-WAN. Muchos proveedores líderes de SD-WAN (por ejemplo, Fortinet, Versa, VMware, Cisco Viptela) han integrado sus soluciones con vWAN, simplificando la conectividad de las sucursales. Un virtual appliance gestionado puede desplegarse directamente en un hub de vWAN, simplificando el despliegue y reduciendo la sobrecarga operativa en comparación con una VNet separada. La funcionalidad de Secure Hub con Azure Firewall Manager (también es posible usar FortiGate-VM o Palo Alto VM-Series en lugar de Azure Firewall, pero requiere una VNet separada) es un gran punto de venta para la seguridad centralizada forzada. Esta integración directa agiliza el proceso de dirigir todo el tráfico de sucursal, VNet e Internet a través de un punto de inspección de seguridad común.

La historia de integración de GCP NCC con SD-WAN está evolucionando. Por ahora, sigue en gran medida el modelo VPN-to-spoke, donde los appliances SD-WAN establecen VPNs IPsec a un VPN Gateway en un VPC spoke, que luego se conecta a NCC. Si bien los principales proveedores como Fortinet y Palo Alto ofrecen robustos virtual appliances para GCP, NCC no tiene (aún) la misma integración profunda que el Secure Hub de vWAN o el soporte nativo de SD-WAN. Sin embargo, NCC facilita la conexión de despliegues SD-WAN on-premises a los servicios de Google Cloud y otros entornos cloud a través de sus diversos tipos de spoke, centralizando la gestión de estas conexiones sin dictar la solución SD-WAN en sí. La próxima integración de Private Service Connect con NCC promete una mayor simplificación para acceder a servicios SaaS y de socios.

Modelos de Costo: Egreso y Attachments

Característica	AWS Transit Gateway (TGW)	Azure Virtual WAN (vWAN)	GCP Network Connectivity Center (NCC)
Costo por hora por Hub	$0.05/hora por TGW + $0.05/hora por conexión de peering interregional	Hub Standard: $0.25/hora. Hub Seguro: $0.35/hora + costos de Azure Firewall.	$0.025/hora por unidad de hub (regional, 1000 spokes)
Costo por Attachment	$0.05/GB procesado de entrada/salida (cargo por datos procesados)	No hay cargo directo por attachment. Se aplican cargos de VPN/ExpressRoute gateway.	Spoke Unit hora: $0.0025/hora por spoke. Datos procesados: $0.02/GB para todos los datos que transitan NCC.
Transferencia de Datos Interregional	$0.02/GB - $0.09/GB (dependiendo de las regiones)	Varía según el par de regiones, típicamente $0.02/GB - $0.08/GB	$0.02/GB - $0.12/GB (varía entre regiones, específico para Cross-Cloud)
Ejemplo: 50 VPCs/VNets/Spokes (aprox.)	~50 VPCs * $0.05/GB (datos procesados) + TGW por hora. Total ~0.05 * 24 * 30 = $36/mes (solo TGW). Datos a 100TB/mes: 100 * 1024 * 0.05 = $5120.	Hub Standard ~0.25 * 24 * 30 = $180/mes. Sin cargos directos por spoke. Datos vía ExpressRoute/VPN.	Unidad de Hub NCC ~0.025 * 24 * 30 = $18/mes. 50 Unidades de Spoke ~50 * 0.0025 * 24 * 30 = $90/mes. Datos a 100TB/mes: 100 * 1024 * 0.02 = $2048.
Ejemplo: 500 VPCs/VNets/Spokes (aprox.)	~500 VPCs * $0.05/GB (datos procesados) + TGW por hora. Probablemente se necesiten múltiples TGWs en regiones grandes debido a los límites. Datos a 500TB/mes: 500 * 1024 * 0.05 = $25600.	Hub Standard ~0.25 * 24 * 30 = $180/mes. Routing Intent puede añadir tarifas. Tarifas de datos.	Unidad de Hub NCC ~0.025 * 24 * 30 = $18/mes. 500 Unidades de Spoke ~500 * 0.0025 * 24 * 30 = $900/mes. Datos a 500TB/mes: 500 * 1024 * 0.02 = $10240.

Los modelos de costos son significativamente diferentes. AWS TGW cobra por GB de datos 'procesados' (de entrada o salida a cualquier attachment). Esto significa que el tráfico east-west dentro de un TGW incurre en un cargo. Azure vWAN cobra principalmente por hora por el hub en sí y por cualquier ExpressRoute o VPN Gateway desplegado dentro de él. Se aplican cargos de egreso de datos al tráfico que sale de Azure hacia Internet, pero el tráfico VNet-a-VNet dentro de un hub de vWAN no incurre en cargos adicionales por GB para el servicio vWAN en sí (aún se aplican los cargos estándar de VNet peering si no se utiliza vWAN para VNet a VNet). GCP NCC cobra una tarifa por hora baja por la unidad de hub y una tarifa por hora por 'spoke unit'. Al igual que TGW, cobra por los datos procesados (en tránsito) a través de NCC. Sin embargo, para los datos intra-NCC, GCP cobra una tarifa por GB más baja en comparación con los $0.05/GB fijos de TGW, lo que puede ser significativo a escala.

Para un escenario con 500 VPCs/VNets/Spokes y 500TB/mes de tráfico interno agregado, AWS podría volverse rápidamente el más caro debido a su cargo de $0.05/GB por datos procesados. Los $0.02/GB por datos procesados de GCP en NCC son más competitivos. El modelo de Azure, que en gran medida abstrae los cargos por datos VNet-a-VNet internos al hub, puede ser muy atractivo para organizaciones con flujos masivos de datos internos. Sin embargo, esto es cierto en gran medida para el tráfico que permanece dentro del alcance regional del hub de vWAN. El tráfico multi-región de Azure vWAN incurrirá en tarifas de transferencia de datos interregionales, similares a AWS y GCP.

Observability y Troubleshooting

AWS proporciona métricas de CloudWatch para TGW (por ejemplo, BytesIn/Out, Packet Drop). Flow Logs para attachments de TGW permiten una visibilidad granular del tráfico, permitiendo la integración con servicios como VPC Flow Logs a S3, CloudWatch Logs o SIEMs de terceros. AWS Network Manager ofrece una vista topológica y el estado de conectividad para TGW y las conexiones asociadas. La resolución de problemas de enrutamiento a menudo implica inspeccionar las tablas de rutas de TGW, la configuración de propagación y las asociaciones de attachments, junto con el estado de la sesión BGP para VPN/DX.

Azure vWAN ofrece monitoreo integral a través de Azure Monitor, proporcionando métricas para la utilización del hub, throughput del gateway y estado de conexión de VPN/ExpressRoute. Componentes de Network Watcher como NSG Flow Logs (para Secure Hubs) y connection monitor ayudan a visualizar patrones de tráfico y diagnosticar problemas de conectividad. La naturaleza global de la consola de administración de vWAN simplifica la resolución de problemas entre regiones, proporcionando un único panel para todas las conexiones y rutas del hub. Los logs de Azure Firewall dentro de un Secure Hub ofrecen una inspección profunda del tráfico y registro de eventos de seguridad.

GCP NCC también se integra con Cloud Monitoring para métricas y Cloud Logging para auditoría y logs de flujo. Los VPC Flow Logs para spokes proporcionan registros detallados del tráfico. Google Cloud Network Intelligence Center proporciona vistas topológicas, monitoreo de rendimiento e información sobre el estado de la red a través de los spokes adjuntos. Dada la fuerte énfasis de GCP en la observability, la resolución de problemas de NCC típicamente aprovecha herramientas familiares de Cloud Console y la suite Stackdriver. El monitoreo de sesiones BGP para Interconnects es robusto, proporcionando estado detallado y rutas anunciadas.

Extractos de Configuración y Ejemplo de la Vida Real

Attachment de AWS TGW a VPC con propagación de rutas:

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
}

Este fragmento de Terraform demuestra cómo adjuntar una VPC a un AWS TGW y luego asociar y propagar sus rutas a una tabla de rutas TGW específica, lo cual es fundamental para la segmentación y la conectividad. Para despliegues a gran escala, las políticas de Cloud WAN gestionan estas asociaciones y propagaciones dinámicamente a través de múltiples TGWs.

Veredicto

AWS TGW (con Cloud WAN) es la mejor opción cuando:

• Usted es una organización nativa de AWS con más del 90% de su infraestructura en AWS.
• Necesita un control granular sobre la propagación y asociación de rutas en un entorno AWS multi-cuenta y multi-región complejo.
• Necesita integrar Direct Connects existentes y un gran número de VPNs, especialmente con requisitos específicos de BGP community.
• Su flujo de datos east-west interno es moderado, ya que el cargo de $0.05/GB por procesamiento de datos puede escalar rápidamente a grandes volúmenes.

Azure Virtual WAN es la mejor opción cuando:

• Tiene un entorno híbrido centrado en Microsoft, aprovechando en gran medida ExpressRoute y los servicios de Azure.
• La aplicación centralizada de seguridad a través de Secure Hubs y Azure Firewall Manager es un requisito crítico para el cumplimiento normativo y una gestión simplificada.
• Está desplegando un overlay SD-WAN global y prefiere una integración y gestión profundas con el backbone de la nube.
• Su tráfico VNet-a-VNet dentro de una región es extremadamente alto, ya que la fijación de precios basada en hub puede ser más predecible que el procesamiento por GB para este tipo de tráfico.

GCP Network Connectivity Center (NCC) es la mejor opción cuando:

• Usted está liderando con GCP para la mayor parte de su footprint en la nube, pero también necesita conectividad eficiente y de alto rendimiento a AWS u otras nubes a través de Cross-Cloud Interconnect.
• La simplicidad en la gestión de redes globales es una prioridad principal, ofreciendo un único constructo global en lugar de TGWs regionales o peering interregional explícito.
• Su organización valora el backbone global altamente optimizado de Google para conectividad de baja latencia y alto ancho de banda entre regiones.
• La eficiencia de costos para altos volúmenes de transferencia de datos internos es crucial, dado el cargo de procesamiento de datos más bajo de NCC ($0.02/GB) en comparación con AWS TGW para el tráfico interno.

Lectura relacionada

• AWS Network Firewall vs Palo Alto VM-Series 2025
• Estrategias de Azure ExpressRoute para Empresas Globales 2025
• GCP Cloud VPN vs Interconnect: Análisis Profundo del Rendimiento
• Integración Multi-Cloud de Fortinet SD-WAN