The AWS Well-Architected review, explained for non-enterprise teams

An AWS Well-Architected review is a structured self-assessment: you answer a fixed set of questions about one workload across six pillars — operational excellence, security, reliability, performance efficiency, cost optimization, and sustainability — and the framework flags the gaps as risk items, the serious ones as “high risk issues” (HRIs). It is not an audit, nobody grades you, and the tooling is free in the console. For a small team, the honest pitch is this: it is a checklist written by people who have seen thousands of AWS failures, and answering it truthfully for your main workload takes about half a day.

What you are deciding

You are deciding whether to spend a half-day of senior attention answering uncomfortable questions on the record. That is the real cost — the AWS Well-Architected Tool itself has no charge. The questions are of the form “How do you back up data?” and “How do you respond to a security incident?”, each with a menu of practices you either do or do not follow. Where enterprise teams run this per workload per quarter with a facilitator, a non-enterprise team gets most of the value from one honest pass on the workload that pays the bills, repeated yearly.

The second decision is whether to run it yourselves or with a partner. AWS Partners run facilitated reviews, and AWS has at times funded remediation through partner programs — worth asking a partner about, never worth assuming. A facilitator adds two real things: they stop you from grading yourself gently, and they have seen how other companies answer. What they do not add is knowledge of your environment — the answers still have to come from whoever operates it. The framework documentation at https://docs.aws.amazon.com/wellarchitected/ is public; there is no secret content behind the facilitation.

What to check first

Before starting a review, get these in place — they determine whether the review produces work or theatre:

• Pick one workload, not the account. The review is per-workload. Choose the one whose failure would hurt most.
• Get the operator in the room. Answers from architecture diagrams are fiction; answers from the person who gets paged are data.
• Agree that “we don’t” is an acceptable answer. The review only works if unflattering answers are safe to give.
• Check whether basic visibility exists. If nobody can say what the workload costs or when backups last ran, note it — those gaps will dominate the findings.
• Timebox it. Half a day for the first pass. Reviews that sprawl across weeks die of scheduling.

How to verify

The Well-Architected Tool lives in the console at AWS Well-Architected Tool > Workloads > Define workload. Define the workload, answer the questions per pillar, and the tool tracks risk counts and generates a report. From the CLI:

# Workloads already defined in the account
aws wellarchitected list-workloads \
  --query 'WorkloadSummaries[].[WorkloadId,WorkloadName,RiskCounts]'

# Risk detail for one workload's current lens review
aws wellarchitected list-lens-review-improvements \
  --workload-id a1b2c3d4e5f6a1b2c3d4e5f6a1b2c3d4 \
  --lens-alias wellarchitected \
  --query 'ImprovementSummaries[].[QuestionTitle,Risk]' --output table

A useful cross-check on your own honesty: for a handful of answers, verify them the way an outsider would. If you answered that backups are tested, show the restore job. If you answered that the workload withstands an AZ failure, show the second AZ actually carrying traffic. The distance between your answers and your evidence is the most informative output of the whole exercise.

The approach

1. Define the workload in the tool. Name, environment, regions, and the honest one-line description of what it does for the business.
2. Answer the reliability and security pillars first. These two contain most of the questions that map to outages and incidents. If the half-day runs out, run out on the other pillars.
3. Mark, do not debate. When the room disagrees or does not know, mark the practice as not followed and move on. Unknown is a “no” — the review measures what is operationalized, not what is believed.
4. Let the tool rank, then re-rank yourself. The tool flags HRIs, but it does not know your business. A medium-risk item on the revenue path can outrank an HRI on an internal tool. Produce a top-five list with owners.
5. Convert findings to tickets the same week. The half-life of review energy is short. Each top-five item becomes a ticket with an owner and a date — the same discipline as any architecture review remediation queue.
6. Save a milestone and rerun yearly. The tool supports milestones; the year-over-year diff of risk counts is the only progress metric that resists wishful thinking.

When this is the wrong move

Skip the formal review when the top problems are already known and unfixed — a review that rediscovers the missing backups everyone knows about spends credibility for nothing; fix first, review after. It is also the wrong instrument for a workload in active firefighting, and mostly wasted on throwaway environments. And if the team treats it as a certification to pass rather than a mirror, the answers will be gamed and the output will be decorative.

Common mistakes

• Answering aspirationally. “We’re about to set up backups” is a no. The review measures today.
• Running it on all workloads at once. Breadth kills depth; one workload done honestly beats ten done by copy-paste.
• Treating HRI counts as a score to minimize. The goal is accurate risk visibility, not a low number — gaming the count defeats the purpose.
• Filing the report and fixing nothing. A review with no remediation queue is a half-day of well-organized guilt.

Keeping it under control

• Rerun the review annually per key workload, using milestones to track the diff rather than absolute counts.
• Assign every accepted risk a named owner and a written rationale — acceptance is a decision, not a default.
• Fold the two fastest-decaying claims into quarterly operations checks: restores tested, alarms reaching a human, per the CloudWatch alarm baseline.
• When a new workload launches, answer the reliability and security pillars before go-live, while changes are cheap.
• Keep the review scoped to half a day forever; ritual length is inversely correlated with repeat frequency.

The Well-Architected review is the cheapest structured second opinion available on AWS — its value is set entirely by the honesty of the answers and the follow-through on the findings. If nobody on your team truly owns the AWS environment end to end, that is the root of most of these problems — Stack Harbor runs AWS accounts daily under AWS Operations, and you can book an AWS review.