The AWS Well-Architected Framework organises its guidance into pillars. Name the pillars and say what each one asks about a workload.
answer
- Six of them, not five
- One is newer than the rest
- Ops, security, reliability, performance, cost
- The sixth one is environmental
- They deliberately trade against each other
basics
~10 sThe AWS Well-Architected Framework has six pillars: Operational Excellence, Security, Reliability, Performance Efficiency, Cost Optimization and Sustainability. Each pillar groups design questions and best practices used to assess a workload from one angle.
solid answer
~40 sThere are six pillars. **Operational Excellence** asks how you run, monitor and continuously improve the workload — deployment, runbooks, learning from incidents. **Security** covers identity, traceability, protecting data in transit and at rest, and incident response. **Reliability** asks whether the workload does its job consistently and recovers from failure. **Performance Efficiency** asks whether you are using the right resource types and adapting as demand and available services change. **Cost Optimization** asks whether you get the business value at the lowest sustainable price. **Sustainability**, added in 2021, asks about the environmental impact of what you run. The pillars deliberately pull against each other — cross-AZ redundancy buys reliability and costs money — so the value of walking them is that the tradeoff gets stated out loud instead of made by accident.
go deeper
Be able to name all six pillars without hesitating, and give a one-line description of each. Say plainly that this is guidance and a review process, not a certification you pass or fail.
An interviewer expects you to apply the pillars to a diagram on the spot: one concrete concern per pillar for the architecture in front of you, phrased as a question you would ask the team that built it.
Show that you use the pillars to force tradeoffs into the open. Give a real example where you accepted a lower position on one pillar — cost, usually — with a stated business justification behind the decision.
Own the question of which pillars your organisation actually weights and why. Be ready to argue where the framework's generic guidance is wrong for your context, and how you would encode that disagreement rather than quietly ignoring it.
## What the framework actually is The AWS Well-Architected Framework is written guidance, not a product. AWS publishes a whitepaper per pillar plus a structured set of *design questions*, each listing best practices underneath it. Nothing enforces it, nothing certifies you, and reading it costs nothing. It exists so that the conversation "is this architecture any good?" has an agreed shape instead of turning on whoever in the room is most senior. In an interview the pillars are useful as a *thinking structure*. When someone puts a diagram in front of you and says "critique this", walking the six pillars gives you six angles you will not forget under pressure. ## The six pillars **Operational Excellence.** Can you run this thing day to day and get better at running it? Design questions here are about how teams are organised and how they know the workload is healthy, how changes are made small and reversible, how failures are anticipated, and how you learn from operational events. This is the pillar people skip, and it is usually the one that decides whether an incident lasts ten minutes or ten hours. **Security.** Protecting data, systems and assets. Its themes are a strong identity foundation (short-lived credentials over long-lived keys), traceability (log and audit what happened), security applied at every layer rather than only at the perimeter, protecting data in transit and at rest with classification driving the controls, keeping people away from raw data, and preparing for incidents before you have one. **Reliability.** Does the workload perform its intended function correctly and consistently, and does it recover? Themes: recover automatically from failure, test recovery procedures rather than assume them, scale horizontally to reduce the blast radius of any single component, stop guessing capacity, and manage change through automation. **Performance Efficiency.** Are you using computing resources efficiently, and do you keep doing so as demand and the available services change? This covers picking the right resource type and size for the job, going global where latency demands it, using managed services so that hard problems are somebody else's, and measuring rather than assuming. **Cost Optimization.** Are you delivering the business value at the lowest sustainable price? Themes: expenditure awareness (you cannot control what you cannot attribute), adopting a consumption model, selecting the right resource and pricing model, and analysing spend over time rather than once at launch. **Sustainability.** Added in 2021 as the sixth pillar. It asks about the environmental impact of running the workload: maximising utilisation of what you provision, adopting more efficient hardware and software offerings as they appear, reducing the downstream impact of your service on the devices your users run, and setting sustainability goals you actually measure. ## The pillars are meant to conflict A common misreading is that a good architecture maximises all six. It cannot. Running three Availability Zones instead of one improves reliability and increases cost. Caching aggressively improves performance efficiency and complicates correctness. Encrypting everything with customer-managed keys strengthens security and adds an operational burden plus key-management charges. The framework's real contribution is that it turns those into recorded, deliberate decisions with a stated business justification. "We accepted a single-AZ database because this is an internal reporting tool with a four-hour recovery objective" is a Well-Architected answer. "We never thought about it" is the thing a review is designed to surface. ## How the pillars get used in practice The pillars are operationalised as *lenses*: the base AWS Well-Architected Framework lens contains the pillar design questions, and additional lenses — serverless, SaaS, data analytics, machine learning and others, plus custom lenses you write yourself — add questions specific to a technology or industry on top. A review answers those questions for one named workload, and unselected best practices become rated risks with an improvement plan attached. ## What an interviewer is checking Two things. First, that you can name the pillars without groping — it signals you have been near a real AWS design review. Second, and worth far more, that you can *use* them: given an architecture, produce one concrete concern per pillar and say which tradeoff you would accept. Reciting six nouns and stopping is a weaker answer than naming five and immediately applying them.
- Which pillar is the newest, and why was it added separately rather than folded into Cost Optimization?Sustainability, added in 2021. It overlaps with cost — idle capacity is wasteful in both senses — but not completely. Choosing a Region for lower carbon intensity, or reducing the work done on users' devices, are sustainability decisions that a purely financial lens would never surface, so AWS gave it its own design questions.
- An architecture scores well on every pillar except Cost Optimization. Is that a problem?Not necessarily. The framework is a set of tradeoffs, not a score to maximise. A regulated payments workload may accept a deliberately expensive design for reliability and security. What matters is that the cost position is a recorded decision with a business justification behind it, not an oversight nobody has looked at.
- Where do the pillars actually show up when you sit down to do a review?As design questions inside a lens. The base AWS Well-Architected Framework lens groups its questions by pillar, and each question offers best practices you either select, leave unselected, or mark as not applicable. Additional lenses layer technology- or industry-specific questions on top of the same pillar structure.
saying these in an interview costs you the question
- Says there are five pillars and omits Sustainability
- Treats the framework as an AWS certification or compliance standard
- Claims a good architecture maximises every pillar at once
- Confuses Performance Efficiency with Cost Optimization
- Names the pillars but cannot apply one to a real design