Buscar

ia

Deep Dive : Generar diagramas AWS con un agente IA y Draw.io MCP

Deep Dive : Generar diagramas AWS con un agente IA y Draw.io MCP

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.

Generación automática de un diagrama AWS con Claude Code y Draw.io 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íaHerramientasUso
Inspecciónget-selected-cell, list-paged-modelLeer el estado del lienzo
Creaciónadd-rectangle, add-edge, add-cell-of-shapeAñadir elementos
Modificaciónedit-cell, edit-edge, set-cell-dataModificar elementos existentes
Bibliotecaget-shape-categories, get-shapes-in-categoryExplorar 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:

  1. Un servidor MCP local — configurado en el archivo de settings de tu agente (ej.: .mcp.json para Claude Code)
  2. 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:

  1. Leer el código de infraestructura (Terraform, CloudFormation)
  2. Extraer los recursos AWS y sus relaciones
  3. Construir el diagrama con los iconos oficiales de AWS
  4. 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&nbsp;DNS" ❌ Shows "&nbsp;" 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íaColorServicios
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

ComponenteServicio AWSConfiguración
DNSRoute 53Zona jls42.org, 3 dominios
CDNCloudFrontOAC, CF Function, políticas de cache
StorageS3Bucket privado, AES256, solo OAC
TLSACMCertificado us-east-1, validación DNS

El diagrama generado

Aquí está el resultado final:

Arquitectura AWS jls42.org generada automáticamente Arquitectura AWS jls42.org generada automáticamente

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:

  1. Crear los componentes principales (Users, Route53, CloudFront, S3, ACM)
  2. Añadir las anotaciones detalladas (políticas de cache, encabezados de seguridad, configuración de buckets…)
  3. Trazar las conexiones con etiquetas (HTTPS, Alias DNS, OAC, certificado TLS…)
  4. Añadir los servicios externos (Plausible Analytics, Gandi para los emails)
  5. 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:

SegmentoContenidoVelocidad
0:00-0:10Petición a Claude para generar el diagrama1x
0:10-0:32Análisis del código Terraform15x
0:32-0:35Skill /aws-diagram detectado y lanzado automáticamente1x
0:35-3:46Generación del diagrama en el navegador15x
3:46-3:56Reposicionamiento de las etiquetas para mejor visual1x

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

Arquitectura EKS Alta Disponibilidad generada automáticamente Arquitectura EKS Alta Disponibilidad generada automáticamente

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


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