Reyan's Cloudy ThoughtsHow I Automated My AWS Diagram Creation with Claude Desktop and Draw.io
Creating AWS architecture diagrams can quickly become time-consuming… ⏱️
Between searching for the right official icons, aligning elements, managing overlaps, respecting naming and color conventions… you can easily spend several hours on a complex diagram.
I had already tested several approaches, including tools like AWS Diagram MCP Server. The issue for me is that it doesn’t allow modifying the generated diagram afterward through an interface. You have to create a new prompt and regenerate. Plus, the aesthetics leave something to be desired in my opinion.
In most companies I work with, the standard is to create diagrams using Draw.io, with the ability to integrate official AWS icons through library installation.
That’s why I looked for a way to generate AWS diagrams with Draw.io using an LLM. By looking under the hood of the tool, I found that Draw.io uses XML in the backend. Each icon, each group, each connection is defined by a specific XML structure.
So I asked myself: Instead of manually manipulating a graphical interface, why not ask Claude to generate this XML directly based on structured references?
That’s exactly what I set up using the project feature in Claude Desktop. And the result? Fairly complete diagrams generated in seconds 🚀
How a Claude Project Works
For those who don’t know, Claude Desktop allows you to create projects (you can think of them as AI agents) with:
- Custom instructions that define Claude’s behavior ⚙️
- Reference files that Claude systematically consults 📄
- Context that persists between conversations 💾 (Memory)
Reference Files
I structured my project around 4 markdown files that serve as references for Claude:
1. aws-icons-reference.md 📚
A file that references icons for over 150 AWS services with their exact XML configurations. I managed to generate it thanks to Claude by asking it to analyze several AWS draw.io diagrams I designed and having it consult:
- The official AWS icon library on draw.io
- AWS Architecture Icons 4.0 style conventions
- Official AWS color palettes by service category
In the end, I get a markdown file that, for each service, includes:
- The exact icon name
- Official AWS colors (fill + gradient)
- The complete XML template
- The category (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 🏗️
Similarly, I generated a reference file for all containers and groupings:
<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>
With all styles for:
- AWS Cloud boundary
- Regions
- VPCs with CIDR
- Availability Zones
- Public/Private Subnets
- Security Groups
- EKS/ECS Clusters…
3. aws-connections-reference.md 🔗
Another file with standardized styles for each type of connection, with a color code per category:
- 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 ☸️
Working on Kubernetes architectures, I also generated a file with all Kubernetes components, including pods, deployments, services, ingress, configmaps, etc.
## Pod
prIcon=pod
fillColor=#326CE5
## Deployment
prIcon=deploy
fillColor=#326CE5
Instructions
The reference files allow the agent to know the XML references for icons, groups, and links. But you also need to tell Claude how to use them. Here’s the structure of my instructions that I refined over time through my interactions with the agent using prompt engineering.
1. Diagram Generation Workflow
Here I specify to the agent the methodology to adopt: analyze the user’s request which can be a description or an image, then identify the different components to build on the diagram.
Then generate the diagram while carefully considering the files that contain references for icons, groups, and links.
Finally, what format the output file should be generated in.
#### 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. Key Principles
Here, we define the principles that the agent must respect for diagram generation:
- Icon naming convention: how the agent must respect naming rules to correctly identify each AWS service icon
#### 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
- Color codes by category: which color to use for each service category (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 |
- Container and group representation: how to visually represent VPCs, regions, availability zones, and other logical groupings
#### 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
- Connection styles: the different types of links and arrows to use, as well as their coloring based on the services they’re attached to
#### 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) |
A Final Checklist
Finally, we define a checklist that the agent must follow and verify before delivering:
- All services use official styles
- No visual overlaps
- Connections with appropriate style
- Readable and well-positioned labels
- Valid and complete XML
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
Some Concrete Examples: Serverless Architecture
We also define examples of requests it should respond to and what we expect as output:
**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
How to Configure the Project in Claude Desktop
All the files I just presented are available on a GitHub project so you can easily configure your project.
Installing Claude Desktop
If you haven’t already, download and install Claude Desktop from the Anthropic website.
Configuring the Project in Claude Desktop
- Open Claude Desktop and click on the Projects icon in the sidebar
- Click the New Project button to create a new project
- Give your project a name (for example “AWS Diagrams Generator”) and add a description in the corresponding field
- Copy the content of the
INSTRUCTIONS.mdfile from the GitHub repository and paste it into the Instructions field of the project - Add the reference files:
aws-icons-reference.md- Complete catalog of AWS icons with their XML configurationsaws-groups-reference.md- Reference for containers and groups (VPC, Subnets, etc.)aws-connections-reference.md- Patterns for connection styleskubernetes-icons-reference.md- Catalog of Kubernetes components
Usage
Once the project is configured, you can simply describe an architecture in natural language:
Create a diagram for a simple web application with an Application Load Balancer,
EC2 instances in an Auto Scaling Group, and an RDS database
in two availability zones.
Claude will then generate a complete .drawio XML file that you can:
- Save with the
.drawioextension - Open directly in app.diagrams.net
- Import into the draw.io desktop application
- Modify and customize according to your needs
Let’s Play with Our Agent
Example 1: Serverless Architecture from a Description
First type of request: Generate a diagram of a serverless architecture.
Example 2: Three-Tier Architecture from a Photo
Note that the agent successfully generated a valid diagram, with official AWS icons, groups, connections, labels, etc. Even though there’s a small hallucination about the region name, it’s nothing serious :)
Conclusion
Thanks to creating this custom agent, automating my AWS diagrams saves me time, especially for complex diagrams.
To be transparent, the result isn’t always 100% perfect on the first generation. But the advantage here is that I quickly get a coherent structure that respects AWS conventions, and I just need to refine a few details to get exactly what I had in mind.
The more I use the agent, the more refined it becomes. Because each small anomaly I encounter is an opportunity to:
- Update the reference files or instructions to eliminate the error.
- Leverage the Claude project memory that builds up over time through my interactions with the agent to prevent that error from happening again.
This project reinforces my belief that generative AI, when properly guided with clear rules and strict conventions, can truly become a very effective daily assistant. I’m only at the beginning of this exploration, and I already have many ideas to push the concept even further!
Feel free to follow me on LinkedIn to stay updated on my next experiments.