top of page

Migración de NAT Gateways zonales a NAT Gateways regionales

hace 5 días
7 min de lectura

Los NAT Gateways son un componente habitual en arquitecturas de red sobre AWS. Permiten que recursos ubicados en subredes privadas inicien conexiones salientes hacia internet sin exponer directamente esos recursos con direcciones públicas.


Históricamente, el patrón recomendado para alta disponibilidad era crear un NAT Gateway por Availability Zone y configurar las tablas de ruteo para que cada subred privada use el NAT Gateway de su misma zona. Ese modelo sigue siendo válido, pero agrega complejidad operativa: más recursos, más Elastic IPs, más rutas y más cuidado al expandir la VPC a nuevas zonas.


AWS incorporó los Regional NAT Gateways, una modalidad que permite crear un único NAT Gateway regional asociado a una VPC. En modo regional, AWS puede expandir y contraer la cobertura entre Availability Zones según la presencia de workloads, simplificando el diseño y la operación de la salida a internet desde subredes privadas.


Este TeraTip explica qué cambia, qué ventajas aporta, que riesgos hay que revisar y cómo planificar una migración segura.


Que cambia

Con NAT Gateways zonales, cada NAT Gateway vive en una Availability Zone específica. Para una arquitectura multi-AZ resiliente, normalmente se crea un NAT por zona y se mantiene una ruta 0.0.0.0/0 por cada tabla de ruteo privada hacia el NAT Gateway local de esa zona.


Con NAT Gateways regionales, se crea un NAT Gateway en modo regional y las rutas privadas pueden apuntar a un único NAT Gateway ID. En modo automático, AWS administra la expansión por Availability Zone y la asignación de direcciones IP públicas necesarias para prestar el servicio.

Según la documentación oficial de AWS, este enfoque busca simplificar la arquitectura de red, mejorar la postura de seguridad y configurar alta disponibilidad por defecto.


Ventajas de cambiar a NAT Gateway regional

Las principales ventajas son:

  • Menos complejidad de red: se puede usar un único NAT Gateway ID para subredes privadas en distintas Availability Zones, reduciendo la lógica de ruteo por zona.

  • Menos recursos que operar: se reduce la necesidad de crear, nombrar, taggear y mantener múltiples NAT Gateways y múltiples rutas asociadas.

  • No requiere subred publica para alojar el NAT: AWS documenta que el NAT Gateway regional es un recurso independiente con su propia tabla de ruteo. Esto reduce el riesgo de errores donde recursos privados terminan en subredes con conectividad publica.

  • Alta disponibilidad automática: el NAT regional se expande y contrae segun la presencia de workloads en las Availability Zones, manteniendo afinidad zonal cuando corresponde.

  • Escalabilidad de puertos e IPs superior: AWS indica que los NAT Gateways regionales soportan hasta 32 direcciones IP por Availability Zone, frente a 8 en NAT Gateways zonales. Cada IP incrementa en 55.000 el limite de conexiones simultaneas hacia un mismo destino.

  • Mejor abstracción para módulos Terraform: permite exponer una opción simple como nat_gateway_availability_mode = "regional" sin obligar al consumidor del modulo a modelar manualmente cada AZ.

  • Menos riesgo al crecer a nuevas AZs: en lugar de agregar NAT, subred pública y rutas cada vez que se incorpora una zona, el modo regional puede cubrir esa expansión automáticamente.


La ventaja principal no debe venderse solo como ahorro. En muchos casos, el beneficio mas claro es la simplicidad operativa, la menor probabilidad de mala configuracion y una arquitectura de salida mas facil de estandarizar.


Cuando conviene usar NAT Gateway regional

Tiene sentido evaluarlo cuando:

  • Se necesita salida a internet desde subredes privadas.

  • La VPC opera en multiples Availability Zones.

  • Se quiere simplificar el diseño de rutas privadas.

  • Se esta creando una VPC nueva y se quiere evitar complejidad desde el inicio.

  • Se mantienen módulos Terraform reutilizables y se busca una opción mas simple para consumidores.

  • No se usa Private NAT Gateway.

  • Se puede validar el cambio en una ventana controlada.


Cuando conviene mantener NAT Gateways zonales

No todos los entornos deberían migrar automáticamente.


Conviene mantener NAT Gateways zonales cuando:

  • Se necesita Private NAT Gateway. AWS indica que NAT Gateway regional no soporta NAT privada.

  • Se requiere control manual estricto por Availability Zone.

  • Hay dependencias fuertes sobre IPs publicas de egreso actuales.

  • Existen allowlists externas que no pueden cambiarse fácilmente.

  • La zona o el tipo de arquitectura no soporta NAT regional.

  • No se puede aceptar una ventana de mantenimiento.


Consideraciones de costos

Regional NAT Gateway no significa necesariamente "un NAT en lugar de tres" a nivel de facturación.


La pagina oficial de precios de Amazon VPC indica que un NAT Gateway regional se cobra por cada hora en que esta configurado en cada Availability Zone. Por ejemplo, si un NAT regional opera en tres Availability Zones durante una hora, se facturan tres NAT Gateway-hours. Tambien se cobran los GB procesados por el NAT Gateway y los cargos estándar de transferencia de datos.


Por eso, antes de migrar, conviene revisar:

  • Volumen de tráfico saliente a internet.

  • Trafico hacia servicios AWS que podría usar VPC Endpoints.

  • Uso de Gateway Endpoints para S3 y DynamoDB.

  • Uso de Interface Endpoints para servicios AWS de alto trafico.

  • Posible variación de cargos por procesamiento y transferencia.


El cambio puede simplificar la arquitectura, pero no debe asumirse como reducción automática de costos.


Riesgos de migración

La migración debe tratarse como un cambio de red productivo.


Riesgos principales:

  • Reseteo de conexiones: AWS advierte que convertir de NAT zonal a NAT regional puede resetear conexiones existentes.

  • Cambio de IP publica de egreso: si se crea un NAT regional con nuevas IPs, servicios externos pueden ver un origen distinto.

  • Allowlists externas: firewalls, partners, APIs o SaaS pueden depender de las IPs actuales.

  • Errores en route tables: una ruta 0.0.0.0/0 mal apuntada puede cortar la salida de subredes privadas.

  • Cambios destructivos en Terraform: hay que evitar que un wrapper y un modulo interno compitan por la propiedad de NAT Gateways, Internet Gateways o rutas.

  • Tiempo de expansión a nuevas AZs: AWS documenta que la expansión del NAT regional hacia una nueva Availability Zone puede tardar hasta 60 minutos luego de detectar workloads alli.


Estrategia recomendada de migracion

Usar una ventana de mantenimiento y aplicar el cambio de forma controlada.


1. Inventariar el estado actual

Antes de modificar Terraform o rutas, registrar:

  • NAT Gateway IDs actuales.

  • Elastic IPs actuales.

  • Route tables privadas y sus rutas 0.0.0.0/0.

  • Subredes publicas usadas solo para NAT.

  • Sistemas externos que allowlistean IPs de egreso.

  • Volumen de trafico por NAT Gateway.

  • Uso o no de Private NAT Gateway.


Comandos utiles:


aws ec2 describe-nat-gateways \
  --filter Name=state,Values=available \
  --query 'NatGateways[].{Id:NatGatewayId,Vpc:VpcId,Subnet:SubnetId,State:State,PublicIps:NatGatewayAddresses[].PublicIp}'
aws ec2 describe-route-tables \
  --query 'RouteTables[].{RouteTableId:RouteTableId,VpcId:VpcId,Routes:Routes[?DestinationCidrBlock==`0.0.0.0/0`]}'

2. Decidir si se preservan las IPs de egreso

AWS documenta dos caminos de migración.

Si se pueden usar nuevas IPs:

  1. Crear un nuevo NAT Gateway regional.

  2. Actualizar las route tables privadas para apuntar al NAT regional.

  3. Eliminar los NAT Gateways zonales anteriores.

Este camino es mas simple, pero cambia las IPs de egreso y resetea conexiones al actualizar las rutas.

Si se deben conservar las IPs actuales:

  1. Eliminar los NAT Gateways zonales existentes para liberar sus Elastic IPs.

  2. Crear el NAT Gateway regional usando esas IPs liberadas.

  3. Actualizar las route tables privadas para apuntar al NAT regional.


Este camino preserva IPs, pero requiere ventana de mantenimiento porque hay interrupción de egreso durante la transición.


3. Actualizar el provider de Terraform

El recurso aws_nat_gateway soporta el argumento availability_mode, con valores zonal y regional. En modo regional, Terraform usa vpc_id y no subnet_id.


Usar AWS provider >= 6.24.0 si el módulo depende de esta funcionalidad.


terraform {
  required_providers {
    aws = {
      source  = "hashicorp/aws"
      version = ">= 6.24.0"
    }
  }
}

4. Modelar NAT Gateway regional en Terraform

Ejemplo simplificado en modo automático:


resource "aws_internet_gateway" "this" {
  vpc_id = aws_vpc.this.id
}

resource "aws_nat_gateway" "regional" {
  vpc_id            = aws_vpc.this.id
  availability_mode = "regional"

  tags = {
    Name = "example-regional-nat"
  }

  depends_on = [aws_internet_gateway.this]
}

Las route tables privadas apuntan al NAT Gateway regional:

resource "aws_route" "private_default" {
  for_each = aws_route_table.private

  route_table_id         = each.value.id
  destination_cidr_block = "0.0.0.0/0"
  nat_gateway_id         = aws_nat_gateway.regional.id
}

5. Revisar el plan de Terraform

Antes del apply, validar:

  • Que se cree el NAT Gateway regional esperado.

  • Que las rutas privadas apunten al nuevo NAT regional.

  • Que no haya reemplazos no esperados de VPC, subnets, route tables o Internet Gateway.

  • Que los NAT zonales anteriores no se destruyan antes de tener una ruta funcional, salvo que se este preservando IPs.

  • Que create_vpc = false o modos de VPC externa no intenten crear recursos NAT por error.

  • Que el comportamiento zonal siga siendo el default para retrocompatibilidad.


6. Validar después del cambio

Chequeos de infraestructura:

aws ec2 describe-nat-gateways \
  --nat-gateway-ids <nat-gateway-id> \
  --query 'NatGateways[].{Id:NatGatewayId,State:State,Mode:AvailabilityMode,RouteTableId:RouteTableId,Addresses:NatGatewayAddresses}'
aws ec2 describe-route-tables \
  --filters Name=route.nat-gateway-id,Values=<nat-gateway-id> \
  --query 'RouteTables[].RouteTableId'

Chequeos funcionales:

  • Instancias o workloads privados pueden salir a internet.

  • Pull de imágenes, updates de paquetes y llamadas a APIs externas funcionan.

  • Los sistemas externos ven las IPs de egreso esperadas.

  • No aparecen errores de ruteo en subredes privadas.

  • Métricas de CloudWatch del NAT Gateway se mantienen saludables.


Plan de rollback

Preparar rollback antes del cambio.


Si se migra usando nuevas IPs:

  1. Mantener los NAT Gateways zonales anteriores hasta terminar la validación.

  2. Si algo falla, restaurar las route tables hacia los NAT Gateway IDs anteriores.

  3. Confirmar salida a internet desde subredes privadas.

  4. Eliminar el NAT regional solo cuando el rollback este confirmado.


Si se migra preservando IPs, el rollback es mas complejo porque los NAT zonales se eliminaron para liberar Elastic IPs. En ese caso, documentar la topologia previa y asumir una interrupción adicional si hay que volver atras.


Conclusión

Los NAT Gateways regionales son una mejora importante para simplificar la salida a internet de workloads privados en VPCs multi-AZ. Permiten reducir complejidad de rutas, mejorar la postura de seguridad al no requerir subredes publicas para alojar el NAT, y delegar en AWS la expansión de alta disponibilidad entre zonas.


El cambio no elimina costos de NAT Gateway, no reemplaza Private NAT Gateway y no debe aplicarse sin revisar IPs de egreso, allowlists, rutas, provider de Terraform y plan de rollback.


La recomendación práctica es mantener NAT zonal como comportamiento default para retrocompatibilidad y ofrecer NAT regional como una opción explícita del módulo para entornos que se beneficien de una arquitectura más simple y estandarizada.


Referencias oficiales





Silvio Depetri

Cloud Engineer

 
 
bottom of page
window.addEventListener('load', function() {   var search = window.location.search;   if (!search || search === '?') return;   var params = search.slice(1);   setTimeout(function() {     document.querySelectorAll('iframe').forEach(function(fr) {       try { fr.contentWindow.postMessage({type:'TERACLOUD_UTM', params: params}, '*'); } catch(e) {}     });   }, 1500); });