The AWS Well-Architected Framework organises its guidance into pillars. Name the pillars and say what each one asks about a workload.

## 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.