AWS Well-Architected Review Checklist: What to Prepare

Prepare workload context, operational evidence and remediation ownership for an AWS Well-Architected review across all six framework pillars.

A useful review starts before the meeting

An architecture diagram is not enough. A review needs workload context, operating evidence, named decisions and owners who can explain what happens when the system changes or fails.

The AWS Well-Architected Framework currently uses six pillars: operational excellence, security, reliability, performance efficiency, cost optimization and sustainability. Confirm the current questions and guidance in the official AWS Well-Architected Framework before running a formal review.

This checklist helps a workload team prepare evidence. It does not imply AWS approval, certification or a Well-Architected Partner designation.

1. Define the workload boundary

Write down the customer or business outcome, critical user journeys, availability expectations, peak and normal demand, data sensitivity, recovery objectives, regions and accounts, major dependencies and the people who operate the workload.

If the boundary is unclear, the review will mix unrelated systems and produce remediation that nobody owns.

2. Bring an architecture that shows responsibility

The diagram should show traffic entry, identity, application and data tiers, asynchronous paths, third-party dependencies, deployment flow, observability and recovery boundaries. Mark systems of record and trust boundaries.

"type": "svg-architecture", "title": "Workload evidence map for an architecture review", "layers": [ ] }} />

3. Prepare evidence for each pillar

| Pillar | Evidence to bring | Decision the team should be able to explain | |---|---|---| | Operational excellence | Runbooks, deployment records, change failure examples, operational metrics and post-incident actions | How changes are made, observed, stopped and improved | | Security | Identity model, access reviews, data classification, encryption, logging, vulnerability handling and incident response | Which risks are accepted, reduced or transferred, and by whom | | Reliability | Dependency map, failure modes, recovery objectives, backup results, failover tests and capacity limits | What may fail, how the workload continues and how recovery is verified | | Performance efficiency | Demand profile, latency and throughput percentiles, load tests, resource choices and scaling behaviour | Why the selected architecture fits the workload and when it must change | | Cost optimization | Cost allocation, unit-cost view, commitments, idle resources, demand forecast and optimization history | Which costs support the outcome and which changes are safe | | Sustainability | Utilization, data lifecycle, efficient service choices, workload scheduling and measurement approach | How resource use is reduced without weakening the required outcome |

AWS describes these six pillars and their focus areas in The pillars of the Well-Architected Framework.

4. Use observed evidence, not status labels

“Highly available,” “secure” and “scalable” are conclusions. Bring the evidence behind them.

Examples include a dated restore test, a deployment that was rolled back, p50 and p99 latency under a stated load, access-review records, the result of a dependency failure exercise, cost per business unit, and a tracked remediation from a previous incident.

State the measurement period and environment. A staging load test and a production observation answer different questions.

Test whether the evidence is decision-grade

For every important claim, ask four questions:

Is it current? Evidence from a previous architecture or traffic profile may no longer describe the workload.
Is it representative? A successful test of one component does not prove the complete customer journey can recover.
Is it reproducible? Another engineer should be able to find the procedure, inputs and result without relying on the person who ran it.
Does it prove the stated outcome? A configured backup proves that a job ran. A restore exercise proves that usable data can be recovered within a measured time.

Create a small evidence register before the review. Link each item to its environment, collection date, owner and the question it supports. This prevents a long meeting from turning into a search across dashboards, tickets and personal notes.

5. Prepare the review as a working session

A practical review needs the people who understand the workload and the people who can accept or fund remediation. Include the product or business owner, the application owner, an operations or reliability representative, the security owner and the person responsible for cloud cost. Add data, compliance or vendor owners when the workload depends on them.

Share the workload boundary and evidence register in advance. Ask participants to identify disputed assumptions before the session. During the review, separate three kinds of statements:

an observed fact supported by evidence;
a design assumption that still needs validation;
a risk decision that requires an accountable owner.

Do not spend the session reading framework questions aloud. Use the questions to examine real operating decisions, failure modes and evidence gaps.

A simple preparation timeline

| When | Activity | Output | |---|---|---| | 10 working days before | Confirm scope, owners and critical journeys | Workload boundary and participant list | | 7 days before | Collect diagrams, objectives, operational records and cost data | Evidence register with gaps | | 3 days before | Review likely failure modes and disputed assumptions | Initial risk hypotheses | | Review day | Test decisions against evidence across all six pillars | Findings, accepted risks and unresolved questions | | Within 2 working days | Sequence remediation and confirm owners | Decision record and delivery backlog | | At the agreed validation date | Test the changed control or architecture | Closure evidence or a reopened finding |

6. Record tradeoffs and accepted risk

The review should not turn every answer into a red or green badge. Some risks are acceptable because the business impact is low or remediation would displace more valuable work.

For each material finding, record:

The affected workload and user outcome.
The evidence and uncertainty.
The failure or cost consequence.
The options considered.
The decision and accountable owner.
The validation method and review date.

7. Convert findings into a remediation sequence

Prioritize by consequence, likelihood, reversibility and dependency. A severe recovery gap may come before a moderate cost opportunity. A low-cost observability change may come before a larger redesign because it provides the evidence needed for that redesign.

"type": "svg-flow", "title": "From review finding to verified remediation", "steps": [ ] }} />

Triage without turning the review into a rewrite programme

Not every finding requires a redesign. Classify the response before estimating work:

Immediate containment: reduce exposure now through a limit, alert, permission change, feature flag or operational guardrail.
Evidence task: run a restore, load, failover or access test before choosing a solution.
Targeted remediation: change one control or component with a measurable acceptance condition.
Architectural change: redesign a boundary only when the existing design cannot meet the required outcome.
Accepted risk: record why the risk is tolerable, who accepted it and when the decision expires.

For every remediation, define the condition that would prove completion. “Improve reliability” is not testable. “Restore the production-sized database into an isolated account within the approved recovery time, then verify application reads against a reconciliation sample” is testable.

8. Avoid common review failure modes

The review is weak when it examines configuration without the customer journey, treats missing evidence as evidence of safety, or produces a backlog with no business consequence. It also fails when teams attempt to remediate every low-level observation while a known recovery or access-control risk remains unresolved.

Another failure mode is reviewing a reference architecture instead of the deployed workload. Managed services can reduce undifferentiated operating work, but service selection alone does not prove that identity, recovery, observability, cost ownership or change controls work in the organization’s implementation.

9. Close with an owned decision record

The output should contain the workload boundary, evidence reviewed, findings, accepted risks, remediation backlog, accountable owners and validation dates. Keep architecture decisions and evidence linked so the next review can see what changed.

A review is complete when the team understands its risks and owns the next decisions. It is not complete because a questionnaire has no unanswered rows.

The next action

Select one production workload and write its boundary on a single page. Then attach one piece of current evidence for each pillar and mark every missing item. If the team cannot identify an owner for a critical journey, recovery objective or material risk, resolve that ownership gap before scheduling the formal review.