Most AWS diagrams fail the same way: someone drops thirty service icons on a canvas, connects them with arrows, and calls it architecture. It looks busy and says almost nothing, because the thing that actually matters in an AWS design is not which services you used. It is the boundaries: what is public, what is private, what lives in which zone, and where the trust lines fall. Get the boundaries right and the diagram teaches. Skip them and it is decoration.
So build an AWS diagram from the outside in, boundary by boundary, and add the services last.
Start with the boundaries, not the services
Think of an AWS diagram as a set of nested containers. Each one is a boundary that a reader needs to see:
- Region: the outermost box. Everything lives in one (or you draw two for a multi-region story).
- VPC: your private network inside the region.
- Availability Zones: two or three columns inside the VPC, because that is how you draw resilience.
- Subnets: public and private lanes within each zone. This split is the single most important line in the whole diagram.
Draw those first, as nested rectangles, before a single service goes down. Now every resource you add has a home, and its position carries meaning: a database in a private subnet says something a floating icon never could.
Add the services where they belong
Only now do the services go on, and where you place them is the documentation. The load balancer sits in the public subnet; the application servers sit private; the managed database sits deepest, private and multi-zone. An object store or a CDN lives outside the VPC because that is where it actually is. Placement is not decoration here; it encodes the security posture.
In an AWS diagram, position is the argument. Where a box sits says more than the icon on it.
Use recognisable icons, sparingly
Real provider icons help a diagram read at a glance, a reader spots the database, the queue, the load balancer without reading labels. Use them, but do not let them become the point. One clear icon per resource, consistent sizing, and plenty of whitespace beats a dense mosaic. The boundaries carry the meaning; the icons just speed up recognition.
Generate the draft from your Terraform
Placing all of this by hand is slow and goes stale the moment infrastructure changes. If you manage AWS with Terraform, the layout is already described: the VPC, the subnets, the instances and the managed services are all declared. Generate the diagram from that, and the boundaries and resources come from the real definition, not your recollection of it. Then you shape it: fix the layout, group the tiers, highlight the public edge.
Finish for the reader
Before you ship it, do a legibility pass. Is the public-versus-private split unmistakable? Can someone trace a request from the internet to the database? Are the availability zones visibly separate so the resilience story is obvious? Trim anything that does not serve those questions. A focused diagram that answers them beats a complete inventory of every resource in the account.
Draw the boundaries, place the services by trust level, keep the icons calm, and generate the draft from Terraform so it stays honest. That is an AWS diagram people will actually use.