Blog Cloud Security

¿Subred pública o privada en AWS? Qué va en cada una (2026)

La única diferencia real: una subred pública tiene ruta a internet (a través de un Internet Gateway) y una privada no

📅 Publicado: 21 jul 2026
🔄 Actualizado: 21 jul 2026
👤 Por: Jaivic Villegas
📌 Última revisión: 21 jul 2026
📋 Contenido
  1. Subred pública: la cara visible
  2. Subred privada: lo valioso, oculto
  3. El patrón que todos usan
  4. ¿Por qué: seguridad en capas?
  5. Preguntas frecuentes
  6. Artículos relacionados

¿Subred pública o privada en AWS, cuál uso para cada cosa? En la pública va lo que debe ser accesible desde internet, como el balanceador; en la privada va todo lo que guarda o procesa datos, como tus servidores y tu base de datos. La diferencia es una sola: si la subred tiene o no camino directo a internet., que es el diagrama que todo el mundo busca.

La única diferencia real, y es esta: una subred pública tiene una ruta hacia internet, a través de una puerta de enlace de internet. Una subred privada no la tiene. Eso es todo. No hay magia; es una cuestión de si hay camino de salida directo o no.

Pública = tiene ruta a internet (Internet Gateway). Privada = NO la tiene. Todo lo demás sale de ahí.

Subred pública: la cara visible

En la subred pública pones lo que necesita hablar con internet de forma directa. El balanceador de carga que recibe a tus usuarios. Un servidor puente para administrar, el bastión. Cosas que son, a propósito, la cara visible hacia fuera.

Lo que debe ser accesible/salir directo: balanceador de carga, un bastión de administración. La puerta de entrada.

Subred privada: lo valioso, oculto

En la subred privada pones lo valioso y sensible, lo que nunca debería estar expuesto directamente. Tus servidores de aplicación. Tu base de datos, sobre todo. Ahí viven ocultos, sin una puerta directa desde internet a ellos.

Servidores de aplicación y, sobre todo, la base de datos. Nunca expuestos directamente a internet.

El patrón que todos usan

El patrón clásico, el diagrama que se repite en todas partes, es este. Balanceador en la pública, recibiendo a los usuarios. Detrás, en la privada, tus servidores. Y más al fondo, también en la privada, la base de datos. El tráfico entra por delante y baja hacia dentro.

  1. Pública: balanceador de carga (recibe a los usuarios)
  2. Privada: servidores de aplicación (detrás)
  3. Privada: base de datos (lo más al fondo)
  4. Salida de los privados: por NAT Gateway

¿Por qué: seguridad en capas?

Por qué se hace así: seguridad en capas. Si tu base de datos no tiene ninguna ruta desde internet, un atacante no puede llegar a ella directamente aunque quiera. Reduces la superficie de ataque a lo mínimo: solo el balanceador da la cara.

La BD sin ruta a internet = nadie la alcanza directamente. Solo el balanceador da la cara. Mínima superficie de ataque.

Preguntas frecuentes

¿Por qué puede salir caro?

Un aviso honesto de coste, ya que estamos: el NAT Gateway cobra por hora y por datos, y es un sospechoso habitual de las facturas caras. Tenlo presente al diseñar; no lo pongas y lo olvides.

El NAT Gateway cobra por hora y por GB: un clásico de las facturas caras. No lo pongas y lo olvides.

¿Qué detalle sorprende a casi todos?

Pero surge una duda: si mis servidores están en la privada sin salida, ¿cómo descargan actualizaciones o llaman a una API externa? Con un NAT Gateway. Es una salida de un solo sentido: ellos pueden salir a internet, pero nadie de fuera puede entrar a ellos.

Con un NAT Gateway: salida de un solo sentido. Los privados SALEN a internet, pero nadie ENTRA a ellos. Ojo, el NAT cuesta.

¿Por dónde empiezo?

Por qué se hace así: seguridad en capas. Si tu base de datos no tiene ninguna ruta desde internet, un atacante no puede llegar a ella directamente aunque quiera. Reduces la superficie de ataque a lo mínimo: solo el balanceador da la cara.

Jaivic Villegas Jaivic Villegas Ver todos los artículos →

Artículos relacionados