A Well-Architected Review is often positioned as a compliance exercise. Done properly it is closer to a structural survey: an independent read of what will fail, what it will cost, and what to do about it in what order.
What the six pillars actually surface
| Pillar | What we look for | Most common finding |
|---|---|---|
| Operational excellence | Deployment, observability, runbooks, incident process | No SLOs, so no shared definition of 'working' |
| Security | Identity, network boundaries, data protection, detection | Standing administrative access nobody has reviewed |
| Reliability | Failure isolation, recovery, capacity, dependencies | Recovery procedures that have never been executed |
| Performance efficiency | Resource selection, scaling, monitoring | Instance families chosen years ago and never revisited |
| Cost optimisation | Consumption, commitments, allocation | Non-production running 168 hours a week |
| Sustainability | Utilisation, region and hardware selection | Low utilisation across an over-provisioned fleet |
A targeted review of two or three pillars is available where the concern is already known.
How the two weeks run
- Days 1–2: Read-only access configured; automated discovery across accounts
- Days 3–6: Workshops per pillar with your architects and operations team
- Days 7–8: Analysis, findings drafted, severity and effort scored
- Days 9–10: Findings walkthrough, prioritisation with your team, final report
The workshops matter more than the automated scanning. Tooling tells you what is configured; only the conversation tells you what was deliberate, what was a workaround, and what nobody remembers deciding.
Read-only access to the accounts in scope, and roughly ten hours total across your architecture and operations people. Less than that and the findings are shallower.
What you receive
- A findings register with severity, effort and pillar for each item
- A prioritised remediation backlog written as actionable tickets, not recommendations
- A quantified cost-optimisation opportunity with the analysis behind each number
- An executive summary that a non-technical sponsor can act on
- The raw analysis and queries, so your team can re-run any of it
The remediation backlog is the artefact that matters. Findings that are not expressed as work someone can pick up next sprint tend not to become work at all.
A review that produces a report is an expense. A review that produces a backlog is an investment.
How findings are prioritised
Every finding is scored on risk — likelihood and consequence — and on remediation effort. Plotting them produces four groups, and the sequencing follows from that:
| Group | Characteristics | Sequencing |
|---|---|---|
| Fix now | High risk, low effort | Immediately; often within the review period |
| Plan | High risk, high effort | Next quarter, with dedicated capacity |
| Batch | Low risk, low effort | Bundle into ordinary sprint work |
| Accept | Low risk, high effort | Document the acceptance and revisit annually |
The 'accept' group matters — explicitly accepting a finding is a legitimate outcome, and better than an ignored backlog item.
After the review
You can execute the backlog yourself, have us execute all or part of it, or use the report to scope a competitive procurement. We are genuinely comfortable with all three, and we price the review as a standalone engagement precisely so it is not a sales device.
Where the review is delivered under the AWS Well-Architected Partner Program, funding may offset some or all of the cost. We confirm that at qualification rather than implying it.
Two weeks to know what is actually wrong
Fixed price, read-only access, no disruption to production, and a backlog your team can start on the following Monday.