Bienvenidos a un nuevo workshop del maravilloso mundo de las redes en la nube.
Usualmente nuestros recursos están desplegados en diferentes redes (VPCs), ya sea porque necesitamos separar cargas de trabajo o porque consumimos servicios propios o de terceros.
Para lograr una comunicación privada entre estos componentes, nuestras redes deben estar interconectadas. En una entrega anterior, aprendimos sobre VPC Peering Workshop Vpc-Peering paso a paso, una excelente alternativa para conexiones uno a uno. Sin embargo, este enfoque deja de ser escalable y eficiente cuando el número de VPCs crece, ya que administrar múltiples conexiones de forma individual se vuelve complejo. Además, las conexiones VPC Peering no son transitivas.
Que son las conexiones transitivas?
En el contexto de redes en la nube, es la capacidad de enlazar múltiples entornos a un único punto central (un hub) logrando que todos se comuniquen entre sí de forma nativa. Con VPC Peering, si tienes cinco redes que necesitan interactuar, tendrías que crear y gestionar diez conexiones individuales (una malla compleja, que se vuelve mas compleja entre mas redes existan). Con AWS Transit Gateway, el enrutamiento es transitivo: cada VPC se conecta una sola vez al hub central y, de inmediato, todas pueden intercambiar datos de ida y vuelta. Además, si en el futuro necesitas aislamiento (por ejemplo, evitar que la red de Desarrollo se comunique con Producción), tienes la flexibilidad de restringirlo gestionando las tablas de rutas dentro del mismo Transit Gateway.
Revisemos la diferencia entre cantidad de conexiones cuando usamos vpc peerings y transit gateway, veamos esto con un grafico.
Como puedes ver en el gráfico, si tenemos 10 VPCs y queremos que todas se comuniquen entre sí usando conexiones VPC Peering uno a uno, esto se traduciría en 45 conexiones individuales.
Si eres fanático de entender el porqué de las cosas, esto se explica matemáticamente con la siguiente fórmula (que también tiene toda la lógica del mundo):
n(n-1) / 2
Donde n es el número de VPCs. Si aplicamos la fórmula para nuestras 10 redes:
10 x (10-1) = 99
99 / 2 = 45
¿Por qué el número crece de forma tan agresiva?
💡 Pro-Tip: Porque la VPC 1 tiene que establecer conexión con 9 redes distintas. Luego, la VPC 2 tiene que conectarse a 8 redes adicionales (porque ya contamos su conexión con la 1). La VPC 3 se conecta a 7, y así sucesivamente.
Bueno, hemos terminado la teoría. Espero que los conceptos estén claros hasta aquí, porque llegó la hora de ensuciarnos las manos y pasar a la acción.
Este es el diagrama de arquitectura de lo que vamos a desplegar el dia de hoy:
Para este laboratorio utilizaremos un stack base que desplegaremos automáticamente mediante AWS CloudFormation. El objetivo de esto es enfocarnos en lo que de verdad nos interesa para este workshop en particular: la configuración e implementación manual del Transit Gateway.
Solo debes descargar la plantilla (Iac/stack-base.yaml) disponible en el repositorio de este workshop:
madriz03
/
Transit-Gateway-Workshop
AWS Transit Gateway Workshop
Antes de ejecutar la plantilla, hagamos un breve repaso mental de la arquitectura. Es importante entender qué parte del trabajo pesado estamos delegando y cuál es nuestra verdadera misión en este taller.
🏗️ Lo que despliega CloudFormation (La base automática)
Para que podamos simular un entorno realista, la plantilla creará la siguiente infraestructura subyacente:
3 VPCs independientes (VPC A, VPC B y VPC C) simulando distintos entornos o departamentos.
Subredes y tablas de enrutamiento locales para cada VPC.
Un Internet Gateway para cada VPC, permitiendo el tráfico de salida.
Instancias EC2 de prueba en cada red, con sus respectivos Security Groups configurados para permitir tráfico ICMP (necesario para hacer ping).
Un Rol de IAM con políticas de Systems Manager (SSM) adjunto como perfil de instancia a las EC2. Esto nos permitirá conectarnos a los servidores directamente desde el navegador de manera segura, sin necesidad de gestionar claves SSH.
(Nota: En este punto, las redes están totalmente aisladas. Si nos conectamos a una instancia e intentamos hacer ping a otra, el paquete se perderá).
🎯 Lo que haremos nosotros (La verdadera acción)
Aquí es donde entras tú. Una vez que la infraestructura base esté lista, iremos a la consola de AWS a construir el núcleo de la comunicación:
Crear el Transit Gateway: Nuestro enrutador central.
Configurar los Attachments: Conectaremos cada una de las VPCs a nuestro Transit Gateway.
Actualizar el Enrutamiento: Modificaremos las tablas de rutas de cada VPC para decirles: "Si quieres hablar con otra red, envía el tráfico a través del TGW".
Pruebas de conectividad: Confirmaremos que la conexión transitiva funciona realizando pings exitosos entre redes que antes estaban aisladas.
Manos a la obra, vayamos a cloudformation y creemos un stack con la plantilla base: stack-base.yaml que descargaste.
Después de subir la plantilla, asígnale un nombre al stack (en mi caso le pondré workshop-tgw) y avanza en el asistente hasta llegar a la pantalla final de revisión.
Por último, en la parte inferior de la página, asegúrate de marcar esta casilla antes de hacer clic en crear:
☑ I acknowledge that AWS CloudFormation might create IAM resources with custom names.
¿Por qué AWS nos pide esto?
Es una medida de seguridad. Con esto confirmamos de manera explícita que autorizamos a la plantilla para crear recursos de identidad. En nuestro caso, le estamos dando permiso de crear el Rol de IAM con las políticas de SSM que usarán nuestras instancias EC2.
Solo debes esperar unos minutos para ver el stack con el status de "CREATE_COMPLETE"
Cuando el stack termine de desplegarse, siéntete libre de explorar los recursos que acabas de crear. Puedes ver la lista completa desde la pestaña "Recursos" en la consola de CloudFormation, o navegando directamente por cada servicio involucrado.
Crear Transit Gateway
Comencemos con la joya de la corona. Dirígete a la consola del servicio VPC para crear nuestro Transit Gateway, el enrutador central que nos permitirá interconectar las redes de manera eficiente
En el panel de navegación izquierdo, haz scroll hacia abajo hasta encontrar la sección Transit Gateways.
Haz clic en la opción Transit Gateways y luego presiona el botón naranja (Crear transit gateway).
Name tag: Asigna un nombre para identificar tu recurso. En mi caso, le colocaré tgw-workshop.
Description: Aunque este campo es opcional, una buena práctica de arquitectura es colocar siempre un detalle claro. Puedes usar algo como: "Conecta VPC A, VPC B y VPC C".
Campo ASN: El ASN (Número de Sistema Autónomo, por sus siglas en inglés) es básicamente un identificador único que usan las redes para presentarse y compartir rutas entre sí mediante un protocolo llamado BGP. Piensa en ello como el "código postal" de tu Transit Gateway, Para efectos de ESTE workshop, la respuesta corta es que puedes colocar el valor por defecto que te da AWS, que es 64512.
Opciones adicionales (El enrutamiento interno del TGW):
Antes de hacer clic en crear, notarás que AWS deja varias casillas marcadas por defecto. Déjalas así. Las dos más importantes para el éxito de nuestro laboratorio son:
Default route table association: Al dejar esto marcado, el Transit Gateway creará una Tabla de Rutas por defecto internamente y asociará automáticamente a ella cualquier VPC que conectemos.
Default route table propagation: Esta es la verdadera magia. Le indica al Transit Gateway que aprenda automáticamente el bloque de IPs (CIDR) de cada VPC que conectemos. Así, el TGW sabrá exactamente hacia dónde enviar el tráfico sin que tengamos que escribir las rutas a mano dentro de él.
- Ahora sí, ve al final de la página y haz clic en "Create transit gateway".
(💡 Pro-Tip: En entornos de producción más complejos donde requieras aislamiento —por ejemplo, que la VPC de Desarrollo no pueda ver a la VPC de Producción—, estas casillas suelen desmarcarse para crear múltiples tablas de rutas manuales. Para nuestro caso de interconexión total, la configuración por defecto es perfecta).
Crear Attachments (Conexiones)
Los attachments no son más que el "cable virtual" que conecta cada VPC a nuestro hub central (el Transit Gateway). Para crearlos, nos mantenemos en la columna izquierda del servicio VPC y ubicamos la opción Transit Gateway Attachments.
Haz clic en el botón Create transit gateway attachment. Deberás repetir los siguientes pasos para cada una de nuestras tres VPCs:
Name tag: Asigna un nombre para identificar la conexión. Te sugiero usar Attachment-VPC-01 (y luego -02 y -03 para las siguientes).
Transit Gateway ID: Selecciona el enrutador central que creamos en el paso anterior (tgw-workshop).
Attachment type: Selecciona VPC.
(Nota técnica: Un Transit Gateway es muy versátil; como verás en el menú, además de VPCs, también permite conectar redes físicas a través de VPN Site-to-Site, AWS Direct Connect, entre otros).
VPC ID: Selecciona tu VPC-01. Con esto le confirmamos a AWS que estamos creando un enlace directo entre esta red específica y nuestro hub.
Subnet IDs: Selecciona la subred de esa VPC (ej. subnet-01). Aquí es donde "habitará" físicamente la interfaz de red de este attachment.
💡 Pro-Tip de Arquitectura: Por simplicidad, en este workshop usamos una sola subred. Sin embargo, en producción la mejor práctica es crear subredes /28 exclusivas para los attachments.
¿La razón técnica? El attachment inyecta una interfaz (ENI) que obedece a la Tabla de Rutas y NACLs de su subred. Si lo alojas junto a tus servidores, compartirán las mismas reglas y perderás control direccional. Aislarlo te permite tener una tabla de rutas independiente para el TGW, un requisito arquitectónico indispensable si a futuro necesitas forzar que el tráfico entrante pase primero por un Firewall de inspección antes de llegar a tus aplicaciones.
Para terminar, simplemente haz clic en el botón Create transit gateway attachment.
¡Repite el proceso! Vuelve a realizar estos mismos pasos para crear los dos attachments restantes. Presta especial atención en seleccionar la VPC correspondiente en cada iteración (VPC-02 y VPC-03) y no olvides asignarles un nombre descriptivo a cada uno.
Los attachments suelen demorar pocos minutos para estar como disponibles.
Actualizar las Tablas de Enrutamiento (Route Tables) de nuestras VPCs.
¿Por qué es necesario este paso?
Imagina que construiste una carretera nueva entre tres ciudades, pero olvidaste poner los letreros. Las VPCs están conectadas al Transit Gateway, pero por defecto no saben que deben enviar el tráfico por ahí.
Tenemos que ir a las tablas de rutas que creó nuestra plantilla de CloudFormation y agregar ese "letrero".
Allí verás las tablas creadas por nuestro stack (rt-01, rt-02 y rt-03), las cuales ya están asociadas a nuestras subredes (sub-01, sub-02 y sub-03).
Selecciona la primera tabla de rutas (rt-01).
En la parte inferior, ve a la pestaña Routes (Rutas) y haz clic en el botón Edit routes (Editar rutas).
De momento solo existen dos rutas, la ruta local y una ruta de salida hacia el Internet Gateway (0.0.0.0/0). Esta última es vital, ya que es la que permite que el agente de Systems Manager (SSM) tenga salida a Internet y nos podamos conectar a las instancias más adelante sin usar claves SSH.
Nuestra VPC-01 tiene el bloque de red 10.0.0.0/16. Para que pueda alcanzar a sus vecinas, debemos agregar las siguientes dos rutas en su tabla rt-01:
- Destino: 11.0.0.0/16 (VPC-02) ➡️ Target: Transit Gateway
- Destino: 12.0.0.0/16 (VPC-03) ➡️ Target: Transit Gateway
💡 ¿Cómo se lee esto en lenguaje humano?
Básicamente le estamos diciendo a la red: "Cuando queramos comunicarnos con la VPC-02 o la VPC-03, envía ese tráfico al Transit Gateway; él ya sabe cómo resolverlo y llevarlo a su destino.
¡Atención con las otras tablas!
Recuerda que debes repetir la misma lógica para las otras dos redes:
- En la rt-02, deberás agregar rutas hacia la 10.0.0.0/16 (VPC-01) y 12.0.0.0/16 (VPC-03).
- En la rt-03, deberás agregar rutas hacia la 10.0.0.0/16 (VPC-01) y 11.0.0.0/16 (VPC-02).
Prueba de Conectividad
¡Llegó la hora de la verdad! Es el momento de poner a prueba toda nuestra arquitectura de red. Para ello, vamos a conectarnos a nuestras instancias EC2 y, desde allí, haremos un ping hacia las direcciones IP privadas de las otras dos instancias. Esto nos confirmará que los paquetes viajan, reciben respuesta y que nuestras VPCs están interconectadas correctamente gracias al Transit Gateway.
Cómo realizar la prueba:
Dirígete al servicio EC2 y en el panel izquierdo selecciona Instances.
Selecciona la instancia EC2-01 que pertenece a la VPC-01 y haz clic en el botón superior que dice Connect (Conectar).
- Ve a la pestaña Session Manager y haz clic nuevamente en Connect. Esto abrirá una terminal segura en tu navegador.
- Una vez dentro de la consola negra, ejecuta el comando de ping utilizando la IP privada de las instancias de la VPC-02 y VPC-03 (puedes ver sus IPs privadas desde la consola de EC2).
💡 Pro-Tip: Te recomiendo abrir dos ventanas en el servicio EC2 uno para hacer la conexion y otro para copiar las Ips privadas de las instancias a las que te quieres conectar.
# Ejemplo: Ping desde EC2-01 hacia la EC2-02 en VPC-02
# No olvides utilizar la ip privada de tu instancia.
ping -c 4 11.0.0.188
¡Tenemos respuesta satisfactoria! Esto significa que la VPC-01 y la VPC-02 están conectadas exitosamente.
# Ejemplo: Ping desde EC2-01 hacia la EC2-03 en VPC-03
# No olvides utilizar la ip privada de tu instancia.
ping -c 4 12.0.0.172
¡Qué belleza! La VPC-01 está conectada exitosamente tanto con la VPC-02 como con la VPC-03.
🎯 Te dejo un pequeño reto
Ya puedes cerrar la sesión de terminal con la que ingresaste a la EC2-01.
Conéctate de la misma manera a la EC2-02 y haz ping hacia la IP privada de la EC2-01. Espera la respuesta y luego haz ping a la IP privada de la EC2-03.
De igual manera, conéctate a la EC2-03 y haz ping hacia la IP privada de la EC2-01 y EC2-02.
Yo ya lo hice y todo está funcionando perfecto, pero hay que dejar evidencias, así que te adjunto mis conexiones exitosas. ¡Tú cuéntame en los comentarios qué tal te fue!
Ping exitoso desde EC2-01 hacia EC2-02 y EC2-03
Ping exitoso desde EC2-02 hacia EC2-01 y EC2-03
Ping exitoso de EC2-03 hacia EC2-01 y EC2-02
Resumen y cierre de Workshop
Hasta aquí todo ha funcionado a la perfección. Hemos desplegado un stack base usando infraestructura como código (IaC) con CloudFormation. Esto nos ahorró tiempo valioso y nos permitió enfocarnos directamente en nuestro propósito principal: dominar el AWS Transit Gateway.
Haciendo un repaso de lo que logramos construir hoy:
Creamos el Hub Central: Desplegamos desde cero nuestro AWS Transit Gateway, configurándolo como el enrutador central (la estrella) de nuestra arquitectura.
Comprendimos el núcleo: Vimos cómo funciona la propagación de rutas y la asociación automática a la tabla de rutas central del TGW.
Visión de arquitectura: Conocimos en qué casos de uso empresariales es necesario crear tablas individuales con rutas personalizadas para aislar entornos.
Conectamos la infraestructura: Hicimos los attachments correspondientes para unir nuestras tres VPCs al hub central.
Dirigimos el tráfico: Creamos las rutas en las tablas locales de cada subred, enseñándole a los paquetes de red que, para hablar con una instancia en otra VPC, debían tomar el camino del Transit Gateway, dejando que este se encargara del enrutamiento final.
Validamos con éxito: Finalizamos con las pruebas de conexión cruzada, obteniendo resultados exitosos y respuestas satisfactorias para todas las combinaciones posibles.
Limpieza de recursos (Evita cargos en tu cuenta)
Es muy importante eliminar los recursos que creamos hoy para no generar gastos innecesarios, especialmente el Transit Gateway, que tiene un costo por hora de uso. Sigue este orden exacto:
- Eliminar los Attachments: En el menú izquierdo de VPC, ubica Transit Gateway Attachments. Selecciona los tres que creaste, haz clic en Actions y luego en Delete transit gateway attachment.
(Nota importante: Debes esperar un par de minutos a que su estado pase completamente a "Deleted" antes de continuar).
Eliminar el Transit Gateway: Ve a la sección Transit Gateways, selecciona tu tgw-workshop, haz clic en Actions y luego en Delete.
Eliminar el Stack de CloudFormation: Finalmente, ve al servicio CloudFormation, selecciona el stack que creaste al inicio del laboratorio y haz clic en Delete. Esto se encargará de destruir automáticamente las VPCs, subredes, instancias EC2 y el Internet Gateway.
Hemos terminado
Si hiciste este workshop y sientes que aprendiste algo, tienes alguna duda, quieres llevarlo a otro nivel o simplemente quieres conversar, ¡deja tu comentario! Por último, no olvides compartirlo con tus compañeros, grupos de estudio y el mundo entero.
Hasta la próxima.
Top comments (0)