La mayoría de los diagramas de AWS fallan de la misma manera: alguien suelta treinta iconos de servicios en un lienzo, los une con flechas y lo llama arquitectura. Parece muy completo y no dice casi nada, porque lo que de verdad importa en un diseño de AWS no es qué servicios usaste. Son los límites: qué es público, qué es privado, qué vive en qué zona y por dónde pasan las líneas de confianza. Si aciertas con los límites, el diagrama enseña. Si te los saltas, es decoración.
Así que construye un diagrama de AWS de fuera hacia dentro, límite a límite, y añade los servicios al final.
Empieza por los límites (región, VPC, subredes), no por los servicios
Piensa en un diagrama de AWS como un conjunto de contenedores anidados. Cada uno es un límite que el lector necesita ver:
- Región: la caja más externa. Todo vive en una (o dibujas dos para una historia multirregión).
- VPC: tu red privada dentro de la región.
- Zonas de disponibilidad: dos o tres columnas dentro de la VPC, porque así es como se dibuja la resiliencia.
- Subredes: carriles públicos y privados dentro de cada zona. Esta división es la línea más importante de todo el diagrama.
Dibuja eso primero, como rectángulos anidados, antes de colocar un solo servicio. Ahora cada recurso que añadas tiene un sitio, y su posición tiene significado: una base de datos en una subred privada dice algo que un icono flotando nunca podría decir.
Añade los servicios donde les corresponde
Solo ahora entran los servicios, y dónde los colocas es la documentación. El balanceador de carga va en la subred pública; los servidores de aplicación, en la privada; la base de datos gestionada va lo más adentro posible, privada y en varias zonas. Un almacenamiento de objetos o una CDN viven fuera de la VPC porque es ahí donde realmente están. Aquí la posición no es decoración; codifica la postura de seguridad.
En un diagrama de AWS, la posición es el argumento. Dónde está una caja dice más que el icono que lleva.
Usa iconos reconocibles, con moderación
Los iconos reales del proveedor ayudan a leer un diagrama de un vistazo: el lector localiza la base de datos, la cola o el balanceador de carga sin leer las etiquetas. Úsalos, pero no dejes que se conviertan en lo principal. Un icono claro por recurso, tamaños coherentes y mucho espacio en blanco es mejor que un mosaico denso. Los límites aportan el significado; los iconos solo aceleran el reconocimiento.
Genera el diagrama de AWS desde tu Terraform
Colocar todo esto a mano es lento y queda desactualizado en cuanto cambia la infraestructura. Si gestionas AWS con Terraform, la topología ya está descrita: la VPC, las subredes, las instancias y los servicios gestionados están todos declarados. Genera el diagrama a partir de eso, y los límites y los recursos salen de la definición real, no de tu recuerdo de ella. Después le das forma: ajustas el diseño, agrupas las capas y resaltas el borde público.
Remátalo pensando en el lector
Antes de publicarlo, haz una pasada de legibilidad. ¿La división entre público y privado es inconfundible? ¿Alguien puede seguir una petición desde internet hasta la base de datos? ¿Las zonas de disponibilidad están visiblemente separadas para que la historia de resiliencia sea evidente? Recorta todo lo que no responda a esas preguntas. Un diagrama enfocado que las responde es mejor que un inventario completo de cada recurso de la cuenta.
Dibuja los límites, coloca los servicios según su nivel de confianza, mantén los iconos discretos y genera el borrador desde Terraform para que siga siendo fiel. Ese es un diagrama de AWS que la gente usará de verdad.