Diagrama de VPC de AWS: subredes, tablas de enrutamiento y NAT bien dibujados

La mayoría de los diagramas de VPC se dibujan una sola vez, al principio del proyecto, copiando el mapa de recursos de la consola. Muestran todos los recursos y no responden a ninguna de las preguntas con las que la gente acude a ellos: ¿puede Internet llegar a esta base de datos? ¿Por qué la aplicación puede descargar paquetes pero no recibir conexiones? ¿Qué se rompe si cae una zona de disponibilidad?

Esta guía muestra cómo dibujar un diagrama de VPC de AWS que responda esas preguntas. Usamos una topología habitual, una VPC en dos zonas de disponibilidad con subredes públicas, privadas y de datos, y repasamos las piezas que deciden la accesibilidad: subredes, tablas de enrutamiento, puertas de enlace, puntos de conexión y grupos de seguridad.

Las preguntas que debe responder un diagrama de VPC

• ¿Qué puede alcanzar Internet? Solo los recursos de subredes públicas con una ruta a una puerta de enlace de Internet, y solo si sus grupos de seguridad lo permiten.
• ¿Cómo salen los recursos privados? Normalmente a través de una puerta de enlace NAT, a veces a través de puntos de conexión de VPC y a veces de ningún modo.
• ¿Cómo fluye el tráfico entre capas? Del balanceador de carga a la aplicación, de la aplicación a la base de datos, y por qué puertos.
• ¿Qué pasa si falla una AZ? Qué recursos existen en cada zona y cuáles son compartidos.

Si el dibujo hace difícil responder a cualquiera de estas preguntas, necesita menos recursos y más estructura.

Los componentes básicos

Pieza	Qué es	Cómo dibujarla
VPC	Tu red privada, con un bloque de CIDR como 10.0.0.0/16	El marco exterior, con el CIDR en la etiqueta
Zona de disponibilidad	Una ubicación aislada dentro de la región	Una columna o un marco dentro de la VPC
Subred	Un rango del CIDR de la VPC en exactamente una AZ	Un marco dentro de su AZ, con el CIDR en la etiqueta
Tabla de enrutamiento	Reglas que envían el tráfico de una subred a un destino	Una tabla pequeña por cada capa de subredes
Puerta de enlace de Internet	La puerta de la VPC hacia Internet	En el borde de la VPC, del lado de Internet
Puerta de enlace NAT	Permite que las subredes privadas inicien conexiones salientes	Zonal: dentro de una subred pública, una por AZ. Regional: una sola puerta de enlace para todas las AZ, sin subred
Punto de conexión de VPC	Un camino privado hacia los servicios de AWS	Puntos de conexión de puerta de enlace para S3 y DynamoDB; puntos de conexión de interfaz en las subredes
Grupo de seguridad	Firewall con estado en cada interfaz de red	Reglas de puertos como etiquetas de las conexiones, no como cajas
ACL de red	Filtro sin estado en la subred	Una nota en la subred, solo si usas reglas personalizadas

Dos hechos determinan todo el layout. Una subred vive en exactamente una zona de disponibilidad, así que en tu diagrama una subred nunca puede abarcar varias columnas de AZ. Y una puerta de enlace NAT estándar (zonal) vive en una AZ: si la única está en la AZ a, las subredes privadas de la AZ b pierden el acceso saliente cuando falla la AZ a. Desde noviembre de 2025, AWS también ofrece puertas de enlace NAT regionales, que se expanden por sí solas entre las AZ y no necesitan subred pública; este ejemplo usa puertas de enlace zonales.

El ejemplo: dos AZ, tres capas

La VPC usa 10.0.0.0/16 en dos zonas de disponibilidad, con tres subredes en cada una:

Capa	AZ a	AZ b	Ruta para 0.0.0.0/0
Pública	10.0.0.0/24	10.0.1.0/24	Puerta de enlace de Internet
Aplicación (privada)	10.0.10.0/24	10.0.11.0/24	Puerta de enlace NAT de la misma AZ
Datos (privada)	10.0.20.0/24	10.0.21.0/24	Ninguna

Cada tabla de enrutamiento tiene además la ruta local para 10.0.0.0/16, que permite que las subredes de la VPC se comuniquen entre sí; después, los grupos de seguridad deciden qué se permite realmente. AWS reserva cinco direcciones en cada subred, así que un /24 te da 251 direcciones utilizables.

Qué se ejecuta dónde:

• Un Application Load Balancer tiene nodos en las dos subredes públicas y acepta HTTPS desde Internet.
• Los servidores de aplicaciones (instancias EC2 o tareas de ECS) se ejecutan en las dos subredes de aplicación y solo aceptan tráfico del grupo de seguridad del ALB.
• Una instancia principal de RDS PostgreSQL se ejecuta en una subred de datos, con una instancia en espera en la otra. RDS exige un grupo de subredes de base de datos con subredes en al menos dos AZ.
• Una puerta de enlace NAT en cada subred pública da a los servidores de aplicaciones acceso saliente para actualizaciones y API de terceros.
• Un punto de conexión de puerta de enlace para S3 permite que los servidores de aplicaciones lleguen a S3 sin pasar por la puerta de enlace NAT, lo que además ahorra cargos de procesamiento de datos de NAT.

Este es el diagrama:

Reglas de layout para que se lea bien

Columnas para las AZ, filas para las capas

Coloca las zonas de disponibilidad una junto a otra y las capas de arriba abajo: la pública arriba, luego la de aplicación y después la de datos. Así la accesibilidad se lee de arriba abajo, y un recurso que falta en una columna se ve al instante.

Pon la puerta de enlace de Internet en el borde

La puerta de enlace de Internet se adjunta a toda la VPC, no a una subred. Dibújala sobre el marco de la VPC, entre Internet y las subredes públicas.

Muestra las rutas en una tabla, no con flechas a todas partes

Una flecha de cada subred a cada puerta de enlace convierte el diagrama en una telaraña. Una tabla de enrutamiento pequeña por capa, como la de arriba, dice lo mismo con precisión. Dibuja flechas solo para los flujos de tráfico principales.

Pon las reglas de los grupos de seguridad en las conexiones

Los grupos de seguridad pertenecen a las interfaces de red, no a las subredes, así que los marcos no son la forma adecuada para representarlos. En su lugar, etiqueta las conexiones: HTTPS 443 from internet, 8080 from ALB SG, 5432 from app SG. Esa es la información que la gente busca.

Deja las interconexiones y la VPN en el borde

Las puertas de enlace de tránsito, las interconexiones de VPC y las VPN de sitio a sitio conectan la VPC con otras redes. Dibújalas en el borde de la VPC, con los CIDR remotos en la etiqueta, y deja el lado remoto en su propio diagrama.

Errores comunes

• Una subred que abarca dos AZ. No puede existir. Dibuja una subred por AZ, aunque sean gemelas.
• Una sola puerta de enlace NAT zonal para las dos AZ, sin indicarlo. Puede ser una decisión deliberada para ahorrar; escríbela en el diagrama para que nadie dé por hecho que las zonas son independientes.
• Grupos de seguridad dibujados como cajas anidadas. Se superponen libremente y se aplican por interfaz; anidarlos sugiere reglas que no existen.
• Copiar el mapa de recursos de la consola con cada interfaz de red y cada asociación de tabla de enrutamiento. Útil para auditorías, ilegible para diseñar.
• Sin CIDR. Los rangos que se solapan son los que bloquean la interconexión más adelante. Pon el CIDR en cada marco de VPC y de subred.

Constrúyelo en Archboard

1. Inicia sesión con Google o GitHub y crea un diagrama.
2. Desde el pack Red, añade un marco VPC y establece su CIDR en 10.0.0.0/16.
3. Dentro, añade elementos Marco del pack Básico para las dos AZ y, dentro de cada AZ, marcos Subred del pack Red con sus CIDR.
4. Añade un nodo Internet del pack Red fuera de la VPC y un Enrutador en el borde de la VPC para la puerta de enlace de Internet.
5. Añade del pack Nube un Balanceador de carga en la nube para el ALB, nodos Instancia de cómputo para los servidores de aplicaciones y nodos Base de datos administrada para las instancias principal y en espera de RDS. Usa nodos Enrutador del pack Red para las puertas de enlace NAT.
6. Conecta los puertos y etiqueta las conexiones con los puertos y los grupos de seguridad de origen.
7. Añade una Tabla del pack Básico con las tablas de enrutamiento y una Nota para decisiones como una puerta de enlace NAT por AZ.

El ejemplo completo usa más de los 15 nodos de diagrama del plan Free, así que un diagrama de VPC tan detallado encaja bien con Pro. Para diseños multirregión, consulta el diagrama de arquitectura multirregión de AWS y, para más patrones de red, la página del caso de uso de redes.

Preguntas frecuentes

¿Debe aparecer cada subred en el diagrama? En el diagrama de diseño de la VPC, sí, porque la accesibilidad depende de la subred y de la tabla de enrutamiento. En un diagrama de aplicación suele bastar con un marco por capa.

¿Necesito una puerta de enlace NAT en cada AZ? Con puertas de enlace NAT zonales, sí, para que las zonas sean independientes. Una sola puerta de enlace NAT zonal ahorra dinero, pero hace que todas las AZ dependan de una zona para el tráfico saliente y añade cargos por transferencia de datos entre AZ. Una puerta de enlace NAT regional es una única puerta de enlace que se expande a cada AZ con cargas de trabajo. Elijas lo que elijas, escríbelo en el diagrama.

¿Dónde van los puntos de conexión de VPC? Los puntos de conexión de puerta de enlace (S3 y DynamoDB) son destinos en las tablas de enrutamiento, así que dibújalos en el borde de la VPC y menciónalos en la tabla de enrutamiento. Los puntos de conexión de interfaz son interfaces de red en tus subredes, así que dibújalos dentro de las subredes que los alojan.

¿Grupos de seguridad o ACL de red en el diagrama? Los grupos de seguridad, siempre como etiquetas de las conexiones. Las ACL de red, solo como nota en la subred y solo si cambiaste los valores predeterminados.

¿Puedo generar esto desde mi cuenta de AWS? Archboard no lee tu cuenta de AWS. Dibuja el diseño que buscas y compáralo con el mapa de recursos de la consola durante las revisiones.

Empieza gratis — un puesto, sin tarjeta de crédito.