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.