Creación de un punto único de salida a internet para múltiples VPC usando AWS Transit Gateway

por Vinod Madabushi y Perry Wald

En este articulo, mostraremos cómo centralizar el tráfico saliente hacía internet desde varias VPC sin comprometer el aislamiento de estas. Utilizando AWS Transit Gateway, podemos configurar una única VPC utilizando varios NAT Gateway, y así consolidar el tráfico saliente desde multiples VPC. Al mismo tiempo, podremos utilizar múltiples tablas de rutas dentro de Transit Gateway, para mantener el aislamiento entre las VPCs. Este diseño hub-and-spoke permite administrar todas las comunicaciones salientes hacía Internet de forma segura desde un punto único.

Sin usar AWS Transit Gateway, tendría que combinar el uso de Internet Gateways con NAT Gateway o instancias de tipo NAT para cada una de las VPC que necesite acceso de salida a Internet. Sin embargo, si tiene un número elevado de VPC, la administración de múltiples Internet Gateways y de instancias o gateways NAT agrega trabajo y costes innecesarios. En ese caso, puede ahorrar gastos gestionando el tráfico saliente con AWS Transit Gateway.

Este diseño permite una arquitectura centralizada con un par de NAT gateways compartidos, pero es posible modificar su arquitectura para reemplazar los NAT gateways con otros dispositivos de seguridad para llevar a cabo tareas como captura de tráfico, cumplimiento de las políticas, filtrado web, etc., siempre y cuando esos dispositivos sean capaces de realizar NAT y tengan las configuraciones de routing requeridos.

Información general de la solución

La siguiente arquitectura muestra cómo usar AWS Transit Gateway para centralizar el tráfico de Internet saliente desde múltiples VPC, con un diseño de tipo hub-and-spoke. El diseño se basa en el uso de dos NAT gateway, tal como se muestra en el siguiente diagrama.

Figura 1: Diagrama de arquitectura que muestra como utilizar AWS Transit Gateway para centralizar el tráfico de salida a Internet desde múltiples VPC.

Requisitos previos

Para completar este tutorial necesita:

• Una cuenta de AWS
• Un usuario de IAM con acceso a recursos de AWS, incluido AWS Transit Gateway

Implementación del ejemplo

En esta sección, mostramos cómo implementar AWS Transit Gateway y tres VPC utilizando bloques de direcciones IP que no se superponen en una única región y como conectar AWS Transit Gateway a estas VPC. Dentro del hub de VPC, mostramos como implementar los NAT Gateway (uno en cada zona de disponibilidad), y un Internet Gateway. Finalmente, mostraremos como configurar las tablas de rutas en cada VPC y utilizaremos una instancia de prueba en la VPC spoke para verificar la conectividad saliente hacía Internet.

Si prefieres utilizar una automatización de toda la configuración, puede seguir las instrucciones aquí para implementar todos los componentes. Esto automatiza las siguientes tres partes de la implementación, lo que le permitirá continuar desde la sección de “Prueba de la implementación” directamente. Asegúrese de elegir la región deseada para este Stack antes de desplegar los componentes.

Creación y configuración de las VPC

Primero, mostramos como implementar los componentes principales de este diseño, incluido las VPC, subredes, Internet Gateway, NAT Gateway y las tablas de rutas. Las siguientes instrucciones implementan este ejemplo en la región Norte de Virginia (us-east-1). Sin embargo, puede implementar este procedimiento en cualquier región ajustando la región y los parámetros para las AZ.

1. Crear las siguientes tres VPC: Egress-VPC, App1-VPC y App2-VPC. Proporcione valores para cada una como se muestra en la siguiente tabla. Para obtener más información, consulte la Introducción a Amazon VPC.

2. Cree las subredes en cada una de las VPC como se decribe en la siguiente tabla. Para más información, consulte Cómo crear una subred. En los siguientes pasos, configurará las tablas de rutas para hacer que algunas de las subredes sean públicas.

3. Cree y asocie (attach) un Internet Gateway (IGW) a la VPC Egress-VPC. Use IGW como nombre de etiqueta para este Internet Gateway. Para más información, consulte Cómo crear y asociar un Internet Gateway.

4. Cree un NAT Gateway en la VPC Egress-VPC. Para obtener más información, consulte NAT Gateway. Cree solo un NAT Gateway para este ejemplo. En su entorno de producción, debe crear una gateway NAT por cada zona de disponibilidad en la que tenga una subred y usar los NAT Gateway para cada zona de disponibilidad.

• Para la subred, elija Egress-Public-AZ1.
• Para la ID de asignación de IP elástica, seleccione Crear una nueva EIP.

5. En el apartado Route Tables, cree dos tablas de rutas nuevas asociadas a la VPC Egress-VPC. Como nombres de etiquetas, utilice Egress-Public-RT y Egress-Private-RT.

6. Agregue una nueva ruta predeterminada en la tabla de ruta Egress-Public-RT con el destino configurado a 0.0.0.0/0. Asocie la ruta con el Internet Gateway llamado IGW. Para obtener más información, consulte Asociación y eliminación rutas desde una tabla de ruta. Luego edite la asociación de subred (en el menu Actions, elija Edit subnet Associations) y agregue tanto las subredes Egress-Public-AZ1 y Egress-Public-AZ2 a esta tabla de ruta.

7. Agregue una nueva ruta predeterminada en la tabla de ruta Egress-Private-RT con el destino configurado a 0.0.0.0/0. Asocie la ruta con el NAT Gateway. Luego edite la asociación de subred y agregue tanto las subredes Egress-Private-AZ1 y Egress-Private-AZ2 a esta tabla de ruta.

Desplegar y configurar AWS Transit Gateway

A continuación, mostraremos como desplegar el nuevo Transit Gateway y asociarlo a las tres VPC, y dirigir el tráfico a Internet a través del NAT Gateway. Primero conectaremos Transit Gateway a las tres VPC:

1. En la consola de VPC, elija Transit Gateway y cree uno nuevo. Use el nombre TGW-Internet, agregue una descripción adecuada y asegúrese de desmarcar la opción de propagar la tabla de rutas por defecto (Default route table propagation) y la asociación de tabla de ruta por defecto (Default route table association)).

2. Elija Asociaciones de Transit Gateway (Transit Gateway Attachments en la consola) y cree las asociaciones que se describen en la siguiente tabla.

3. Seleccione Transit Gateway Route Tables y cree dos tablas de rutas. Nombre las tablas de rutas como Egress-RouteTable y App-RouteTable, y asocie ambas tablas de ruta con el Transit Gateway llamado TGW-Internet.

4. Dentro de la misma opción de Transit Gateway Route Tables, elija la App-RouteTable, asociacions (Associations), Crear asociación (Create association). Asocie tanto App1-Attachment como App2-Attachment a esta tabla de rutas.

5. En la misma tabla de ruta, elija rutas, Crear ruta, ingrese la ruta 0.0.0.0/0 y elija la asociación: Egress-Attachment.

6. Agregue estas rutas adicionales: 192.168.0.0/16, 172.16.0.0/12 y 10.0.0.0/8 como agujero negro para asegurarse de que las VPC no se puedan comunicar entre sí a través del NAT Gateway.

7. Bajo las tablas de ruta AWS Transit Gateway, elija la Egress-RouteTable, Asociaciones, Crear asociación. Asocie Egress-Attachment a esta tabla de ruta.

8. En la misma tabla de ruta, elija Rutas, Crear ruta e ingrese 10.0.0.0/16 con la asociación (attachment) App1-Attachment. Luego, ingrese una segunda ruta para 10.1.0.0/16 con la asociación (attachment) App2-Attachment.

9. En el panel de navegación izquierdo, elija las Tablas de ruta (Route Tables) y edite la tabla de ruta predeterminada asociada con App1-VPC y App2-VPC, y agregue la ruta 0.0.0.0/0 y configure TGW-Internet como destino.

10. Edite las tablas de ruta Egress-Public-RT asociadas con Egress-VPC y agregue 10.0.0.0/16 y 10.1.0.0/16. Configure TGW-Internet como el destino.

Lanzar las instancias de prueba

Para probar esta configuración, lance tres instancias EC2. Lance la primera en una subred pública en Egress-VPC que actuará como bastión. Lance las dos instancias restantes en las VPCs App1-VPC y App2-VPC. Para obtener más información, consulte Lanzar una instancia.

1. Lance una instancia EC2 en Egress-VPC con la siguiente configuración:

AMI: AMAZON Linux 2 AMI (HVM)
Tipo de instancia: t2.large
Red: Egress-VPC
Subred: Egress-Public-AZ1
Asignación automática de IP pública: Habilitado
Etiquetas: Agregue una etiqueta con clave: Name y valor: Bastión
Grupo de seguridad: Cree un nuevo grupo de seguridad para permitir el tráfico SSH desde su dirección de IP Pública (puede encontrar su dirección de IP actual en www.myipaddress.com)

2. Lance dos instancias EC2, una en App1-VPC y la otra en App2-VPC con la siguiente configuración:

AMI: AMAZON Linux 2 AMI (HVM)
Tipo de instancia: t2.large
Red: App1-VPC
Subred: App1-Private-AZ1
Asignación automática de IP pública: Deshabilitado
Etiquetas: Agregue una etiqueta con clave: Name y valor: App1VM
Grupo de seguridad de entrada: Cree un nuevo grupo de seguridad para permitir el tráfico SSH y todos los ICMP – IPV4 desde 10.0.0.0/16, 10.1.0.0/16 y 192.168.0.0/16.

AMI: AMAZON Linux 2 AMI (HVM)
Tipo de instancia: t2.large
Red: App2-VPC
Subred: App2-Private-AZ1
Asignación automática de IP pública: Deshabilitado
Etiquetas: Agregue una etiqueta con clave: Name y valor: App2VM
Grupo de seguridad de entrada: Cree un nuevo grupo de seguridad para permitir el tráfico SSH y todos los ICMP – IPV4 desde 10.0.0.0/16, 10.1.0.0/16 y 192.168.0.0/16.

Prueba de la implementación

Inicie sesión en la instancia bastión vía SSH. Desde esta instancia utilice SSH para conectarse a App1VM. Para verificar que las rutas de tráfico configuradas en AWS Transit Gateway funcionan correctamente y le enrutan vía NAT Gateway en la VPC de Egress, utilice el comando CURL para conectarse a varios sitios webs. Luego use SSH para conectar desde App1VM a App2VM. A pesar de estar permitida por el grupo de políticas de seguridad, esta conectividad debería fallar debido a los agujeros negros configurados en las rutas. Este error confirma que AWS Transit Gateway no está enrutando entre las instancias App1-VPC y App2-VPC. El siguiente diagrama demuestra el flujo de red para las pruebas que acaba de realizar.

Figura 2: El diagrama muestra la arquitectura de salida a Internet vía Transit Gateway

1. En la consola EC2, identifique la dirección de IP Pública o los nombres de DNS públicos de la máquina bastión que ha lanzado en el paso previo.

2. Use SSH para conectar a la máquina bastión:

ssh -i (ruta hacia clave) ec2-user@(IP Pública de la máquina bastión)

3. Copie la clave de SSH para esta región a la máquina bastión para iniciar sesión en App1VM:

vi sshkey.pem
Presiones i para poner vi en modo insertar.
Copie la clave privada que ha descargado anteriormente y pégue esto en vi.
Presione escape
Escriba :wq para guardar y salir.

4. Use SSH para conectar a la instancia App1VM desde la máquina bastión:

ssh -i ./sshkey.pem ec2-user@(IP Privada de la instancia App1VM)

5. Pruebe los filtros implementados para acceder a una URL mediante CURL para las siguientes:

curl http://www.amazon.com
curl http://calculator.s3.amazonaws.com/index.html

6. Use SSH/ping para llegar a la dirección de IP de App2VM desde App1VM y verifique que la conectividad falla (como es esperado):

ping (IP Privada de App2VM)
ssh (IP Privada de App2VM)

7. De forma alternativa, puede verificar que la conectividad falle con el siguiente comando SSH:

ssh ec2-user(IP Privada de App2VM)

Costes de la solución

En la mayoría de los casos, un NAT Gateway centralizado proporciona un mejor retorno en su inversión que múltiples puntos de salida. Incluso si consideramos el coste de NAT Gateway y el coste de transferencia por GB de datos, el proceso debería reducir sus cargos por hora utilizando múltiples NAT Gateways en un único punto de salida y simplificar la administración de la solución.

Si ya utiliza NAT Gateways, la cantidad de datos procesador por NAT Gateway permanece constante, tanto si es canalizada a través de un NAT Gateway único o de múltiples NAT Gateways.

Los siguientes elementos afectan el coste de esta solución:

• Cada asociación de Transit Gateway (por hora)
• Procesamiento de datos de Transit Gateway (por GB)
• NAT Gateway (por hora)
• Procesamiento de datos por NAT Gateway (por GB)

Consulte nuestra página de precios de AWS Transit Gateway y página de precios de NAT Gateway NAT para obtener más información.

Consideraciones de diseño

Este diseño no cubre todos los casos de uso exsitentes. Por lo que, los costes y el desempeño podrían hacer que esta solución no sea la adecuada para algunos casos de uso.

Coste

Como hemos discutido anteriormente, hay un cargo de transferencia de datos adicional de 0,02 USD por GB en comparación con la ejecución de NAT Gateway de manera local en la misma VPC. Podría preferir implementar un NAT Gateway local en función del número de VPC que ejecute y el volumen de datos transferidos puede ser más eficiente en coste.

Desempeño

Cuando implemente esta solución, considere además el rendimiento. A partir de esta publicación, un NAT Gateway único admite 10 Gbps de ancho de banda y crece automáticamente hasta los 45 Gbps. Si implementa dos NAT Gateways (uno en cada zona de disponibilidad) en un entorno de producción, su ancho de banda será muy superior que con un único NAT Gateway. Si los requisitos de ancho de banda totales exceden la capacidad de los dos NAT Gateways, considere conectar su VPC con requisitos de alto rendimiento al NAT Gateway local.

Un NAT Gateway admite hasta 55.000 conexiones simultáneas, (o aproximadamente 900 conexiones por segundo/55.000 conexiones por minuto) por cada destino único. Si necesita más capacidad que esta, considere crear múltiples NAT Gateways y distribuir así la carga.

Antes de concluir, debemos también remarcar otros dos elementos de diseño cruciales:

Las ruta hacia agujeros negros

Mientras configuraba su Transit Gateway, hemos configurado todos los espacios IP RFC 1918 (192.168.0.0/16, 172.16.0.0/12 y 10.0.0.0/8) como destinos hacia un agujero negro (Black Hole) en la tabla de rutas de las aplicaciones. Como publicitamos la ruta 0.0.0.0/0 para cada VPC de aplicación, el tráfico destinado a otra VPC es enviado al NAT Gateway, el cual vuelve a enrutar el tráfico a la VPC de destino. Como resultado, las comunicaciones entre las VPC son exitosas incluso si AWS Transit Gateway no enruta el tráfico directamente. Agregar las rutas hacia agujeros negros previene enrutamientos no deseados y se asegura que las VPC permanezcan aisladas unas de otras.

Inspecciones de seguridad

El diseño presentado en esta publicación permite centralizar el tráfico saliente a través de una VPC central con dos NAT Gateways compartidos. También puede usar este diseño para reemplazar el NAT Gateway con otros dispositivos de seguridad que ayudan a inspeccionar el tráfico saliente, por ejemplo, llevar a cabo inspecciones de seguridad profundad, captura de tráfico, cumplimiento de las políticas y filtrado web.

Sin embargo, usted es responsable en última instancia de diseñar la alta disponibilidad y escalabilidad en estos dispositivos. AWS usa una arquitectura distribuida para mantener la tolerancia a fallos y la escalabilidad de cada NAT Gateway. Si reemplaza los NAT Gateway con instancias Amazon EC2, sus diseños se enrutan a solo una instancia por prefijo y no realizan comprobaciones de salud para rutas estáticas. Asegúrese de que cualquier dispositivo de seguridad que utilice para reemplazar la función NAT Gateway tenga las configuraciones de rutas requeridas.

Conclusión

En esta publicación, mostramos cómo usar AWS Transit Gateway para construir un punto de salida hacia Internet centralizado. Cuando consolida su tráfico saliente, puede administrar las comunicaciones salientes y su seguridad, escalabilidad y configuración en un único lugar. Si ejecuta un número elevado de VPC, creemos que esta centralización puede ahorrarle trabajo, dinero y estrés. Sin embargo, mientras este diseño reduce el número de NAT Gateways y de Internet Gateways que administra, tenga en cuenta que también requiere que implemente y administre un Transit Gateway a escala.

Por último, solo hemos mostrado su tráfico saliente a través de un NAT Gateway hacia Internet. Puede expandir en este diseño y reemplazar los NAT Gateways con dispositivos de terceros que pueden realizar prestaciones adicionales de filtrado como el filtrado de URL, la detección de malware y el protocolo de inspección de paquetes salientes.

Si tiene alguna pregunta o comentarios, escríbanos.