Free lesson · AWS Fundamentals

The Well-Architected Framework - six pillars

Easy6 min read

What The Framework Is For

The AWS Well-Architected Framework is a structured set of questions for evaluating an architecture. It is not a certification, a compliance standard, or a checklist that produces a pass mark. Its actual value is that it forces a team to make implicit tradeoffs explicit, in writing, before those tradeoffs become incidents.

Six pillars, each with design principles and a set of review questions:

The framework also has Lenses - domain-specific extensions with additional questions for serverless, SaaS, machine learning, financial services, IoT, and others - and the Well-Architected Tool in the console, which walks a workload through the questions and records the answers.

The Six Pillars In Practice

Operational Excellence. Everything as code, including infrastructure and operational procedures. Frequent small reversible changes rather than infrequent large ones. Refine procedures continuously. Anticipate failure through game days. Learn from operational events with blameless postmortems. In practice this pillar is mostly about whether your runbooks are executable and whether your deployment can be rolled back.

Security. Strong identity foundation with least privilege. Traceability through logging and monitoring. Security at all layers, not just the perimeter. Automate security best practices. Protect data in transit and at rest. Keep people away from data. Prepare for security events. The recurring finding in real reviews is over-broad IAM and unmonitored access paths.

Reliability. Automatically recover from failure. Test recovery procedures - the untested backup is the one that fails. Scale horizontally to reduce blast radius. Stop guessing capacity. Manage change through automation. The recurring finding is single points of failure hidden inside otherwise redundant designs.

Performance Efficiency. Choose the right resource type and size against measured evidence rather than habit. Use serverless and managed services to remove undifferentiated work. Experiment more often. Go global in minutes when latency demands it. The recurring finding is instance types chosen years ago and never revisited.

Cost Optimization. Adopt a consumption model. Measure overall efficiency. Stop spending on undifferentiated heavy lifting. Analyse and attribute expenditure - you cannot optimise what you cannot attribute, which makes tagging a cost-pillar concern. Use managed services to reduce cost of ownership.

Sustainability. Understand your impact. Set improvement goals. Maximise utilisation - an instance at 15% CPU wastes most of the energy it consumes. Adopt more efficient hardware and software as it becomes available. Use managed services, which run at higher shared utilisation than dedicated infrastructure. Reduce the downstream impact of your workload.

Tip: Sustainability and Cost Optimization point the same direction far more often than not. Higher utilisation, right-sized instances, newer processor generations, deleted unused data, and managed services improve both simultaneously. If you need to justify sustainability work commercially, this overlap is usually the argument.

The Part That Matters: The Pillars Conflict

graph TD
    R[Reliability] ---|multi-region costs more| C[Cost Optimization]
    S[Security] ---|more controls, more latency| P[Performance Efficiency]
    O[Operational Excellence] ---|tooling and process investment| C
    P ---|larger instances| C
    P ---|newer, denser hardware| SU[Sustainability]
    C ---|higher utilisation| SU
    R ---|redundant capacity| SU

This diagram shows tensions between the six Well-Architected pillars. Reliability conflicts with Cost Optimization because multi-region designs cost more. Security conflicts with Performance Efficiency because additional controls add latency. Operational Excellence conflicts with Cost Optimization because tooling and process require investment. Performance Efficiency conflicts with Cost Optimization when larger instances are chosen. Performance Efficiency aligns with Sustainability through newer denser hardware, and Cost Optimization aligns with Sustainability through higher utilisation. Reliability tensions with Sustainability because redundant capacity consumes resources.

A design that maximises every pillar simultaneously does not exist. Multi-region active-active maximises reliability and damages cost. Aggressive Spot usage maximises cost efficiency and damages reliability. Encrypting everything with customer-managed keys and per-request authorisation maximises security and costs you latency and operational complexity.

The framework's real output is a written record of which pillar you chose to sacrifice, and why. A team that says "we accepted a four-hour RTO because active-active would have tripled infrastructure cost for a workload with no revenue impact during a regional outage" has used the framework correctly. A team that scored well on all six pillars has probably not been honest.

Important: Treat "well-architected" as a direction, not a state. Every review produces high-risk and medium-risk items. The correct response to a high-risk item is sometimes "accepted, with this justification and this review date" - not always remediation. A review that produces zero accepted risks is a review nobody engaged with.

Running A Review

1. Define the workload boundary. One application, one business capability. Reviewing "our AWS account" is too broad to produce anything actionable.
2. Get the right people in the room. Someone who operates it, someone who built it, someone who owns the business outcome. Missing the third person is why reviews produce technically correct but commercially irrelevant findings.
3. Work through the pillar questions. The Well-Architected Tool structures this and stores the answers.
4. Record risks as High, Medium, or None. Be honest. Optimistic scoring wastes the exercise.
5. Triage into remediate / accept / defer, each with an owner and a date.
6. Re-review on a cadence and after significant architectural change.

The most common failure of Well-Architected reviews is that they are run once by an architect who did not build the system, produce a document nobody reads, and are never repeated.

Common Failure Modes

Warning: Using it as a checklist. The framework is a set of questions, and the answers are context-dependent. "Yes we use multi-AZ" is not an answer to a reliability question about a batch job with a 24-hour recovery objective.

Reviewing without the business context. RTO, RPO, revenue impact, and regulatory obligation determine what "good" means. Without them, every reliability recommendation is over-engineering or under-engineering and there is no way to tell which.

Scoring for the audience. Reviews run to impress a stakeholder produce findings that are safe to report rather than true.

One-and-done. Architectures drift. A review is a snapshot with a short shelf life.

Ignoring the Lenses. A serverless workload reviewed only against the core framework misses questions that matter specifically to it.

Why This Matters In An Interview

Interview: In certification exams, the pillars supply the vocabulary that scenario questions are phrased in. "Least operational overhead" is Operational Excellence. "Most cost-effective" is Cost Optimization. "Highly available" is Reliability. Recognising which pillar a question is optimising for narrows four options to two immediately.

In system design interviews, the framework is most useful as a closing move. After you have designed something, walking the pillars out loud - "reliability-wise this survives an AZ; cost-wise the weak point is cross-AZ transfer; operationally the gap is that we have no runbook for a failed migration" - demonstrates structured thinking and often surfaces the exact weakness the interviewer was about to probe.

What loses points: reciting the six pillars as a list. Everyone can do that. Applying two of them to the specific design on the whiteboard is the signal.

Common follow-ups:

• "Which pillar would you sacrifice here and why?" → Name one, justify it against the stated business requirement. Refusing to choose reads as inexperience.
• "How do you know this is reliable enough?" → Ask for the RTO and RPO. Reliability without a target is an opinion.
• "What would a Well-Architected review find in this design?" → Name two genuine weaknesses in your own design. Candidates who cannot criticise their own work are marked down.

Practice

Exercise: Starter. Match each pillar to the AWS service most associated with reviewing it: CloudWatch, IAM Access Analyzer, Auto Scaling, Compute Optimizer, Cost Explorer, and the Customer Carbon Footprint Tool.

Intermediate. Take a system you know and write one genuine High risk for three different pillars. Then write the justification for accepting one of them rather than fixing it.

Advanced. Design the same workload twice: once optimising Reliability above all else, once optimising Cost above all else. State the RTO, RPO, and monthly cost of each, then identify which business circumstances would make each the correct choice.

Related Topics

• Module 01 - Topic 1: failure domains, which underpin the Reliability pillar
• Module 01 - Topic 4: how AWS pricing works, which underpins Cost Optimization
• Module 10 - Security & Governance
• Course 5 - AWS Solutions Architecture: the Well-Architected review as a working method

Back to AWS Fundamentals