NAT Gateway y subredes privadas

Los recursos de las subredes privadas solo tienen direcciones IP privadas y no disponen de una ruta a un Internet Gateway, por lo que no pueden iniciar conexiones salientes a Internet. Sin embargo, a menudo necesitan acceder a Internet para descargar parches del sistema operativo, obtener imágenes de Docker, llamar a API de terceros o actualizar software. La solución consiste en dirigir el tráfico de la subred privada a través de un dispositivo que tenga acceso a Internet y realice NAT (Network Address Translation), ocultando las IP privadas tras una IP pública. AWS ofrece dos opciones: NAT Gateway (administrada) y una NAT Instance autogestionada (heredada).

Una NAT Gateway es un servicio totalmente administrado, de alta disponibilidad, que permite a las instancias de las subredes privadas iniciar conexiones salientes a Internet mientras bloquea el tráfico entrante no solicitado. Se encuentra en una subred pública, tiene una Elastic IP y escala automáticamente hasta un ancho de banda de 100 Gbps. No necesita aplicar parches, escalar ni administrar la infraestructura subyacente. La NAT Gateway traduce la IP de origen privada de los paquetes salientes a su propia EIP y, después, devuelve las respuestas a la IP privada original.

Después de crear un NAT Gateway, añada una ruta a la tabla de enrutamiento de la subred privada: destino 0.0.0.0/0 → ID del NAT Gateway. Esto indica que todo el tráfico dirigido a Internet desde las instancias de la subred privada debe ir al NAT Gateway, que después lo reenvía a través del Internet Gateway hacia Internet. La tabla de enrutamiento conserva la ruta local de la VPC (por ejemplo, 10.0.0.0/16 → local) para el tráfico interno. Sin esta entrada de ruta, las instancias de la subred privada seguirán sin acceso a Internet aunque haya un NAT Gateway implementado.

Un NAT Gateway es específico de una AZ: solo gestiona el tráfico de las subredes de la misma AZ. Para lograr alta disponibilidad, implemente un NAT Gateway por AZ y cree tablas de enrutamiento privadas específicas de cada AZ: la tabla de enrutamiento privada de AZ-a dirige 0.0.0.0/0 al NAT-GW de AZ-a; la tabla de enrutamiento privada de AZ-b dirige el tráfico al NAT-GW de AZ-b. Esto evita los cargos por transferencia de datos entre AZ y garantiza que, si AZ-a falla, las instancias de AZ-b (con su propio NAT) sigan teniendo acceso a Internet.

Una NAT Instance es una instancia de EC2 autogestionada que ejecuta una AMI de NAT: el enfoque heredado anterior a la existencia de los NAT Gateway. Las NAT Instances requieren que usted: desactive la comprobación de origen/destino en la instancia de EC2, gestione el ancho de banda y el escalado, aplique parches al sistema operativo y gestione los errores. Son más económicas para casos de uso con un ancho de banda muy bajo y pueden utilizarse como bastion hosts. Los NAT Gateway son la opción recomendada para producción: están totalmente gestionados, se escalan automáticamente, ofrecen un SLA de disponibilidad del 99,99 % dentro de una AZ y no requieren aplicar parches. El examen ha evaluado históricamente esta comparación.

El precio de NAT Gateway tiene dos componentes: un cargo por hora por cada NAT Gateway (aproximadamente 0,045 USD por hora en us-east-1, unos 32 USD al mes) y un cargo por procesamiento de datos por GB (aproximadamente 0,045 USD/GB en us-east-1). En las cargas de trabajo que transfieren grandes volúmenes de datos mediante NAT (por ejemplo, al descargar imágenes de contenedor grandes o realizar descargas masivas), el coste de procesamiento de datos puede ser el predominante. Optimice los costes de NAT de la siguiente manera: dirija el tráfico de S3 y DynamoDB mediante VPC Gateway Endpoints (evitan completamente NAT y son gratuitos) y dirija las llamadas a las API de AWS mediante VPC Interface Endpoints en lugar de hacerlo a través de NAT.

Las instancias de bases de datos en subredes privadas no deben enrutarse a través del NAT Gateway: no necesitan iniciar conexiones a Internet. Las bases de datos solo necesitan recibir conexiones del nivel de aplicación (dentro de la VPC) y, potencialmente, acceder a servicios de AWS como S3 (para exportaciones e importaciones) mediante un VPC endpoint. Para aplicar parches y actualizaciones a la base de datos, RDS es un servicio gestionado, por lo que no se aplican parches del sistema operativo directamente. En el caso de bases de datos autogestionadas en EC2, utilice Systems Manager Patch Manager, que puede aplicar parches mediante SSM sin acceso a Internet si ha configurado el SSM VPC endpoint.

NAT Gateway proporciona NAT con estado y solo de salida: permite las conexiones salientes iniciadas y sus respuestas, pero bloquea todo el tráfico entrante no solicitado. No es un firewall: no inspecciona ni filtra el contenido del tráfico. Para filtrar el tráfico saliente (por ejemplo, permitir únicamente dominios o direcciones IP de destino específicos desde subredes privadas), necesita controles adicionales: AWS Network Firewall implementado en la VPC o un dispositivo firewall de terceros detrás de un Gateway Load Balancer. Los grupos de seguridad y las NACL también se aplican a las instancias de las subredes privadas, independientemente de NAT.

Además de los NAT Gateway públicos (con EIP para acceder a Internet), AWS admite NAT Gateway privados sin EIP. Los NAT Gateway privados se utilizan para traducir direcciones IP privadas en el tráfico entre VPC o entre una VPC y redes locales cuando los rangos CIDR se solapan. Por ejemplo, si VPC-A (10.0.0.0/16) necesita comunicarse con una red local que también utiliza 10.0.0.0/16, un NAT Gateway privado en VPC-A traduce las IP de origen a un rango que no se solapa antes de enrutar el tráfico mediante un Transit Gateway hacia la red local.

Supervise el estado y el rendimiento de NAT Gateway mediante las métricas de CloudWatch. Métricas clave: ActiveConnectionCount (conexiones TCP activas actuales a través de NAT), BytesInFromDestination / BytesInFromSource (transferencia de datos en ambas direcciones), PacketDropCount (paquetes descartados; indica límites de ancho de banda o errores) y ErrorPortAllocation (NAT agotó las asignaciones de puertos; puede indicar agotamiento de puertos debido a un número excesivo de conexiones). Cada NAT Gateway admite hasta 55 000 conexiones simultáneas por destino único; a partir de ese límite, es posible que se descarten conexiones.

No todas las cargas de trabajo de subredes privadas necesitan un NAT Gateway. Considere el patrón de acceso: si las instancias solo necesitan comunicarse con otros recursos de la VPC y con servicios de AWS accesibles mediante VPC endpoints (S3, DynamoDB, SSM, ECR, Secrets Manager), puede eliminar completamente el NAT Gateway, lo que supone un ahorro de aproximadamente 32 USD al mes por AZ, además de los cargos de procesamiento de datos. Este es el patrón ideal para microservicios completamente privados que utilizan VPC Interface Endpoints para acceder a todos los servicios de AWS. Evalúe cada servicio al que llaman sus instancias y compruebe si un Gateway Endpoint gratuito o un Interface Endpoint de pago puede sustituir a NAT.

Compruebe su comprensión de los conceptos de AWS Solutions Architect (SAA-C03) tratados en esta lección.

En esta lección ha aprendido que: los NAT Gateway permiten el acceso saliente a Internet de las instancias de subredes privadas mediante la traducción de sus IP privadas a una Elastic IP, debe añadir una ruta 0.0.0.0/0 en la tabla de enrutamiento de la subred privada que apunte al NAT Gateway y debe implementar un NAT Gateway por AZ para lograr alta disponibilidad y evitar los cargos por transferencia de datos entre AZ. A continuación, compararemos las Network ACL y los grupos de seguridad para aplicar una defensa por capas en la VPC.