Tu VPC está dividida en subredes públicas y privadas. Pero ¿cómo se conecta realmente con internet? Aquí entran dos componentes con nombres parecidos pero funciones distintas: el Internet Gateway y el NAT Gateway. Confundirlos es habitual, así que vamos a dejarlos clarísimos con analogías.

El Internet Gateway es el componente que conecta tu VPC con internet. Permite que el tráfico entre y salga entre tu red y el mundo exterior. Sin él, tu VPC está totalmente aislada de internet.

Analogía: El Internet Gateway es la puerta principal de tu parcela que da a la calle pública. Por ella entran los visitantes (usuarios que acceden a tu web) y salen tus envíos. Sin esa puerta, nadie de fuera puede entrar y tú no puedes salir.

Características clave:

• Hay uno por VPC (es un componente a nivel de toda la VPC).
• Es bidireccional: permite tráfico de entrada y de salida.
• Solo las subredes públicas lo usan (recuerda: una subred es pública precisamente porque tiene una ruta hacia el IGW).
• Es gratuito y de alta disponibilidad (lo gestiona AWS).

Importante: tener un Internet Gateway no hace que todo en tu VPC esté expuesto. Solo los recursos en subredes públicas, con IP pública y con una regla de ruta hacia el IGW, son accesibles. Los Security Groups (Capítulo 4) siguen controlando qué tráfico concreto se permite.

Aquí está el componente que resuelve el problema que planteamos en el subcapítulo anterior: ¿cómo permite a los recursos privados salir a internet (para descargar actualizaciones, llamar a una API externa…) sin dejar que internet entre a ellos?

El NAT Gateway (Network Address Translation Gateway) hace exactamente eso: es una puerta de salida de sentido único para las subredes privadas.

Analogía: El NAT Gateway es como una puerta trasera con un portero que solo deja salir, no entrar. Tus empleados (recursos privados) pueden salir a hacer recados (descargar actualizaciones, llamar a servicios externos) y volver con lo que fueron a buscar. Pero nadie de la calle puede usar esa puerta para entrar. La iniciativa siempre parte de dentro.

Cómo funciona en la práctica:

1. Un servidor en la subred privada quiere descargar una actualización.
2. Su petición sale a través del NAT Gateway (que está en una subred pública).
3. El NAT Gateway usa el Internet Gateway para llegar a internet.
4. La respuesta vuelve por el mismo camino hasta el servidor privado.
5. Pero internet no puede iniciar una conexión hacia ese servidor privado. Solo responde a lo que el servidor pidió.

Ejemplo real: Tu base de datos está en una subred privada (bien protegida). Una vez al mes necesita descargar parches de seguridad de internet. Gracias al NAT Gateway, puede hacerlo de forma segura: sale a buscar los parches, pero sigue siendo inalcanzable desde fuera. Lo mejor de ambos mundos: protegida pero con capacidad de actualizarse.

A diferencia del Internet Gateway (gratis), el NAT Gateway cuesta dinero: pagas por cada hora que está activo y por cada GB de datos que pasa por él. En arquitecturas grandes, puede convertirse en una sorpresa en la factura.

Dato práctico: El NAT Gateway es una de las causas frecuentes de costes inesperados en VPC. Para alta disponibilidad necesitas uno por AZ, lo que multiplica el coste. Existen alternativas más baratas para ciertos casos (como una «NAT instance» autogestionada, o usar VPC endpoints para hablar con servicios de AWS sin pasar por NAT, que veremos en el subcapítulo 6.5). Tenlo en el radar cuando optimices costes (Capítulo 25).

Juntando todo lo que llevamos del capítulo:

• El Internet Gateway (IGW) es la puerta principal bidireccional entre tu VPC e internet. Lo usan las subredes públicas. Es gratis.
• El NAT Gateway es una salida de sentido único: deja que los recursos privados salgan a internet (para actualizarse, etc.) pero impide que internet entre. Se coloca en una subred pública. Se paga.
• La regla mental: IGW = entrada y salida (público); NAT = solo salida (privado protegido).
• Vigila el coste del NAT Gateway: por hora + por datos, y necesitas uno por AZ para alta disponibilidad.

En el siguiente subcapítulo veremos las «normas de tráfico» que hacen que todo esto funcione: las Route Tables (qué camino sigue el tráfico) y las Network ACLs (un firewall a nivel de subred).