Most teams do not search for the AWS Well-Architected Review Process because they want another explanation of the six pillars. They search because a review is coming up, a customer asked for one, or a production workload has enough risk that "we should probably review this" finally became concrete.
The short answer: an AWS Well-Architected Review moves through three phases: Prepare, Review, and Improve. The value is not the meeting itself. The value is turning current-state answers into a prioritized improvement plan that the team actually owns.
AWS is clear about the tone of the review: it should be lightweight, blame-free, and conversational. It is not an audit. That distinction matters. The goal is to understand the architecture, identify High Risk Issues and Medium Risk Issues, and make better trade-offs before those trade-offs become incidents, cost spikes, or compliance problems.
For the full question set, use the AWS Well-Architected Review checklist. This article focuses on the process: what to prepare, who should attend, how the review runs, what you get back, and what happens after the report is generated.
I use this structure when reviewing AWS environments for security, operations, reliability, and cost risk. The mechanics are simple. The discipline is in keeping the review honest and making sure findings become owned work.
What Is the AWS Well-Architected Review Process?
The AWS Well-Architected Review Process is a structured way to assess a workload against AWS best practices. A workload can be a SaaS application, ecommerce platform, analytics environment, internal tool, or any set of components that delivers business value.
AWS frames the review as a conversation, not a pass/fail test. That is the right mindset. If engineers feel like they are being audited, they will defend old decisions. If they understand the review is there to find improvement opportunities, the conversation gets more honest.
The current AWS Well-Architected Framework is organized around six pillars: Operational Excellence, Security, Reliability, Performance Efficiency, Cost Optimization, and Sustainability. Older posts still mention five pillars, but current AWS documentation includes Sustainability.
The review is useful at specific points in the workload lifecycle:
- Early in design, before hard-to-reverse architecture decisions.
- Before go-live.
- After major architecture changes.
- When recurring incidents or cost issues suggest the architecture has drifted.
- As part of a periodic governance rhythm for important workloads.
AWS also recommends treating reviews as a continuous practice. That does not mean constant meetings. It means you keep the review current as the workload changes, save milestones after meaningful improvements, and use recurring findings to improve platform patterns across teams.
The Short Version: Prepare, Review, Improve
The official WAFR process has three phases: Prepare, Review, and Improve. The names are simple, but each phase has a different owner, output, and failure mode.
Most weak reviews fail in the first or third phase. Teams either arrive without enough context, or they leave with a PDF that never becomes backlog work.
| Phase | Main Question | Inputs | Outputs |
|---|---|---|---|
| Prepare | What workload are we reviewing and why? | Scope, owners, business outcomes, diagrams, evidence | Review plan and attendees |
| Review | What is true today? | Current architecture, answers, notes, trade-offs | Risk profile, notes, report data |
| Improve | What do we fix first? | HRIs, MRIs, business context | Prioritized remediation plan |
That flow is worth keeping in mind because the review is not a single event. It is a loop. The report should change how the team builds, operates, and funds the workload.
Phase 1 - Prepare the Workload and the Team
Preparation is where you save the most time. In its preparation guidance, AWS warns against rushing into a WAFR without enough preparation because it can make the review take longer and make the output harder to act on.
Define the workload scope
Start by defining one workload. Not the whole company. Not every AWS account. One workload with a clear owner and business purpose.
In the AWS Well-Architected Tool, workload definition includes a name, description, review owner, environment, AWS Regions, optional account IDs, optional architecture design URL, optional industry fields, tags, profiles, and lenses. You do not need every optional field to start, but you do need enough context that the review has boundaries.
A practical scope statement looks like this:
We are reviewing the production API platform that serves customer traffic for the EU SaaS product. It runs in
eu-west-1, spans the production and shared services AWS accounts, and supports the onboarding and billing workflows.
That scope is specific enough to decide who attends and which evidence matters.
Map business outcomes before technical fixes
Before discussing services, clarify what business outcome matters most. AWS calls this out directly in the preparation guidance: reviewing an architecture without understanding business priorities is less effective.
Common outcomes include reducing cost, improving security posture, improving customer satisfaction, reducing operational load, or improving sustainability. Those priorities change how you treat findings.
For example, a cost issue in a low-risk internal tool may outrank a minor reliability improvement. The same cost issue in a payment system may wait behind a disaster recovery gap. The framework helps identify risks, but business context tells you what to do first.
Gather evidence before the meeting
The best reviews do not depend on memory.
Prepare these items before the review:
- Architecture diagram or rough service map.
- Workload owner, account IDs, and Regions in scope.
- Deployment, rollback, monitoring, and alerting notes.
- Incident history, backup posture, cost trend, and known risk areas.
- Security, compliance, and open follow-up questions.
AWS suggests using architecture diagrams, design notes, whiteboards, and an action list for questions that require out-of-band research. That last item matters. If nobody knows whether encryption is enabled on a legacy data store, write it down and assign follow-up. Do not guess.
Phase 2 - Run the Review
The review meeting should capture the current state of the workload. Not the intended state. Not what the backlog says might exist next quarter. What is true today.
AWS gives practical guidance for running a WAFR: set roles, agree on the rules of engagement, keep the conversation focused, take useful notes, and avoid turning the review into a solution workshop.
Set roles and rules of engagement
Before answering questions, decide:
- Who leads the review?
- Who shares the screen?
- Who takes notes?
- Which pillars are in scope?
- What order will you follow?
- How much time is allocated per pillar?
- How will you capture out-of-scope items?
- How will findings become backlog work?
One person can lead the conversation, but that person should not also carry the whole review. A second person taking notes is worth it. The AWS docs make the same point: moderating, asking questions, checking documentation, and recording context is too much for one person on a complex workload.
Keep the conversation on current state
The most dangerous answer in a WAFR is "kind of."
"We kind of have backups" usually means nobody has restored from them. "We have monitoring in the backlog" means the workload does not have monitoring today. "The new account structure will fix that" means the current account structure still has the risk.
AWS recommends thinking carefully about "maybe" answers because a review is about the honest current state. That does not mean you punish teams for incomplete work. It means you record the risk accurately so the improvement plan starts from reality.
Also avoid solving every issue during the meeting. Capture the finding, document the context, and keep going. Premature solution design burns time and often excludes the people who need to approve the fix.
Capture notes that future reviewers can use
Checkboxes are not enough. The AWS Well-Architected Tool lets you record notes, and you should use them.
Good notes explain why an answer was selected, what evidence supports it, what assumptions were made, and what follow-up is needed. This helps future reviewers understand whether the workload improved or whether someone simply changed an answer.
A weak note says:
Backups enabled.
A useful note says:
RDS automated backups enabled with 14-day retention. No evidence of quarterly restore testing. Assign restore test to platform team before next milestone.
That level of detail turns the review into operational memory.
Phase 3 - Improve the Workload
This is the phase that decides whether the review was worth doing. AWS Well-Architected Tool identifies architectural risks as High Risk Issues and Medium Risk Issues based on the answers captured during the review.
An HRI is not just "a best practice we skipped." AWS defines HRIs as architectural or operational choices that may significantly negatively affect the business, operations, assets, or people. MRIs are similar but lower impact. AWS also publishes specific guidance for improving a workload after the review.
What happens one day after the review
AWS recommends sending a recap email one day after the WAFR. That recap should summarize:
- Who attended.
- Key findings.
- Timeline for next steps.
- The improvement plan.
Do this while the discussion is still fresh. Waiting two weeks to send a report is how findings lose context and urgency.
What happens two to three days after the review
AWS recommends an HRI prioritization meeting two to three days after the review. Prioritize by effort and impact with the teams responsible for the workload.
This is where engineering judgment matters. Do not sort only by pillar or severity. Sort by business risk, blast radius, effort, dependency, and whether one initiative can remove several risks.
For each HRI, capture:
- Risk description.
- Business impact.
- Affected workload or component.
- Owner.
- Estimated effort.
- Target date.
- Mitigation approach.
- Verification method.
What happens one week after the review
AWS recommends beginning the improvement plan one week after the review and considering a 90- or 180-day window. That timeline is realistic for meaningful architecture work. Some findings are quick wins. Others require design changes, migration work, or governance changes across accounts.
The best improvement plans group related findings. A logging gap, incident response gap, and weak operational visibility may all point to the same platform capability. Fix the mechanism, not just the symptom.
What You Get After an AWS Well-Architected Review
The visible output is usually a report, but the report should not be the only deliverable. AWS Well-Architected Tool reports include workload-question responses, notes, current HRI/MRI counts, and improvement actions for questions with risks.
AWS also supports milestones. A milestone records the state of a workload at a point in time. Save one after the initial review, then save new milestones after improvement work so you can measure progress.
A useful review package should include:
| Deliverable | Why It Matters |
|---|---|
| Workload summary | Keeps scope clear for leadership and future reviewers. |
| Workload report | Records answers, notes, risk counts, and improvement actions. |
| HRI/MRI register | Gives teams a practical list of risks to prioritize. |
| Improvement plan | Converts risks into a 90- or 180-day action plan. |
| Backlog-ready items | Assigns owners, effort, and verification method. |
| Evidence gaps | Captures what could not be answered during the session. |
| Milestone | Creates a baseline for measuring progress. |
If the review ends with only a PDF, expect weak follow-through. The PDF is a record. The backlog is where the work happens.
Who Should Attend a Well-Architected Review?
AWS does not prescribe one universal attendee list, because workloads differ. The right group for a small internal tool is not the right group for a regulated production payments platform.
The principle is simple: invite the people who can answer current-state questions and the people who can prioritize the findings.
| Phase | Recommended Attendees | Reason |
|---|---|---|
| Prepare | Workload owner, cloud/platform lead, application lead | Define scope, systems, and evidence. |
| Review | Application lead, SRE/operations, security, platform, finance or product when relevant | Answer pillar questions with enough context. |
| Improve | Engineering manager, workload owner, platform/security owners, product or finance sponsor | Prioritize and fund remediation work. |
For security-heavy workloads, include someone who understands identity, logging, incident response, and data protection. For cost-heavy workloads, include someone who can connect technical usage to budget ownership. The review should be collaborative, but it should not be crowded.
Self-Service vs Partner-Led Review
You can run the AWS Well-Architected Review yourself. The AWS Well-Architected Tool has no additional charge, and it gives you the structure needed to define a workload, answer questions, generate reports, and track improvement.
The harder question is whether your team has the time, objectivity, and AWS depth to get a useful result.
| Situation | Self-Service | Partner-Led |
|---|---|---|
| Workload is well documented | Good fit | Optional |
| Team has strong AWS experience | Good fit | Optional |
| Architecture ownership is unclear | Possible, slower | Useful |
| Cross-team disagreement exists | Harder | Useful neutral facilitation |
| Remediation needs outside expertise | Limited | Stronger |
| Leadership wants independent validation | Weak | Stronger |
Self-service works well for a first baseline, a smaller workload, or a mature team with clear ownership. Partner-led reviews help when the organization needs independent facilitation, deeper AWS experience, or a remediation plan that spans teams.
Be careful with any promise that a review automatically fixes the architecture. It identifies and prioritizes risk. The follow-through is a separate engineering commitment.
Well-Architected Review vs Security, Cost, and Operational Reviews
A Well-Architected Review is broad by design. It covers six pillars and gives you a balanced view of the workload. That breadth is useful, but sometimes a narrower review is the better first move.
If your main concern is public exposure, IAM sprawl, missing logging, or compliance readiness, start with an AWS security review process. If your AWS bill keeps growing and nobody knows why, an AWS cost optimization assessment will go deeper than the Cost Optimization pillar alone.
| Review Type | Best For | Depth |
|---|---|---|
| Well-Architected Review | Broad workload health across six pillars | Wide, balanced |
| Security Review | IAM, network exposure, logging, data protection, incident response | Deep security |
| Cost Optimization Assessment | Spend visibility, utilization, pricing models, waste, ownership | Deep cost |
| Operational Review | Runbooks, alerting, deployment safety, incidents, on-call health | Deep operations |
The reviews are not competitors. They answer different questions. A WAFR can identify that Security or Cost Optimization needs deeper work, then a focused review can handle the detail.
Common Mistakes That Make Reviews Useless
The AWS Well-Architected Review Process is simple enough to run, but easy to weaken. The most common failure mode is treating the review like a meeting instead of a mechanism.
Here are the mistakes I would watch for:
- Treating the review like an audit and making engineers defensive.
- Reviewing the future roadmap instead of the current workload.
- Inviting only engineers and ignoring business priorities.
- Answering questions without evidence.
- Recording checkbox answers without notes.
- Trying to solve every finding during the review meeting.
- Leaving HRIs without owners.
- Letting the report replace a remediation backlog.
- Never saving follow-up milestones after improvements.
The fix is not complicated. Keep the review focused, capture honest current-state answers, write useful notes, and schedule the HRI prioritization meeting before the review fades from memory.
The Review Is Only Useful If Findings Become Work
The AWS Well-Architected Review Process is not valuable because it produces a report. It is valuable because it forces a team to look at a workload through a structured lens, name the risks, and decide what to do next.
Use the review to create clarity. What is risky? What matters to the business? What should be fixed first? Who owns it? How will we know it improved?
That is the difference between architecture governance that helps engineers and architecture governance that becomes shelfware.
Next step
Turn Your WAFR Findings Into a Remediation Roadmap
I review the workload behind the questionnaire, validate what matters across all six Well-Architected pillars, and give your team a prioritized plan with practical implementation guidance.