An AWS Well-Architected Review — the six pillars, the workshop, and the credits it unlocks.

IWhat a Well-Architected Review is — and what it is not

The AWS Well-Architected Framework is AWS’s codified opinion on how to build well on its platform. A review (WAFR) is the act of measuring one of your workloads against that opinion and writing down where the gaps are.

The Framework has existed since 2015 and is updated continuously; as of 2026 it spans six pillars and a library of dozens of domain-specific "lenses" (Serverless, SaaS, Data Analytics, Machine Learning, Financial Services, and more) that overlay industry-specific guidance on top of the core questions. A review walks a single workload — not your whole account, one workload — through a set of questions per pillar and records the answers honestly.

The crucial reframe: a Well-Architected Review is not a pass/fail certification and it is not a compliance attestation. There is no "Well-Architected certified" badge you can put on your homepage. What you get instead is a list of issues categorized by severity, with the worst ones flagged as high-risk issues (HRIs), plus AWS’s specific recommendation for each. It is a diagnostic, not a diploma.

It also is not a one-time event. AWS’s own guidance is that you re-review a workload at major milestones — before a launch, after a significant architecture change, ahead of a funding round or an enterprise security questionnaire, and on a roughly annual cadence regardless. The Well-Architected Tool keeps a versioned history so you can see whether last quarter’s HRIs actually got fixed.

If you are reading this because a customer, an investor, or a SOC 2 auditor asked whether your AWS architecture is "well-architected," a WAFR is the concrete artifact that answers the question. The rest of this page covers the six pillars, what the review session actually looks like, how the AWS funding works, and how to decide between doing it yourself and bringing in a partner.

IIThe six pillars — what each one actually checks

Each pillar is a lens on a different failure mode. A workload can score beautifully on cost and still be one Availability Zone away from a multi-hour outage. The point of having six is that they catch different problems.

Below is what each pillar is really asking. The review questions are more granular than this, but every question rolls up to one of these six concerns.

IIIWhat a review actually involves — the tool, the workshop, the HRIs

A review is three things in sequence: the AWS Well-Architected Tool that structures it, a working session (the "workshop") where you answer the questions honestly with someone who knows what good looks like, and an output — the list of high-risk issues and what to do about them.

The Well-Architected Tool. This is a free service in the AWS console. You define a workload (its name, environment, regions, and which optional lenses apply), then work through the question set pillar by pillar. For each question you select the best-practice items you have actually implemented and leave the rest unchecked. The tool then computes which gaps are high-risk versus medium-risk and generates an improvement plan with links to the relevant AWS documentation. You can run it entirely solo.

The workshop. The difference between a tool exercise and a real review is the conversation. In a partner-led review, an experienced reviewer facilitates a working session — typically a half-day to three days depending on workload complexity — and pushes on the answers. "You checked that you encrypt data at rest. Show me the KMS policy. Who can decrypt? Is the key rotated?" The honest answers are usually messier than the self-assessment, and that is the point: the workshop is where the real HRIs surface.

High-risk issues (HRIs). An HRI is a gap that AWS considers materially likely to cause harm — an outage, a security incident, data loss, or significant unnecessary cost. These are the headline output. A typical first review of a Series-A workload surfaces somewhere between five and fifteen HRIs across the pillars, weighted toward security and reliability. Medium-risk issues (MRIs) are logged too but are not the priority.

The deliverable. You walk away with a documented set of findings, each HRI mapped to a specific recommendation and the AWS services involved, plus a milestone you can re-review against later. With a good partner you also get effort estimates and a sequenced remediation roadmap (covered below) rather than just an undifferentiated list.

IVThe AWS funding angle — how a review unlocks credits for the fixes

This is the part most write-ups skip, and it is the most useful part for a startup. A Well-Architected Review is not just diagnostic; in the partner-led path it is a recognized AWS funding event. AWS pays partners to run reviews and offers credits to fund the remediation that follows.

There are two distinct money flows, and keeping them separate avoids overclaiming. First, AWS funds the review itself: under AWS’s partner funding programs, a qualified AWS Well-Architected Partner can be paid by AWS to facilitate your review. That is why a partner-led WAFR frequently costs the customer $0 — the partner’s time on the review is covered by AWS, not billed to you.

Second, and more valuable, a completed review can unlock remediation credits. AWS has long operated funding tied to Well-Architected — historically partners could request AWS credits (commonly cited at up to $5,000 per qualifying workload) specifically to offset the AWS spend incurred while fixing the HRIs the review found. The exact figure and program names shift year to year, so treat any specific number as representative rather than a guarantee — but the mechanic is durable: AWS would rather fund you to fix a high-risk issue than watch the workload fail.

For a credit-eligible company, the two flows compound with the broader Activate credit pool. A typical pattern: the partner runs the review (AWS-funded), the review surfaces a cluster of security and reliability HRIs, the partner files for Well-Architected remediation credits to cover the AWS spend of the fixes, and — where the company also qualifies — the remediation work itself is delivered against the company’s Activate credits and partner engagement funding. The net effect for the customer can be a hardened, audit-ready architecture for $0 or low cost.

The honest framing: the AWS-funded review is broadly available through a partner, but the larger remediation and engagement funding is for credit-eligible companies (typically institutionally funded startups with a real AWS workload). If you do not qualify for the credit programs, a partner-led review is still a vetted, expert engagement at a known price — just not a free one. CloudRoute will tell you which bucket you are in before anyone files anything.

VHow to prepare so the review is worth doing

A review where you bluff every answer produces a clean-looking score and zero value. A review where you come prepared with the real state of the workload produces a roadmap. The prep is mostly about having evidence at hand and picking the right scope.

You do not need to fix anything before a review — the review tells you what to fix. But a few hours of preparation makes the workshop dramatically more productive:

• Pick one workload and define its boundary — Resist reviewing "all of AWS." Choose the workload that matters most (usually the production system behind your core product) and be precise about what is in and out of scope, including which regions and accounts it spans.
• Choose the right lenses — If the workload is serverless, add the Serverless Lens; if you are a multi-tenant SaaS, add the SaaS Lens; regulated industries have their own. The lens sharpens the questions so the findings are relevant rather than generic.
• Have your architecture diagram and IAM reality ready — An accurate, current diagram and an honest picture of who has access to what saves hours. The single biggest time-sink in a review is reconstructing what the architecture actually is mid-session.
• Pull the obvious evidence in advance — Backup and restore test results, your CloudTrail/Config/GuardDuty status, your tagging and cost reports, your incident history. The reviewer will ask; having it ready turns "we think so" into a real answer.
• Get the right people in the room — You need whoever actually deploys, whoever owns security, and someone who can make decisions. A review run only with the most junior available engineer produces the most junior available answers.
• Decide what a finding will trigger — Agree up front that HRIs will be turned into tracked tickets with owners. A review whose output dies in a slide deck was a waste of a good workshop.

VIDIY vs partner-led — when each makes sense

The Well-Architected Tool is free and you can absolutely self-assess. Whether that is enough depends on what you need the review for and whether you want the funding that only the partner path unlocks.

A self-assessment is genuinely useful as a first pass — it costs nothing, it surfaces the obvious gaps, and it gives you a baseline to track against. The limits are honesty and funding. Teams reliably over-score themselves on questions they do not fully understand, so the gaps that bite hardest are exactly the ones a solo review misses. And a self-assessment unlocks no AWS funding: there is no partner to be paid by AWS for the review and no partner to file for remediation credits.

A partner-led review adds three things: an experienced reviewer who has seen these failure modes before and will not let you bluff, a facilitated workshop that forces the real answers out, and — the decisive factor for most startups — access to the AWS funding. For a credit-eligible company the partner-led review is frequently cheaper than the DIY one, because "free workshop plus credits that fund the fixes" beats "free tool plus you pay for everything you then have to fix."

Rough rule of thumb: self-assess first to get your bearings, then bring in a partner for the review that actually counts — the one before a launch, a funding round, or a security audit, and the one where you want AWS to help fund the remediation. CloudRoute exists for exactly that second review: it routes you to a vetted AWS Well-Architected Partner, the partner runs the funded review, and (where you qualify) the fixes get done largely on AWS’s dime.

VIITurning findings into a remediation roadmap

The review produces a list. The value is in sequencing that list into work that actually happens — highest-risk first, quick wins early, and each item owned and tracked rather than admired in a report.

A good remediation roadmap sorts the HRIs along two axes: severity (how bad if it bites) and effort (how much work to fix). That gives you a natural order:

• 1 — High severity, low effort — Do these immediately. Enabling MFA on root, turning on GuardDuty, fixing an over-permissive security group, switching on automated backups. Hours of work, large reduction in risk. Many are self-funding via the cost pillar.
• 2 — High severity, high effort — Plan and fund these next. Moving a single-AZ database to Multi-AZ, rebuilding IAM around least privilege, standing up a real DR posture. This is the bucket where Well-Architected remediation credits and partner delivery matter most.
• 3 — Medium severity, low effort — Batch these into normal sprints. Tagging clean-up, right-sizing obvious over-provisioning, tightening logging retention.
• 4 — Medium severity, high effort — Backlog with a date. Worth doing, not worth blocking a launch for. Re-evaluate at the next review.

The roadmap should name the AWS services for each fix, attach an owner and a ticket, and set a re-review milestone in the Well-Architected Tool so the next review can prove the HRIs actually closed. When CloudRoute routes a partner-led engagement, this roadmap is the bridge between the review and the funded remediation: the partner files for the remediation credits against the high-severity / high-effort bucket, then delivers the work — for credit-eligible companies, largely AWS-funded — so the most expensive fixes are also the ones AWS helps pay for.