Skip to content

Background

Running a Well-Architected review

A Well-Architected review is a structured conversation about one workload: the people who build and run it answer a set of questions, pillar by pillar, and agree what to improve first. You can run one on your own workloads with nothing more than the questions on this page and an afternoon.

What a review is for

A review finds the gap between how a workload is meant to work and how it really works. It isn't an audit, and there's no pass mark. The questions don't have right answers; they have honest ones. A "no" or "we don't know" is the most useful thing a review can produce, because it points at a risk nobody had written down.

The answers are yours to judge. What counts as good enough depends on what the workload does, what an outage or a breach would mean, and what you're willing to spend. The review makes those judgements explicit.

How to run one

  1. Choose one workload. A review covers one service or application, not a whole estate. Write down what it does and who relies on it.
  2. Bring the right people. Someone who builds it, someone who runs it, and someone who knows what it's worth to the business. One to two hours is usually enough.
  3. Agree the targets first. Before the questions, settle the recovery time and recovery point the workload needs, and any security or compliance obligations. Later answers are judged against these.
  4. Work through the pillars. For each question, record the answer and the evidence for it. "We think so" is an answer; note that it's a belief.
  5. Mark the risks. For each answer that falls short of the targets, record a risk and rate it high, medium or low.
  6. Choose what to improve. Pick a small number of improvements, starting with the high risks, and give each an owner.
  7. Repeat. Review again after a major change to the workload, and at a regular interval, such as once a year.

Question set

Use the questions as a starting point; add your own where the workload needs them. Each pillar page explains the principles behind its questions.

Operational excellence

# Question Things to consider
OPS-1 Can the workload's infrastructure and configuration be rebuilt from code? What would still be done by hand?
OPS-2 How does a change reach production, and can it be undone? Review, testing, rollback steps
OPS-3 How would you know the workload is unhealthy before users told you? Metrics, logs, alerts, and where they're kept
OPS-4 Are there runbooks for the tasks and failures you expect, and have they been run? Restore, credential rotation, failover
OPS-5 Are test and production built the same way? Differences that could hide a problem

Security and sovereignty

# Question Things to consider
SEC-1 Who can change this workload, and is that list still right? Organisation roles, per-project access, people who have moved on
SEC-2 Does each tool or pipeline have its own application credential, with an expiry where it fits? Shared credentials, credentials for retired machines
SEC-3 Which ports are reachable from the internet, and from where? Security group sources, floating IPs, administrative access
SEC-4 How are the operating systems and applications inside the instances kept patched? Who owns it, how often, rebuild or update
SEC-5 Where are secrets kept, and who can read them? Code repositories, images, user data
SEC-6 Could you tell who made a given change, and when? Audit log, version control history
SEC-7 What obligations apply to where this workload's data is held and who controls it? Your own policies and those that apply to your organisation

Reliability

# Question Things to consider
REL-1 What recovery time and recovery point does the workload need? What an outage or data loss would mean
REL-2 What happens to the service if one instance fails? More than one instance, a load balancer, health checks
REL-3 Does the workload need to survive the loss of a region? If so, can it? Instances, data and traffic steering in both regions
REL-4 How is the data protected, and where are the copies kept? Snapshots, backups, copies in the other region
REL-5 When was a restore last tested, and how long did it take? Against the recovery targets in REL-1
REL-6 Could the environment be rebuilt from code after a failure? What would have to be done by hand

Performance efficiency

# Question Things to consider
PERF-1 How do you know each instance is the right size? Measurements over normal and busy periods
PERF-2 What is the bottleneck when the workload is under load? CPU, memory, disk, network
PERF-3 How does the workload add capacity when load grows? More instances or larger flavours, and how long it takes
PERF-4 When was the sizing last reviewed? Changes in load since then

Spend efficiency

# Question Things to consider
SPEND-1 Can you see what this workload spends, separate from others? Projects per team, environment or workload
SPEND-2 Are there resources nothing uses? Unattached volumes, unassociated floating IPs, old snapshots, forgotten environments
SPEND-3 Which parts run all the time, and do they need to? Test and development environments, build agents
SPEND-4 Is the extra spend on reliability a decision you've made? Second instances, second region, backup retention
SPEND-5 Who reads the usage and invoices, and how often? Owners for each project

Sustainability

# Question Things to consider
SUS-1 How busy are the workload's instances on average? Consolidation, smaller flavours
SUS-2 Which resources are idle outside working hours? Delete and rebuild from code
SUS-3 Is there a retention rule for snapshots, backups and logs? How long each is needed, and who deletes the rest
SUS-4 Does capacity follow demand, or stay at the peak? Scaling in as well as out

Recording the results

Keep the results in a simple table, one row per risk, alongside the workload's code or documentation:

Question Answer and evidence Risk Rating Improvement Owner
REL-5 Restore last tested over a year ago Restore time unknown against the recovery target High Run a restore in a test project and time it Operations lead
SPEND-2 Three unattached volumes found Paying for storage nobody uses Low Confirm and delete Workload owner

The rows above are examples of the format, not findings about any workload.

Impact

  • Risks that lived in people's heads are written down, rated and owned.
  • Improvements are chosen by risk, not by whoever argues hardest.
  • Repeated reviews show whether the workload is getting better.

Common anti-patterns

  • Reviewing everything at once: an estate-wide review produces a list too long to act on.
  • Answers without evidence: "yes" to every question, with nothing to show for it.
  • A list nobody owns: improvements recorded with no owner and no date.
  • Once and done: a review that's never repeated after the workload changes.

Builds on

Put it into practice

Further reading