Three different things get called an "AWS Well-Architected review," and they cost three different amounts: nothing, nothing-with-strings, and real money. Picking the wrong one wastes either your time or your budget. Here is what each one actually is.
The free tool is real — use it
The AWS Well-Architected Tool is a service in the AWS console. It is free. You define a workload — a name, an environment, the regions it runs in — then answer several dozen questions across the six pillars: Operational Excellence, Security, Reliability, Performance Efficiency, Cost Optimization, and Sustainability.
The questions are concrete. "How do you manage identities for people and machines?" Each one is a checklist of practices; the ones you leave unchecked drive the risk rating. Skip enough and the tool flags a high risk issue (HRI) or medium risk issue (MRI) and links you to the relevant guidance. You can save milestones to track progress between runs, and add lenses — Serverless, SaaS, and others — for domain-specific questions.
This is genuinely useful. It is a structured tour of everything AWS believes can go wrong with a workload, distilled from watching workloads fail at scale. If you have never run it against your production workload, do that before you pay anyone for anything.
Its limit is structural: the tool records what you say, not what is true. Nothing in it inspects your account. (A Trusted Advisor integration can surface some automated checks next to the questions, but the answers remain yours.) The output is a self-assessment — a mirror, not an audit. If the person answering believes the backups are tested, the tool believes it too.
Partner-led free reviews: read the incentive
The second thing sold as a "free Well-Architected review" is a partner-led WAFR. An AWS partner engineer books a session or two, walks your team through the same tool questions, and records the answers.
It is free because AWS funds it. The Well-Architected Partner Program ties partner standing to reviews delivered and high risk issues remediated, and AWS has offered customers service credits contingent on fixing the HRIs a review finds. The exact amounts and terms change; the structure does not: the partner is rewarded when the review turns into remediation work, and the credits typically arrive when you buy that work.
None of this makes the review dishonest. A good partner engineer asks sharper follow-up questions than you would ask yourself, and the credits are real money if you were going to fund remediation anyway. But be clear about what you are getting: the same self-reported questionnaire, guided, with a sales motion attached. The answers are still interview answers. Nobody pulled your CloudTrail logs.
What a paid, evidence-backed review adds
One word: verification. Instead of asking whether access keys get rotated, pull the IAM credential report and read the key ages. Instead of asking whether anything reaches the internet that shouldn't, query AWS Config for the security groups and bucket policies that answer it. Instead of asking what the workload costs, read the Cost and Usage Report line by line.
Concretely, a paid review should give you:
- Findings verified against evidence. CloudTrail for what actually happened, AWS Config for how resources are actually configured, the CUR for what you actually spend — collected under read-only access (the ViewOnlyAccess and SecurityAudit managed policies, no write permissions).
- Scored findings. Each one rated for severity and remediation effort, so the order of work is an argument you can defend, not a feeling.
- Target architectures. Not "improve resilience" — a diagram of the state to move toward and what changes between here and there.
- A remediation roadmap. Sequenced, dependencies called out, effort estimated, written so an engineer can start Monday.
- Security-questionnaire mapping. Findings mapped to the questions enterprise customers and SOC 2 auditors actually ask, so evidence collected once gets reused.
The gap between self-assessment and evidence is the gap between "we believe our S3 buckets are private" and "here is the Config query that checked all of them, and the two it caught."
When free is the right choice
Often. Specifically:
- Small footprint. One account, a handful of services, an architecture one person holds in their head. Self-assess.
- You have the time. A senior engineer with the tool and a focused week will find most of what matters.
- No external pressure. No enterprise deal, no auditor, no diligence process asking for proof. A self-assessment that drives real fixes beats a report nobody reads.
- You already planned to buy remediation. Then a partner-led WAFR is rational — take the credits; that is what they exist for.
When paid earns its price
- A customer sent a security questionnaire, or SOC 2 is on the calendar. Self-attestation satisfies neither.
- Diligence is coming, and someone will ask "are we OK on AWS" — and wants an answer that did not come from the team being evaluated.
- You have run the free tool twice and the same HRIs are still open. You need scoring and a roadmap with a name on it.
- Nobody internal has the slack to be honest with the checkboxes. Self-assessments fail quietly this way — not through lying, through optimism.
Run the free tool first. It costs an afternoon and it will teach you the framework. Pay for a review when the findings need to survive contact with an auditor, a customer, or an acquirer.
If you need the evidence-backed version — fixed price from $8,500, read-only access, sample report published — see our Well-Architected Review.