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.

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, median (p50) and 99th-percentile (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? Backup configuration shows intended settings. Job records show whether the backup ran. A restore exercise provides evidence of recovery under its tested conditions and 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.

For an S3 object-access question, use the CloudTrail GetObject evidence worksheet to check whether the selected source could have collected that activity before interpreting an empty search. Record an unresolved collection or search gap separately from a claim that no access occurred.

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.

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.