Not an audit. A structured conversation.
The AWS Well-Architected Framework is published documentation: a set of foundational questions, grouped into six pillars, that measure one workload against cloud practice. Working through them surfaces the choices that will cost you later — and AWS is explicit that the process is "a constructive conversation about architectural decisions, and is not an audit mechanism."
What comes out is a graded list. AWS's own tooling classifies findings as High Risk Issues (HRIs) and Medium Risk Issues, and provides an improvement plan against them. A workload is not one thing, so the review is scoped to one — a customer-facing application, a data platform, a specific account. Then the work begins.
Six pillars — and what breaks without each one.
Open a pillar for what it covers, the failure mode that follows from skipping it, and the work we do about it. These are engineering consequences, not predictions about your business.
Reviews are widely available. So what is the money for?
The framework is public and the AWS Well-Architected Tool is free to use, so it is a fair thing to ask. The answer is that the price is not for the list.
Closing a finding is engineering: IAM to re-scope, networks to segment, a restore to actually perform, a pipeline to rebuild so the fix cannot regress. That work — not the list — is what this engagement is built around. Ours is also an independent review — we run it against AWS's published framework, we are not doing it under anyone's program, and the findings are ours to stand behind.
So, plainly, what the starting price covers: the review across all six pillars, the graded findings report, and a selection of quick wins taken off that list — which ones depends entirely on what the review turns up. It is not a promise to remediate every finding for a flat fee. Anything larger gets scoped from the findings and quoted separately, against work we have both now seen.
A pass across all six pillars, findings graded High and Medium risk, and a prioritised backlog with effort and impact against each one. Yours to keep whatever happens next.
A selection of the findings — the ones worth doing straight away, chosen from what the review actually turned up — come back as reviewable pull requests in your repositories, with the infrastructure changes as code. Your team reviews and merges them, so the fix and the knowledge both stay. The heavier items are scoped from the same backlog and quoted separately.
This is block 02 of seven — see the full set of accelerators for what else can be sequenced around it.