Well-Architected Review: what an audit really finds, notes from the field

“We’re pretty well architected, we follow AWS best practices.” That’s roughly the opening line in 9 out of 10 audits at Distribuée. Then we run a Well-Architected Review (WAR), and two hours later the engineering team has a list of 8 to 12 issues they had no idea existed. It’s not a judgment on the team — it’s the format of the exercise itself that surfaces blind spots a code audit or a Terraform review will never catch.

This article walks through what we actually find on engagements, how the AWS funding program that can cover part of the cost works, and the method to turn results into an action plan instead of a report gathering dust.

What a Well-Architected Review actually is, in two minutes

The AWS Well-Architected Framework rests on 6 pillars: Operational Excellence, Security, Reliability, Performance Efficiency, Cost Optimization, Sustainability. The AWS Well-Architected Tool (free, built into the console) walks a workload through a series of questions per pillar, and classifies each gap into two severity levels:

• HRI (High Risk Issue): an architectural choice that could have significant impact — data loss, extended outage, security exposure, budget blowout
• MRI (Medium Risk Issue): a real gap but less critical in the short term

The session itself is designed to be lightweight: AWS describes it as “a conversation, not an audit,” meant to take hours, not days. In practice, a full review — prep, sessions across all 6 pillars, HRI prioritization, initial improvement plan — spans 2 to 4 calendar weeks, for a few days of actual working time.

What we actually find, notes from the field

On first-time reviews of an account, the observed average is 5 to 12 High Risk Issues — consistent with what we see on engagements with SMBs of 20 to 150 people who thought they’d “cleaned house.” The most frequent, in order of recurrence:

• Missing or partial MFA on the root account — often the root account doesn’t even have hardware MFA, just a password sitting in a shared password manager
• Database with no tested automated backup — the backup exists, but nobody ever ran an actual restore to confirm it works
• Stateful service running single-AZ — the database or Redis cache runs in a single availability zone, invisible until there’s an incident
• S3 bucket with unintentional public access — usually a logs or assets bucket created in a hurry, never reviewed since
• No documented, tested disaster recovery plan — the plan exists on paper, never actually run

The common thread: these are risks that are invisible in normal operation. They break nothing day-to-day, so nobody prioritizes them — until the incident that exposes them at the worst possible time.

AWS funding: up to $5,000 in credits

An underused lever for most SMBs: AWS partly funds remediation through the AWS Well-Architected Partner Program. How it works today:

1. An accredited AWS partner (like Distribuée) runs the review with you on the AWS Well-Architected Tool
2. Identified HRIs get documented in a remediation plan
3. Once 45% of HRIs are remediated, the company becomes eligible for a $5,000 Service Credit Voucher, applied to the next AWS bill

It isn’t automatic — the request goes through the AWS Partner Funding Portal, and the partner needs an active program status. But for an SMB that’s going to fix these gaps anyway (MFA, backups, encryption), it’s direct funding for remediation that’s rarely tapped simply because it’s not widely known.

The method that avoids a report gathering dust

The real risk of a WAR isn’t finding nothing — it’s finding 40 items, producing a PDF report, and watching 35 of them never get addressed. Three rules we apply on engagements:

Prioritize Security and Reliability first. HRIs in these two pillars represent the most concrete short-term risk (data loss, security incident). Performance, cost, and sustainability come after — unless a cost HRI crosses a threshold that justifies immediate action.

Fix HRIs in weeks, not quarters. A typical “missing MFA” HRI takes an hour to fix. Filing it into a quarterly backlog is accepting the risk without saying so.

Re-run the review every 12 to 18 months, not once for show. Architecture moves — new services, new teams, new debt. A WAR frozen in 2024 says nothing about the real state of the account in 2026.

What the tool doesn’t replace

The Well-Architected Tool guides the conversation, but it doesn’t know your business context or real constraints. Two limits we see consistently:

• Self-reported answers skew optimistic. Without technical proof (a screenshot, a Config export, a CLI query), a team will answer “yes, we encrypt everything” without having checked the last bucket created three months ago.
• Specialized lenses aren’t enabled by default. AWS offers lenses for SaaS, serverless, AI/ML, IoT — relevant depending on your stack, but they need to be added explicitly to the review.

That’s why we run WARs on engagements with technical verification running alongside the self-reported answers — AWS accounts, IAM Credential Report, Config Rules — rather than a questionnaire ticked off in a meeting.

Conclusion

A Well-Architected Review isn’t just another compliance exercise. It’s the fastest way to surface the 5 to 12 risks a competent engineering team no longer sees, because they’ve become invisible through familiarity. Add the AWS funding available for remediation, and the opportunity cost of skipping it far outweighs the cost of running it.

For more on turning the resulting technical controls into an automated setup, our article on preparing a SOC2 audit on AWS covers automation via Security Hub, GuardDuty, and AWS Config.

If you want to know what a Well-Architected Review would surface on your account, it’s the starting point of our DevSecOps Audit — plan on half a day for the session, with a prioritized improvement plan as output.