Reyan's Cloudy Thoughts
Accueil Articles À propos de moi
Reyan's Cloudy Thoughts

Contenu

Comment j'ai automatisé la création de mes diagrammes AWS avec Claude Desktop et Draw.io

   1954 mots   10 minutes 
/images/drawio-aws-diagrams/featuredImage.png

Créer des diagrammes d’architecture AWS, peut vite devenir chronophage… ⏱️

Entre la recherche des bonnes icônes officielles, l’alignement des éléments, la gestion des chevauchements, le respect des conventions de nommage et de couleurs… on peut facilement passer plusieurs heures sur un diagramme complexe.

J’avais déjà testé plusieurs approches, dont notamment des outils comme AWS Diagram MCP Server. Le souci pour moi est que cela ne permet pas de modifier a posteriori le diagramme généré via une interface. Il faut pour cela faire un nouveau prompt et relancer une génération. De plus, l’esthétique laisse à désirer selon moi.

Dans la majorité des entreprises avec lesquelles je travaille, la norme est de réaliser les diagrammes avec l’outil Draw.io, avec la possibilité d’intégrer les icônes officielles d’AWS via l’installation d’une librairie.

C’est pourquoi j’ai cherché un moyen de générer des diagrammes AWS avec Draw.io en utilisant un LLM. En soulevant le capot de l’outil, j’ai constaté que Draw.io utilise du XML en backend. Chaque icône, chaque groupe, chaque connexion est défini par une structure XML spécifique.

Je me suis donc posé la question : Au lieu de manipuler manuellement une interface graphique, pourquoi ne pas demander à Claude de générer directement ce XML en se basant sur des références structurées?

C’est exactement ce que j’ai mis en place en utilisant la fonctionnalité de projet sur Claude Desktop. Et le résultat ? Des diagrammes assez complets générés en quelques secondes 🚀

Comment fonctionne un projet Claude

Pour ceux qui ne connaissent pas, Claude Desktop permet de créer des projets (on peut les assimiler en quelque sorte à des agents IA) avec :

  • Des instructions personnalisées qui définissent le comportement de Claude ⚙️
  • Des fichiers de référence que Claude consulte systématiquement 📄
  • Un contexte qui persiste entre les conversations 💾 (Mémoire)

Les fichiers de références

J’ai structuré mon projet autour de 4 fichiers markdown qui servent de références à Claude :

1. aws-icons-reference.md 📚

Un fichier qui référence les icônes de plus de 150 services AWS avec leurs configurations XML exactes. J’ai réussi à le générer grâce à Claude en lui demandant d’analyser plusieurs diagrammes AWS draw.io que j’ai conçus et en lui faisant consulter :

  • La bibliothèque d’icônes AWS officielle sur draw.io
  • Les conventions de style AWS Architecture Icons 4.0
  • Les palettes de couleurs officielles AWS par catégorie de service

À la fin, je récupère un fichier en markdown qui, pour chaque service, inclut :

  • Le nom exact de l’icône
  • Les couleurs officielles AWS (fill + gradient)
  • Le template XML complet
  • La catégorie (Compute, Database, Networking…)
## Lambda
resIcon=mxgraph.aws4.lambda
fillColor=#D05C17
gradientColor=#F78E04

## Aurora
resIcon=mxgraph.aws4.aurora
fillColor=#3334B9
gradientColor=#4D72F3

2. aws-groups-reference.md 🏗️

De la même manière, j’ai généré un fichier de références pour tous les conteneurs et groupements :

<mxCell id="vpc" value="VPC (10.0.0.0/16)" 
  style="shape=mxgraph.aws4.group;grIcon=mxgraph.aws4.group_vpc;
  strokeColor=#248814;fillColor=none;..." 
  vertex="1" parent="region">
  <mxGeometry x="20" y="120" width="1420" height="920"/>
</mxCell>

Avec tous les styles pour :

  • AWS Cloud boundary
  • Regions
  • VPCs avec CIDR
  • Availability Zones
  • Public/Private Subnets
  • Security Groups
  • EKS/ECS Clusters…

3. aws-connections-reference.md 🔗

Un autre fichier avec les styles standardisés pour chaque type de connexion, avec un code couleur par catégorie :

- Compute: #FF9900 (Orange)
- Database: #3B48CC (Blue)
- Networking: #8C4FFF (Purple)
- Security: #DD3522 (Red)
- Storage: #277116 (Green)

## Primary Data Flow (Solid)
strokeColor=#232F3E
strokeWidth=2

## Async/Event Flow (Dotted)
strokeColor=#BC1356
strokeWidth=1
dashPattern=2 2

4. kubernetes-icons-reference.md ☸️

Travaillant sur des architectures Kubernetes, j’ai également généré un fichier avec tous les composants Kubernetes, incluant pods, deployments, services, ingress, configmaps, etc.

## Pod
prIcon=pod
fillColor=#326CE5

## Deployment
prIcon=deploy
fillColor=#326CE5

Les instructions

Les fichiers de référence, permettent à l’agent de connaître les références xml des icônes, groupes, liens. Mais il faut aussi dire à Claude comment les utiliser. Voici la structure de mes instructions que j’ai affinées au fur et à mesure de mes interactions avec l’agent avec du prompt engineering.

1. Workflow de génération du diagramme

Je spécifie ici à l’agent, la méthodologie à adopter: analyser la requête de l’utilisateur qui peut être une description ou une image, pour ensuite identifier les différents composants à construire sur le diagramme.

Puis de générer le diagramme en prenant bien en compte les fichiers qui contiennent les références des icônes, groupes, liens.

Enfin, quel est le format du fichier qui doit être généré en sortie.

#### 1. Analyze User Request

When the user provides an architecture description or image:

- Identify all mentioned AWS services and Kubernetes components
- Map logical groupings (VPCs, subnets, clusters, namespaces)
- Identify data flows and connections
- Note all necessary labels or annotations

#### 2. Generate the Diagram

Use reference files to:

- Select correct icon styles from `aws-icons-reference.md` for AWS and `kubernetes-icons-reference.md` for Kubernetes
- Apply correct group containers from `aws-groups-reference.md` for AWS and `kubernetes-icons-reference.md` for Kubernetes
- Create connections with appropriate style from `aws-connections-reference.md`

#### 3. Output Format

Always generate a complete `.drawio` XML file that can be:

- Opened directly in app.diagrams.net
- Imported into draw.io desktop
- Edited and customized by the user

2. Principes clés à suivre

Ici, on définit les principes que l’agent doit respecter pour la génération du diagramme :

  • Convention de nommage des icônes : comment l’agent doit respecter les règles de nommage pour identifier correctement chaque icône de service AWS
#### Icon Naming Convention

All AWS icons use the format: `mxgraph.aws4.[service_name]`

**Resource icons:**

```xml
shape=mxgraph.aws4.resourceIcon;resIcon=mxgraph.aws4.[service]
```xml

**Service icons:**

```xml
shape=mxgraph.aws4.[service]
```xml
  • Codes couleur par catégorie : quelle couleur utiliser pour chaque catégorie de services (compute, storage, networking, etc.)
#### Official AWS Color Palette

| Category | Fill Color | Gradient Color |
|----------|------------|----------------|
| Compute (Orange) | #D05C17 | #F78E04 |
| Database (Blue) | #3334B9 | #4D72F3 |
| Networking (Purple) | #5A30B5 | #945DF2 |
| Security (Red) | #DD3522 | #FF5757 |
| Storage (Green) | #277116 | #60A337 |
| Management (Pink) | #BC1356 | #F34482 |
| Analytics (Purple) | #4D27AA | #A166FF |
  • Représentation des conteneurs et groupes : comment représenter visuellement les VPC, régions, availability zones et autres regroupements logiques
#### Group Containers

**CORRECT VPC Style:**

```xml
<mxCell id="vpc" value="VPC (10.0.0.0/16)" 
  style="points=[[0,0],[0.25,0],[0.5,0],[0.75,0],[1,0],[1,0.25],[1,0.5],[1,0.75],[1,1],[0.75,1],[0.5,1],[0.25,1],[0,1],[0,0.75],[0,0.5],[0,0.25]];outlineConnect=0;gradientColor=none;html=1;whiteSpace=wrap;fontSize=12;fontStyle=0;container=1;pointerEvents=0;collapsible=0;recursiveResize=0;shape=mxgraph.aws4.group;grIcon=mxgraph.aws4.group_vpc;strokeColor=#248814;fillColor=none;verticalAlign=top;align=left;spacingLeft=30;fontColor=#AAB7B8;dashed=0;" 
  vertex="1" parent="region">
  <mxGeometry x="20" y="120" width="1420" height="920" as="geometry"/>
</mxCell>
```xml

Use appropriate styles for:

- AWS Cloud boundary
- Region
- VPC with CIDR
- Availability Zone
- Public/Private Subnets
- Security Groups
- EKS/ECS Clusters
- Namespaces
- Pods/Deployments/Services
  • Styles de connexion : les différents types de liens et flèches à utiliser, ainsi que leur coloration en fonction des services auxquels ils sont rattachés
#### Connection Styles

**Primary Data Flow (Solid):**

```xml
style="edgeStyle=orthogonalEdgeStyle;rounded=0;orthogonalLoop=1;jettySize=auto;html=1;strokeColor=#232F3E;strokeWidth=2;"
```xml

**Secondary/Optional Flow (Dashed):**

```xml
style="edgeStyle=orthogonalEdgeStyle;rounded=0;orthogonalLoop=1;jettySize=auto;html=1;strokeColor=#232F3E;strokeWidth=1;dashed=1;dashPattern=5 5;"
```xml

**Async/Event Flow (Dotted):**

```xml
style="edgeStyle=orthogonalEdgeStyle;rounded=0;orthogonalLoop=1;jettySize=auto;html=1;strokeColor=#BC1356;strokeWidth=1;dashed=1;dashPattern=2 2;"
```xml

#### Color-Coded Connections by Service Category

| Service Type | Connection Color |
|----------------|---------------------|
| Compute | #FF9900 (Orange) |
| Database | #3B48CC (Blue) |
| Networking | #8C4FFF (Purple) |
| Security | #DD3522 (Red) |
| Storage | #277116 (Green) |
| Management/Monitoring | #BC1356 (Pink) |
| Integration/Messaging | #C925D1 (Magenta) |

Une dernière checklist

Pour finir, on définit une checklist que l’agent doit suivre et s’assurer avant de livrer :

  • Tous les services utilisent les styles officiels
  • Pas de chevauchements visuels
  • Connexions avec le style approprié
  • Labels lisibles et bien positionnés
  • XML valide et complet
Before delivering a diagram, verify:

- ☑ All services use official AWS 4.0 and Kubernetes icon styles
- ☑ VPC style uses `grIcon=mxgraph.aws4.group_vpc` (NOT `group_vpc2`)
- ☑ Groups are properly nested (Cloud > Region > VPC > Subnet)
- ☑ Connections have appropriate style (color, thickness, line style)
- ☑ Container icons use `shape=mxgraph.aws4.container_1`
- ☑ EKS icon uses `resIcon=mxgraph.aws4.eks` with `fillColor=#ED7100`
- ☑ Labels are readable and properly positioned
- ☑ XML is valid and complete with appropriate mxfile structure
- ☑ No overlaps or superpositions between services

Quelques exemples concrets : Architecture serverless

On lui définit également des exemples de demandes auxquelles il doit répondre et ce qu’on attend en sortie :

**User Request:**

> "Create an event-driven architecture with API Gateway, Lambda functions, SQS queues, SNS topics, and DynamoDB tables."

**Expected Output:**

- ✅ AWS Cloud → Region → VPC
- ✅ API Gateway outside VPC (edge service)
- ✅ VPC with private subnets across two AZs
- ✅ Services positioned:
  - Lambda functions in private subnets
  - SQS queues
  - SNS topics
  - DynamoDB tables (shown outside VPC or with VPC endpoint)
- ✅ Connections:
  - Users → API Gateway (solid purple, strokeWidth=2)
  - API Gateway → Lambda (solid orange)
  - Lambda → SNS (dotted pink for async, dashPattern=2 2)
  - SNS → SQS (dotted pink)
  - Lambda → SQS (dotted pink for consumer pattern)
  - Lambda → DynamoDB (solid blue)
- ✅ S3 bucket for object storage with solid green connection
- ✅ All icons use correct official AWS colors per service category

Comment configurer le projet dans Claude Desktop

Tous les fichiers que je viens de présenter sont disponibles sur un projet GitHub pour que vous puissiez facilement configurer votre projet.

Installation de Claude Desktop

Si vous ne l’avez pas déjà fait, téléchargez et installez Claude Desktop depuis le site d’Anthropic.

Configuration du projet dans Claude Desktop

  1. Ouvrez Claude Desktop et cliquez sur l’icône Projects dans la barre latérale
  2. Cliquez sur le bouton New Project pour créer un nouveau projet
  3. Donnez un nom à votre projet (par exemple “AWS Diagrams Generator”) et ajoutez une description dans le champ correspondant
  4. Copiez le contenu du fichier INSTRUCTIONS.md depuis le dépôt GitHub et collez-le dans le champ Instructions du projet
  5. Ajoutez les fichiers de référence :
    • aws-icons-reference.md - Catalogue complet des icônes AWS avec leurs configurations XML
    • aws-groups-reference.md - Référence pour les conteneurs et groupes (VPC, Subnets, etc.)
    • aws-connections-reference.md - Patterns pour les styles de connexion
    • kubernetes-icons-reference.md - Catalogue des composants Kubernetes

/images/drawio-aws-diagrams/claude-project.png

Utilisation

Une fois le projet configuré, on peut simplement décrire une architecture en langage naturel :

Crée un diagramme pour une application web simple avec un Application Load Balancer,
des instances EC2 dans un Auto Scaling Group, et une base de données RDS 
dans deux zones de disponibilité.

Claude générera alors un fichier XML .drawio complet que l’on pourra :

  • Sauvegarder avec l’extension .drawio
  • Ouvrir directement dans app.diagrams.net
  • Importer dans l’application desktop draw.io
  • Modifier et personnaliser selon vos besoins

Jouons avec notre agent

Exemple 1 : Architecture serverless depuis une description

Premier type de demande : Générer un diagramme d’une architecture serverless.

/images/drawio-aws-diagrams/serverless-architecture-description-1.png

/images/drawio-aws-diagrams/serverless-architecture-description-2.png

/images/drawio-aws-diagrams/serverless-diagram.png

Exemple 2 : Architecture three-tier depuis une photo

/images/drawio-aws-diagrams/handdrawn-diagram.jpeg

/images/drawio-aws-diagrams/handdrawn-response-1.png

/images/drawio-aws-diagrams/handdrawn-response-2.png

/images/drawio-aws-diagrams/aws-architecture_4.drawio.png

On notera que l’agent a bien généré un diagramme valide, avec les icônes officielles AWS, les groupes, les connexions, les labels, etc. Même si petite hallucination sur le nom de la région, mais bon rien de bien grave :)

Conclusion

Grâce à la création de cet agent personnalisé, l’automatisation de mes diagrammes AWS me permet de gagner du temps, en particulier pour des diagrammes complexes.

Pour être transparent, le résultat n’est pas toujours parfait à 100% dès la première génération. Mais l’avantage ici, c’est que j’obtiens rapidement une structure cohérente qui respecte les conventions AWS, et il ne me reste plus qu’à peaufiner quelques détails pour arriver exactement à ce que j’avais en tête.

Plus j’utilise l’agent, plus il s’affine. Car chaque petite anomalie que je rencontre est une opportunité pour :

  • Mettre à jour les fichiers de référence ou les instructions pour éliminer l’erreur.
  • Capitaliser sur la mémoire du projet Claude qui se construit au fur et à mesure de mes interactions avec l’agent pour éviter que cette erreur ne se reproduise plus.

Ce projet me conforte dans l’idée que l’IA générative, quand elle est bien encadrée avec des règles claires et des conventions strictes, peut vraiment devenir un assistant quotidien très efficace. Je ne suis qu’au début de cette exploration, et j’ai déjà plein d’idées pour pousser le concept encore plus loin !

N’hésitez pas à me suivre sur LinkedIn pour vous tenir au courant de mes prochaines expérimentations.

Mis à jour le 2026-01-20
 aws, ai, automation, draw.io, diagrams
Retour | Accueil