Subredes públicas y privadas, NAT y gateways
Una subred no es pública por una casilla que se tilda: lo es por su tabla de ruteo. Entender esa diferencia explica de una vez por qué una base de datos no se expone, por qué hace falta NAT y por qué ese NAT aparece en la factura.
Para este tema conviene tener claro:Redes virtuales, subredes y direccionamiento CIDR
Datos de proveedores verificados contra la documentación oficial el 19 de sept de 2026.
La red ya está partida en subredes y ahora hay que decidir cuáles ven internet. La intuición dice que tiene que haber una opción de “pública” en algún lado. No la hay, o mejor dicho: lo que la define no es una etiqueta sino hacia dónde apunta la ruta por defecto de la subred.
Toda la arquitectura de red de una cuenta sale de esa única decisión repetida.
Qué hace pública a una subred
Cada subred tiene una tabla de ruteo: una lista de “para este rango de direcciones, salí por
acá”. Siempre hay una ruta local que cubre la red entera, y después está la ruta por defecto,
la de 0.0.0.0/0, que es la que atrapa todo lo que no es local.
| Ruta por defecto de la subred | Qué queda | Para qué sirve |
|---|---|---|
| A un gateway de internet | Subred pública | Balanceadores, pasarelas NAT, hosts de salto |
| A una pasarela NAT | Subred privada con salida | Aplicaciones que consumen APIs y bajan paquetes |
| Sin ruta por defecto | Subred privada aislada | Bases de datos, caches, back-ends internos |
Y hay una segunda condición que sorprende a muchos: en una subred pública, un recurso además necesita una dirección IP pública propia. Sin ella, la ruta al gateway de internet no le sirve de nada: no hay dirección de origen desde la cual salir.
Antes de seguir, predecí
Por qué hace falta NAT
Las aplicaciones casi nunca deberían estar en una subred pública, pero igual necesitan salir: descargar dependencias, consultar una API de pagos, mandar un correo. Esa es exactamente la combinación que resuelve NAT: salida iniciada desde adentro, sin entrada posible desde afuera.
El recorrido de una request hacia una API externa
- La instancia privada manda el paquete; su tabla de ruteo apunta
0.0.0.0/0a la pasarela NAT. - La pasarela vive en una subred pública y tiene dirección pública propia.
- Reescribe la dirección de origen por la suya y anota la traducción en su tabla de conexiones.
- La respuesta vuelve a la pasarela, que busca la conexión en su tabla y la devuelve a la instancia.
- Nadie de afuera puede iniciar una conexión hacia la instancia: en esa tabla no hay nada que buscar.
| Capacidad | AWS | Google Cloud | Azure |
|---|---|---|---|
| Salida de una subred pública | Internet Gateway | Ruta por defecto a "default-internet-gateway" | Salida por defecto de la VNet |
| Salida sin exponerse | NAT Gateway | Cloud NAT | NAT Gateway |
| Alcance del servicio | Por zona: una pasarela por zona | Por región, gestionado y sin instancias | Por subred, asociado a IPs públicas |
| Llegar a servicios gestionados sin salir a internet | VPC endpoints y PrivateLink | Private Service Connect y acceso privado a Google | Private Endpoint y Service Endpoints |
El NAT en la factura
Una pasarela NAT gestionada cobra por hora de existencia y por gigabyte procesado. No es una pieza cara por sí sola, pero está prendida las 730 horas del mes y ve pasar todo el tráfico saliente de la aplicación.
Antes de seguir, predecí
El diseño que sirve para casi todo
Tres capas, repetidas en cada zona
- Subred pública, chica: sólo balanceadores y la pasarela NAT. Nada de aplicaciones.
- Subred privada de aplicación, grande: contenedores, instancias, funciones con acceso a la red.
- Subred privada de datos, sin ruta por defecto: bases, caches, colas internas.
Las reglas de firewall completan lo que el ruteo no hace. El ruteo dice por dónde puede ir un paquete; el firewall, quién puede hablar con quién. La capa de datos acepta conexiones sólo desde la capa de aplicación, y la de aplicación sólo desde el balanceador.
Más a fondo · nivel seniorCuando la salida tiene que ser auditable
En organizaciones con requisitos de cumplimiento, la salida a internet no se resuelve con NAT suelto en cada red sino con una red de inspección central: todas las redes rutean su salida hacia un punto único donde hay un firewall que registra y filtra por dominio. Se arma con Transit Gateway y Network Firewall en AWS, con Cloud NAT más Secure Web Proxy en Google Cloud, y con Azure Firewall en una red hub.
Tiene dos consecuencias que conviene anticipar: el punto central pasa a ser un componente crítico que necesita su propia alta disponibilidad, y aparece el problema de las listas de dominios permitidos, que envejecen mal. La alternativa de menor fricción es empezar por endpoints privados para los servicios del proveedor, que cubren buena parte del tráfico sin ninguna lista que mantener.
Cierre
Autoevaluación
¿Lo entendiste?
Práctica