AWS Diagram Agent Skill with Draw.io MCP 

When I first built my Diagram Agent Skill with Draw.io MCP, the focus was Azure.

That was deliberate. I wanted to solve one problem properly before broadening it. If you have ever tried to create a cloud architecture diagram that is both accurate and easy to read, the trade-off is familiar enough: manual drawing gives you precision but takes too long, while auto-generation is quick but often produces cluttered output that needs rework.

That was the starting point for the Azure version of the skill, and the goal was simple: generate diagrams that are consistent, readable, and reliable enough to use in real reviews.

Since publishing that post, I have been asked a few times whether I could add AWS support too.

That felt like the right next step. Even in teams that are mostly Azure, AWS still turns up often enough in real work. Sometimes it is part of a migration discussion. Sometimes it is a partner integration. Sometimes it is inherited estate that still needs to be understood, reviewed, and explained clearly. Once you start using AI-assisted diagramming as part of normal engineering workflow, stopping at one cloud starts to feel like an artificial limit.

Why Draw.io MCP Still Matters

One of the main points in my earlier post was that diagramming should not feel like manual busywork. Draw.io MCP makes it possible to generate diagrams from structured inputs instead of arranging every shape by hand, which changes the economics of diagram creation quite a bit. It becomes faster to produce a usable draft, easier to regenerate when something changes, and much more realistic to treat diagrams as engineering artefacts rather than static images that drift out of date.

That part has not changed.

What has changed is the scope of the skill sitting on top of it.

The Azure version worked because it added Azure-specific logic where generic generation usually falls short. The AWS support follows the same principle. It is not really about “supporting another cloud” in the abstract. It is about making the generated output more reliable in the places where real architecture diagrams usually break down.

Why Generic Diagram Generation still falls short

Generic diagram generation is fine for producing boxes and arrows.

The problem is that architecture diagrams are not generic graphs. They are communication tools. They need to show service boundaries clearly, keep the flow readable, avoid unnecessary clutter, and use visuals that engineers recognise quickly. In the Azure post, I called out exactly where generic workflows tend to struggle: inconsistent icon references, render problems, dense layouts, and too much iteration after the first pass because visual QA fails.

That same problem exists with AWS as well.

If the generation logic does not understand provider-specific conventions, you end up in the same loop: regenerate, fix icons, simplify the layout, untangle the lines, and try again. You still get a diagram in the end, but the time saving starts to disappear.

That is the gap I wanted the skill to close in Azure, and it is the same gap I wanted to close when adding AWS support.

What Actually Changed in the Skill

This was not just a matter of dropping in a second icon library.

Under the covers, the skill now expands beyond Azure-only references to cover AWS as well. The AWS update introduces AWS4-related support, including an icon search script and broader changes around the diagramming skill, rather than treating AWS as a cosmetic afterthought.

The practical point is that AWS support is being handled as part of the skill design, not just pasted in as extra assets.

That matters because provider support is rarely just more files. Different platforms have different icon sets, different naming patterns, and different rendering assumptions. If you ignore that and try to force everything through the same path, it usually looks fine until the second or third variation exposes where the assumptions were too narrow.

What the Skill Improves in Practice

In the Azure version, I was quite explicit about where the skill adds value.

It checks icon availability before generation, applies fallback mappings where needed, prevents rendering when required icons are missing, uses curated Azure2 references, adds recovery logic for problematic paths, and applies readability defaults such as left-to-right flow, limited lanes, stage numbering, and minimal crossing lines. It also keeps Azure-specific validation scoped so it only applies when relevant.

That practical specificity matters more than the headline.

The point of the skill is not that it can “draw Azure.” The point is that it improves the first draft in the places where generated diagrams usually fall apart.

That is the same standard I wanted to carry into AWS support.

So the real value of the AWS work is not simply that the skill now knows about AWS services. It is that AWS diagrams can now be generated with provider-aware references and structure in mind, instead of being pushed through a generic model that treats everything as interchangeable. The end goal is the same as before: get to a draft that is close enough to review without needing a rescue operation first.

The Human Still Refines The Diagram

This is the bit I would not want to lose.

In the original Azure post, one of the most important points was that automation does not remove the need for human input. The first generated version usually still needs refinement, but the effort shifts away from manual layout and toward improving architectural clarity. Later in that same post, I made the point again in more practical terms: the generated output was not perfect, but it was close enough that refining it took minutes rather than rebuilding it from scratch.

That is still exactly how I think about this.

The skill is not replacing architecture thinking. It is giving you a better starting point. The engineer still decides what matters, what needs simplifying, what should be called out, and what should be left off the page. The better the first draft is, the more time goes into improving the architecture itself instead of dragging shapes around.

That is a much more useful kind of automation.

Why This Fits Well in AI-Assisted Development

Another theme in the Azure post was that diagrams matter more, not less, when you are working with AI-assisted development.

A text-only description can sound plausible for quite a while. A diagram exposes weak assumptions much faster. That is why the workflow in the original post matters: prompt for architecture intent, generate a draft, validate the icons and layout, refine what matters, then publish it alongside design documentation. The post also ties this into CI/CD and lifecycle usage across design, PR reviews, and operational documentation.

AWS support fits that same workflow.

It means the same pattern can now be used when the architecture is AWS-native, or when the boundary is not neatly inside one provider. That makes the skill more useful in the environments teams actually have, rather than the neat single-cloud diagrams people sometimes imagine they have.

A Natural Follow-On from the Azure Version

I do not think AWS support changes the core idea of the skill.

It extends it.

The Azure post was about making generated diagrams consistent, readable, and reliable enough to fit into real engineering work. Adding AWS support keeps that exact goal, while making the workflow more useful for mixed estates and broader architecture conversations. The original post already made the case that diagrams should become a living part of the engineering process rather than stale documentation. This feels like a continuation of that same idea, not a separate one.

That is why this feels like the right follow-on.

Not because it turns into a vague multi-cloud story, but because it keeps the same practical workflow: structured generation, provider-aware guardrails, reviewable first drafts, and refinement by engineers who still own the architecture.

Looking at a couple of examples it has produced:

/drawio-mcp-diagramming create me an aws diagram showing a three tier paas web app

What’s in the diagram:

Internet / Edge Zone (orange):

• Users → Route 53 → CloudFront + WAF + Shield + ACM (TLS) + Cognito (OAuth 2.0)

Production VPC (green thick border — strokeWidth=4):

AWS Managed Services (blue panel):

• S3 (static assets), CloudWatch, Secrets Manager, CloudWatch Logs

Traffic flows labeled with HTTPS:443, HTTP:8080/8090, PostgreSQL:5432, Redis:6379, OAuth 2.0/OIDC, and egress via NAT – plus a traffic legend and network isolation explanation box.

/drawio-mcp-diagramming create an AWS diagram showing an ECS Fargate multi-tier architecture with ALB, private subnets, RDS, and ECR

What’s in the diagram:

Internet / Edge Zone (orange):

• Users → Route 53 → CloudFront + WAF + Shield + ACM (TLS) + Cognito (OAuth 2.0)

Production VPC (green thick border — strokeWidth=4):

AWS Managed Services (blue panel):

• S3 (static assets), CloudWatch, Secrets Manager, CloudWatch Logs

Traffic flows labeled with HTTPS:443, HTTP:8080/8090, PostgreSQL:5432, Redis:6379, OAuth 2.0/OIDC, and egress via NAT — plus a traffic legend and network isolation explanation box.

How awesome is that?

Wrapping Up

The original Azure Diagram Agent Skill proved the model for one provider.

Adding AWS support makes it more practical, more flexible, and more representative of the environments teams actually work with. But the value is still the same as it was in the Azure version: better first drafts, less rework, clearer reviews, and diagrams that can be regenerated as the architecture changes.

That is the real improvement here.

Not just faster diagrams. Better ones to start from.

And that is usually the difference between something that is interesting once and something teams will actually keep using.

Check out the skill here