Free lesson · AWS Solutions Architecture

The Well-Architected review as a working method

Easy8 min readawssystem-designarchitecture

Not A Checklist

The Well-Architected Framework is most often encountered as a review someone runs once, produces a report, and files. That use extracts almost none of its value.

Its actual value is as a set of lenses applied during design - six recurring questions that surface the trade-offs you are making, whether or not you noticed making them.

Important: The framework's most useful property is not the questions within each pillar. It is that the pillars conflict.

Reliability wants redundancy; cost optimisation does not. Security wants controls; operational excellence wants simplicity. Performance wants provisioned capacity; cost wants elasticity.

You cannot maximise all six, and any architecture is a position on those trade-offs. The review's function is making that position explicit rather than accidental.

A review that produces "we scored well on all pillars" has either found a genuinely exceptional system or, far more likely, has not asked hard enough questions.

The Six Pillars

Operational Excellence is the pillar most consistently under-invested, and it is the one that determines whether the other five survive contact with reality. An architecture that is secure, reliable, and performant on the day it ships, with no deployment automation, no observability, and no runbooks, degrades from that day forward.

Tip: If a review has time for only one pillar, choose Operational Excellence. It is the leading indicator for all the others.

A team that deploys manually will deploy inconsistently, which produces reliability incidents. A team without observability will not detect degradation, which produces both reliability and performance problems. A team without runbooks will improvise during incidents, extending them.

The other pillars describe the system. Operational Excellence describes whether the system stays that way.

Sustainability is the newest and the most often skipped, and it is more useful than it appears - its questions about right-sizing, utilisation, managed services, and data lifecycle overlap heavily with cost optimisation, so the two reinforce each other.

Running A Review Properly

graph LR
    P[**Prepare** - scope the workload,<br/>gather the architecture,<br/>identify participants] --> W[**Workshop** - work the<br/>questions, pillar by pillar]
    W --> R[**Risks identified** —<br/>high, medium, low]
    R --> T[**Trade-offs surfaced** —<br/>which are deliberate?]
    T --> PL[**Plan** - owned, dated,<br/>prioritised items]
    PL --> I[Implement]
    I --> RV[**Re-review** - at major<br/>change, or periodically]
    RV --> W

This diagram shows the Well-Architected review cycle. Preparation scopes the workload, gathers the architecture, and identifies participants. A workshop works through the questions pillar by pillar, producing identified risks classified as high, medium, or low, and surfacing trade-offs with the question of which are deliberate. That produces a plan of owned, dated, prioritised items which are implemented, followed by a re-review at major change or periodically, feeding back into the workshop.

Scope one workload, not an estate. A review covering "our AWS environment" produces generalities. A review covering one system with a defined boundary produces findings someone can act on.

Who attends: the people who built it, the people who operate it, and at least one person who did not - a reviewer from another team, or a senior engineer with no stake in the design.

Warning: A review conducted only by the team that built the system finds what that team already knows.

The value of an outside participant is not superior knowledge - it is the absence of the assumptions everyone inside shares. The question "why does the service in AZ-A talk to the database in AZ-B?" is obvious to an outsider and invisible to a team for whom that has always been true.

Structure it so disagreement is expected. A review where nobody challenges anything has been a presentation.

Time-box it. A pillar in ninety minutes, or the whole framework across two half-days. A review scheduled for a week does not happen.

The output is a risk register, not a score. High-risk items get owners and dates; medium ones get scheduled; low ones get recorded.

The Tool And The Lenses

The AWS Well-Architected Tool provides the question set, records answers and risks, tracks improvement over time, and supports milestones so you can compare a workload against its earlier state.

Lenses adapt the questions for specific workload types - Serverless, SaaS, Data Analytics, Machine Learning, IoT, Financial Services, and others. Use the relevant lens rather than the general framework alone, because the specific questions are considerably more useful than the generic ones.

Custom lenses encode your own organisational standards as review questions - the platform team's requirements, the security team's baseline, the compliance obligations. This is the strongest use of the tool at organisational scale: the review becomes the mechanism that checks a workload against your standards rather than only against AWS's.

Working The Trade-Offs

The part the framework structures and most reviews skip.

For each significant trade-off, the review should establish three things: what the trade is, whether it was deliberate, and whether it is still correct.

Important: "Was this deliberate?" is the single most productive question in a Well-Architected review.

A deliberate trade-off is a decision - it has a rationale, it can be revisited when circumstances change, and it should be in an ADR. An accidental one is a gap that nobody has assessed.

The two look identical in the architecture and they are entirely different findings. A single-AZ database chosen deliberately for a development environment is fine; the same configuration in production because nobody thought about it is a high risk.

Ask it of every finding, and the answer sorts the risk register faster than any severity rubric.

Findings, And Making Them Land

Classify by risk, not by pillar. A stakeholder cares that there is an unmitigated single point of failure, not which pillar it appeared under.

High-risk items should have a stated impact in business terms. "No multi-AZ on the primary database - an AZ failure means a multi-hour outage with data loss up to the last snapshot" lands where "does not meet REL 10 best practice" does not.

Every item needs an owner, a date, and a place in the normal backlog - the same requirement as postmortem actions in Course 4 Module 05 Topic 1, and it fails the same way without them.

Warning: A Well-Architected review whose findings are never actioned is worse than no review, because it creates a documented record that the organisation knew about the risk and did nothing.

That is a genuine liability in a regulated context, and it is a credibility problem everywhere else - the second review is taken less seriously than the first, and the third does not happen.

Track the completion rate. If it is low, stop running reviews until the process for acting on them exists. Producing findings is the easy half.

Using It As A Design Tool

The highest-value application, and the least common.

During design, work the pillar questions against the proposed architecture before it is built. The findings are free at that point - a change to a diagram rather than to a running system.

A lightweight version that fits into a design review: one question per pillar, asked of every significant design.

Six questions, twenty minutes, and they catch a substantial proportion of what a full review would find later at far greater cost.

Cadence

Milestones in the tool make the comparison meaningful - a workload reviewed annually with the previous state recorded shows whether it is improving, which is more useful than any single review's findings.

Common Failure Modes

Warning: Treated as a one-off audit. Most of the value unclaimed.

Reviewed only by the team that built it. Finds what they already know.

Scoped to an estate rather than a workload. Generalities.

No trade-off discussion. The most productive part skipped.

"Was this deliberate?" never asked. Decisions and gaps indistinguishable.

Findings without owners or dates. Not actioned.

Findings never actioned at all. A documented record of known risk.

The relevant lens not used. Generic questions where specific ones exist.

No custom lens encoding organisational standards.

Scored rather than risk-registered. A number instead of a plan.

Operational Excellence under-weighted. The pillar that sustains the others.

Never used at design time. Findings paid for at their most expensive.

Why This Matters In An Interview

Interview: Well-Architected questions test whether it is understood as a method or recited as a list.

What interviewers are listening for:

• The pillars conflicting, and the architecture being a position on those trade-offs.
• "Was this deliberate?" as the discriminating question.
• Using it at design time rather than as an audit.
• Operational Excellence as the pillar that sustains the others.

Common follow-ups:

• "What is the Well-Architected Framework for?" → Surfacing the trade-offs you are making between six competing concerns, so they are deliberate rather than accidental. Not a checklist to pass.
• "How would you run a review?" → One workload, time-boxed, with someone from outside the team, working the relevant lens, producing a risk register with owners and dates rather than a score. Then the question of whether each trade-off was deliberate.
• "Which pillar matters most?" → It depends on the workload, and Operational Excellence is the one most consistently under-invested - because it determines whether the other five survive after launch.
• "Your review found twelve high risks and nothing changed. What went wrong?" → No owners, no dates, or no place in the normal backlog. And now there is a documented record that the organisation knew. Fix the action process before running another review.

Practice

Exercise: Starter. Apply the six design-time questions to an architecture you know. Note which you cannot answer.

Intermediate. Run a single-pillar review of one workload with someone from outside the team. For each finding, ask whether the trade-off was deliberate.

Advanced. Build a custom lens encoding your organisation's standards, and review a workload against it. The questions it fails are the gap between your standards and your reality.

Related Topics

• Topic 1 - The method the review supports
• Topic 3 - Availability, the reliability pillar's arithmetic
• Module 03 Topics 1–4 - The constraint-driven design each pillar addresses
• Course 1 Module 01 Topic 6 - The framework's structure

Back to AWS Solutions Architecture