Service spotlight: running an AWS Well-Architected Tool review

“We should do a Well-Architected review” tends to get said in the same tone as “we should write more tests” — a good idea everyone agrees with and nobody schedules. Having actually run several of these against real production workloads, the tool is more useful than its reputation as a compliance checkbox exercise suggests, provided you go in knowing what it will and won’t tell you.

What it actually is

The AWS Well-Architected Tool is a free console tool that walks a defined workload (you register one per application or system you want reviewed) through a structured questionnaire organized by the **six pillars**: Operational Excellence, Security, Reliability, Performance Efficiency, Cost Optimization, and Sustainability. Each pillar has a set of questions (“How do you manage identity and permissions for people and machines?”), each question has a list of best-practice choices you select as implemented or not, and unchosen best practices become flagged risk items — categorized as high or medium risk — in a summary report per pillar.

The output is a milestone: a snapshot of your answers and risk items at a point in time, which you can re-run later and diff against to show whether risk actually went down after remediation work, not just that a review happened once.

Where it earns its keep

• Structured coverage across dimensions people forget under deadline ** pressure.** Reliability and cost questions in particular tend to get skipped in day-to-day feature work; walking through all six pillars on a schedule forces a periodic look at “do we have alarms on this,” “is this single-AZ,” and “why is this instance still on-demand” even when no one’s actively fighting a fire in those areas.
• A shared vocabulary for architecture discussions. Once a team has gone through a review together, “that’s a Reliability risk” or “that’s not really Well-Architected on the Security pillar” becomes shorthand everyone in the room understands the same way, which speeds up later design reviews.
• Lenses for workload-specific guidance. Beyond the six generic pillars, AWS publishes lenses (Serverless, SaaS, Machine Learning, Container Build, and others) with more specific best practices for that architecture style — the Serverless lens asks meaningfully different questions than the generic Operational Excellence pillar does, and is worth applying if your workload fits one.
• AWS credits for remediation, sometimes. Depending on your account’s relationship with AWS (particularly through a Partner or an active Enterprise Support engagement), completing a review and acting on findings can be tied to funding programs — worth checking with your account team if cost is a factor in prioritizing the work.

Where it falls short

The questionnaire is generic by design, which means its questions are necessarily abstracted away from your actual architecture — it will ask whether you have a documented incident response runbook, but it can’t tell you whether your specific runbook is any good, or whether your DR RTO target is realistic for your actual failure modes. It’s a structured prompt for a conversation your team needs to have, not a substitute for that conversation, and treating it as a checkbox exercise where you tick “implemented” without actually verifying the practice is in place defeats the entire point — self-reported answers are only as honest as the person answering them.

It also doesn’t automatically inspect your account — answering the questionnaire accurately still requires someone to actually go look at what’s configured, which is real work. (AWS’s separate Trusted Advisor and Well-Architected Tool’s own automated checks integration can pull some findings in automatically for a subset of best practices, narrowing but not eliminating that manual-verification gap.)

A practical tip

Don’t try to review an entire application’s full six-pillar surface in one sitting — split the review across a couple of working sessions per pillar with the people who actually own that area (security engineer for the Security pillar, whoever owns the on-call rotation for Reliability), and treat the output high-risk items as backlog tickets with owners, not a report that goes in a drawer once the review is done.