How to Draw AWS Architecture Diagrams
AWS diagrams go wrong when they become icon soup. This guide shows how to draw ones that communicate real architecture: boundaries, data flow, and the few services that matter.
AWS gives you around two hundred services and a beautiful icon for each, and that abundance is exactly the trap. It is tempting to sprinkle every icon your system touches across a canvas and call it an architecture diagram. The result looks impressive and communicates almost nothing, because the reader cannot tell what is on the critical path, what is a boundary, and what is incidental.
A good AWS diagram is an act of editing. It shows the services that matter for the point you are making, groups them inside the network and availability boundaries that govern how the system behaves, and traces the flow of a request or of data through them. This guide covers how to make those choices and how to draw the result cleanly, whether by hand in Atlas Diagram Studio at /diagrams or by starting from an AI draft at /diagram-tools/ai-diagram-generator.
Choose your abstraction before you open the icon library
The first decision is what the diagram is for. A logical architecture diagram shows what the system does - "an API tier, a datastore, a queue" - using generic shapes and minimal AWS specifics, and is best for explaining the design to a broad audience. A physical or infrastructure diagram shows the actual AWS services, VPCs, subnets, and availability zones, and is best for operations, security review, and cost reasoning.
Do not try to make one diagram serve both purposes. If you show every subnet and also every business capability, you get the icon soup that helps no one. Decide which question you are answering, and if you genuinely need both, draw two diagrams and link them. The logical one uses plain shapes; the physical one uses the official AWS icon set so it reads correctly to people who know the platform.
Show boundaries: regions, VPCs, subnets, and AZs
The single most valuable thing an AWS diagram can add over a generic architecture diagram is boundaries. AWS behavior is governed by where things sit: which region, which VPC, which availability zone, which subnet, and whether a subnet is public or private. Those boundaries determine latency, failure isolation, blast radius, and what is reachable from the internet.
Draw them as nested containers: a region box, VPC boxes inside it, availability zone boxes, and public versus private subnets inside those. Place each service icon inside the boundary where it actually lives. Suddenly the diagram answers real questions: is this database reachable from the internet, does this design survive an AZ failure, does this traffic cross a NAT gateway. A flat diagram with no boundaries cannot answer any of those, no matter how many icons it has.
An AWS diagramming checklist
Run through this before you consider an AWS diagram finished.
- Use the official AWS icon set so services are instantly recognizable to people who know the platform.
- Enclose resources in region, VPC, availability zone, and subnet boundaries drawn as nested containers.
- Mark public versus private subnets clearly, since that distinction drives security reasoning.
- Show the internet-facing edge explicitly: the internet gateway, load balancer, or CloudFront distribution.
- Trace one primary request path with directional arrows so the reader can follow a real flow.
- Label managed services with their role (for example, "RDS - primary database," "SQS - job queue") not just the icon.
- Indicate multi-AZ or multi-region redundancy where it exists, because a single-AZ design and a resilient one can otherwise look identical.
- Add a title, a date, and a note on whether this is logical or physical, so readers know how to read it.
Trace the flow, do not just place icons
The difference between a decorative AWS diagram and a useful one is that the useful one has a story: a request enters through CloudFront, hits an Application Load Balancer, routes to a service in a private subnet, which reads from RDS and pushes a job to SQS, which a Lambda consumes. Arrows carry that story. Without them, you have a parts catalog, not an architecture.
If you are documenting a specific interaction in depth - say, how a checkout call fans out across services - pair the AWS diagram with a sequence diagram at /diagram-tools/sequence-diagram, which shows the ordering and timing far better than arrows on an infrastructure map. The two together are far more powerful than either alone.
Keeping AWS diagrams honest over time
Cloud infrastructure changes constantly, so a hand-drawn AWS diagram is a snapshot the moment you save it. Be honest about that: date every diagram and treat the drawn version as a communication aid, not a source of truth. For the actual current state, your infrastructure-as-code and AWS's own console are authoritative.
To keep drawn diagrams from rotting, keep them small and focused on the parts that change slowly - the overall topology and boundaries - rather than every ephemeral resource. Atlas Diagram Studio helps here with real-time collaboration for design reviews, import of existing Mermaid and .drawio diagrams, and export in the formats your docs need. If you are comparing cloud diagramming tools, the notes at /diagram-tools/vs/lucidchart and /diagram-tools/vs/drawio are a fair place to start.