Una VPC es tu parcela vallada, pero dentro necesitas organizarla en zonas. Esas zonas se llaman subredes (subnets), y la decisión más importante es cuáles serán públicas (accesibles desde internet) y cuáles privadas (ocultas y protegidas). Este es el corazón del diseño de redes seguras en AWS.

Una subred es una división de la VPC con su propio rango de direcciones (un trozo del CIDR de la VPC). Cada subred vive en una zona de disponibilidad (AZ) concreta.

Analogía: Si la VPC es tu parcela vallada, las subredes son las distintas calles o zonas dentro de ella. Una zona da a la entrada principal (pública); otra está en el interior, sin acceso directo desde fuera (privada).

Por ejemplo, si tu VPC es 10.0.0.0/16, podrías dividirla así:

Cada /24 da unas 250 direcciones. Fíjate en que hay subredes en dos AZ distintas: eso es para la alta disponibilidad que vimos en el Capítulo 3.

Aquí está el concepto central. La diferencia no está en la subred en sí, sino en si tiene o no una ruta hacia internet:

Definición práctica: una subred es pública si tiene una ruta hacia un Internet Gateway (la puerta a internet, subcapítulo 6.3). Si no la tiene, es privada. Esa ruta es lo que la hace pública o no. Lo veremos al detalle en el subcapítulo 6.4 (route tables).

Esta es la decisión de diseño que define la seguridad de tu arquitectura:

Recursos que necesitan ser accesibles desde internet:

• Servidores web que los usuarios visitan.
• Balanceadores de carga (Capítulo 13) que reciben el tráfico.
• NAT Gateways (subcapítulo 6.3).

Recursos sensibles que no deben estar expuestos:

• Bases de datos (¡nunca expongas una base de datos a internet!).
• Servidores de aplicación con lógica de negocio interna.
• Sistemas internos, colas, procesos de fondo.

Ejemplo real — arquitectura web típica:

Internet
   │
   ▼
[Subred pública]  ← Balanceador de carga + servidor web
   │ (se comunica internamente)
   ▼
[Subred privada]  ← Servidor de aplicación + Base de datos

Los usuarios solo llegan a la subred pública. La base de datos, en la subred privada, es invisible desde internet: solo el servidor de aplicación (dentro de la VPC) puede hablar con ella. Aunque un atacante comprometiera algo, la base de datos sigue sin tener puerta de entrada desde fuera.

Pon en subredes públicas solo lo que ESTRICTAMENTE necesita acceso desde internet. Todo lo demás, en subredes privadas.

Esto aplica el principio de defensa en profundidad: cuantas menos cosas expongas, menor es la superficie de ataque. Una base de datos en una subred privada es muchísimo más segura que una accesible desde internet, aunque ambas tengan contraseña.

Recuerda el subcapítulo 3.2: para alta disponibilidad, crea subredes en al menos dos AZ. Así, si una AZ falla, tu aplicación sigue funcionando desde la otra.

Por eso el diseño habitual «mínimo decente» tiene cuatro subredes: una pública y una privada en cada una de dos AZ.

Buena pregunta que surge siempre: si la base de datos o un servidor están en una subred privada (sin acceso a internet), ¿cómo descargan actualizaciones de software, por ejemplo?

La respuesta es el NAT Gateway, que permite a los recursos privados salir a internet (para descargar cosas) sin permitir que internet entre a ellos. Es una calle de sentido único hacia fuera. Lo veremos en detalle en el siguiente subcapítulo.

• Una subred es una división de la VPC, ubicada en una AZ, con su propio rango de IPs.
• Pública = tiene ruta a internet (para lo que debe ser accesible). Privada = sin ruta directa a internet (para lo sensible).
• Regla de oro: expón solo lo imprescindible en subredes públicas; pon bases de datos y sistemas internos en subredes privadas.
• Reparte subredes en varias AZ para alta disponibilidad (diseño típico: pública + privada en 2 AZ).
• Los recursos privados pueden salir a internet de forma segura mediante un NAT Gateway (siguiente subcapítulo).

En el siguiente subcapítulo veremos las dos «puertas» de tu red: el Internet Gateway (entrada/salida pública) y el NAT Gateway (salida segura para lo privado).