Deep Dive : AWS-Diagramme mit einem KI-Agenten und Draw.io MCP erzeugen

Um in einer Infrastruktur den Überblick zu behalten, ist ein gutes Schaubild immer willkommen. Aber sie von Hand zu erstellen kostet Zeit: die richtigen Icons finden, die Elemente positionieren, die Verbindungen zeichnen… Was mich heute begeistert, ist die Möglichkeit, all das mit KI zu automatisieren.

In diesem Artikel zeige ich, dass es möglich ist, einen KI-Agenten mit dem Draw.io MCP zu verwenden, um automatisch AWS-Architekturdiagramme zu erzeugen. Ich nutze Claude Code in meinem Kontext, aber dieser Ansatz funktioniert mit jedem MCP-kompatiblen Agenten.

Ausgangspunkt : ein altes Schaubild aktualisieren

Ich hatte bereits einen Artikel zur Infrastruktur dieses Blogs aus dem Jahr 2018 mit einem manuell erstellten Diagramm in Draw.io. Die Infrastruktur hat sich nicht enorm verändert — ich habe im Wesentlichen OAC (Origin Access Control) und eine CloudFront Function hinzugefügt — aber die AWS-Icons haben sich weiterentwickelt und ich wollte das Diagramm mit den neuesten Versionen aktualisieren.

Auf der Suche nach Automatisierungslösungen bin ich auf den Draw.io MCP Server mit seiner Chrome-Erweiterung gestoßen. Ich habe es ausprobiert… und fand es so cool, dass ich beschlossen habe, einen Artikel darüber zu schreiben und die Info zu teilen!

Das MCP Draw.io : Draw.io mit KI steuern

Der Draw.io MCP Server, erstellt von Ladislav (lgazo), ist ein MCP-Server (Model Context Protocol), der es ermöglicht, Draw.io programmatisch zu steuern. Konkret bedeutet das, dass ein KI-Agent Elemente in einem Draw.io-Diagramm erstellen, ändern und organisieren kann.

Verfügbare Tools

Voraussetzungen

Damit der KI-Agent mit Draw.io kommunizieren kann, müssen zwei Elemente wie in der Projektdokumentation angegeben konfiguriert werden:

1. Einen lokalen MCP-Server — konfiguriert in der Settings-Datei Ihres Agenten (z. B. .mcp.json für Claude Code)
2. Die Chrome-Erweiterung Draw.io MCP — die die Brücke zwischen dem MCP-Server und der Draw.io-Anwendung im Browser bildet

Sobald diese beiden Elemente eingerichtet sind, kann der Agent den Draw.io-Canvas direkt manipulieren: Shapes erstellen, positionieren, Verbindungen zeichnen — alles programmatisch.

Beim Testen des MCP Draw.io habe ich festgestellt, dass man den Agenten anleiten muss, um ein sauberes Ergebnis zu erhalten: keine Ressourcen erfinden, die richtigen AWS-Icons verwenden, eine konsistente Positionierung einhalten, Farben nach Kategorie anwenden, HTML in Texten vermeiden… Daher habe ich ein Claude Code Skill erstellt, das diese Regeln kodiert.

Erstellung des Skills /aws-diagram

Ein Claude Code Skill ist eine Markdown-Datei, die einen Workflow und Regeln definiert. Wenn man /aws-diagram aufruft, lädt Claude Code diese Instruktionen und wendet sie automatisch an.

Der Workflow

Der Skill folgt einem 4-Schritte-Prozess:

1. Den Infrastrukturcode lesen (Terraform, CloudFormation)
2. AWS-Ressourcen und ihre Beziehungen extrahieren
3. Das Diagramm erstellen mit den offiziellen AWS-Icons
4. Die Verbindungen hinzufügen mit beschreibenden Labels

## 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

Die kritischen Regeln

Ich musste mehrere wichtige Regeln im Skill verankern:

1. Niemals Ressourcen erfinden

Das war die größte Falle. LLMs neigen dazu, das zu “ergänzen”, was logisch erscheint. „Da ist CloudFront, also sollte es Lambda@Edge geben…“ — Nein! Das Diagramm muss exakt das darstellen, was im Code vorhanden ist, nicht mehr.

### 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. Die Nutzer sind extern

Die “Users” sind keine AWS-Ressourcen. Sie müssen außerhalb der AWS-Cloud-Gruppe erscheinen.

### 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. Kein HTML in Texten

Draw.io rendert kein HTML. Wenn Sie text: "S3<br>Private" schreiben, werden Sie buchstäblich <br> im Diagramm sehen.

### 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. Layout planen, um Kollisionen zu vermeiden

Sich kreuzende Kanten machen das Diagramm unlesbar. Der Skill empfiehlt, den Hauptfluss auf einer horizontalen Linie zu platzieren und Hilfsdienste darüber oder darunter.

### 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. Anmerkungen rechts, nicht darunter

AWS-Icons haben ihr Label automatisch unterhalb. Wenn Sie Anmerkungen ebenfalls darunter platzieren, überlappen sie die nächste Zeile. Platzieren Sie sie rechts neben dem Icon.

### 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

Das Farbsystem

Ich habe eine konsistente Palette gemäß den AWS-Konventionen definiert:

Für Datenflüsse nutze ich Umgebungsfarben:

• Production : grün #4CAF50
• Preview : orange #FF9800
• Configuration : grau #AAAAAA (gestrichelt)

### 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 |

Konkrete Anwendung : die Infrastruktur jls42.org

Um den Skill zu testen, habe ich ihn auf der Infrastruktur dieses Blogs angewendet.

Der analysierte Terraform-Code

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

Die extrahierte Architektur

Das generierte Diagramm

Hier ist das Endergebnis:

Ausgehend von einem einfachen Prompt in natürlicher Sprache:

«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.»

🇩🇪 «Analysiere die Infrastruktur dieses Projekts gründlich und erstelle dann ein professionelles Schaubild der AWS-Architektur. Nur die Produktions-Infrastruktur, keine Preview oder Legacy.»

Claude Code hat zunächst die Terraform-Dateien analysiert, um die Infrastruktur zu identifizieren, und dann das Skill /aws-diagram geladen, dessen Anweisungen folgendes ermöglichten:

1. Die Hauptkomponenten erstellen (Users, Route53, CloudFront, S3, ACM)
2. Detaillierte Anmerkungen hinzufügen (Cache-Policies, Security Headers, Bucket-Config…)
3. Verbindungen mit Labels zeichnen (HTTPS, DNS Alias, OAC, TLS Cert…)
4. Externe Dienste hinzufügen (Plausible Analytics, Gandi für E-Mails)
5. Eine Legende nach Kategorien generieren

Alles unter Beachtung eines sauberen Layouts mit:

• Der AWS-Cloud automatisch dimensioniert (900×420px)
• Den Users links von der Cloud
• Den externen Diensten rechts
• Einer Legende unter dem Diagramm

Der komplette Workflow : von Terraform zum Video

Ich habe das Experiment weitergesponnen und ein Demonstrationsvideo erstellt.

Aufnahme

Ich habe die Erstellung des Diagramms in Echtzeit aufgezeichnet: 4 Minuten 10 Sekunden, in denen Claude Code das Terraform liest, die Elemente einzeln erstellt und das Diagramm vor meinen Augen aufbaut.

Postproduktion mit FFmpeg

4 Minuten sind lang für eine Demo. Ich habe FFmpeg verwendet, um eine beschleunigte Version mit variabler Geschwindigkeit zu erstellen:

Ergebnis: ein Video von 42 Sekunden statt 4 Minuten, wobei die wichtigsten Momente in normaler Geschwindigkeit bleiben.

Vertonung mit HeyGen

Um eine Sprachspur hinzuzufügen, habe ich ein Narrationsskript geschrieben, das Video in 30-Sekunden-Segmente (HeyGen-Limit) aufgeteilt und die Stimme auf Französisch generiert. Die Standardstimmen gefielen mir nicht, also habe ich deren Funktion zur Stimmgestaltung genutzt, um eine Stimme per Prompt anzupassen, bis der Ton stimmte.

Das fertige Video ist oben in diesem Artikel zu sehen.

Zweites Beispiel : hochverfügbare EKS-Architektur

Um zu zeigen, wie gut der MCP Draw.io funktioniert, hier ein zweites, komplexeres Beispiel: eine hochverfügbare EKS-Architektur. Der MCP hat die gesamte Erstellung in Draw.io übernommen — ich musste nur einen detaillierten Prompt liefern.

Diesmal habe ich einen ausführlichen Prompt geliefert, der die gewünschte Architektur beschreibt:

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 |

Das generierte Ergebnis

Dieses Diagramm zeigt eine production-ready Kubernetes-Architektur mit:

• 3 Availability Zones für hohe Verfügbarkeit
• Redundante NAT Gateways (je eine pro AZ) für den ausgehenden Traffic
• Node Groups verteilt mit Pods in jeder AZ
• EFS cross-AZ für gemeinsam genutzten persistenten Speicher
• Getrennt visuell dargestellter, AWS-managed Control Plane
• IRSA (IAM Roles for Service Accounts) zur Absicherung der Pods

Der MCP Draw.io hat die Struktur korrekt interpretiert, indem er VPC- und AZ-Gruppen erstellt, die NAT Gateways in den öffentlichen Subnets und die Node Groups in den privaten Subnets positioniert hat. Das Ergebnis bietet eine exzellente Ausgangsbasis, die man visuell weiter anpassen oder eventuelle Fehler korrigieren kann — deutlich schneller, als von Grund auf neu zu beginnen.

Was dieses Projekt zeigt

Dieses Experiment illustriert mehrere Aspekte meiner Arbeitsweise:

• Dokumentation automatisieren : Der Code ist die Quelle der Wahrheit; das Diagramm sollte automatisch daraus entstehen
• Die richtigen Werkzeuge nutzen : Der MCP Draw.io war genau das, was ich brauchte — das Rad musste nicht neu erfunden werden
• Regeln kodieren : Skills erlauben es, Expertise festzuhalten und häufige Fehler zu vermeiden — anwendbar auf jede Art von Draw.io-Diagramm, nicht nur AWS
• An echten Beispielen testen : Ich habe meine eigene Infrastruktur als Versuchsfeld genutzt
• Weiter erkunden : Von der automatischen Generierung bis zum vertonten Video — jeder Schritt war eine Lerngelegenheit

Der Skill ist jetzt in meinen Workflow integriert. Beim nächsten Infrastruktur-Änderung kann ich das Diagramm mit einem einfachen Prompt neu generieren.

Ressourcen

• Draw.io MCP Server par Ladislav (lgazo)
• MCP - Model Context Protocol par Anthropic
• Claude Code — das CLI-Tool, das ich täglich nutze

Wenn Sie einen MCP-kompatiblen Coding-Agenten nutzen und Infrastrukturen zu dokumentieren haben, empfehle ich Ihnen, diesen Ansatz auszuprobieren. Es ist sehr befriedigend, ein sauberes Diagramm automatisch vor den eigenen Augen entstehen zu sehen.

Vielen Dank fürs Lesen — ich hoffe, dieser Artikel inspiriert Sie zum Experimentieren!

Dieses Dokument wurde von der fr-Version in die Sprache en mithilfe des Modells gpt-5-mini übersetzt. Für weitere Informationen zum Übersetzungsprozess siehe https://gitlab.com/jls42/ai-powered-markdown-translator