An AWS Well-Architected review that leads to useful changes
Use the six pillars to uncover the next architectural risk worth fixing, then turn findings into work your team can finish.
The diagram is the start of the conversation
A system can look tidy on a slide and still be difficult to recover, expensive to operate or unsafe to change. An architecture review becomes useful when it connects those operating realities to the promises made to customers.
AWS’s Well-Architected Framework organizes its guidance around six pillars: operational excellence, security, reliability, performance efficiency, cost optimization and sustainability. This article explains that framework briefly, then offers an original review workflow for a small team.
1. Draw the workload boundary
Choose a specific user-facing service or business process. Identify the components, external dependencies and people who operate it. Bring the service owner and someone who handles incidents; architecture decisions are easier to assess when the people who live with them are present.
Start by writing three things on the diagram: what a successful request does, where important data is stored and which failures would interrupt the service. Mark unknowns instead of quietly treating them as healthy dependencies.
2. Ask across the six pillars
AWS uses the pillars to examine different architectural concerns. Their purpose is to expose trade-offs across the workload rather than optimize a single metric. In particular, reliability includes operation and testing through the system’s lifecycle; sustainability includes using resources efficiently.
- Operations: can the on-call person recognize a failed deployment and reverse it?
- Security: who can access sensitive data, and which evidence explains that access?
- Reliability: which recovery procedure has actually been exercised?
- Performance: what happens to response times when a dependency slows down?
- Cost: which resources have no clear owner or measured purpose?
- Sustainability: where is capacity consistently provisioned without useful work?
The prompts below are worqcloud’s review questions, not a substitute for the official AWS questionnaire.
3. Replace assurances with evidence
Ask for the latest restore exercise, deployment record, permission review and performance observation. “We have backups” is a starting claim; the useful evidence is whether restoration meets the service’s data-loss and recovery requirements.
The AWS reliability guidance emphasizes foundations, resilient design, change management and failure recovery. Our practical recommendation is to walk through one controlled failure scenario and record the gaps between the runbook and the team’s actual response.
Keep exercises proportionate. Begin in a suitable test environment and agree scope, stop conditions and ownership before introducing failure. A review should not become an unplanned production experiment.
4. Prioritize the risk, not the most interesting redesign
An elegant rewrite can absorb the effort needed for a much smaller recovery fix. Rank findings using customer impact, likelihood, detection and recovery options. Note dependencies so an apparently quick change does not hide several weeks of prerequisite work.
For each selected finding, write a concrete acceptance condition. “Improve resilience” is difficult to close. “Restore a recent backup into an isolated environment and demonstrate the agreed recovery target” gives the team a verifiable result.
Make the review a repeatable habit
End with a short improvement backlog, named owners and a follow-up date. Review again after significant changes to traffic, dependencies or service commitments. Keep previous evidence so the next conversation starts from what changed.
The framework provides a structure for judgement. The value comes from the decisions and operating improvements that follow—not from declaring an architecture finished.