Para entender mejor una infraestructura, un buen diagrama siempre es bienvenido. Pero crearlos a mano lleva tiempo: buscar los iconos correctos, posicionar los elementos, trazar las conexiones… Lo que me apasiona hoy es poder automatizar todo eso con la IA.
En este artículo les muestro que es posible usar un agente IA con el MCP Draw.io para generar automáticamente diagramas de arquitectura AWS. Uso Claude Code en mi contexto, pero este enfoque funciona con cualquier agente compatible con MCP.
El punto de partida: actualizar un esquema antiguo
Ya tenía un artículo sobre la infraestructura de este blog de 2018 con un esquema hecho manualmente en Draw.io. La infraestructura no ha cambiado mucho desde entonces: esencialmente añadí OAC (Origin Access Control) y una CloudFront Function, pero los iconos de AWS han evolucionado y quería actualizar el esquema con las versiones más recientes.
Buscando soluciones para automatizar esto, encontré el Servidor Draw.io MCP con su extensión para Chrome. Lo probé… y me pareció tan genial que decidí escribir un artículo para compartir la información.
El MCP Draw.io: controlar Draw.io con la IA
El Servidor Draw.io MCP creado por Ladislav (lgazo) es un servidor MCP (Model Context Protocol) que permite controlar Draw.io programáticamente. En la práctica, eso significa que un agente IA puede crear, modificar y organizar elementos en un diagrama de Draw.io.
Las herramientas disponibles
| Categoría | Herramientas | Uso |
|---|---|---|
| Inspección | get-selected-cell, list-paged-model | Leer el estado del lienzo |
| Creación | add-rectangle, add-edge, add-cell-of-shape | Añadir elementos |
| Modificación | edit-cell, edit-edge, set-cell-data | Modificar elementos existentes |
| Biblioteca | get-shape-categories, get-shapes-in-category | Explorar las formas disponibles |
Configuración requerida
Para que el agente IA pueda comunicarse con Draw.io, hay que configurar dos elementos como se indica en la documentación del proyecto:
- Un servidor MCP local — configurado en el archivo de settings de tu agente (ej.:
.mcp.jsonpara Claude Code) - La extensión Chrome Draw.io MCP — que hace el puente entre el servidor MCP y la aplicación Draw.io en el navegador
Una vez estos dos elementos estén en su sitio, el agente puede manipular directamente el canvas de Draw.io: crear shapes, posicionarlas, trazar conexiones, todo de forma programática.
Al probar el MCP Draw.io, constaté que hay que guiar al agente para obtener un resultado limpio: no inventar recursos, usar los iconos AWS correctos, respetar un posicionamiento coherente, aplicar colores por categoría, evitar HTML en los textos… Por eso creé un skill Claude Code que codifica estas reglas.
Creación del skill /aws-diagram
Un skill de Claude Code es un archivo Markdown que define un flujo de trabajo y reglas. Cuando se invoca /aws-diagram, Claude Code carga esas instrucciones y las aplica automáticamente.
El flujo de trabajo
El skill sigue un proceso en 4 pasos:
- Leer el código de infraestructura (Terraform, CloudFormation)
- Extraer los recursos AWS y sus relaciones
- Construir el diagrama con los iconos oficiales de AWS
- Añadir las conexiones con etiquetas descriptivas
📄 Extracto del skill: Workflow
## Workflow
1. **Read infrastructure code** (Terraform, CloudFormation, etc.)
2. **Extract AWS resources** and their relationships
3. **Build diagram** with official AWS icons
4. **Add connections** with descriptive labels Las reglas críticas
Tuve que codificar varias reglas importantes dentro del skill:
1. Nunca inventar recursos
Ese era el principal riesgo. Los LLMs tienden a “completar” lo que les parece lógico. “Hay CloudFront, entonces debería haber Lambda@Edge para…” — ¡No! El diagrama debe representar exactamente lo que existe en el código, nada más.
📄 Extracto del skill: Nunca inventar
### NEVER invent resources
**Only diagram what actually exists in the infrastructure code.**
| Situation | Wrong | Correct |
| -------------------------- | --------------------------------------------- | -------------------------------------------- |
| No Lambda in Terraform | Add Lambda@Edge because "it would make sense" | Don't add Lambda |
| CloudFront Function exists | Use Lambda icon | Use CloudFront icon with "CF Function" label |
| No WAF configured | Add WAF for "security" | Don't add WAF | 2. Los usuarios son externos
Los “Users” no son recursos de AWS. Deben aparecer fuera del grupo Cloud de AWS.
📄 Extracto del skill: Usuarios externos
### Users OUTSIDE the AWS Cloud
**Users are NOT AWS resources.** They represent external actors.
WRONG:
┌─────────────────────────────────┐
│ AWS Cloud │
│ [Users] → [Route53] → [CF] │ ❌ Users inside cloud
└─────────────────────────────────┘
CORRECT:
[Users] → ┌─────────────────────────┐
│ AWS Cloud │
│ [Route53] → [CF] → [S3] │ ✅ Users outside
└─────────────────────────┘ 3. No usar HTML en los textos
Draw.io no renderiza HTML. Si escribes text: "S3<br>Private", verás literalmente <br> en el diagrama.
📄 Extracto del skill: Sin HTML
### NEVER use HTML in text parameters
Draw.io does NOT render HTML tags in text fields. They display as raw text.
**FORBIDDEN (will show ugly raw HTML):**
text: "S3 Bucket<br>Private" ❌ Shows "<br>" literally
text: "Route 53 DNS" ❌ Shows " " literally
text: "<font color='red'>ACM</font>" ❌ Shows raw HTML tags
**CORRECT (clean text):**
text: "S3 Bucket" ✅ Single line, clean
text: "Route 53" ✅ Service name only
text: "ACM" ✅ Simple label 4. Planificar el layout para evitar colisiones
Los edges que se cruzan hacen el diagrama ilegible. El skill recomienda colocar el flujo principal en una línea horizontal, y los servicios auxiliares arriba o abajo.
📄 Extracto del skill: Layout y colisiones
### Rule 1: Main Flow on a Horizontal Line
Place the primary data flow (request path) on a single horizontal row:
[Entry] → [Service A] → [Service B] → [Service C]
y=300 y=300 y=300 y=300
### Rule 2: Auxiliary Services Above or Below
Services that connect TO a main service (not part of the flow) go above or below:
[Auth] [Edge Logic] ← Auxiliary row (y=150)
\ /
\ /
↓ ↓
[Entry] → [Gateway] → [Compute] → [Storage] ← Main flow (y=300) 5. Anotaciones a la derecha, no debajo
Los iconos AWS tienen su etiqueta colocada automáticamente debajo. Si añades anotaciones debajo también, se superpondrán con la línea siguiente. Colócalas a la derecha del icono.
📄 Extracto del skill: Colocación de anotaciones
### Annotation Placement Rules
**CRITICAL: Place annotations to the RIGHT of icons, not below.**
**WRONG - Annotations below icons:**
[CloudFront] [S3]
|
"Cache Policies" ← Overlaps with next row!
"Security Headers"
|
[CloudFront Preview] ← Collision!
**CORRECT - Annotations to the RIGHT:**
[CloudFront] ── "Cache Policies: HTML 0s | Assets 1y"
| "Security: CSP | HSTS"
↓
[CloudFront Preview] ← No collision El sistema de colores
Definí una paleta coherente con las convenciones de AWS:
| Categoría | Color | Servicios |
|---|---|---|
| Networking | #8C4FFF (violeta) | Route53, CloudFront, VPC |
| Storage | #7AA116 (verde) | S3, EFS |
| Security | #DD344C (rojo) | ACM, IAM, WAF |
| Compute | #ED7100 (naranja) | Lambda, EC2 |
Para los flujos de datos, uso colores por entorno:
- Producción : verde
#4CAF50 - Preview : naranja
#FF9800 - Configuración : gris
#AAAAAA(dashed)
📄 Extracto del skill: Colores y estilos
### Colors by Category
| Category | Color | Services |
| -------------- | ------------------- | ------------------------------------------ |
| **Networking** | `#8C4FFF` (violet) | Route53, CloudFront, VPC, ELB, API Gateway |
| **Compute** | `#ED7100` (orange) | Lambda, EC2, ECS, Fargate |
| **Storage** | `#7AA116` (green) | S3, EFS, EBS |
| **Database** | `#C925D1` (magenta) | RDS, DynamoDB, ElastiCache |
| **Security** | `#DD344C` (red) | ACM, IAM, WAF, Cognito |
| **General** | `#232F3D` (gray) | Users, Generic |
### AWS Icon Style Template
sketch=0;outlineConnect=0;fontColor=#232F3E;fillColor=<COLOR>;strokeColor=#ffffff;
dashed=0;verticalLabelPosition=bottom;verticalAlign=top;align=center;html=1;
fontSize=12;fontStyle=0;aspect=fixed;shape=mxgraph.aws4.resourceIcon;
resIcon=mxgraph.aws4.<SERVICE>;
### Edge Colors by Environment
| Environment | Color | Usage |
| ------------- | --------- | ---------------------- |
| Production | `#4CAF50` | Main production flow |
| Preview | `#FF9800` | Staging environments |
| Configuration | `#AAAAAA` | Dashed, non-data links | Aplicación concreta: la infraestructura jls42.org
Para probar el skill, lo utilicé en la infraestructura de este blog.
El código Terraform analizado
terraform/
├── cloudfront-astro.tf # Distribution CloudFront prod
├── s3-astro.tf # Bucket S3 privé avec OAC
├── acm-astro.tf # Certificat SSL
├── route53.tf # DNS
└── variables.tf # Variables
La arquitectura extraída
| Componente | Servicio AWS | Configuración |
|---|---|---|
| DNS | Route 53 | Zona jls42.org, 3 dominios |
| CDN | CloudFront | OAC, CF Function, políticas de cache |
| Storage | S3 | Bucket privado, AES256, solo OAC |
| TLS | ACM | Certificado us-east-1, validación DNS |
El diagrama generado
Aquí está el resultado final:
A partir de un simple prompt en lenguaje natural:
«Analyse en profondeur l’infrastructure de ce projet puis réalise un super schéma de l’architecture AWS comme un pro. Juste l’infra de prod, pas preview ni legacy.»
🇪🇸 «Analiza en profundidad la infraestructura de este proyecto y luego realiza un gran diagrama de la arquitectura AWS como un profesional. Solo la infra de prod, no preview ni legacy.»
Claude Code primero analizó los archivos Terraform para identificar la infraestructura, luego cargó el skill /aws-diagram cuyas instrucciones permitieron:
- Crear los componentes principales (Users, Route53, CloudFront, S3, ACM)
- Añadir las anotaciones detalladas (políticas de cache, encabezados de seguridad, configuración de buckets…)
- Trazar las conexiones con etiquetas (HTTPS, Alias DNS, OAC, certificado TLS…)
- Añadir los servicios externos (Plausible Analytics, Gandi para los emails)
- Generar una leyenda por categoría
Todo respetando un layout limpio con:
- El cloud de AWS dimensionado automáticamente (900×420px)
- Los Users a la izquierda del cloud
- Los servicios externos a la derecha
- Una leyenda debajo del diagrama
El flujo completo: de Terraform al video
Llevé la experiencia más allá creando un video de demostración.
Grabación
Grabé la generación del diagrama en tiempo real: 4 minutos 10 segundos de Claude Code leyendo el Terraform, creando los elementos uno a uno y construyendo el diagrama ante mis ojos.
Postproducción con FFmpeg
4 minutos es largo para una demo. Usé FFmpeg para crear una versión acelerada con velocidades variables:
| Segmento | Contenido | Velocidad |
|---|---|---|
| 0:00-0:10 | Petición a Claude para generar el diagrama | 1x |
| 0:10-0:32 | Análisis del código Terraform | 15x |
| 0:32-0:35 | Skill /aws-diagram detectado y lanzado automáticamente | 1x |
| 0:35-3:46 | Generación del diagrama en el navegador | 15x |
| 3:46-3:56 | Reposicionamiento de las etiquetas para mejor visual | 1x |
Resultado: un video de 42 segundos en lugar de 4 minutos, manteniendo los momentos clave a velocidad normal.
Narración con HeyGen
Para añadir una voz en off, escribí un guion de narración, dividí el video en segmentos de 30 segundos (límite de HeyGen) y generé la voz en francés. Las voces base no me convencieron, así que usé su función de diseño vocal que permite crear una voz a vuelo ajustando un prompt hasta encontrar el tono perfecto.
El resultado final es el video que puedes ver al inicio de este artículo.
Segundo ejemplo: Arquitectura EKS Alta Disponibilidad
Para ilustrar lo bien que funciona el MCP Draw.io, aquí hay un segundo ejemplo más complejo: una arquitectura EKS (Elastic Kubernetes Service) altamente disponible. El MCP hace todo el trabajo de creación en Draw.io — yo solo tuve que proporcionar un prompt detallado.
Esta vez proporcioné un prompt detallado describiendo la arquitectura deseada:
📋 Prompt completo para la arquitectura EKS
Architecture EKS Hautement Disponible
Génère un diagramme d'architecture AWS EKS avec les composants suivants :
## Services AWS à inclure
### Externes (gauche du cloud)
- Users (icône utilisateurs générique)
### Networking
- Route 53 (DNS)
- Application Load Balancer (ALB) - dans les subnets publics
- NAT Gateway (3x, un par AZ)
- VPC avec 3 AZ
### Compute (subnets privés)
- EKS Control Plane (géré par AWS - représenter séparément)
- 3 Node Groups (un par AZ) avec pods à l'intérieur
### Storage
- EFS (stockage partagé cross-AZ)
### Security
- ACM (Certificate Manager)
- IAM (pour Pod Identity / IRSA)
### Observability
- CloudWatch (logs et métriques)
## Connexions à tracer
| Source | Target | Label | Style |
| ----------------- | ----------- | ------------------- | ----------- |
| Users | Route 53 | HTTPS | Solid green |
| Route 53 | ALB | DNS Alias | Solid green |
| ALB | Node Groups | Traffic | Solid green |
| ACM | ALB | TLS | Dashed gray |
| Node Groups | EFS | NFS Mount | Solid green |
| EKS Control Plane | Node Groups | kubectl API | Solid green |
| EKS Control Plane | IAM | IRSA / Pod Identity | Dashed gray |
| Node Groups | CloudWatch | Logs / Metrics | Dashed gray | El resultado generado
Este diagrama ilustra una arquitectura Kubernetes lista para producción con:
- 3 Availability Zones para alta disponibilidad
- NAT Gateways redundantes (uno por AZ) para la salida a Internet
- Node Groups distribuidos con pods en cada AZ
- EFS cross-AZ para almacenamiento compartido persistente
- Control Plane gestionado por AWS separado visualmente
- IRSA (IAM Roles for Service Accounts) para la seguridad de los pods
El MCP Draw.io interpretó correctamente la estructura creando los grupos VPC y AZ, posicionando las NAT Gateways en los subnets públicos y los Node Groups en los subnets privados. El resultado ofrece una excelente base de trabajo para pulir luego según preferencias visuales, o corregir posibles errores — mucho más rápido que empezar desde cero.
Lo que revela este proyecto
Esta experiencia ilustra varios aspectos de mi forma de trabajar:
- Automatizar la documentación: el código es la fuente de verdad, el diagrama debería derivar automáticamente de él
- Usar las herramientas adecuadas: el MCP Draw.io fue exactamente lo que necesitaba, no reinventé la rueda
- Codificar las reglas: los skills permiten capturar la experiencia y evitar errores comunes — aplicable a cualquier tipo de diagrama Draw.io, no solo AWS
- Probar con casos reales: usé mi propia infraestructura como campo de experimentación
- Ir más allá: desde la generación automática hasta el video narrado, cada paso fue una oportunidad para aprender
El skill ahora está integrado en mi flujo de trabajo. La próxima vez que modifique la infraestructura, podré regenerar el diagrama con un simple prompt.
Recursos
- Servidor Draw.io MCP por Ladislav (lgazo)
- MCP - Protocolo de Contexto de Modelo por Anthropic
- Claude Code — la herramienta CLI que uso a diario
Si utilizas un agente de codificación compatible con MCP y tienes infraestructuras que documentar, te animo a probar este enfoque. Es satisfactorio ver un diagrama limpio construirse automáticamente ante tus ojos.
Gracias por leer, ¡espero que este artículo te haya dado ganas de experimentar!
Este documento ha sido traducido de la versión fr a la lengua es utilizando el modelo gpt-5-mini. Para más información sobre el proceso de traducción, consulte https://gitlab.com/jls42/ai-powered-markdown-translator