well-architected-review

Well-Architected Review

A well-architected review is worthless if it produces a scored checklist nobody acts on. The pillars — reliability, security, cost, performance, operational excellence, sustainability — exist in tension with each other, and the point of the review is to surface where a system has silently picked a tradeoff nobody signed off on, then rank what to fix.

Treat the review as a prioritization exercise, not a grading exercise. A review that doesn't end in an ordered, owned list of changes was not worth running.

For the full pillar-by-pillar question checklist, read references/review-checklist.md.

1. Scope the review to a system, not the whole estate

A review of "everything" produces shallow findings on everything and depth on nothing. Pick one system or one bounded set of services, understand its actual traffic and failure history, and review that deeply. Repeat for other systems on a cadence rather than trying to cover the whole estate in one pass.

Done when: the review's scope and boundary are written down before the first pillar is assessed.

2. Assess each pillar against evidence, not intent

For each pillar, ask what actually happens, not what the design intends:

• Reliability — has the stated failure domain (see cloud-architecture) actually been tested, and does disaster-recovery and chaos-engineering coverage exist for it?
• Security — is access scoped by iam-access-management, are secrets handled per secrets-management, has vulnerability-management run recently?
• Cost — does spend match the cost-optimization and resource-tagging expectations, or has it drifted?
• Performance — is there load-testing evidence at expected peak, not just steady state?
• Operational excellence — do runbooks exist and match reality, is on-call-management sane for this system's incident volume?
• Sustainability — is compute and storage rightsized (rightsizing), or is idle capacity running because nobody's looked?