How to run a Well-Architected Review without it becoming a tick-box exercise

Most reviews produce a document nobody reads

The AWS Well-Architected Framework has over a hundred questions spread across six pillars. A review that answers all of them faithfully can produce two hundred findings. Nobody acts on two hundred findings. The document goes into a shared drive, where it competes with the quarterly planning deck and the onboarding guide from 2019.

A review that produces a short, ordered, honest list of three to five things gets done. The difference is not in the framework — it is in how you run the review.

Start from the failure you are trying to prevent

Before you open the framework, ask the team a different question: what is the thing that keeps you up at night about this workload? What would a bad day look like?

The answers are always specific. "Our database is in one availability zone and we have never tested what happens if it goes away." "Our IAM roles have been growing since 2020 and nobody knows what they can actually reach." "We are spending twice what we budgeted and we do not know why."

Those answers tell you where to focus. The six pillars give you the vocabulary for the finding; the team's own fears give you the ranking.

Do the credential exercise first

Before you score the security pillar, pick one identity — a workload role, a deployment pipeline, a developer's access key — and trace what it can reach. Read access. Write access. Assume other roles. Network movement.

Do this on paper, with the team in the room, without looking at the policy documents first. Then look at the policy documents. The gap between what the team believed and what the policy actually permitted is usually the most important finding in the review, and it surfaces in twenty minutes.

Rank by consequence, not by severity label

The framework's severity labels are a starting point. They are not the ranking. A "high" finding on a non-production workload with no sensitive data ranks below a "medium" finding on the only path to your customer records.

For each finding, ask one question: what actually happens if we never fix this? If the answer is "probably nothing for a long time," it belongs lower on the list regardless of its label. If the answer is "we breach a compliance requirement" or "an attacker gets our whole customer dataset," it belongs at the top regardless of its label.

Leave with three numbers

At the end of a well-run review, three questions should have answers.

First: if a credential leaked right now, how far would an attacker get? The answer should be one or two resources, not "most of the account."

Second: if the database went away right now, how long would recovery take, and when did you last test it?

Third: what are you paying for that nothing uses? Not architecturally — specifically. A list of line items with owners.

If you cannot answer those three questions, the review is not done yet.

The free review

We run Well-Architected Reviews against one workload at no cost, because we have found it to be the most honest way to start a conversation with an engineering team. You get the findings and the ranked list whether you work with us afterwards or not.

The details of how it works and what access we need are on this page.