The Well-Architected Framework: Six Pillars & Reviews

In one line

AWS's framework for judging an architecture: operational excellence, security, reliability, performance efficiency, cost optimisation, and sustainability. It turns vague 'is this good?' into specific questions and trade-offs.

0/4 · 0%

Think of it like this

A building inspection. Inspectors check the same categories for every building (structure, fire safety, plumbing, electrics, energy use) and list issues by severity. A Well-Architected review does the same for a cloud system.

Key ideas

01
OPERATIONAL EXCELLENCE: everything as code, small reversible changes, runbooks, observability, learning from failures. SECURITY: strong identity (least privilege, no long-lived keys), traceability (CloudTrail), protection in every layer, encryption at rest and in transit, incident preparation.
02
RELIABILITY: automatic recovery, horizontal scaling, multi-AZ by default, tested backups and DR, managing service quotas. PERFORMANCE EFFICIENCY: choosing the right resource types (instance families, Graviton, managed services, caching), measuring, and experimenting.
03
COST OPTIMISATION: pay only for what you use, right-size, use Savings Plans and Spot, measure cost per team and per feature (DevOps guide, cloud cost). SUSTAINABILITY: maximise utilisation, use efficient hardware (Graviton), and keep data only as long as needed.
04
THE REVIEW: the free AWS Well-Architected Tool walks a workload through ~50 questions per pillar and produces High/Medium risk issues and an improvement plan; LENSES add domain-specific questions (serverless, SaaS, containers, generative AI). The pillars conflict (more reliability costs more money), so the output is explicit trade-offs, not perfection.

Code & diagrams

the pillars and a typical finding eachtext

Operational excellence  No runbook for the checkout alarm; deploys are manual        → HIGH
Security                Access keys on developer laptops; S3 bucket without block-public → HIGH
Reliability             RDS single-AZ; backups never restored                         → HIGH
Performance efficiency  m5 instances at 12% CPU; no caching of product reads          → MEDIUM
Cost optimisation       No Savings Plan for steady baseline; NAT data costs            → MEDIUM
Sustainability          Logs kept forever; x86 where Graviton works                    → LOW

Explain it without notes

Why do the Well-Architected pillars sometimes conflict?

Practice

Run a mini review of ShopLite's architecture (the Terraform course's final design) for the Reliability pillar. List three risks.

Trade-offs

↔
A full review takes time but surfaces high-risk issues early; lightweight pillar checklists in design reviews give most of the benefit continuously.

Done when you can

I can name the six pillars and a key practice for each
I can run a Well-Architected review and prioritise findings