Salida centralizada a Internet - Creación de una infraestructura de red de AWS de varias VPC escalable y segura

Salida centralizada a Internet

A medida que implemente aplicaciones en su zona de aterrizaje, muchas aplicaciones requerirán acceso a Internet solo saliente (por ejemplo, al descargar bibliotecas/parches/actualizaciones del sistema operativo). Puede lograr esto preferentemente mediante el uso de una puerta de enlace de traducción de direcciones de red (NAT) o, alternativamente, una instancia de EC2 (configurada con NAT de origen (SNAT)) como salto siguiente para todos los accesos a Internet de salida. Las aplicaciones internas residen en subredes privadas, mientras que las instancias NAT Gateway/EC2 NAT residen en una subred pública.

Utilización de la puerta de enlace de NAT

La implementación de una puerta de enlace de NAT en cada VPC radial puede resultar costosa porque paga un cargo por hora por cada puerta de enlace de NAT que implemente (consulte los precios de Amazon VPC), por lo que centralizarla podría ser una opción viable. Para centralizar, creamos una VPC de salida en la cuenta de servicios de red y dirigimos todo el tráfico de salida de las VPC radiales a través de una puerta de enlace de NAT ubicada en esta VPC que aprovecha Transit Gateway, como se muestra en la figura 10.

Nota: Cuando se centraliza NAT Gateway con Transit Gateway, se paga un cargo adicional por procesamiento de datos de Transit Gateway, en comparación con el enfoque descentralizado de ejecutar una puerta de enlace de NAT en cada VPC. En algunos casos periféricos, cuando se envían grandes cantidades de datos a través de NAT Gateway desde una VPC, mantener la NAT local en la VPC para evitar el cargo de procesamiento de datos de Transit Gateway puede ser una opción más rentable.

Figura 10: Puerta de enlace de NAT centralizada mediante Transit Gateway (descripción general

Figura 11: Puerta de enlace de NAT centralizada mediante Transit Gateway (diseño de tabla de enrutamiento)

En esta configuración, las vinculaciones de VPC radiales se asocian a la tabla de enrutamiento 1 (RT1) y se propagan a la tabla de enrutamiento 2 (RT2). Hemos agregado explícitamente una ruta Blackhole para impedir que las dos VPC se comuniquen entre sí. Si desea permitir la comunicación entre VPC, puede eliminar la entrada de ruta “10.0.0.0/8 -> Blackhole” del RT1. Esto les permite comunicarse a través de la puerta de enlace de NAT. También puede propagar las vinculaciones de VPC radiales a RT1 (o, alternativamente, puede usar una tabla de enrutamiento y asociar/propagar todo a ella), lo que permite el flujo de tráfico directo entre las VPC mediante Transit Gateway.

Añadimos una ruta estática en RT1 que apunta todo el tráfico a la VPC de salida. Debido a esta ruta estática, Transit Gateway envía todo el tráfico de Internet a través de sus ENI en la VPC de salida. Una vez en la VPC de salida, el tráfico sigue las reglas definidas en la tabla de enrutamiento de subred en la que están presentes estos ENI de Transit Gateway. Agregamos una ruta en esta tabla de enrutamiento de subred que apunta todo el tráfico hacia la puerta de enlace de NAT. La tabla de enrutamiento de subred de puerta de enlace de NAT tiene la puerta de enlace de Internet (IGW) como salto siguiente. Para que el tráfico de retorno fluya hacia atrás, debe agregar una entrada de tabla de enrutamiento estática en la tabla de enrutamiento de subred de la puerta de enlace de NAT que señale todo el tráfico vinculado a la VPC radial a Transit Gateway como siguiente salto.

Alta disponibilidad

Para una alta disponibilidad, debe usar dos puertas de enlace de NAT (una en cada zona de disponibilidad). Dentro de una zona de disponibilidad, la puerta de enlace de NAT tiene un SLA de disponibilidad del 99,9 %. AWS gestiona la redundancia contra fallos de componentes dentro de una zona de disponibilidad en virtud del acuerdo de SLA. El tráfico se interrumpe durante el 0,1 % cuando la puerta de enlace de NAT no pueda estar disponible en una zona de disponibilidad. Si una zona de disponibilidad falla por completo, el punto de conexión de Transit Gateway junto con la puerta de enlace de NAT en esa zona de disponibilidad fallarán y todo el tráfico fluirá a través de los extremos de conexión de la puerta de enlace de NAT y Transit Gateway en la otra zona de disponibilidad.

Seguridad

Se confía en los grupos de seguridad de las instancias de origen, las rutas de agujeros negros en las tablas de enrutamiento de Transit Gateway y la ACL de red de la subred en la que se encuentra la puerta de enlace de NAT.

Escalabilidad

Una puerta de enlace NAT puede admitir hasta 55.000 conexiones simultáneas a cada destino único. Desde el punto de vista del rendimiento, está limitado por los límites de rendimiento de la puerta de enlace de NAT . Transit Gateway no es un equilibrador de carga y no distribuirá el tráfico de manera uniforme entre la puerta de enlace de NAT en las distintas zonas de disponibilidad. Si es posible, el tráfico a través de Transit Gateway permanecerá dentro de una zona de disponibilidad. Si el tráfico de inicio de la instancia de EC2 se encuentra en AZ 1, el tráfico saldrá de la interfaz de red elástica de Transit Gateway en la misma AZ 1 en la VPC de salida y fluirá al siguiente salto en función de la tabla de enrutamiento de subred en la que reside la interfaz de red elástica. Para obtener una lista completa de reglas, consulte Reglas y límites de la puerta de enlace de NAT.

Para obtener más información, consulte la publicación del blog Creating a single internet exit point from multiple VPCs Using AWS Transit Gateway.

Uso de una instancia de EC2 para la salida centralizada

El uso de un dispositivo de firewall basado en software (en EC2)AWS Marketplace como punto de salida es similar a la configuración de la puerta de enlace de NAT. Esta opción se puede utilizar si desea aprovechar las capacidades de firewall de capa 7, prevención de intrusiones y sistemas de detección (IPS/IDS) de las distintas ofertas de proveedores.

En la figura 12, sustituimos la puerta de enlace de NAT por una instancia de EC2 (con SNAT habilitada en la instancia de EC2). Hay algunas consideraciones clave con esta opción:

Alta disponibilidad

En esta configuración, es responsable de supervisar la instancia de EC2, detectar errores y reemplazar la instancia de EC2 por una instancia de copia de seguridad/en espera. La mayoría de los proveedores de AWS tienen automatización prediseñada para su software implementado en esta configuración. Esa automatización puede controlar lo siguiente:

  • Detectar errores en la instancia de EC2-1 principal 

  • Cambie la tabla de enrutamiento “Route Table Egx 1” para que apunte todo el tráfico a la instancia de EC2-2 de seguridad en caso de que falle la instancia principal. Esto también se debe hacer para las subredes de la AZ 2.

Figura 12: NAT centralizada mediante instancias de EC2 y Transit Gateway

Escalabilidad

Transit Gateway no es un equilibrador de carga y no distribuirá el tráfico de manera uniforme entre las instancias de las dos zonas de disponibilidad. Si es posible, el tráfico a través de Transit Gateway permanecerá dentro de una zona de disponibilidad. Está limitado por las capacidades de ancho de banda de una sola instancia de EC2. Puede escalar verticalmente esta instancia de EC2 a medida que aumenta el uso.

Si el proveedor que elija para la inspección del tráfico de salida no admite la automatización para la detección de errores, o si necesita un escalado horizontal, puede usar un diseño alternativo. En este diseño (Figura 13), no creamos una vinculación de VPC en la puerta de enlace de tránsito para la VPC de salida, sino que creamos una conexión de VPN de IPSec y creamos una VPN de IPSec desde Transit Gateway a las instancias de EC2 que aprovechan BGP para intercambiar rutas.

Ventajas

  • Detección de errores y reenrutamiento del tráfico gestionado por BGP. No se requiere la automatización de tablas de enrutamiento de subredes de VPC.

  • El ECMP de BGP se puede utilizar para equilibrar la carga del tráfico en varias instancias de EC2; es posible el escalado horizontal.

Figura 13: NAT centralizada mediante instancias de EC2 y VPN de Transit Gateway

Consideraciones clave

  • Sobrecarga de administración de VPN en instancias de EC2

  • El ancho de banda en Transit Gateway está limitado a 1,25 Gbps por túnel de VPN. Con ECMP Transit Gateway puede admitir un ancho de banda de VPN total de hasta 50 Gbps. Las capacidades de procesamiento de paquetes y VPN del dispositivo del proveedor pueden ser un factor limitante.

  • Este diseño supone que la instancia de EC2 de FW funciona con la misma interfaz de red elástica para el tráfico entrante y saliente.

  • Si habilita el balanceador de carga de ECMP del tráfico en varias instancias de EC2, debe convertir con SNAT el tráfico en la instancia de EC2 para garantizar la simetría del flujo de retorno, lo que significa que el destino no conocerá el verdadero origen.