AWS Transit Gateway: Patrones de Diseño Multi-Cuenta de Alta Escala para 2026

En 2026, el AWS Transit Gateway (TGW) sigue siendo la columna vertebral indiscutible de cualquier arquitectura multi-cuenta de nivel empresarial, pero la “luna de miel” del modelo hub-and-spoke ha terminado para los ingenieros que no tienen en cuenta la fatiga de los peering connections, los límites de las cuotas y la necesidad absoluta de una inspección centralizada. Si aún gestiona VPC peering connections individuales o la propagación manual de rutas en una dispersión de más de 50 cuentas, no está diseñando; solo está esperando que un bucle de ruteo o una excepción de “Quota Exceeded” derribe su stack de producción. El diseño moderno de TGW requiere un enfoque implacable en la automatización con Resource Access Manager (RAM), dominios de ruteo aislados y la integración de Gateway Load Balancer (GWLB) para resolver la brecha de seguridad Este-Oeste.

La Realidad Multi-Cuenta de 2026: Escalar o Morir

Los días de una única cuenta monolítica de AWS quedaron atrás hace mucho tiempo. Las organizaciones ahora alcanzan la marca de más de 500 VPCs en cientos de cuentas gestionadas a través de AWS Organizations. A esta escala, el TGW se convierte en algo más que un router; es una capa de abstracción. Al usar AWS Resource Access Manager (RAM), puede compartir un único TGW (residiendo en una cuenta dedicada de Network Services/Hub) con toda la Organization. Esto evita la “shadow networking” donde los desarrolladores levantan VPCs aisladas que satisfacen requisitos locales pero violan las políticas corporativas de egreso.

Sin embargo, escalar a más de 1,000 VPCs introduce un conjunto específico de limitaciones. Si bien el TGW teóricamente soporta 5,000 attachments por región, el verdadero cuello de botella es el límite de tablas de ruteo del TGW (actualmente 20 por TGW) y las rutas por tabla de ruteo del TGW (10,000). Para sobrevivir a la escala de 2026, debe alejarse del ruteo plano y adoptar un enfoque similar a VRF dentro del TGW utilizando múltiples Route Tables adaptadas a las capas de aplicación (ej., Prod, Dev, Shared Services, Inspection).

Resource Access Manager (RAM) y el Pipeline de Automatización

Compartir manualmente el TGW a través de la consola es una infracción grave. En un entorno profesional de CI/CD, la cuenta Hub debe compartir automáticamente el recurso TGW con toda la Organizational Unit (OU). Cuando se aprovisiona una nueva cuenta a través de Control Tower o una fábrica de cuentas personalizada (Account Factory), debe recibir automáticamente una “TGW Attachment Request.”

# Terraform snippet para compartir con RAM
resource "aws_ram_resource_share" "tgw_share" {
  name                      = "central-tgw-share"
  allow_external_principals = false
}

resource "aws_ram_principal_association" "org_association" {
  principal          = data.aws_organizations_organization.current.arn
  resource_share_arn = aws_ram_resource_share.tgw_share.arn
}

resource "aws_ram_resource_association" "tgw_association" {
  resource_arn       = aws_ec2_transit_gateway.main.arn
  resource_share_arn = aws_ram_resource_share.tgw_share.arn
}

Un consejo crítico: Deshabilite siempre default_route_table_association y default_route_table_propagation en el TGW. Si deja estas opciones activas, cada nuevo attachment de VPC volcará automáticamente sus rutas locales en una tabla global y recibirá rutas a todas las demás VPCs. Esto es una pesadilla en términos de radio de explosión. Desea un ruteo explícito y basado en la intención.

La VPC de Inspección: Implementando GWLB en el Borde

La Deep Packet Inspection (DPI) para el tráfico Este-Oeste (VPC-a-VPC) y Norte-Sur (VPC-a-Internet) es innegociable. El estándar de oro para 2026 es el patrón de VPC de Inspección utilizando el Gateway Load Balancer (GWLB) y una flota de dispositivos FortiGate o Palo Alto VM-Series. Al usar TGW, puede dirigir el tráfico desde cualquier spoke VPC hacia la VPC de Inspección antes de que llegue a su destino.

Esto se logra mediante el Appliance Mode. Asegúrese de que appliance_mode_support esté habilitado en el attachment de TGW a la VPC de Inspección. Sin esto, el TGW no mantendrá la simetría de flujo, enviando la solicitud a través del firewall de una AZ y la respuesta a través de otra, lo que hará que el firewall con estado descarte el paquete. Para una inmersión más profunda en la integración de firewalls, consulte nuestra guía sobre Patrones de Diseño de FortiGate GWLB.

Ingeniería de Tráfico: Segregando Prod, Dev y Shared Services

Para limitar el radio de explosión, trate las tablas de ruteo del TGW como VRFs en el mundo de Cisco. Debería tener, como mínimo:

• Prod_RT: Contiene rutas para VPCs de producción. Propaga a la VPC de Inspección pero NO a la Dev_RT.
• Dev_RT: Contiene rutas para entornos de desarrollo. Aislado de Prod a nivel de TGW.
• Inspection_RT: La tabla de “aterrizaje” para todo el tráfico que requiere escrutinio. Esta tabla tiene una ruta predeterminada (0.0.0.0/0) apuntando al endpoint del GWLB en la VPC de Inspección.
• Edge_RT: Para attachments de Direct Connect (DX) o VPN.

El impacto en los costos de este diseño es predecible pero significativo. Cada attachment de TGW cuesta aproximadamente $36.50/mes por región (basado en $0.05/hora) más $0.02 por GB de datos procesados. En un entorno de 1,000 VPCs, está buscando $36,500/mes solo en tarifas de attachment. Si está enviando 1PB de datos a través del TGW, agregue otros $20,000. Para necesidades de alto rendimiento y baja latencia, considere el VPC Peering para pares de alto tráfico específicos, manteniendo el TGW como plano de gestión.

Mitigación del Radio de Explosión: Filtrado de Rutas y Blackholing

Una ruta mal configurada en una tabla de ruteo de TGW puede facilitar un movimiento lateral de ransomware en toda su empresa. Utilice rutas de Blackhole estratégicamente. Si un rango CIDR específico nunca debería ser alcanzable a través del TGW (por ejemplo, su subred de gestión legacy on-premise que tiene su propio DX), póngalo explícitamente en blackhole en las tablas de ruteo de Spoke.

Además, implemente Service Control Policies (SCPs) para evitar que los desarrolladores modifiquen las tablas de ruteo en sus VPCs locales para eludir el TGW. La tabla de ruteo de VPC local debe tener un 0.0.0.0/0 o un CIDR específico apuntando a la interfaz del TGW para que el tráfico regional sea inspeccionado. Si un desarrollador cambia esto a un Internet Gateway (IGW) directamente, ha eludido su stack de seguridad. Use SCPs para denegar ec2:CreateRoute y ec2:DeleteRoute cuando la ID del gateway sea un IGW, a menos que la cuenta esté explícitamente en la lista blanca.

La Integración con Direct Connect Gateway (DXGW)

La conexión de su centro de datos on-premise a un entorno TGW multi-cuenta requiere un Transit VIF en su Direct Connect. No use Private VIFs para esto; no escalan y no funcionarán con TGW. El Transit VIF termina en un Direct Connect Gateway (DXGW), que luego se asocia con el TGW. Esto permite que hasta 3 TGWs (potencialmente en diferentes regiones) compartan la misma conexión DX.

En 2026, estamos viendo que más empresas optan por conexiones dedicadas de 100Gbps. A este ancho de banda, el límite por flujo del TGW (aproximadamente 10Gbps por flujo de attachment de VPC) se convierte en el cuello de botella. Para lograr velocidades más altas, debe usar múltiples flujos o considerar AWS Cloud WAN si su huella es verdaderamente global en más de 10 regiones, ya que Cloud WAN automatiza el peering interregional que el TGW requiere que construya manualmente.

Escalando Más Allá de 1000 VPCs: TGW Peering vs. Cloud WAN

Una vez que exceda los límites físicos o lógicos de un único TGW, o cuando sus requisitos de latencia entre Tokio y US-East-1 se vuelvan críticos, debe decidir entre TGW Peering y AWS Cloud WAN. TGW Peering es un proceso estático y manual. Crea el attachment de peering y luego actualiza manualmente las tablas de ruteo en ambos lados. Es tedioso y propenso a “podredumbre de rutas.”

AWS Cloud WAN utiliza un Network Function Manager y una Core Network Policy (un documento JSON) para definir cómo interactúan los segmentos (como Prod y Dev) a nivel global. Si opera a nivel de una empresa Fortune 100, Cloud WAN es el estándar de 2026. Sin embargo, para la mayoría de las empresas, un hub regional de TGW con TGW Peering para las 2-3 regiones secundarias es más rentable y fácil de solucionar utilizando herramientas estándar como Reachability Analyzer.

Conclusión: El Veredicto de TechLeague

Construir una red multi-cuenta en 2026 sin un Transit Gateway es una receta para la bancarrota operativa. Sin embargo, el TGW es un router “tonto” a menos que lo envuelva en un marco de políticas estricto. Use RAM para la distribución, múltiples Route Tables para el aislamiento y GWLB para la inspección centralizada. Cualquier cosa menos es simplemente una red plana con un costo de tamaño de nube. Si su equipo de redes tiene dificultades para desacoplar la seguridad de la conectividad a escala, consulte nuestras auditorías de infraestructura personalizadas en techleague.io.

Preguntas Frecuentes

¿Por qué no usar simplemente VPC Peering, ya que es gratuito para la transferencia de datos dentro de la misma AZ?

El VPC Peering crea un caos de complejidad n^2. Si bien ahorra en tarifas de procesamiento de datos, la sobrecarga de gestión de actualización de cientos de tablas de ruteo y grupos de seguridad, combinada con la falta de ruteo transitivo, lo hace imposible de gestionar a escala. Use TGW para el plano de gestión y VPC Peering solo para flujos “elefante” de alto ancho de banda entre dos VPCs específicas.

¿Cómo manejo CIDRs superpuestos en un entorno TGW?

El TGW no maneja CIDRs superpuestos de forma nativa en la misma Route Table. Debe usar Private NAT Gateway en las spoke VPCs para traducir su IP de origen antes de que llegue al TGW, o usar tablas de ruteo de TGW separadas y mapearlas a través de una “VPC de Traducción” que contenga más instancias NAT o firewalls realizando DNAT/SNAT.

¿El TGW soporta multicast?

Sí, el TGW soporta multicast IGMP. Debe crear un Multicast Domain en el TGW y asociar las subredes de VPC específicas. Esto es crítico para aplicaciones financieras legacy o ciertos protocolos de transmisión de medios que no se han modernizado para entornos de nube unicast.

¿Cuál es el rendimiento máximo de un solo TGW?

Aunque AWS dice que el TGW escala “dinámicamente”, cada attachment de VPC está limitado a 50Gbps de rendimiento en ráfaga. Crucialmente, un solo flujo TCP generalmente está limitado a 10Gbps. Si necesita 100Gbps entre dos VPCs, debe asegurarse de que su tráfico se distribuya entre muchos flujos distintos de 5-tuplas.

¿Debería usar TGW Connect para la integración de SD-WAN?

Absolutamente. Los attachments de TGW Connect le permiten ejecutar túneles GRE sobre el TGW, lo que permite la interconexión BGP directamente entre sus dispositivos virtuales SD-WAN (como Cisco SD-WAN o Silver Peak) y el TGW. Esto elimina la necesidad de numerosas VPNs IPsec y simplifica significativamente la tabla de enrutamiento.

¿Cómo resuelve el Appliance Mode el problema de asimetría de flujo?

Cuando el Appliance Mode está habilitado en un attachment, el TGW asegura que, durante la vida de un flujo, selecciona la misma Network Interface (y, por lo tanto, la misma AZ) para el tráfico de retorno que se utilizó para la solicitud inicial. Esto es vital para firewalls con estado en una VPC de Inspección que de otra forma descartarían los paquetes si solo vieran un lado del handshake.