AWS Well-Architected Framework

TL;DR

• The Well-Architected Framework organizes architecture evaluation into six pillars: Operational Excellence, Security, Reliability, Performance Efficiency, Cost Optimization, and Sustainability.
• The pillars are not independent — improving one routinely degrades another (more redundancy costs more, tighter security adds latency and operational overhead).
• A Well-Architected Review (WAFR) is a point-in-time snapshot, not a permanent certification — architecture drift and new services reintroduce risk after the review closes.
• Trusted Advisor provides automated, always-on best-practice checks; it does not replace a structured, workload-specific human review.
• Findings without an owner and a date are functionally equivalent to no findings — they will still be open at the next review.

Core Concepts

The six pillars

• Operational Excellence — the ability to deploy, observe, and roll back a workload without dependence on one individual’s undocumented knowledge. The real test of a runbook is whether someone other than its author can execute it successfully during a live incident, not whether it exists.
• Security — least privilege, defense in depth, and the capacity to detect and respond, not merely prevent. A workload with airtight IAM but no GuardDuty/CloudTrail visibility still fails this pillar under a real audit, because prevention alone does not cover the case where a control is bypassed or misconfigured.
• Reliability — whether the workload recovers automatically from the failure modes it is actually expected to encounter (AZ loss, dependency timeout, bad deployment), and whether that recovery has been tested, not just designed on paper. An untested failover path is a hypothesis.
• Performance Efficiency — right-sizing for the current traffic pattern, not a traffic pattern from a prior stage of the workload’s life. Instance types and capacity chosen once during a proof of concept and never revisited are a frequent source of drift here.
• Cost Optimization — cost visibility and cost control are distinct capabilities. Tagging and Cost Explorer provide visibility; Savings Plans, right-sizing, and lifecycle policies provide control. A workload commonly has one without the other.
• Sustainability — the newest pillar and the most frequently skipped in practice, but it converges with cost and performance efficiency more often than assumed: a right-sized, efficiently utilized fleet is typically both cheaper and lower-carbon.

The cross-pillar trade-off model

The pillars actively pull against each other rather than operating in isolation. More redundancy (Reliability) increases spend (Cost Optimization). More granular IAM policies and encryption (Security) add latency and operational overhead (Performance Efficiency, Operational Excellence). A review that fails to surface these tensions and force an explicit, documented decision produces a list of “best practices” with no prioritization — which is not materially different from producing no findings at all.

Running a review

1. Start from business context, not the architecture diagram: the actual availability target, the actual budget ceiling, the actual compliance requirement. Reviews that start from the diagram tend to optimize the wrong variable.
2. Walk each pillar and force an explicit trade-off decision wherever two pillars conflict. Record it as an Architecture Decision Record, not a verbal agreement that evaporates within a week.
3. Use Trusted Advisor and AWS Config as the automated first pass (idle resources, open security groups, unencrypted volumes), so the human conversation focuses on judgment calls a script cannot make.
4. Classify every finding as High/Medium/Low risk with a named owner and a target date. An unowned finding remains open at the next review by default.
5. Set the re-review cadence to change velocity, not a fixed calendar interval. A workload shipping weekly needs review more frequently than one that is stable and low-change.

Common Pitfalls

• Pitfall: Treating a passed review as a permanent certification. Why: A WAFR is a snapshot; architecture drift and new services after the review reintroduce risk. Fix: Schedule reviews on a recurring cadence tied to the workload’s change velocity, not as a one-time gate.
• Pitfall: Optimizing one pillar in isolation, most often Cost. Why: Pillars are coupled — cost cuts frequently remove redundancy, degrading Reliability. Fix: Evaluate every optimization for its effect on the other five pillars before implementing it.
• Pitfall: Running the review without the people who operate the workload day to day. Why: Their absence produces a theoretical discussion disconnected from operational reality. Fix: Require operators, not only architects, in the review room.
• Pitfall: Generating a long list of findings with no owners or dates. Why: Unowned findings have no forcing function to get resolved. Fix: Assign an owner and a target date to every finding at the time it is raised.

Interview Questions

• Provide a concrete example where improving one pillar degraded another, and describe how it was resolved — tests whether the trade-off model is understood specifically, rather than answered with a generic “security vs. usability” response.
• Explain how a Well-Architected Review differs from what Trusted Advisor already reports automatically — tests whether the candidate distinguishes the automated-check layer from the human-judgment layer.
• A stakeholder wants to defer Security pillar findings to hit a launch date — how should this be handled? — tests whether a technical position can be held under business pressure without becoming obstructive.
• Map a set of findings (missing RTO/RPO, no load test, no cost tags) to the pillars they belong to — tests whether the six pillars are understood as distinct, applicable categories rather than an abstract list.