¡Bienvenidos todos a un nuevo workshop sobre redes! El día de hoy vamos a trabajar con VPC Peering: aprenderemos qué es, cuándo podemos usarlo, cuáles son sus beneficios e inclusive cuándo es mejor evitarlo. Pero no nos quedaremos solo en la teoría; implementaremos esta solución conectando dos redes totalmente aisladas y realizaremos pruebas para mover tráfico real entre los recursos desplegados en cada VPC.
¿Qué es un VPC Peering?
Un VPC Peering (o interconexión de VPC) es una conexión de red entre dos VPC que permite el enrutamiento de tráfico entre ellas utilizando direcciones IPv4 o IPv6 privadas. Los recursos desplegados en estas redes pueden comunicarse entre sí como si estuvieran dentro de la misma red local. Lo mejor de todo es que permite conectar VPC que están en la misma región, en regiones distintas e, inclusive, pertenecientes a cuentas de AWS diferentes.
Alcance del workshop
Nos enfocaremos en cómo establecer la interconexión y las reglas de seguridad necesarias para mover el tráfico de una VPC a otra de manera segura, aplicando el principio de mínimo privilegio.
Como en guías anteriores ya aprendimos los conceptos fundamentales de VPC y sus componentes, no repetiremos ese trabajo de forma manual. Para centrar nuestra atención únicamente en la interconexión, las rutas y la seguridad, he preparado una plantilla de CloudFormation en formato YAML. Con ella desplegaremos automáticamente las VPC que vamos a interconectar y los recursos que intercambiarán tráfico una vez establecido el peering.
Plantilla cloudformation para desplegar recursos
AWSTemplateFormatVersion: '2010-09-09'
Description: 'Infraestructura base para Workshop de VPC Peering y EIC Endpoint - Entorno Privado'
Parameters:
LatestAmiId:
Type: 'AWS::SSM::Parameter::Value<AWS::EC2::Image::Id>'
Default: '/aws/service/ami-amazon-linux-latest/al2023-ami-kernel-6.1-x86_64'
Description: "AMI mas reciente de Amazon Linux 2023"
InstanceType:
Type: String
Default: t3.micro
Description: "Tipo de instancia para el laboratorio"
Resources:
# --- INFRAESTRUCTURA VPC 01 ---
VPC01:
Type: AWS::EC2::VPC
Properties:
CidrBlock: 10.0.0.0/24
EnableDnsSupport: true
EnableDnsHostnames: true
Tags:
- Key: Name
Value: vpc-01-workshop
Subnet01:
Type: AWS::EC2::Subnet
Properties:
VpcId:
Ref: VPC01
CidrBlock: 10.0.0.0/25
AvailabilityZone: !Select [ 0, !GetAZs "" ]
Tags:
- Key: Name
Value: subnet-01-privada
RouteTable01:
Type: AWS::EC2::RouteTable
Properties:
VpcId:
Ref: VPC01
Tags:
- Key: Name
Value: rt-01-privada
SubnetRouteTableAssociation01:
Type: AWS::EC2::SubnetRouteTableAssociation
Properties:
SubnetId:
Ref: Subnet01
RouteTableId:
Ref: RouteTable01
# --- SEGURIDAD VPC 01 ---
SGEIC01:
Type: AWS::EC2::SecurityGroup
Properties:
GroupDescription: "Security Group para EIC Endpoint 01"
VpcId:
Ref: VPC01
Tags:
- Key: Name
Value: sg-eic-01
SGInstance01:
Type: AWS::EC2::SecurityGroup
Properties:
GroupDescription: "Security Group para Instancia 01"
VpcId:
Ref: VPC01
SecurityGroupIngress:
- IpProtocol: tcp
FromPort: 22
ToPort: 22
SourceSecurityGroupId:
Ref: SGEIC01
Tags:
- Key: Name
Value: sg-instance-01
# Regla de salida para que el EIC llegue a la instancia
EIC01Egress:
Type: AWS::EC2::SecurityGroupEgress
Properties:
GroupId:
Ref: SGEIC01
IpProtocol: tcp
FromPort: 22
ToPort: 22
DestinationSecurityGroupId:
Ref: SGInstance01
# --- RECURSOS VPC 01 ---
EICEndpoint01:
Type: AWS::EC2::InstanceConnectEndpoint
Properties:
SubnetId:
Ref: Subnet01
SecurityGroupIds:
- Ref: SGEIC01
Tags:
- Key: Name
Value: eic-endpoint-01
Instance01:
Type: AWS::EC2::Instance
Properties:
InstanceType:
Ref: InstanceType
ImageId:
Ref: LatestAmiId
SubnetId:
Ref: Subnet01
SecurityGroupIds:
- Ref: SGInstance01
Tags:
- Key: Name
Value: instancia-01-requester
# --- INFRAESTRUCTURA VPC 02 ---
VPC02:
Type: AWS::EC2::VPC
Properties:
CidrBlock: 11.0.0.0/24
EnableDnsSupport: true
EnableDnsHostnames: true
Tags:
- Key: Name
Value: vpc-02-workshop
Subnet02:
Type: AWS::EC2::Subnet
Properties:
VpcId:
Ref: VPC02
CidrBlock: 11.0.0.0/25
AvailabilityZone: !Select [ 0, !GetAZs "" ]
Tags:
- Key: Name
Value: subnet-02-privada
RouteTable02:
Type: AWS::EC2::RouteTable
Properties:
VpcId:
Ref: VPC02
Tags:
- Key: Name
Value: rt-02-privada
SubnetRouteTableAssociation02:
Type: AWS::EC2::SubnetRouteTableAssociation
Properties:
SubnetId:
Ref: Subnet02
RouteTableId:
Ref: RouteTable02
# --- SEGURIDAD VPC 02 ---
SGEIC02:
Type: AWS::EC2::SecurityGroup
Properties:
GroupDescription: "Security Group para EIC Endpoint 02"
VpcId:
Ref: VPC02
Tags:
- Key: Name
Value: sg-eic-02
EIC02Egress:
Type: AWS::EC2::SecurityGroupEgress
Properties:
GroupId:
Ref: SGEIC02
IpProtocol: tcp
FromPort: 22
ToPort: 22
DestinationSecurityGroupId:
Ref: SGInstance02
SGInstance02:
Type: AWS::EC2::SecurityGroup
Properties:
GroupDescription: "Security Group para Instancia 02"
VpcId:
Ref: VPC02
SecurityGroupIngress:
- IpProtocol: tcp
FromPort: 22
ToPort: 22
SourceSecurityGroupId:
Ref: SGEIC02
Tags:
- Key: Name
Value: sg-instance-02
# --- RECURSOS VPC 02 ---
EICEndpoint02:
Type: AWS::EC2::InstanceConnectEndpoint
Properties:
SubnetId:
Ref: Subnet02
SecurityGroupIds:
- Ref: SGEIC02
Tags:
- Key: Name
Value: eic-endpoint-02
Instance02:
Type: AWS::EC2::Instance
Properties:
InstanceType:
Ref: InstanceType
ImageId:
Ref: LatestAmiId
SubnetId:
Ref: Subnet02
SecurityGroupIds:
- Ref: SGInstance02
Tags:
- Key: Name
Value: instancia-02-accepter
Outputs:
Instancia01ID:
Description: "ID de la Instancia 01"
Value:
Ref: Instance01
Instancia02ID:
Description: "ID de la Instancia 02"
Value:
Ref: Instance02
Que despliega exactamente esta plantilla?
Para garantizar un entorno seguro y portátil, el código automatiza la infraestructura base bajo un modelo 100% privado:
2 VPC aisladas: vpc-01-workshop (10.0.0.0/24) y vpc-02-workshop (11.0.0.0/24), configuradas sin salida a internet (sin Internet Gateways ni NAT Gateways).
2 Subredes privadas: subnet-01-privada y subnet-02-privada, segmentadas con máscaras /25 en la primera zona de disponibilidad de la región.
2 Tablas de rutas base: rt-01-privada y rt-02-privada asociadas a sus respectivas subredes, listas para recibir las rutas del peering manualmente.
2 EC2 Instance Connect (EIC) Endpoints: eic-endpoint-01 y eic-endpoint-02. Estos componentes actúan como el puente seguro para conectarnos por SSH desde nuestra terminal sin usar IPs públicas ni llaves .pem.
2 Instancias EC2: instancia-01-requester e instancia-02-accepter con Amazon Linux 2023, ubicadas en el corazón de sus redes privadas.
4 Grupos de Seguridad (Security Groups): Dos para los endpoints (con reglas de salida en el puerto 22) y dos para las instancias, configurados bajo el principio de mínimo privilegio para aceptar conexiones SSH únicamente si provienen de su respectivo EIC Endpoint.
Paso 1: Despliegue de la infraestructura base
Guarda la plantilla anterior en un archivo .yaml y abre CloudFormation en la consola de AWS. Aunque el código funciona en cualquier región, te recomiendo usar N. Virginia (us-east-1) para que tu pantalla coincida exactamente con las imágenes de referencia que verás en cada paso.
Crea el Stack siguiendo estos pasos rápidos:
Haz clic en Create stack (With new resources).
Selecciona Choose an existing template -> Upload a template file y sube tu archivo .yaml.
Asigna un nombre a tu Stack y avanza presionando Next (deja el resto de opciones por defecto).
Haz clic en Submit.
El aprovisionamiento tomará un par de minutos. Una vez que el estado cambie a CREATE_COMPLETE, la automatización habrá terminado y estaremos listos para iniciar la configuración manual de nuestro VPC Peering.
Paso 2: Comprobar el aislamiento (El fallo esperado)
Con nuestro Stack desplegado, el primer paso será conectarnos a nuestra instancia-01-requester ubicada (en la vpc-01-workshop). Lo haremos a través del EIC Endpoint (EC2 Instance Connect) que automatizamos con la plantilla. Esto representa una excelente práctica de seguridad: eliminamos por completo la gestión de llaves de acceso .pem y añadimos una capa de protección adicional, si nunca has manejado los EIC te dejo el enlace al workshop anterior donde explicamos todos los endpoint incluyendo los EIC y ademas usamos cada uno de ellos en un ejemplo: Workshop VPC Endpoints.
- Dirígete al servicio de EC2, selecciona la instancia instancia-01-requester y haz clic en el botón Connect.
En la próxima pantalla notarás algunos mensajes de advertencia como: «No public IPv4 or IPv6 address assigned» e «Instance is not in a public subnet». ¡No te preocupes! Lejos de ser un error, esto es una excelente señal: nos confirma que nuestras subredes y recursos están completamente aislados del mundo exterior.
- En la pestaña de EC2 Instance Connect, cambia el tipo de conexión a Connect using EC2 Instance Connect Endpoint.
- Verás que el sistema seleccionará automáticamente nuestro eic-endpoint-01 en la lista desplegable.
- TPara finalizar, haz clic en el botón Connect.
Una vez dentro de la terminal de la instancia-01-requester, ejecutaremos un comando para intentar comunicarnos con la instancia-02-accepter. (Ve a la consola de EC2 y copia la dirección IP privada de esa segunda instancia, la vas a necesitar).
ping -c 4 <IP_PRIVADA_DE_INSTANCIA_02>
Nota rápida: El comando ping se utiliza para verificar la conectividad básica entre dos recursos. La bandera -c 4 (count) le indica al sistema que envíe exactamente 4 paquetes de prueba hacia la IP de destino.
Ejecuta el comando y observa el resultado:
El diagnóstico es claro: 4 paquetes transmitidos, 0 paquetes recibidos (100% packet loss). El comando se queda congelado y expira.
¿Por qué pasa esto? Porque ambas VPC están en un aislamiento absoluto. En términos de redes, el router de nuestra vpc-01-workshop recibe el paquete con destino a la red 11.0.0.x, revisa su tabla de rutas local y, al no encontrar ninguna instrucción que le diga cómo llegar allá, simplemente descarta el paquete. Para él, esa dirección IP no existe.
Ahora si viene lo bueno...
Paso 3: Creacion de un VPC Peering
A continuación, vamos a construir el puente entre ambas redes para que nuestros servidores dejen de estar aislados.
Dirígete al servicio de VPC en la consola de AWS.
En la columna izquierda, busca y selecciona Peering connections.
Haz clic en el botón Create peering connection.
Colocale un nombre, yo usare: pc-vpc1-to-vpc2
VPC ID (Requester): Selecciona vpc-01-workshop. Esta será la red encargada de iniciar la solicitud de interconexión.
Para este laboratorio, deja seleccionadas las opciones por defecto: My account (Mi cuenta) y This region (Esta región).
En el campo VPC ID (Accepter), selecciona vpc-02-workshop.
- Finaliza haciendo clic en Create peering connection en la parte inferior.
Nota de Arquitecto: En este ejercicio ambas VPC conviven en la misma cuenta y región, pero ten en cuenta que el proceso es idéntico si decidieras interconectar redes en zonas geográficas o estructuras corporativas distintas; en ese caso, simplemente elegirías las opciones Another account o Another region según corresponda.
Ya creamos nuestro peering, pero ¡ATENCIÓN! Falta un paso crucial. Recuerda que al configurar esta conexión establecimos un solicitante (Requester) y un aceptador (Accepter). Esto significa que la solicitud está flotando en el aire y la vpc-02-workshop debe aceptarla formalmente para que el estado pase de Pending acceptance a Active.
En la misma pantalla donde acabas de crear el peering (justo debajo del banner verde de éxito): haz clic en el menú desplegable Actions (en la esquina superior derecha), elige la opción Accept request y confirma.
Nota de Arquitecto: Estamos aceptando la solicitud nosotros mismos porque ambas VPC están en nuestra cuenta de AWS. Si la VPC de destino perteneciera a otra cuenta corporativa o a un cliente externo, el administrador de esa cuenta tendría que iniciar sesión en su propia consola para aceptar tu conexión.
Paso 4: Configuración de Tablas de Rutas (El Mapa de Red)
Ya tenemos nuestro puente construido y activo (VPC Peering), pero si intentas hacer ping nuevamente, notarás que sigue fallando. ¿Por qué? Porque aunque el enlace lógico ya existe, los routers de nuestras VPC todavía no saben que deben usarlo. Nos falta configurar las instrucciones de navegación: las Tablas de Rutas.
Comenzaremos configurando el camino de ida. Vamos a dirigirnos al servicio VPC, tabla de rutas y seleccionamos la asociada a nuestra subred origen (rt-01-privada) para especificarle que cuando un recurso intente comunicarse con el bloque CIDR 11.0.0.0/24 (la red de la VPC-02), redirija ese tráfico utilizando nuestra Peering Connection (pc-vpc1-to-vpc2).
- Selecciona la tabla de rutas rt-01-privada y dirígete a la pestaña Routes en la parte inferior.
Nota de observación: Verás que de momento solo existe una ruta con el destino (Target) configurado como local. Esta regla por defecto le indica a la VPC que cualquier tráfico dirigido al bloque CIDR 10.0.0.0/24 debe quedarse dentro de su propia red local.
Haz clic en el botón Edit routes (esquina superior derecha de la pestaña).
En el editor de rutas, haz clic en Add route y configura los siguientes campos:
- - Destination: Coloca el bloque CIDR completo de la VPC-02 (11.0.0.0/24). Con esto le indicas al router el "rango de red de destino". Le estás diciendo: «Cualquier paquete que intente ir a cualquier recurso dentro de la VPC-02, debe aplicar esta regla». (Ojo: no colocamos la IP de la instancia individual, sino el rango de toda la red vecina).
Target: Selecciona Peering Connection en la lista desplegable. Al hacer clic en el cuadro de búsqueda vacío, el sistema te mostrará automáticamente el ID de nuestro peering pc-vpc1-to-vpc2
Por último, haz clic en Save changes (Guardar cambios) para fijar el mapa de ida.
El "muro" del laboratorio
Ok, tenemos el peering activo y nuestra ruta definida. Si volvemos a la terminal e intentamos ejecutar el comando nuevamente:
ping -c 4 IP_PRIVADA_DE_INSTANCIA_02
¿Qué sucede? Sí, nos topamos exactamente con el mismo mensaje: 4 packets transmitted, 0 received, 100% packet loss, time 3153ms.
Este es el típico escenario de redes que suele frustrar a la mayoría y hacerlos dudar de su configuración. ¡Pero hoy no será nuestro caso! Si nuestra conexión de peering está OK y la tabla de rutas de origen está OK, ¿qué otro elemento nos está bloqueando? Debemos revisar al guardián que protege directamente al recurso: el Security Group de la instancia-02-accepter.
- Selecciona la pestaña Inbound rules (Reglas de entrada). Notarás que este grupo de seguridad fue creado por nuestra plantilla de CloudFormation con una única regla: permitir tráfico SSH en el puerto 22 exclusivamente desde el EIC Endpoint. Por eso podemos conectarnos sin problemas, pero cualquier otro tipo de acceso está denegado por defecto.
Para que nuestra instancia de destino acepte y responda a las solicitudes de eco (Echo Requests) que le envía el comando ping, necesitamos habilitar el protocolo ICMP (Internet Control Message Protocol). A diferencia de los servicios web comunes, este tráfico no utiliza puertos TCP o UDP, sino que opera directamente a nivel de red para enviar mensajes de diagnóstico. Como los Security Groups bloquean todo el tráfico entrante por defecto, debemos añadir una regla explícita para permitirlo. ¡Vamos a hacerlo!.
Haz clic en Edit inbound rules y luego en el botón Add rule.
Configura los siguientes campos en la nueva fila:
Type: Selecciona All ICMP - IPv4.
Source: Déjalo en Custom y en el cuadro de texto ingresa el bloque CIDR de la VPC-01 (10.0.0.0/24).
Haz clic en Save rules.
Source Custom: Agregamos el CIDR de la vpc-01 que es donde habita la instancia instancia-01-requester desde donde estamos ejecutado el comando ping y queremos que pueda comunicarse y ademas recibir respuesta de la instancia instancia-02-accepter a la que protege este grupo de seguridad.
¿Qué acabamos de hacer? Le indicamos al grupo de seguridad de la instancia-02-accepter que permita la entrada de paquetes de diagnóstico (ping), siempre y cuando provengan de algún recurso ubicado dentro de la red de la VPC-01.
El segundo ping
Con el grupo de seguridad con las reglas correctas, estamos listos para volver a ejecutar nuestro comando en la terminal:
ping -c 4 IP_PRIVADA_DE_INSTANCIA_02
Y el resultado es... ¡otra vez lo mismo!: 4 packets transmitted, 0 received, 100% packet loss, time 3100ms.
Te debes estar preguntando: «A ver, el peering está activo, la ruta de ida está lista y el Security Group ya permite el ping... ¿Qué rayos sucede? Javier, ¿acaso quieres estresarme?»
La realidad es que no, pero en la arquitectura de redes la mejor manera de aprender es fallando, entendiendo el porqué de las cosas y corrigiendo. Lo que estamos experimentando aquí es un concepto vital: el enrutamiento en AWS no es bidireccional por defecto.
Para que un ping sea exitoso, el paquete necesita un camino de ida y un camino de vuelta. Analicemos qué está pasando en este instante tras bambalinas:
El viaje de ida: El paquete sale de la instancia-01, el router de la VPC-01 ve la ruta hacia el peering, el puente cruza con éxito, llega a la VPC-02, el Security Group valida que es un paquete ICMP permitido y se lo entrega a la instancia-02. ¡La ida funciona perfecto!
El viaje de vuelta: La instancia-02 recibe el paquete y, como es educada, genera una respuesta (Echo Reply) con destino a la IP de la VPC-01.
El problema: Cuando este paquete de regreso llega al router de la VPC-02, este revisa su propia tabla de rutas. Como no hemos tocado la tabla de rutas de la VPC-02, el router solo ve su regla local (11.0.0.0/24). Al no tener una instrucción explícita que le diga cómo regresar a la red 10.0.0.0/24, el router no sabe qué hacer y tira la respuesta a la basura.
En resumen: la instancia-02 sí recibe el mensaje, pero sus respuestas se quedan atrapadas en su propia red. La instancia-01 se queda esperando eternamente un eco que jamás va a volver.
Configurando el camino de regreso
¿Qué debemos hacer entonces para solucionar el problema del paquete atrapado? Exacto: ir a la tabla de rutas rt-02-privada (asociada a la VPC-02) y repetir el mismo procedimiento que hicimos al principio. Esta vez, agregaremos una regla que especifique que todo el tráfico dirigido a la red de la VPC-01 (10.0.0.0/24) debe salir a través de nuestra Peering Connection.
Guarda los cambios y, ahora sí, regresemos a la terminal de nuestra primera instancia para lanzar el comando de nuevo:
ping -c 4 IP_PRIVADA_DE_INSTANCIA_02
¡Victoria! Respuesta totalmente satisfactoria: 4 packets transmitted, 4 received, 0% packet loss, time 3126ms. Oficialmente, este es el momento de poner a sonar de fondo We Are the Champions de Queen. ¡Ja, ja!
Probando la bidireccionalidad
Al configurar las rutas en ambos sentidos, el puente de red ha quedado completamente establecido de forma bidireccional, sin importar qué recurso inicie la comunicación. Esto significa que si nos conectamos a la instancia-02-accepter en la VPC-02, podríamos hacerle un ping de vuelta a la instancia-01-requester en la VPC-01.
Eso sí... espero que te hayas acordado del detalle vital que acabamos de aprender con los grupos de seguridad (firewall). Para que la instancia-01 pueda procesar esa solicitud, su propio Security Group debe permitirlo.
Dirígete al grupo de seguridad sg-instance-01 (el que protege a la instancia en la VPC-01) y añade la regla correspondiente en las Inbound rules:
Type: All ICMP - IPv4
Source: El CIDR de la VPC-02 (11.0.0.0/24)
Ahora, conéctate a la instancia de la VPC-02 (usando su pestaña de EC2 Instance Connect como hicimos en el Paso 1) y ejecuta el ping apuntando al origen:
ping -c 4 IP_PRIVADA_DE_INSTANCIA_01
¡Resultados impecables! 4 packets transmitted, 4 received, 0% packet loss, time 3114ms.
¡Lo hemos logrado! Conseguimos establecer una comunicación fluida, privada y segura entre recursos que habitan en redes totalmente aisladas gracias a VPC Peering y a una correcta gestión de enrutamiento y seguridad.
Cuándo usar (y cuándo evitar) un VPC Peering?
El VPC Peering es la herramienta ideal cuando necesitas una conexión directa, UNO a UNO, entre dos redes. Sin embargo, hay una regla de oro a nivel de infraestructura que es imprescindible recordar: las conexiones de Peering NO son transitivas.
¿Qué significa esto en la práctica? Imagina el siguiente escenario:
Tienes un Peering que conecta la VPC-A con la VPC-B.
Tienes otro Peering que conecta la VPC-B con la VPC-C.
Es muy común que los principiantes supongan que, como la VPC-B está en el medio, la red A podría comunicarse con la C utilizándola como puente. Pero en AWS esto no es posible. Debido a que el ruteo no es transitivo, para que la VPC-A y la VPC-C se puedan hablar, tendrías que crear obligatoriamente un tercer Peering directo entre ellas.
El problema de la escala:
Por esta misma naturaleza, el VPC Peering se recomienda únicamente cuando manejas un número pequeño de redes. Si tu infraestructura crece y necesitas interconectar 10, 20 o 50 VPCs entre sí, configurar conexiones "uno a uno" creará una telaraña inmanejable de enlaces y tablas de rutas, convirtiéndose en una pesadilla de administración.
Nota de Arquitecto: Cuando te enfrentes a un escenario donde necesitas interconectar muchas redes a gran escala, la solución ya no es el VPC Peering; en ese caso, debes dar el salto a un servicio de enrutamiento centralizado como AWS Transit Gateway que aprovecho para haceres spoiler, sera nuestro proximo workshop.
Paso Final: Eliminación de recursos (¡No olvides este paso!)
Después de que interactúes y pruebes todo lo que acabamos de construir, es fundamental eliminar los recursos para evitar costos innecesarios en tu cuenta de AWS. Sigue este orden específico para garantizar una limpieza exitosa:
VPC Peering: Dirígete al servicio de VPC, selecciona Peering connections en la columna izquierda, busca el peering que creamos (pcx-vpc01-to-vpc02), selecciónalo y haz clic en Delete.
CloudFormation Stack: Una vez borrado el peering, ve al servicio de CloudFormation, selecciona el Stack que desplegamos al inicio y haz clic en Delete. AWS se encargará de borrar las instancias, VPCs, tablas de rutas y Security Groups automáticamente.
¡Con esto habremos terminado! Espero sinceramente que hayas aprendido algo nuevo el día de hoy sobre enrutamiento y seguridad en nubes privadas virtuales.
Si tienes alguna opinión, feedback o duda, no olvides dejarla en la sección de comentarios. Además, te invito a compartir este contenido técnico; ¡podría ser de gran ayuda para otras personas en su camino de aprendizaje!
Nos vemos en el próximo workshop, donde abordaremos el siguiente nivel: AWS Transit Gateway.