Entendiendo Amazon VPC Regional NAT Gateway

Descripción general

El Regional NAT Gateway opera a nivel de VPC en lugar de por AZ. Creas un único NAT Gateway, referencias un solo ID en tus tablas de rutas de todas las AZ, y AWS gestiona automáticamente la expansión, la asignación de IP y la alta disponibilidad. No se necesitan subredes públicas: el RNAT es un recurso independiente con su propia tabla de rutas.

Esto simplifica las arquitecturas de salida centralizada, pasando de gestionar N NAT Gateways (uno por AZ) + N subredes públicas + N tablas de rutas a un solo RNAT + una entrada de ruta.

Cómo funciona el Regional NAT Gateway

Cuando lanzas recursos en una nueva Zona de Disponibilidad, el Regional NAT Gateway detecta la presencia de una interfaz de red (ENI) en esa AZ y se expande automáticamente a esa zona. De igual forma, se contrae desde las AZ que no tienen cargas de trabajo activas. Esta expansión y contracción mantiene la afinidad zonal: el tráfico de la AZ1 es procesado por la instancia NAT en la AZ1, y el tráfico de la AZ2 por la instancia en la AZ2.

Puede tardar hasta 60 minutos en expandirse a una nueva AZ después de que se instancie un recurso allí. Hasta que se complete la expansión, el tráfico de esa AZ es procesado de forma cruzada (cross-zone) por el Regional NAT Gateway en una de las Zonas de Disponibilidad existentes.

El Regional NAT Gateway admite dos modos:

• Modo automático (recomendado): AWS gestiona las direcciones IP y la expansión entre AZ. Cuando el NAT Gateway se expande a una nueva AZ, asigna y asocia automáticamente una EIP. Si usas Amazon VPC IPAM, puede obtener direcciones de tus grupos (pools) de IPAM para una asignación gobernada.

• Modo manual: Tú gestionas las direcciones IP y controlas el NAT para cada AZ. Eres responsable de la expansión y contracción entre Zonas de Disponibilidad.

Tabla de rutas propia: Cuando creas un Regional NAT Gateway, AWS crea automáticamente una tabla de rutas para él con una ruta preconfigurada hacia el internet gateway (0.0.0.0/0 → IGW). Puedes agregar rutas de retorno a esta tabla para middleboxes (endpoints de Network Firewall, endpoints de GWLB, Transit Gateway). Esto es lo que permite el encadenamiento de inspección de tráfico en la ruta de retorno.

Escalado de puertos e IP: Cada IP admite hasta 55.000 conexiones concurrentes a un destino único (combinación única de IP de destino, puerto y protocolo). El Regional NAT Gateway admite hasta 32 direcciones IP por AZ (frente a 8 en el zonal). Cuando las conexiones se acercan a ~40.000 al mismo destino, agrega IPs automáticamente. El escalado hacia arriba tarda ~5 minutos. El escalado hacia abajo es conservador: ocurre después de que las conexiones caen por debajo de ~20.000 durante aproximadamente 1 hora.

No requiere subredes públicas: A diferencia de los NAT Gateways zonales, que deben alojarse en una subred pública, el Regional NAT Gateway es un recurso independiente de la VPC. No necesitas una subred pública en tu VPC, lo que reduce el riesgo de colocar accidentalmente recursos privados en subredes con conectividad pública.

Regional NAT Gateway vs. Zonal NAT Gateway

Cuándo usar Regional vs. Zonal

Usa Regional NAT Gateway cuando:

• Quieres una arquitectura simplificada con un solo NAT ID en todas las AZ
• No necesitas subredes públicas en tu VPC (mejor postura de seguridad)
• Las cargas de trabajo se expanden con frecuencia a nuevas AZ
• Quieres escalado automático de IP para protección contra el agotamiento de puertos
• Necesitas integración con VPC IPAM para una asignación gobernada de IP

Usa Zonal NAT Gateway cuando:

• Necesitas conectividad NAT privada (el RNAT no admite conectividad privada)
• Necesitas una colocación determinista en la AZ desde el inicio (sin retraso de expansión)
• Tienes requisitos estrictos sobre qué EIP se usa por AZ desde la creación

Consideraciones importantes

• La expansión de AZ tarda entre 15 y 60 minutos después de que se detecta una ENI. Hasta entonces, el tráfico se enruta de forma cruzada entre AZ.
• El NAT privado no es compatible; usa NAT Gateways zonales para conectividad privada.
• Hasta 5 Regional NAT Gateways por VPC.
• La tabla de rutas del RNAT admite IGW, endpoints de VPC (GWLBE/firewall), interfaces de red y Transit Gateway como destinos de ruta.
• Al encadenar con Network Firewall, agrega rutas por AZ de las subredes spoke en la tabla de rutas del RNAT para evitar enrutamiento asimétrico (tráfico de retorno descartado en un blackhole).
• El modo manual requiere que gestiones tú mismo la asignación de EIP y la expansión de AZ.

Puntos clave

• El Regional NAT Gateway simplifica la arquitectura de salida: un solo NAT ID, una entrada de ruta, se auto-expande entre AZ.
• No requiere subredes públicas: mejor postura de seguridad para VPCs que alojan cargas de trabajo privadas.
• La afinidad zonal asegura que el tráfico permanezca local por AZ (las distintas EIP por AZ lo confirman).
• No es un reemplazo del NAT zonal en todos los casos: el NAT privado aún requiere el modo zonal.
• Al encadenar con firewalls con estado (stateful), las rutas por AZ en la tabla de rutas del RNAT son obligatorias para prevenir el enrutamiento asimétrico.

Información relacionada

[1] Introducing Amazon VPC Regional NAT Gateway (AWS Blog)

[2] Regional NAT Gateways — AWS Documentation

[3] Build scalable IPv4 addressing with Regional NAT Gateway, VPC IPAM, and Prefix Lists (AWS Blog)

[4] Amazon VPC NAT Gateway pricing