How to Run an AWS Well-Architected Review: The 6 Pillars and Common Findings

What a Well-Architected Review Actually Is

The AWS Well-Architected Framework is a set of questions and best practices that help you evaluate a workload against six pillars. A review is a structured conversation, backed by evidence, where you answer those questions honestly and record the gaps. Done well, it produces a prioritized list of risks and a remediation plan. Done badly, it is a checkbox exercise that generates a PDF nobody reads. This guide keeps you in the first camp.

The Six Pillars

1. Operational Excellence

Can you run and monitor systems to deliver business value, and continuously improve? This covers infrastructure as code, deployment automation, observability, runbooks, and post-incident reviews. A common gap: teams deploy with automation but have no game days and no documented runbooks, so tribal knowledge walks out the door when someone leaves.

2. Security

Can you protect data, systems, and assets? This spans identity and access management, detective controls, infrastructure protection, data protection in transit and at rest, and incident response. The most frequent finding here is over-permissive IAM, wildcards in policies and long-lived access keys, plus missing encryption defaults.

3. Reliability

Can the workload recover from failures and meet demand? This covers fault isolation, automatic recovery, and change management. Teams often discover they have never actually tested a restore from backup, or that a single Availability Zone failure would take them down.

4. Performance Efficiency

Are you using compute resources efficiently as demand and technology change? This looks at selecting the right instance and storage types, monitoring performance, and making informed tradeoffs. Common finding: instances sized for a peak that occurs twice a year, running oversized 24/7.

5. Cost Optimization

Are you avoiding unnecessary costs? This covers usage awareness, cost-effective resources, and managing supply against demand. Idle load balancers, unattached EBS volumes, oversized RDS, and zero commitment-based discounts are the usual suspects. If cost is your driving concern, pair the review with focused AWS cost optimization work.

6. Sustainability

Are you minimizing the environmental impact of your workloads? Added in 2021, this pillar overlaps heavily with cost: right-sizing, choosing efficient regions, and shifting to managed and serverless services all reduce both spend and carbon footprint.

How to Run the Review, Step by Step

1. Define the workload scope. A review covers one workload, not your whole account. Draw a boundary: which services, which environments, which team owns it. Reviewing everything at once produces mush.
2. Gather the right people. You need the engineers who build and operate the workload, plus someone who understands the business requirements. Without the business context you cannot judge whether a tradeoff is acceptable.
3. Use the Well-Architected Tool. The free tool in the AWS console walks you through each pillar's questions and records answers. Create a workload, select the relevant lenses (there are specialized lenses for serverless, SaaS, and more), and work through them.
4. Answer honestly with evidence. For each best practice, mark it as applied or a risk. Do not mark something green because it is embarrassing to admit otherwise. Attach evidence: a link to the IaC repo, a dashboard, a backup test log.
5. Classify risks. The tool separates High Risk Issues (HRIs) from Medium Risk Issues (MRIs). HRIs are things that can cause outages, data loss, or breaches. Fix these first.
6. Build a remediation plan. Turn each risk into a ticket with an owner and a target date. A review with no follow-up backlog was a waste of a day.
7. Schedule the re-review. Architecture drifts. Re-run the review quarterly or after major changes, and track how your HRI count trends over time.

Findings That Show Up Almost Every Time

• No tested disaster recovery. Backups exist but restores have never been rehearsed. Your recovery time objective is a guess until you have timed a real restore.
• IAM sprawl. Wildcard actions, long-lived keys, unused roles, and no automated review of who can do what.
• Single points of failure. A NAT gateway, database, or cache running in one AZ with no failover.
• Missing observability. Logs without structure, no distributed tracing, alerts that fire on symptoms instead of on SLO burn.
• No cost visibility. Nobody can attribute spend to a team or feature because tagging is inconsistent. On-demand pricing everywhere and no Savings Plans.
• Manual deployments. Click-ops changes in the console that are never captured in code, guaranteeing drift.
• Secrets in the wrong place. Credentials in environment variables committed to repos instead of Secrets Manager or Parameter Store.

Turning the Review Into Value

The framework's value is not the score, it is the prioritized backlog and the shared understanding it creates. A useful pattern is to run the review, fix all HRIs within a defined window, then use the remaining MRIs to shape the next quarter's platform roadmap. Tie remediation to concrete outcomes: reduced MTTR, a successful DR drill, a measurable drop in monthly spend. That evidence keeps leadership investing in reliability work that is otherwise invisible until something breaks. Ongoing managed DevOps services make these reviews a recurring rhythm rather than a one-off scramble before an audit.

A first Well-Architected review is eye-opening and a little overwhelming, especially the first time you count your High Risk Issues. If you want senior engineers to run the review with you, prioritize the findings, and actually close them out, InstaDevOps offers a senior DevOps engineer on retainer (Startup $2,999/mo, Business $4,999/mo) with a typical turnaround around 48 hours. Book a 15-minute call to scope your review.