AWS Diagram Guide

How to draw an AWS architecture diagram: a method that survives review

By the engineer who builds Datadef, from client work on data platforms · Reviewed August 21, 2026

Most AWS diagrams fail for the same two reasons: they were started by dragging icons instead of deciding a scope, and they show every service at the same weight. The order below fixes both. Scope first, boundaries second, services third, labels last, and only then worry about how it looks.

Try it free
8 min readFor engineers who have to produce an AWS diagram before a review this week

See it as a diagram

Everything below, as a diagram you can edit. Describe yours and see it in seconds.

243/2000• 3 credits left
Try:

No account needed · Editable canvas, not a picture

Step 1: write the scope in one sentence

A diagram answers one question for one audience. Write the question down before anything else: how does a checkout request reach the database, how is customer data isolated between tenants, what breaks if eu-west-1a goes away. If the sentence needs an "and", you have two diagrams.

Scope also sets the detail level. A leadership review needs the request path and the boundaries. An engineering handoff needs subnet tiers, security group rules, and route targets. Drawing both audiences into one canvas produces something neither can read, which is the most common failure mode in AWS diagrams and the reason so many end up as an unlabeled wall of orange icons.

Step 2: draw the containers before the services

AWS architecture is nested, so the diagram should be too. The order is region, then VPC with its CIDR, then availability zone, then subnet tier, then the resources. Name availability zones the way the console does, us-east-1a and us-east-1b, rather than AZ 1 and AZ 2, because the names are what appears in every alarm and every incident channel.

Two placement mistakes cost credibility immediately. An Application Load Balancer is regional and spans the subnets you register, so drawing it inside a single availability zone is wrong; put it at the VPC level or spanning both zone containers. And global services, Route 53, CloudFront, IAM, and the WAF web ACL attached to a distribution, do not belong inside the region box at all. Give them a lane above it.

If the workload is entirely serverless and region scoped, skip the VPC and zone containers instead of drawing empty ones. Boundaries are only worth drawing when they constrain something.

Step 3: place services in flow order, then label the role

Lay the request path along one axis, left to right or top to bottom, and keep the direction of arrows equal to the direction of the request or the event, not the direction of the dependency. Mixed arrow semantics is why readers ask "so which one calls which" three minutes into every walkthrough.

Then label twice. The node gets a service and a role, "Aurora PostgreSQL, orders write model", not just "Aurora". The edge gets what travels on it: tcp/5432, HTTPS, an EventBridge detail type, a batch size. A diagram whose edges are unlabeled arrows is a picture of a network, not an explanation of a system.

Finish with the metadata that decides whether anyone trusts the picture next quarter: the date, the environment, and the commit or account it describes.

Scope: how a checkout request reaches the orders database in prod
Audience: engineers joining the payments team
Region: eu-west-1, two AZs
In: Route 53, CloudFront, ALB, ECS Fargate (checkout, orders), Aurora, SQS
Out: CI pipeline, log group names, IAM policy detail, the analytics stack
Generated: 2026-08-21 from main @ 4f1c9ab

Step 4: generate the first draft instead of placing forty icons

Icon placement is the least valuable part of the job and it is where the hours go. Describe the architecture in the sentence you already wrote and let Datadef produce the canvas: the real AWS marks, 439 of them in the icon set, VPC and availability zone drawn as zones, labelled edges, and a layout that reads in flow order. Then edit what the model got wrong, which is normally naming rather than structure.

From there the diagram is a normal canvas in the editor: move nodes, rename, group, add a zone, export to PNG or JPEG for the deck. If the architecture is defined in Terraform, skip the description entirely and connect the repository so the drawing comes from the code, covered in repo to diagram.

Put the scope sentence in the title

A diagram titled "Checkout request path, prod, eu-west-1" gets used correctly. One titled "AWS Architecture" gets pasted into decks it does not describe. See which AWS services to show for the include and omit rules.

FAQ

What should an AWS architecture diagram include at minimum?

The entry point, the compute that handles the request, every stateful store it touches, the boundaries that constrain them (region, VPC, availability zone, account), and labelled edges showing what travels between them. Anything that does not change how a reader understands the flow belongs in a caption instead of a box.

Should I draw one diagram or several?

Several, scoped by question. A context diagram for stakeholders, a workload diagram for the request path, and a network diagram for subnets, routes, and security groups. The design standard Datadef generates against aims for 12 to 20 nodes with no more edges than nodes, and allows 25 to 40 only when depth was explicitly asked for. One canvas serving all three questions is past that before it is finished.

Where do global services like Route 53 and CloudFront go?

Outside the region container, in their own lane above it. Route 53, CloudFront, IAM, and the WAF web ACL attached to a distribution are global, and drawing them inside a region implies a locality they do not have. ACM certificates used by CloudFront are the related trap: they must live in us-east-1 regardless of where the workload runs.

Is it wrong to put an ALB inside one availability zone?

Yes. An Application Load Balancer is a regional resource that spans every subnet you register with it, so it should sit at the VPC level or span the availability zone containers. Placing it in one zone tells readers the load balancer is a single-zone failure point, which is the opposite of what it does.

How long should drawing an AWS diagram take?

The thinking is the work: scope, boundaries, and what to leave out. The drawing itself should take minutes, which is why generating the first draft from a description or from the infrastructure code and then editing beats placing icons by hand.