How to Prepare for an AWS Well-Architected Review: A Practical Checklist

Why preparation matters

An AWS Well-Architected Review is only as useful as the information you bring to it. Engineers who arrive with documented architecture diagrams, a clear understanding of business criticality, and access to cost and monitoring data will get findings that are specific, actionable, and prioritised correctly. Those who arrive unprepared will get generic recommendations.

This checklist takes roughly two to four hours to work through — and it will significantly improve the quality of your review output.

Before the review: what to gather

Architecture documentation

• A current architecture diagram for the workload being reviewed (even a rough one is better than none)
• A list of all AWS services in use and their primary function
• Known dependencies — internal services, third-party APIs, databases
• Data flows: where does data enter the system, how does it move, where does it exit?

If you do not have up-to-date documentation, block out time to sketch the current state before the review. The act of drawing the diagram often surfaces issues before the review has even started.

IAM and access

• A list of IAM users, roles, and service accounts with their attached policies
• How developers and operations staff access the AWS console and CLI (direct IAM users, SSO, etc.)
• Whether MFA is enforced for all human users
• Whether any roles use wildcard (*) permissions

Cost and billing

• Your AWS Cost Explorer breakdown for the last three months
• Your top five spending services by cost
• Whether resources are tagged consistently (even partially)
• Whether you have any Reserved Instances or Savings Plans in place

Monitoring and observability

• What monitoring tools are in use (Amazon CloudWatch, third-party, both)
• Whether you have alerting configured — and whether those alerts have been tested recently
• Your last three significant incidents: what happened, what caused it, how long did it take to resolve?
• Whether you have a defined RTO (Recovery Time Objective) and RPO (Recovery Point Objective) for critical workloads

Backups and recovery

• What is backed up, how frequently, and where backups are stored
• When you last tested a restore — and whether it worked
• Whether your database instances have automated backups enabled

Who should be in the room

A Well-Architected Review is most valuable when the right people are involved. At minimum:

• The lead engineer or architect responsible for the workload
• An operations or DevOps representative who manages deployments and responds to incidents
• A business stakeholder who can speak to the criticality and compliance requirements of the workload

If the organisation is small, one or two people may cover all these roles. What matters is that whoever participates can answer both technical and business questions.

During the review: what to expect

The review follows the six Well-Architected pillars. For each pillar, you will be asked a series of questions about your current state. The goal is not to have a perfect answer to every question — it is to surface the gaps.

Be honest. The findings are only useful if they reflect reality, not the ideal state you are aiming for. Reviewers are not auditors; they are there to help you identify what to fix and in what order.

After the review: acting on the findings

The review will typically produce findings categorised as High, Medium, and Low risk. A common mistake is to treat the report as a comprehensive to-do list and feel overwhelmed.

A better approach:

1. Address all High risks first — these are the findings most likely to cause an incident, a breach, or a significant cost overrun
2. Pick the top three Medium risks — specifically the ones with the best ratio of effort to impact
3. Schedule a follow-up review — Well-Architected Reviews are most valuable when repeated annually, as your environment changes

For most environments, resolving the High-risk findings takes two to six weeks of focused engineering time. Most teams complete this within a quarter of receiving the report.

How to track remediation

Create a ticket or task for each finding, assign it an owner, and set a target completion date. Review progress monthly. The AWS Well-Architected Tool (a free service in the AWS console) tracks your improvement score over time as you mark findings as resolved.

If you need help prioritising or implementing the remediations, our engineers can work through the findings with you — or take ownership of the implementation entirely.

Book a free Cloud Health Check to discuss your environment and whether a full Well-Architected Review is the right next step.