AWS Internet Gateway y Route Tables explicados

Un Internet Gateway (IGW) es el componente de AWS que conecta tu VPC con internet. Sin él, una instancia EC2 queda aislada: no la podés acceder desde afuera ni ella puede salir a la web. Pero el IGW solo no alcanza. Necesitás una ruta en la Route Table que apunte el tráfico hacia él.

Esa es la parte que confunde a casi todo el que arranca con redes en AWS. Creás la VPC, lanzás la instancia, le ponés IP pública, y nada. No responde. ¿El motivo? Casi siempre falta el gateway, la ruta, o las dos cosas.

AWS Internet Gateway explicado en una línea: es la puerta oficial de entrada y salida de tu red en la nube. Es un componente que se adjunta a una VPC y habilita comunicación bidireccional entre tus instancias EC2 e internet. No filtra tráfico (de eso se encargan los Security Groups y las NACLs) y no es lo mismo que un NAT Gateway. Su única función es ser el punto de conexión con el mundo exterior.

¿Por qué necesitás un Internet Gateway en AWS?

Pensá tu VPC como una ciudad amurallada. Adentro tenés tus subredes, tus instancias, todo funcionando. Pero la muralla no tiene puerta. Nadie entra, nadie sale.

Eso es exactamente lo que pasa con una VPC recién creada. Por defecto está cerrada al exterior, y es una decisión de diseño: AWS prefiere que vos abras el acceso de forma explícita en vez de exponerte sin querer. Ponele que lanzás una instancia EC2 para hostear una API. La instancia existe, tiene su IP privada, arranca el servidor web. Y sin embargo no podés llegar a ella desde tu navegador, no descarga actualizaciones, ni siquiera puede hacer un apt update. Complementá con integrar APIs externas en tu arquitectura.

¿Y por qué? Porque le falta la puerta. El Internet Gateway es esa puerta.

¿Qué es un Internet Gateway (IGW)?

Un Internet Gateway es un componente de VPC que habilita la comunicación entre las instancias de tu red privada e internet. Según la guía de dev.to sobre IGW y Route Tables, es el punto oficial de entrada y salida del tráfico de internet en AWS.

La analogía del shopping sirve bien: un centro comercial tiene una entrada principal por donde pasan todos los clientes. En AWS, el IGW es esa entrada. Todo el tráfico que va o viene de internet cruza por ahí.

Hay tres cosas que conviene grabarse desde el principio. Primero, es bidireccional: maneja tanto el tráfico que entra (alguien accede a tu servidor) como el que sale (tu instancia baja un paquete). Esto lo diferencia del NAT Gateway, que es de salida nada más. Segundo, se adjunta a la VPC completa, no a una subred ni a una instancia puntual. Tercero, lo tenés que crear y attachar a mano: no viene puesto.

¿Cómo funciona un Internet Gateway por dentro?

El flujo es más simple de lo que parece. Tu instancia EC2 genera un paquete con destino a internet. Ese paquete viaja a la Route Table de su subred, que lo manda al IGW. El gateway lo dirige hacia afuera y, cuando vuelve la respuesta, hace el camino inverso hasta la instancia.

Acá viene lo bueno: el IGW también se encarga de la traducción entre la IP pública y la privada cuando hace falta. Tu instancia “ve” su IP privada, pero el mundo exterior la encuentra por la pública. Esa magia la resuelve el gateway sin que vos toques nada.

Ojo con un malentendido común. El IGW no es un firewall. No mira si el tráfico es legítimo, no bloquea puertos, no decide quién pasa. Es una puerta abierta. El control de acceso real lo ponés vos con los Security Groups (a nivel instancia) y las NACLs (a nivel subred). Confundir las funciones es lo que lleva a dejar una base de datos expuesta pensando que “el gateway ya filtra”. Tema relacionado: automatizar deployments en tu infraestructura.

¿Qué son las Route Tables y por qué son críticas?

Una Route Table es un conjunto de reglas que le dice a AWS adónde mandar cada paquete según su destino. Es la lista de instrucciones de tráfico de tu red.

Cada subred tiene que estar asociada a una Route Table. Sí o sí. Si no asociás una explícita, hereda la principal de la VPC. Y la regla que importa para salir a internet es una sola:

• Destino 0.0.0.0/0: significa “cualquier dirección de internet”.
• Target igw-xxxxxxxx: significa “mandá ese tráfico al Internet Gateway”.

Sin esa entrada, el IGW existe pero nadie lo usa. Es como tener la puerta del shopping cerrada con candado: está, pero no cumple ninguna función. Este es probablemente el error número uno de quien recién arranca: adjuntan el gateway, lo ven en la consola, y dan por hecho que ya está. Falta la ruta.

¿Cómo se comunican el Internet Gateway y las Route Tables?

La relación es de puerta e instrucciones. El IGW es la puerta física; la Route Table son los carteles que dicen “para ir a internet, seguí por acá”.

Un gateway sin rutas que lo apunten es una puerta sin ningún camino que lleve a ella. Y una ruta que apunta a un IGW que no existe tampoco sirve. Las dos piezas trabajan juntas: la ruta 0.0.0.0/0 nombra de forma explícita al igw-xxxxx, y recién ahí el paquete sabe que tiene que cruzar por esa puerta. Esto se conecta con lo que analizamos en conectar bases de datos en la nube.

Cuando una subred tiene una ruta a un IGW, se la llama subred pública. Cuando no la tiene, es privada. La diferencia entre “pública” y “privada” en AWS no la define la subred en sí, la define si su Route Table conoce o no el camino al gateway.

¿Cuándo necesitás un Internet Gateway y cuándo un NAT Gateway?

No todo tiene que ser público. Hay dos escenarios distintos que conviene separar bien:

• Acceso de entrada (inbound): alguien externo se conecta a tu instancia. Servidor web público, API accesible desde internet. Acá va IGW más IP pública.
• Acceso de salida (outbound): tu instancia inicia la conexión para bajar paquetes o pegarle a una API, pero nadie de afuera la llama. Una base de datos que necesita actualizaciones, por ejemplo. Acá, lo correcto suele ser un NAT Gateway en una subred pública, con la instancia bien escondida en la privada.

La diferencia importa por seguridad. Si tu base de datos solo necesita salir a internet para actualizarse, exponerla con un IGW e IP pública es abrirle la puerta a todo el mundo sin razón.

Característica	Internet Gateway (IGW)	NAT Gateway
Dirección del tráfico	Bidireccional (entra y sale)	Solo salida (outbound)
Se adjunta a	La VPC	Una subred pública
Tipo de subred	Pública	Privada (la instancia que lo usa)
Caso típico	Servidor web, API expuesta	DB o backend que solo baja paquetes
Costo	Sin costo por el gateway	Cobro por hora y por GB procesado
IP pública en la instancia	Necesaria para inbound	No necesaria

Si estás armando infraestructura en serio y querés algo más simple que pelear con VPCs, en Argentina tenés opciones de donweb.com para hosting y servidores cloud sin tanta vuelta de red.

Pasos para crear un Internet Gateway y configurar las rutas

La secuencia completa, en orden, desde la consola de AWS (sección VPC):

1. Creá el Internet Gateway: en VPC → Internet Gateways → Create. Le ponés un nombre y listo.
2. Attachalo a tu VPC: el IGW nace “detached”. Acción → Attach to VPC → elegís la tuya.
3. Abrí o creá la Route Table: en VPC → Route Tables, ubicá la de tu subred pública.
4. Agregá la ruta: editá las rutas, sumá destino 0.0.0.0/0 y como target el igw-xxxx que creaste.
5. Asociá la Route Table a la subred: en la pestaña de asociaciones, vinculá la subred que querés hacer pública.
6. Asigná IP pública a la EC2: si necesitás inbound, la instancia precisa IP pública o Elastic IP.
7. Revisá Security Groups y NACLs: abrí los puertos que correspondan (80, 443, 22 según el caso).
8. Probá la conectividad: un ping o un curl de salida, y un acceso desde tu navegador para el inbound.

Si seguiste los ocho pasos y todavía no anda, el 90% de las veces es el Security Group cerrado o la ruta que quedó en la Route Table equivocada.

Errores comunes al configurar un IGW

• Crear el IGW y olvidar la ruta: el gateway queda adjunto pero sin la entrada 0.0.0.0/0 nadie lo usa. Solución: revisá siempre la Route Table después de attachar.
• Editar la Route Table equivocada: agregás la ruta en la tabla principal pero tu subred usa otra asociada. Solución: confirmá qué Route Table tiene asociada esa subred puntual.
• Pensar que el IGW filtra el tráfico: dejás todo abierto creyendo que el gateway protege. No lo hace. Solución: definí el acceso real en los Security Groups y las NACLs.
• Olvidar la IP pública en la instancia: tenés gateway, ruta y SG abierto, pero la EC2 no tiene IP pública para el inbound. Solución: asigná una Elastic IP o activá auto-assign en la subred.

Preguntas Frecuentes

¿Qué es un Internet Gateway en AWS?

Es un componente de VPC que habilita la comunicación bidireccional entre tus instancias EC2 e internet. Se adjunta a la VPC y es el punto oficial de entrada y salida del tráfico. No filtra ni controla acceso: solo conecta tu red con el exterior. En orquestar despliegues en la nube profundizamos sobre esto.

¿Cómo funcionan las tablas de rutas?

Una Route Table es una lista de reglas que define adónde enviar cada paquete según su destino. Cada subred está asociada a una. Para salir a internet, necesita una ruta con destino 0.0.0.0/0 que apunte al Internet Gateway.

¿Necesito un Internet Gateway para que EC2 acceda a internet?

Sí, si la instancia está en una subred pública y necesita conexión directa de entrada o salida. Si solo necesita salida y querés mantenerla privada, la alternativa es un NAT Gateway. Sin ninguno de los dos, la instancia queda aislada.

¿Cuál es la diferencia entre IGW y NAT Gateway?

El IGW maneja tráfico bidireccional y permite que internet llegue a tu instancia. El NAT Gateway es solo de salida: deja que una instancia privada baje datos sin quedar expuesta a conexiones entrantes. El IGW no tiene costo por sí mismo; el NAT cobra por hora y por GB procesado.

¿Cómo configuro un Internet Gateway en AWS?

Creás el IGW, lo adjuntás a tu VPC, agregás una ruta 0.0.0.0/0 → igw-xxxx en la Route Table de la subred, asociás esa tabla a la subred y asignás IP pública a la instancia si necesita inbound. Después abrís los puertos en el Security Group.

Conclusión

El Internet Gateway y las Route Tables son las dos mitades de la misma idea: el gateway es la puerta, la ruta es el cartel que indica el camino hacia ella. Tener una sin la otra no sirve de nada, y ese es justo el punto donde se traba casi todo el que arranca con redes en AWS.

Si te quedás con un solo concepto, que sea este: el IGW conecta, pero no protege. La seguridad la ponés vos con Security Groups y NACLs. Configurá la ruta, separá lo público de lo privado según necesites inbound o solo salida, y probá la conectividad de los dos lados antes de dar nada por terminado.

Fuentes

• AWS Internet Gateway and Route Tables Explained for Beginners – guía introductoria en dev.to
• Documentación oficial de AWS – Internet Gateways
• Documentación oficial de AWS – Route Tables