¿Qué es un Transit Gateway?

AWS Transit Gateway es un router virtual regional que centraliza la interconexión de VPC, VPN, Direct Connect y otros attachments compatibles. En lugar de crear una conexión directa entre cada pareja de redes, se conectan al hub y se controlan los caminos mediante tablas de rutas. El servicio enruta paquetes de capa 3 según su dirección IP de destino.

La centralización simplifica algunas topologías, aunque no hace que todas las redes conectadas puedan comunicarse automáticamente. Transit Gateway ofrece un punto de tránsito configurable, no una malla universal sin políticas. La conectividad depende de los attachments, sus asociaciones, rutas y tablas de las redes conectadas.

Attachments y tablas de rutas

Un attachment conecta al transit gateway un recurso como una VPC, VPN, gateway de Direct Connect, peering entre transit gateways o ciertos appliances. La tabla de rutas del transit gateway decide a qué attachment enviar el tráfico. El attachment es una puerta de entrada y salida, mientras que la ruta define su siguiente salto.

Cada attachment se asocia con una tabla de rutas del transit gateway; puede propagar sus rutas a una o más tablas. Esto permite separar grupos de redes, como producción, desarrollo y servicios compartidos. Asociar y propagar son acciones distintas: una controla qué tabla procesa el tráfico entrante desde el attachment, la otra instala sus rutas en una o varias tablas.

Las rutas pueden propagarse automáticamente desde algunos tipos de conexión o añadirse de forma estática. El peering entre transit gateways, por ejemplo, requiere rutas estáticas en las tablas pertinentes. El comportamiento depende del tipo de attachment y la configuración. No supongas que una ruta aprendida en una VPC aparece en cualquier tabla central.

-InfraCrew dice: Un hub ordena el tránsito; las rutas siguen necesitando destino.-

La ruta completa atraviesa más de una tabla

Para que una instancia de una VPC llegue a otra, debe existir una ruta en la tabla de la subred de origen hacia el transit gateway. Después, la tabla del transit gateway debe enviar el destino al attachment adecuado; la VPC de destino necesita rutas de retorno y controles de acceso compatibles. La ruta de ida y la de vuelta deben revisarse como un conjunto.

Al adjuntar una VPC, AWS requiere seleccionar una subred por zona de disponibilidad para el attachment. El servicio utiliza esas subredes como puntos de entrada y salida y no alcanza recursos en zonas donde no haya attachment habilitado. La disponibilidad regional no sustituye a la planificación por zona. Los cambios de tabla en las subredes asociadas también pueden afectar a qué destinos resultan alcanzables.

El transit gateway puede actuar como router central entre VPC y redes locales a través de VPN o Direct Connect. También se pueden crear tablas adicionales para aislar dominios. La segmentación depende de que los attachments se asocien y propaguen con intención. Una asociación accidental con la tabla por defecto puede mezclar redes que se pretendían mantener separadas.

-InfraCrew dice: El hub es central; los permisos de paso no tienen por qué serlo.-

Cuándo ayuda y qué cuesta

El modelo hub-and-spoke reduce el número de conexiones punto a punto y ofrece un lugar común para gestionar rutas. Resulta útil cuando crecen VPC, cuentas o enlaces híbridos. Menos enlaces directos pueden significar más claridad, especialmente si hay convenciones de nombres y propietarios para cada attachment.

La centralización también introduce dependencias operativas y coste. AWS cobra por attachment y por datos procesados; las rutas incorrectas en el hub pueden afectar a varias redes. El coste y el dominio de fallo deben formar parte del diseño. Para aplicaciones críticas, revisa cuotas, disponibilidad por zona, capacidad y cómo se aíslan fallos de una ruta o servicio compartido.

Las VPC conectadas al mismo transit gateway no deben tener bloques de direcciones que hagan ambiguos los destinos. Planifica CIDR, sumarización, tablas y prefijos antes de sumar cuentas. El enrutamiento central no arregla un plan IP incompatible. Para conectividad entre regiones o gateways, las tablas y rutas requeridas cambian y deben documentarse por separado.

Revisiones antes de habilitar tránsito

Dibuja las redes, attachments, tablas asociadas y rutas propagadas. Marca qué segmentos pueden comunicarse y cuáles deben quedar aislados; añade también los caminos a las redes locales. Un mapa de conectividad debe mostrar rutas efectivas, no solo líneas entre iconos.

Valida primero las rutas de las subredes VPC, luego las tablas del transit gateway y finalmente el retorno en destino. Revisa Security Groups, Network ACLs, firewalls y rutas asimétricas. Un ping fallido no identifica qué tabla descartó el tráfico; registra trazas y métricas en cada salto permitido.

Prueba tanto el acceso autorizado como el aislamiento esperado entre dominios. Confirma disponibilidad desde cada zona, conmutación del enlace híbrido y efecto de una ruta retirada. La segmentación es una propiedad que se prueba, no una intención escrita en el diagrama.

-InfraCrew dice: Si un spoke llega a todos los demás, comprueba primero si ese era el diseño.-

Diccionario de la Crew

Attachment — Conexión lógica entre un transit gateway y una red o servicio compatible.

Propagación de rutas — Instalación de rutas aprendidas desde un attachment en una tabla del transit gateway.

Spoke — Red periférica conectada a un hub central.