AWS Well-Architected Review (WAFR): the six pillars, how a review works, and who pays.
A Well-Architected Framework Review (WAFR) checks one AWS workload against six pillars: operational excellence, security, reliability, performance efficiency, cost optimization and sustainability. The output is a list of high-risk issues and a plan to fix them. You can run it yourself in the free AWS Well-Architected Tool, or with an AWS partner who runs the workshop and can do the fixes.
- A Well-Architected Review scores one workload against the six pillars of the AWS Well-Architected Framework and flags high-risk issues (HRIs): the gaps most likely to cause an outage, a breach, a runaway bill or an audit failure. It is a diagnostic, not a certification.
- The AWS Well-Architected Tool is available at no cost in the AWS console (AWS Well-Architected page, checked 2026-10-10). A partner-led review adds an experienced reviewer and a workshop that gets honest answers, and the partner can then fix what the review finds.
- A review on its own is not an AWS funding route, and AWS's Well-Architected page lists no credit amount for remediation. If the fixes are part of a migration to AWS, a test or new work on AWS, your matched partner can check MAP, POC or incremental workload (IW) funding, which AWS approves.
IWhat a Well-Architected Review is, and what it is not
The AWS Well-Architected Framework is AWS's written guidance on how to build well on its platform. A review measures one of your workloads against that guidance and records where the gaps are.
A review walks a single workload (not your whole account) through a set of questions per pillar and records honest answers. Optional lenses (for example Serverless, SaaS, Data Analytics, Machine Learning, Financial Services) add domain-specific questions on top of the core set.
It is not a pass or fail certification and not a compliance attestation. There is no "Well-Architected certified" badge. You get a list of issues by severity, with the worst flagged as high-risk issues, and a recommendation for each.
It is also not a one-time event. Re-review a workload at major milestones: before a launch, after a big architecture change, ahead of an enterprise security questionnaire or a raise, and roughly yearly. The Well-Architected Tool keeps milestones so you can see whether last quarter's HRIs were fixed.
IIThe six pillars and what each one checks
Each pillar looks for a different kind of failure. A workload can score well on cost and still be one Availability Zone away from a long outage. Pillar summaries follow the AWS Well-Architected page, checked 2026-10-10.
Source: AWS Well-Architected. AWS publishes a detailed whitepaper for each pillar.
Operational excellence
Running and monitoring systems and continually improving processes. In practice: infrastructure as code, automated and reversible deploys, runbooks, and learning from incidents. The common HRI is production changes made by hand in the console with no audit trail or rollback.
Security
Protecting information and systems: least-privilege IAM, no long-lived credentials, encryption at rest and in transit, central logging (CloudTrail, Config, GuardDuty, Security Hub) and a real incident response plan. This pillar overlaps most with SOC 2 and ISO 27001 evidence.
Reliability
Performing the intended function and recovering quickly from failure: Multi-AZ deployment, defined recovery time and recovery point objectives, tested backups. The classic HRI is a single-AZ database with no tested restore.
Performance efficiency
Using the right resource types and sizes, measuring performance, and keeping it efficient as needs change: right-sized instances, the right compute model, caching, and benchmarks instead of guesses.
Cost optimization
Avoiding unnecessary costs: spend visibility (Cost Explorer, tags, budgets), removing idle resources, right-sizing, and Savings Plans or reserved capacity for steady usage. Startups often find quick wins here. See AWS cost optimization.
Sustainability
Minimizing the environmental impact of running the workload: efficient instance families such as Graviton, efficient Regions, removing waste and right-sizing to real demand. Its advice overlaps heavily with cost and performance.
IIIWhat a review involves: the tool, the workshop, the HRIs
Three parts in sequence: the tool that structures the review, a working session that gets honest answers, and the list of high-risk issues with what to do about each.
The Well-Architected Tool. A service in the AWS console, available at no cost. You define the workload (environment, Regions, lenses) and work through the questions pillar by pillar, ticking the practices you actually follow. The tool flags high-risk and medium-risk gaps and builds an improvement plan with links to AWS documentation. You can run it alone.
The workshop. The difference between a tool exercise and a real review is the conversation. A partner-led review has an experienced reviewer run a working session, often half a day to a few days depending on the workload, and push on each answer: "You ticked encryption at rest. Show me the KMS key policy. Who can decrypt? Is the key rotated?" The honest answers are usually messier than the self-assessment, and that is where the real HRIs come out.
High-risk issues. An HRI is a gap AWS considers likely to cause real harm: an outage, a security incident, data loss or a large avoidable cost. Medium-risk issues are recorded too, but HRIs come first.
The deliverable. A documented set of findings, each HRI tied to a recommendation and the AWS services involved, and a milestone you can re-review against. A good partner adds effort estimates and a sequenced remediation plan.
Reviews are scoped per workload, not per company. Three meaningfully different workloads (say the core API, a data pipeline and an analytics product) means three reviews.
IVWho pays for a review, and where AWS funding fits
Be precise here, because a lot of content about this topic is not. There are three separate costs: the review, the fixes, and the AWS usage the fixes create.
The review. The Well-Architected Tool costs nothing. A partner-led review is the partner's time; ask the partner what it charges for the workshop and get it in writing. AWS's Well-Architected page (checked 2026-10-10) points to the AWS Well-Architected Partner Program for help reviewing workloads. It does not list a remediation-credit amount, so this page does not quote one.
The fixes. Remediation is normal engineering work, done by your team or a partner. AWS funding that a partner can file comes through three routes: MAP when you migrate to AWS, POC funding when you test something (see AWS partner funding), and incremental workload (IW) funding when you are already on AWS and launch new work such as a new product, customer or AI feature. If your fixes are part of one of those, for example a review done as the first step of a migration, or hardening a new workload before launch, your matched partner checks whether it qualifies: typically $50K to $150K for startups. Depends on the workload; AWS approves.
The AWS usage. AWS Activate credits pay for AWS usage, and you apply for them yourself. AWS Activate Founders: $1,000 to start, up to $5,000, for founders with no investor. AWS Activate Portfolio: up to $200,000, with the Org ID or invite from your VC, accelerator or angel group if it is an Activate Provider. A consulting partner cannot file Activate for you, and credits do not pay a partner's invoice.
Nothing. CloudRoute is free for startups. Partners pay CloudRoute a monthly membership plus 10% of AWS-approved funding. We reply within 24 hours; your matched partner reaches out within 5 business days.
VHow to prepare so the review is worth doing
A review where you bluff the answers produces a clean-looking score and no value. Come with the real state of the workload.
- Pick one workload and define its boundary: Usually the production system behind your core product. Be precise about which Regions and accounts it spans.
- Choose the right lenses: Serverless, SaaS or an industry lens sharpens the questions so the findings are relevant.
- Have a current architecture diagram and the real IAM picture: Reconstructing the architecture mid-session is the biggest time sink in a review.
- Pull the evidence in advance: Backup restore tests, CloudTrail, Config and GuardDuty status, tagging and cost reports, incident history.
- Get the right people in the room: Whoever deploys, whoever owns security, and someone who can make decisions.
- Decide what a finding will trigger: Agree up front that HRIs become tracked tickets with owners.
VIDo it yourself, or with a partner
The Well-Architected Tool is free and self-assessment is useful. Whether it is enough depends on what you need the review for.
A self-assessment is a good first pass: it costs nothing, surfaces the obvious gaps and gives you a baseline. Its limit is honesty. Teams over-score themselves on questions they do not fully understand, so the gaps that hurt most are the ones a solo review misses.
A partner-led review adds a reviewer who has seen these failures before, a workshop that forces real answers, and a team that can do the fixes. A sensible sequence: self-assess to get your bearings, then bring in a partner for the review that counts, before a launch, a raise or a security audit.
| Dimension | Self-assessment (Well-Architected Tool) | Partner-led review |
|---|---|---|
| Tool cost | No cost | No cost (same tool) |
| Reviewer | Your own team | Experienced reviewer, often from an AWS Well-Architected Partner |
| Honesty of findings | Limited by what you know | Pushed and checked in the workshop |
| Fixes | You do them or hire | The partner can do them |
| AWS funding for the fixes | Not applicable | Only if the work is part of a migration (MAP), a test (POC) or new work on AWS (IW), and AWS approves |
| Best for | A first baseline | A review before a launch, audit or raise |
VIITurning findings into a remediation plan
The review produces a list. The value is in sequencing it into work that gets done: highest risk first, quick wins early, every item owned.
- 1. High severity, low effort: Do these now: MFA on the root user, GuardDuty on, an over-permissive security group fixed, automated backups switched on.
- 2. High severity, high effort: Plan and fund these next: a single-AZ database to Multi-AZ, IAM rebuilt around least privilege, a real disaster recovery posture.
- 3. Medium severity, low effort: Batch into normal sprints: tag cleanup, obvious right-sizing, log retention.
- 4. Medium severity, high effort: Backlog with a date, and re-check at the next review.
Name the AWS services for each fix, give each an owner and a ticket, and set a re-review milestone in the Well-Architected Tool so the next review shows the HRIs closed. Deep dives: disaster recovery on AWS, AWS landing zone, observability.
The six Well-Architected pillars: what each checks and the classic HRI
The one-line version of each pillar, the AWS services it leans on, and the high-risk issue it most often surfaces.
| Pillar | Core question | Representative AWS services | Classic high-risk issue |
|---|---|---|---|
| Operational excellence | Can you run, observe and improve it? | CloudFormation or CDK, CloudWatch, Systems Manager | Hand-made console changes with no rollback or audit trail |
| Security | Are identity, data and detection handled? | IAM Identity Center, KMS, CloudTrail, GuardDuty, Security Hub | Over-permissive IAM and long-lived static credentials |
| Reliability | Does it stay up and recover? | Multi-AZ, Route 53, Auto Scaling, AWS Backup | Single-AZ database with no tested restore |
| Performance efficiency | Right resources, right size, measured? | Compute Optimizer, ElastiCache, Fargate, CloudFront | Guessed sizing, no benchmarks or caching |
| Cost optimization | Spending only on what matters? | Cost Explorer, Budgets, Savings Plans, tagging | Idle resources and untagged spend |
| Sustainability | Is the environmental impact minimized? | Graviton instances, efficient Regions, right-sizing | Old instance families and over-provisioning |
How a match works (example)
- You tell us about the work
You fill in a short form: what you run today, what you want to move, test or build, your stage and your region.
- We pick one partner
We read your answers and pick one vetted AWS consulting partner that fits the work, the stack and the region. We reply within 24 hours; your matched partner reaches out within 5 business days.
- The partner checks which funding fits
Your matched partner scopes the work with you. Then it checks which partner-filed funding fits: MAP if you are moving to AWS, POC if you want to test something, or incremental workload (IW) funding if you are already on AWS and launching new work.
- The partner files, AWS decides
If the work qualifies, the partner files the funding request with AWS. AWS reviews it and decides. The amount depends on the workload.
- You pay nothing
CloudRoute is free for startups. Partners pay CloudRoute a monthly membership plus 10% of AWS-approved funding.
AWS Activate credits are separate, and you apply for them yourself. Use Activate Founders if no investor backs you. Use Activate Portfolio with the Org ID or invite from your VC, accelerator, incubator or angel group if it is an Activate Provider. A consulting partner cannot apply for Activate on your behalf.
Common questions
What is an AWS Well-Architected Review, in one sentence?
What are the six pillars?
Can I do a Well-Architected Review myself for free?
Does a Well-Architected Review unlock AWS credits?
What is a high-risk issue (HRI)?
How long does a review take, and how do I prepare?
Do I need a separate review for each workload?
How does CloudRoute fit in?
Get a Well-Architected Review that leads to real fixes
CloudRoute matches you with a vetted AWS partner who runs the review workshop, sequences the high-risk issues and can deliver the fixes. If the work is part of a migration, a test or new work on AWS, the partner also checks MAP, POC or IW funding: typically $50K to $150K for startups. Depends on the workload; AWS approves.