AWS Well-Architected Review Checklist

When to Use This Checklist

Use this to run a Well-Architected Review on an AWS workload, ideally before a major launch and then periodically. The review is a structured way to find risks across operational excellence, security, reliability, performance efficiency, cost optimization, and sustainability. It produces a prioritized risk register, not a pass/fail grade.

Though framed for AWS, the same six-pillar structure maps onto the Azure and Google equivalents.

How to Use This Checklist

First scope the workload and its business context, because risk is relative to what the workload must achieve. Then walk each pillar with the workload's owners, recording risks as you go rather than debating fixes; remediation comes after. Classify every risk as high, medium, or low.

The output that matters is item nine: a prioritized backlog of high risks with owners and dates. A review that produces findings but no owned actions changes nothing. Schedule a follow-up to confirm the high risks were addressed.

What Good Looks Like

A good review has a clearly scoped workload, honest pillar-by-pillar assessment, and a risk register where every high item has an owner and a target date. Findings are validated against any relevant lens, the report is shared with stakeholders, and a follow-up review is booked. Over time, the number of high risks trends down and the team treats the review as a routine, not an audit to survive.

Common Pitfalls

The biggest pitfall is treating the review as a checkbox exercise that produces a document nobody acts on. Another is scoping too broadly, so the review becomes shallow across many workloads instead of deep on one. Teams often skip the cost and sustainability pillars because they feel less urgent, missing real savings. Recording risks without owners or dates guarantees they linger. Finally, a one-time review with no follow-up lets the architecture drift back into risk.

Related Resources

The AWS Well-Architected Framework and its sustainability pillar are the source material. Use SLOs and incident-management practices for the reliability and operational pillars, FinOps for cost, and architecture decision records to capture the rationale behind remediation choices.