The AWS Well-Architected Framework, and how its six pillars differ

Why this matters

"Is this a good design?" is a hard question to answer without a shared yardstick. One engineer cares about uptime, another about the bill, a security lead about permissions, and each can call the same system good or bad. The AWS Well-Architected Framework is AWS's yardstick: a common language that lets technical and non-technical people discuss a workload's strengths and risks in the same terms.

You do not need to be an architect to use it. A manager can ask which pillar a proposed change serves. A salesperson can explain that a customer's outage was a reliability problem, not a security one. A junior engineer sitting in a design review will hear the pillar names constantly, and needs to know which concern each one covers.

The Framework also has a practical edge. Many cloud decisions trade one pillar against another, such as more redundancy for higher cost, and naming the pillars makes the trade-off visible instead of accidental.

The lesson

AWS Well-Architected Framework

The AWS Well-Architected Framework is a body of guidance for designing and running workloads in the cloud. A workload is a set of components that together deliver business value, such as an online shop or a payroll system. The Framework contains design principles, best practices and a set of review questions, organised into six pillars.

Three facts about what it is, and is not:

• It is guidance, not a service. Nothing is deployed by it. Deploying infrastructure from templates is AWS CloudFormation's job, which is a different thing.
• It is not a certification. AWS does not use it to certify or approve workloads, and it is not a compliance report.
• It applies to any workload, whatever services it uses, not only to Amazon EC2. It sits alongside the shared responsibility model (lesson 6) rather than replacing it.

To run a review in practice, a company uses the AWS Well-Architected Tool in the AWS Management Console. The tool walks through the Framework's questions pillar by pillar, records the answers, highlights risks and tracks an improvement plan over time. Do not confuse it with AWS Trusted Advisor, which runs automated checks against the resources in an account, or with AWS Compute Optimizer, which recommends better-sized compute. Neither leads a question-by-question review of a workload.

The Framework also has general design principles that apply across all six pillars:

• Stop guessing your capacity needs. Use as much or as little as the workload needs, instead of buying for a forecast peak.
• Test systems at production scale. Build a full-size test environment on demand, then remove it.
• Automate, so that trying a different architecture is cheap and repeatable.
• Let the architecture evolve. Favour small, frequent changes over large, infrequent releases, and do not freeze a design once it is live.
• Drive architectures using data. Measure, then decide.
• Improve through game days. Rehearse events such as failures or traffic surges to see how the system and the team respond.

The six pillars and their design principles

There are six pillars, best remembered in pairs: operational excellence and security; reliability and performance efficiency; cost optimization and sustainability. AWS spells the pillar and principle names in American English, so they appear that way here. Each pillar has its own design principles, and naming the principle is a common way a scenario points to its pillar.

Operational excellence is about running and monitoring workloads, and continually improving the processes and procedures behind them. Its principles include organising teams around business outcomes, implementing observability for actionable insights, safely automating where possible, making frequent, small, reversible changes, refining operations procedures frequently, anticipating failure, learning from all operational events and metrics, and using managed services. A team that updates its runbooks (written operating procedures) often and holds regular game days to check them is refining operations procedures.

Security is about protecting data, systems and assets from unauthorised access. Its principles are:

• Implement a strong identity foundation: least privilege, meaning each user gets only the permissions they need, with identities managed centrally.
• Maintain traceability: log and monitor actions, such as every API call, so they can be traced and audited.
• Apply security at all layers: defence in depth, with controls at the network edge, in the VPC (virtual private cloud), on each instance, in the code and on the data, rather than one firewall.
• Automate security best practices.
• Protect data in transit and at rest, for example with encryption and access controls.
• Keep people away from data, reducing direct human access.
• Prepare for security events, with incident response that is planned and practised.

Reliability is about a workload performing its intended function correctly and consistently, and recovering when something fails. Its principles are automatically recover from failure, test recovery procedures (simulate failures to prove recovery works before a real failure does), scale horizontally to increase aggregate workload availability (many small resources instead of one large one, so no single resource is a point of failure), stop guessing capacity, and manage change through automation. Running across several Availability Zones, and backing up data so it can be restored, are reliability practices.

Performance efficiency is about selecting and using computing resources that meet the workload's requirements, and staying efficient as demand and technologies change. Its principles are:

• Democratize advanced technologies: consume complex technologies, such as machine learning, as managed services, so the team needs no deep expertise.
• Go global in minutes: deploy in Regions close to users for lower latency with little effort.
• Use serverless architectures: remove the need to run and maintain servers.
• Experiment more often: try new instance types, storage and configurations.
• Consider mechanical sympathy: use the technology that best matches how the workload uses it.

Choosing compute that meets the workload's needs, or moving from an older instance family to a newer, faster one, falls here.

Cost optimization is about delivering business value at the lowest price, by avoiding unnecessary spending. Its principles are:

• Implement Cloud Financial Management: build the skills and processes to manage cloud cost.
• Adopt a consumption model: pay only for what is needed, for example by shutting down development environments outside working hours.
• Measure overall efficiency: compare the business output of a workload with what it costs.
• Stop spending money on undifferentiated heavy lifting: let AWS run data centres and managed services so the money goes on the business.
• Analyze and attribute expenditure: measure usage and assign cost to the teams and products that cause it, for example by tagging resources with a cost centre.

A monthly bill review that removes idle resources and moves steady workloads to cheaper pricing models is cost optimization.

Sustainability is about minimising the environmental impact of running cloud workloads, including the energy they use. Its principles are understand your impact, establish sustainability goals, maximize utilization (fewer resources running busier, such as consolidating lightly used servers), anticipate and adopt new, more efficient hardware and software offerings, use managed services, and reduce the downstream impact of cloud workloads. Responsibility here is shared: AWS is responsible for sustainability of the cloud, such as efficient data centres and hardware, and the customer is responsible for sustainability in the cloud, through its own design choices.

How the pillars differ from one another

The pillars overlap, and most exam distractors sit in the overlap. Decide by the stated goal of the scenario, not by the action alone.

Cost optimization or sustainability? Cost optimization is about spend; sustainability is about environmental impact. Removing idle resources helps both, so read the aim: "reduce the bill" is cost, "reduce energy use" is sustainability. Sustainability is a pillar of its own, not part of cost optimization. "Measure overall efficiency" sounds like sustainability but belongs to cost optimization, and "maximize utilization" belongs to sustainability.

Reliability or operational excellence? Reliability is about the workload recovering and functioning consistently through failure. Operational excellence is about how people run, monitor and improve operations. A game day that checks runbooks is operational excellence; simulating a failure to prove the workload recovers is reliability. They are two separate pillars, not one that was renamed.

Reliability or performance efficiency? Surviving the loss of an Availability Zone is reliability. Running on resources that are fast enough, or newer and faster, is performance efficiency.

Reliability or security? Both care about data. Backing data up so it can be restored after a failure is reliability; protecting it from unauthorised access, at rest or in transit, is security.

Performance efficiency or sustainability? "Experiment more often" means trying new resource types for performance. Consolidating to fewer, busier resources to save energy is sustainability.

Also learn what is not a pillar. Elasticity, scalability and durability are real cloud characteristics, but none of them is one of the six.

What the exam is really asking

A pillar question usually describes one action and its reason. Find the reason word: "fails", "recovers", "Availability Zone" point to reliability; "permissions", "encrypt", "log every API call" to security; "runbooks", "procedures", "monitor operations" to operational excellence; "faster", "latency", "serverless" to performance efficiency; "bill", "spend", "cost centre" to cost optimization; "energy", "environmental impact", "utilization" to sustainability. If a scenario asks for a tool that reviews a workload against these pillars, the answer is the AWS Well-Architected Tool.