The six Well-Architected pillars
The AWS Well-Architected Framework is the architect's repeatable checklist. It helps expose risk; it is a conversation, not a punishment.
Six lenses for every decision
| Pillar | Child-simple question | Typical evidence |
|---|---|---|
| Operational excellence | Can we run and improve it? | automation, runbooks, telemetry |
| Security | Is it protected? | identities, encryption, detection |
| Reliability | Does it recover? | redundancy, tested recovery |
| Performance efficiency | Is the right tool doing the job? | load tests, right sizing |
| Cost optimization | Are we wasting money? | allocation, budgets, unit cost |
| Sustainability | Are we doing less work for the same result? | efficient code and resources |
A useful review rhythm
At discovery, record assumptions and high-risk choices. Before production, review all six pillars and assign owners and dates to serious risks. In production, use real telemetry, incidents, and spend to update the review.
Trade-offs are normal
More redundancy improves reliability but usually raises cost. Encryption and inspection add small performance and operational costs but reduce security risk. A serverless design reduces infrastructure operations but can introduce quotas, startup latency, and tighter service coupling. The architect makes the trade-off explicit and links it to the business goal.
The answer pattern
For any architecture question:
- State the requirement and constraint.
- Name the failure or threat.
- Propose the design.
- Explain why it meets the requirement.
- State the cost or limitation.
- Explain how it will be tested and observed.
Review prompt
Do not ask only “Is it available?” Ask: “Which component can fail, what will the user see, how quickly will detection happen, who responds, and what proof shows recovery works?”
Official source: AWS Well-Architected Framework.