AWS Well-Architected diagrams: what reviewers actually need to see

The framework reviews a workload, not an account and not a platform. So the first line on the canvas is the workload boundary: a container that says what is in scope. Everything outside it is context, drawn lighter, unlabeled beyond its name. That single boundary settles most of the scoping arguments before the session starts.

Include the operating context inside the boundary too, because reviewers ask for it in the first ten minutes: who owns the workload, what its business criticality is, and which environments the diagram describes. A diagram of prod that turns out to be a diagram of staging invalidates half the answers.

Each pillar looks for something specific, and every one of them is a property of the picture rather than a separate document. For security, draw the trust boundaries and mark where data crosses them, plus the point at which it is encrypted. For reliability, mark the failure domains: which components are single-zone today, what the blast radius of losing a zone is, and where the retries and dead letter queues sit.

For performance efficiency, mark the scaling units: what scales, on which signal, up to what ceiling. For cost optimisation, mark what scales with traffic versus what is fixed, since that is the shape of the bill. For operational excellence, mark where telemetry comes from and which component is the first place on-call looks. Sustainability shows up as the same right-sizing annotations, so it rarely needs its own marking.

The point of putting these on the canvas is that reviewers ask the questions in diagram order. Answering them in advance turns a three-hour walkthrough into a discussion about the two or three genuine trade-offs.

## Bring to the review

- Workload boundary drawn, everything outside marked as context
- Request path from client to data store, protocols on the edges
- Region and availability zone boundaries, with every single-zone component marked
- Data flow: where regulated data enters, where it rests, where it leaves
- Trust boundaries, and the encryption point on each crossing
- Scaling units: what scales, on what signal, to what ceiling
- Failure handling: retries, dead letter queues, timeouts
- The date and the commit the diagram was generated from

The workload diagram shows components and calls. The security and privacy questions need a second view: where regulated data enters the system, every store it lands in, how long it stays, and where it leaves. Those two views rarely fit on one canvas, and the data flow view is the one that gets reused for privacy assessments and vendor questionnaires afterwards.

Datadef supports the second view directly with column-level lineage, which is useful when the workload is a data platform and the question is which downstream table contains a given personal field.

Reviews are periodic and improvements are continuous, so the diagram used for the next review should not be redrawn from scratch. A connected GitHub, GitLab, or Azure DevOps repository regenerates the diagram and an architecture document daily, so the artifact you bring to the next review is the one the team has been reading all along.

For a Terraform repository that document has a fixed shape, and it happens to answer the questions reviewers open with. Architecture states what the code deploys, for whom, and in which environments. Stacks and environments gives one bullet per stack and explains how the tfvars differ. What gets provisioned lists the load-bearing resources with the settings the parse recovered, sku, size, engine version, and the multiplicities that differ per environment. How it wires together is the cross-module dependency story. Operations covers the state backend and the provider versions. A module reference table is appended last, composed from the parse rather than written by a model, so every module, source, and resource count in it is a fact rather than a recollection.

Stamp every export with the date and the commit. Reviewers weigh a diagram differently once they know it was generated this week from main rather than drawn last year by someone who has left.

• How to draw an AWS architecture diagram
• Which AWS services to show in a diagram
• Keep security architecture docs current
• Keep an AWS diagram current
• Column-level lineage