An AWS Well-Architected review checklist is how you turn the six-pillar framework into a meeting that actually produces fixes. TL;DR: scope one workload, bring a diagram that matches production, walk operational excellence, security, reliability, performance efficiency, cost optimization and sustainability, then leave with a ranked list of high risk issues (HRIs), each with an owner and a date.
The hard part isn't knowing the pillars. It's that most reviews start from the diagram nobody updated since 2023, answer half the questions with "I think so?", and end with a PDF nobody opens again.
This guide is the version we'd run ourselves: prep list, per-pillar checklist, how to rank findings, and how to keep the review alive after the meeting.
What an AWS Well-Architected review actually is
Quick grounding, straight from the source. The AWS Well-Architected Framework is built on six pillars: operational excellence, security, reliability, performance efficiency, cost optimization and sustainability. AWS is explicit that you trade pillars off against each other based on business needs, except that security and operational excellence are generally not the ones you trade away.
The review itself is meant to be chill (in the good way). AWS's own review process guidance says it should be "a lightweight process (hours not days) that is a conversation and not an audit," with a blame-free approach that encourages diving deep.
Three terms you'll hear constantly, as defined in the AWS Well-Architected Tool glossary:
- Workload: a set of components that deliver business value, such as a marketing site, an ecommerce backend or an analytics platform.
- High risk issue (HRI): an architectural or operational choice that might result in significant negative impact to the business.
- Medium risk issue (MRI): same idea, lesser impact.
There are two ways to run one. The Well-Architected Tool in the AWS console is a guided self-review that produces HRIs, MRIs and an improvement plan, and AWS states there is no additional charge for it. AWS's user guide also describes an AI-powered Well-Architected Agent that analyzes deployed resources and IaC templates, and positions the two as complementary. Either way, the checklist below is what makes the answers honest.
→ Build a reusable review packet with the free Architecture Review Checklist Builder
When to run the review (timing is half the value)
AWS recommends reviewing at key milestones: early in design, "to avoid one-way doors that are difficult to change," then before go-live, and again after significant architecture changes. Between those, teams should keep answers updated as the architecture evolves.
The one-way vs two-way door framing is the most useful filter you'll get:
| Decision type | Example | Review depth |
|---|---|---|
| Two-way door (reversible) | Instance size, cache TTL, alarm thresholds | Lightweight, decide in the room |
| One-way door (hard to reverse) | Account and network topology, primary data store, tenancy model, Region strategy | Deep review before committing |
| Changed since last review | New public endpoint, new data flow, new third-party dependency | Re-answer the affected pillar questions |
If your first review happens the week before launch, every finding about the data store or network layout is already a one-way door. That's how reviews become "noted, will fix in v2" theatre.
→ See what changed between two versions of a design with Architecture Diff
How to prepare for a Well-Architected review
Prep is where reviews are won. AWS's own suggestions are refreshingly low-tech: a room with whiteboards, printouts of diagrams or design notes, and an action list of questions that need out-of-band research ("did we activate encryption or not?"). Here's the expanded prep checklist:
- One workload, clearly bounded. Name it, list what's in and out of scope, and which accounts and Regions it spans.
- A diagram that matches production. Not the launch-day slide. Show accounts, VPCs, subnets, public entry points, data stores and the critical request path. Our AWS architecture diagram guide covers what reviewers need to see.
- Business context. Availability target, RTO and RPO, compliance scope, expected growth, and the monthly budget envelope.
- The builders and operators. People who wrote it and people who get paged for it. A review run only by architects grades the design, not the system.
- Evidence, pre-pulled. Last restore test result, IAM boundary design, alarm list, cost by tag, last deployment rollback.
- A parking lot. Any question nobody can answer goes on the research list. Never guess an answer to make the score look better.
The diagram point matters most. If the picture drifted from reality, every answer built on it is fiction with nice icons.
→ Catch where live AWS drifted from the design with Drift Detector
The AWS Well-Architected review checklist, pillar by pillar
The best practice areas below are taken from the AWS Well-Architected Framework pillar pages. The checklist questions under each are ours: practical prompts that map to those areas, written to get evidence rather than vibes. They are not AWS's official question text, so use the Tool for the canonical questions and this list to make sure the answers hold up.
Operational excellence
Best practice areas: Organization, Prepare, Operate, Evolve. Design principles include implementing observability for actionable insights, making frequent, small, reversible changes, and anticipating failure.
- Every service has a named owning team and an on-call path.
- Deployments are automated, small and reversible, and someone can describe the last rollback.
- Dashboards and alarms map to customer-facing outcomes, not just CPU.
- Runbooks exist for the top failure modes and were used or tested recently.
- Incidents produce tracked follow-up actions, and those actions actually close.
Security
Best practice areas: Security foundations, Identity and access management, Detection, Infrastructure protection, Data protection, Incident response, Application security. Design principles include implementing a strong identity foundation, maintaining traceability, applying security at all layers and keeping people away from data.
- Human access goes through federation and roles; no long-lived access keys for people.
- Every public entry point is listed on the diagram, and nothing else is reachable from the internet.
- Security group rules are least-privilege, with no stray
0.0.0.0/0on admin or database ports. - Data is encrypted in transit and at rest, and someone can say where the keys live.
- Audit logging is on, centralized and retained for the period compliance needs.
- A threat model exists for the main data flows.
For the threat model, a STRIDE pass over the diagram with the free STRIDE threat checklist is the fastest way to turn "apply security at all layers" into specific findings.
Reliability
Best practice areas: Foundations, Workload architecture, Change management, Failure management. Design principles: automatically recover from failure, test recovery procedures, scale horizontally, stop guessing capacity, and manage change through automation.
- RTO and RPO are written down and agreed with the business.
- Backups exist, and a restore was actually tested (date and result recorded).
- The critical path has no single-AZ components and no single points of failure.
- Service quotas and limits relevant to peak load were checked.
- Dependencies have timeouts, retries with backoff, and a degraded mode.
"Test recovery procedures" is the one teams skip most. Our guide on recovery drill best practices is a solid place to start.
Performance efficiency
Best practice areas: Architecture selection, Compute and hardware, Data management, Networking and content delivery, Process and culture.
- The compute choice (Lambda, containers, EC2) is justified against the workload's actual shape.
- The data store matches the access pattern, and the hot path avoids long synchronous chains.
- Caching and content delivery are used where read-heavy traffic justifies them.
- Load tests exist for the expected peak, and the first bottleneck is known.
Cost optimization
Best practice areas: Practice Cloud Financial Management, Expenditure and usage awareness, Cost-effective resources, Manage demand and supply resources, Optimize over time. Design principles include adopting a consumption model and analyzing and attributing expenditure.
- Spend can be attributed to this workload and team, via tags or accounts.
- Costs that scale with traffic, stored data and data transfer are each understood.
- Idle and over-provisioned resources were reviewed in the last quarter.
- Commitment-based pricing was evaluated for steady-state usage.
- Budgets and anomaly alerts exist, with a named person who reads them.
Attribution without a tagging standard is basically impossible (the free tagging policy builder gets you one fast), and the method in our AWS web app hosting cost breakdown shows how to model spend before you build. AWS pricing changes, so always check current numbers in the official AWS Pricing Calculator.
Sustainability
Best practice areas: Region selection, Alignment to demand, Software and architecture, Data management, Hardware and services, Process and culture.
- Region choice considered sustainability alongside latency and compliance.
- Capacity scales down with demand, including non-production environments outside working hours.
- Data lifecycle policies delete or tier data nobody needs.
- Managed and right-sized services replace always-on, mostly idle fleets.
→ Run the security pillar against your actual topology with Security Posture
How to rank Well-Architected high risk issues
A review that ends with 40 equal-priority findings is a review that changes nothing. The Well-Architected Tool's improvement plan already orders items by your pillar priority, with HRIs listed first and MRIs after. Add your own triage on top:
| Finding | Ask | Typical action |
|---|---|---|
| HRI on a one-way door | Will this get harder to fix after launch? | Fix before go-live, block the milestone |
| HRI with an active blast radius | Is data or availability exposed right now? | Fix this sprint |
| HRI that's two-way | Can we change it cheaply later? | Schedule, add a playbook meanwhile |
| MRI | Does it compound with another finding? | Batch into the next iteration |
| Unknown / unanswered | Can anyone produce evidence? | Research action with an owner |
AWS makes a point worth stealing: even if you don't fix every issue, you can still have playbooks for handling them if they materialize. "Accepted risk with a playbook" is a valid outcome. "Accepted risk because the meeting ran long" is not.
If you use the Tool, pulling the HRIs into your tracker is a one-liner with the AWS CLI. The wellarchitected lens alias is the core framework lens:
# List your workloads and grab the WorkloadId
aws wellarchitected list-workloads \
--query "WorkloadSummaries[].[WorkloadName,WorkloadId]" --output table
# Pull only the high risk improvement items for the core lens
aws wellarchitected list-lens-review-improvements \
--workload-id <workload-id> \
--lens-alias wellarchitected \
--query "ImprovementSummaries[?Risk=='HIGH'].[PillarId,QuestionTitle]" \
--output table
# Snapshot the review state before you start fixing things
aws wellarchitected create-milestone \
--workload-id <workload-id> \
--milestone-name "pre-launch-review"Milestones are AWS's "marker for key changes in your architecture" across design, testing, go-live and production. Create one at each review so you can show HRIs trending down instead of just claiming it.
→ Turn findings into tracked follow-ups with our post-review actions guide
Keeping the review alive after the meeting
The classic failure mode: great review, solid improvement plan, then six months of feature work quietly invalidates half the answers. AWS's answer is to continually review the architecture and follow a set of hygiene processes, including a Well-Architected review, whenever you make significant changes.
In practice that means three habits:
- Re-review on change, not on calendar. A new public endpoint, a new data store or a new Region is a trigger to re-answer the affected pillar, the same week.
- Keep the diagram and the answers in sync. If the diagram is the source of truth for the review, it has to track production. Version it and diff it.
- Look for themes across workloads. AWS suggests reviewing all your reviews holistically and addressing thematic issues with mechanisms, training or principal engineering talks. If five teams have the same untested restore, that's a platform problem, not five team problems.
This is where tooling earns its keep. Architecto keeps the architecture as the shared surface: Security Posture reviews exposure and trust boundaries, Scalability Analyzer looks for bottlenecks across compute, state, queues and data paths, and Cost Estimator breaks a topology into compute, storage, networking and platform spend. None of that replaces the AWS Tool's questions; it gives you better evidence to answer them.
→ Pressure-test the reliability and performance pillars with Scalability Analyzer
Key takeaways
- An AWS Well-Architected review checklist is only as good as the diagram and evidence you bring. Prep beats meeting length.
- Review early (one-way doors), before go-live, and after significant changes. AWS recommends exactly this.
- Six pillars: operational excellence, security, reliability, performance efficiency, cost optimization, sustainability. Security and operational excellence are generally not traded off.
- Rank HRIs by reversibility and current blast radius, not by pillar alone. Unknowns are findings too.
- The Well-Architected Tool is free and its milestones let you prove HRIs are going down.
- Keep answers in sync with production, or the next review starts from fiction again.
→ Start free and generate a review-ready AWS diagram with Architect AI
FAQ
What are the six pillars of the AWS Well-Architected Framework?
Operational excellence, security, reliability, performance efficiency, cost optimization and sustainability. AWS notes that you make trade-offs between pillars based on business needs, but security and operational excellence are generally not traded off against the others.
How do you prepare for an AWS Well-Architected review?
Define the workload boundary, bring a current architecture diagram and design notes, get the people who build and run the workload in the room, and pre-collect evidence such as IAM boundaries, backup and restore results, cost allocation and monitoring dashboards. Anything nobody can answer goes on an action list for out-of-band research rather than being guessed.
What is a high risk issue (HRI) in a Well-Architected review?
AWS defines a high risk issue as an architectural or operational choice that AWS has found might result in significant negative impact to a business. A medium risk issue (MRI) might also negatively impact the business, but to a lesser extent. The Well-Architected Tool lists HRIs first, then MRIs, in the improvement plan.
Is the AWS Well-Architected Tool free?
Yes. AWS states there is no additional charge for the AWS Well-Architected Tool; you pay only for your underlying AWS resources.
How often should you run a Well-Architected review?
AWS recommends reviewing at key milestones: early in design to avoid one-way doors that are hard to reverse, again before go-live, and after significant architecture changes. Between formal reviews, teams should keep their answers updated as the architecture evolves.
→ Set your RTO and RPO targets before the reliability pillar with the free RTO/RPO calculator
Ship the review, not just the slide
The framework is free, the Tool is free, and the questions are public. What separates a useful Well-Architected review from a ceremonial one is a diagram that matches reality, evidence instead of guesses, and HRIs with owners. Get those three right and the six pillars basically run themselves.
Start the next review from an accurate, analyzable architecture instead of a stale slide.