Most engineers I talk to know the Well-Architected Framework exists. Fewer have actually read it with the goal of changing how they think — rather than ticking a box for a client engagement or certification exam.
I've done a fair number of Well-Architected Reviews at this point, and there are a handful of genuinely high-signal ideas buried in the pillars that I keep coming back to.
The Operational Excellence pillar isn't about dashboards
The instinct is to treat Operational Excellence as "build some monitors, set some alarms, write a runbook." But the pillar's most important idea is subtler: make operations procedures a form of code.
If the way you respond to incidents lives only in the heads of your senior engineers, you've built a bus-factor problem into your ops. Every runbook, every escalation path, every recovery procedure — these should be written down, version-controlled, regularly tested, and iterated on.
The exercise of writing an incident playbook forces you to discover the answers to questions you didn't know you hadn't answered. What does a graceful degradation actually look like for this service? Who owns the decision to roll back? What's the definition of "recovered"?
The Reliability pillar is really about assumptions
The Most important question the Reliability pillar asks is: what have you assumed will not fail?
Every system has implicit assumptions. We assume the database is reachable. We assume DNS resolves. We assume the third-party payments API is up. The Well-Architected review surfaces those assumptions and asks: what happens to your system when each one is wrong?
This is where Game Days and chaos engineering earn their keep. Not as performance art for your operations team, but as a structured way to discover which assumptions are load-bearing and which are real guarantees.
Cost Optimisation is a feedback loop, not a one-off exercise
Teams often treat a cost optimisation exercise as a project: review spending, make some cuts, close the ticket. The WAF's recommendation is to treat cost visibility as a continuous feedback loop built into your development process.
This means:
- Tagging every resource with the team and service it belongs to
- Reviewing cost per feature, not just per account
- Making cost a factor in architectural decisions at design time, not post-hoc
I've seen teams spend 40% more than necessary on AWS because they provisioned for peak load without implementing any form of auto-scaling. It's not that they didn't know auto-scaling existed — it's that cost wasn't visible at the point in time when the architecture decision was made.
The question I add to every review
The five pillars of the WAF are well documented. The question I find most useful to add to the formal assessment is one that isn't on the checklist:
"If this service went completely dark right now, what would break for users, and in what order?"
Working backwards from user-visible failure gives you a dependency map and a severity ranking that generic pillar questions don't. It also grounds the architectural discussion in product outcomes, which makes it easier to get buy-in from stakeholders who don't care about high availability in the abstract.
The Well-Architected Framework won't tell you how to build your system. What it will do, if you engage with it as a set of engineering principles rather than a checklist, is give you a structured vocabulary for the trade-offs that matter.
That vocabulary — around failure modes, operational maturity, cost visibility — is genuinely useful regardless of whether you're a team of two or two hundred.