beginnerintermediateadvanced

AWS · Section 51

AWS Well-Architected Framework

Level: intermediate
Read: 25 min
Concepts: 3

The Well-Architected Framework is a consistent set of best practices expressed as questions for evaluating an architecture, organised into six pillars: operational excellence (support development and run workloads effectively, gain insight, continuously improve), security (protect data, systems, and assets), reliability (perform correctly and consistently when expected, including being testable through the whole lifecycle), performance efficiency (use resources efficiently and maintain that as demand changes), cost optimization (deliver business value at the lowest price point), and sustainability (reduce energy consumption and increase efficiency across the workload). It carries its own vocabulary — component, workload, architecture, milestones, technology portfolio, and a level-of-effort scale — which is what makes findings from different reviews comparable. The practice is to ask questions across all six pillars rather than only the ones the room is primed for, at milestones rather than once, and to produce risks with an owner and a level of effort instead of a pass/fail verdict. Finally, every architecture trades one pillar against another, and the framework's real contribution is making those trades explicit: what was chosen, what was given up, the assumptions behind it, an owner, and a review trigger — because assumptions expire silently, and an undocumented trade-off is indistinguishable from an oversight.

This section

6 Pillars of the AWS Well Architected Framework (you should really know this)Be A Better Dev

What is true here

Six pillars, each with a definition AWS states in one sentence.
The framework is a set of questions about an architecture, not a list of services to enable.
Review across all six at milestones; the output is prioritised risks, not a verdict.
Trade-offs between pillars are business decisions — write down the assumptions, not just the choice.
Security and operational excellence are generally not traded off against the others.

What you will be able to do

State all six pillars and AWS's definition of each
Use the framework's vocabulary precisely — component, workload, architecture, milestone, portfolio
Run a review that covers every pillar and produces owned, effort-scored risks
Write a trade-off record whose assumptions a future reviewer can check
Distinguish an accepted risk from a resolved one, and keep it visible

From six pillars to a decision someone can revisit

The six pillars

Review across all of them

Explicit trade-offs and risks

AWS Well-Architected Framework

The six pillars and the framework's vocabulary, reviewing across all of them at milestones, and recording trade-offs and risks so they can be revisited.

The Six Pillars

coreintermediate

The AWS Well-Architected Framework is a consistent set of best practices, expressed as questions you ask about an architecture. It is organised into six pillars: operational excellence, security, reliability, performance efficiency, cost optimization, and sustainability. Each has its own definition, and together they are what a thorough architecture review covers.

Think of it as

The framework is a set of questions, not a set of answers. Its value is that the questions are ones a design team rarely asks itself unprompted — and it is organised so that no single concern quietly dominates the review.

What we're doing: See what changes when a review covers all six pillars instead of the usual two.

six-pillar-review.txttext

Typical review, unprompted: "is it fast enough, and is it secure?"
Findings: two performance items, one security item.

Same design, reviewed across all six pillars:
  operational excellence — no runbook, no on-call ownership defined
  security               — one over-broad IAM role
  reliability            — single NAT gateway; failover never tested
  performance efficiency — no saturation metrics collected
  cost optimization      — non-production runs 24/7
  sustainability         — fleet at 12% average utilization

Four of the six findings would not have been raised at all.

1: Not a bad review — just an incomplete one, shaped by what the reviewers happened to care about.
4: The framework's value is structural: it forces coverage of concerns nobody in the room was primed to ask about.

Why this works: Design reviews naturally follow the expertise in the room, so the same categories of problem get found repeatedly and others never do. Six named pillars turn coverage from a function of who attended into a property of the process.

Treating the framework as an AWS product checklist

Wrong

text

# "Well-Architected means using CloudWatch, Config, and Trusted Advisor."

Better

text

# It is a set of questions about the architecture. Services are how you
# answer some of them, not the answer itself.

What you see: Every recommended service is enabled and the architecture still has an untested failover, an over-broad role, and no runbook — none of which a service turns on.

Why: AWS describes the framework as a consistent set of best practices and a set of questions for evaluating how well an architecture aligns to them. Enabling a service can be part of an answer, but the questions are about design and operation, which no service configures on your behalf.

The six pillars

How it is built and run

Operational excellence

run it, see it, improve it

Security

protect data, systems, assets

Reliability

correct and consistent, and testable

What it costs to do so

Performance efficiency

efficient now, and as demand changes

Cost optimization

business value at the lowest price point

Sustainability

less energy, more efficiency

The framework's own vocabulary

The framework's own vocabulary
Term	AWS's definition	Why it matters
Component	The code, configuration, and AWS resources that together deliver against a requirement	Often the unit of technical ownership, decoupled from others
Workload	A set of components that together deliver business value	The level business and technology leaders communicate about
Architecture	How components work together in a workload	What architecture diagrams are actually about
Milestones	Key changes in your architecture as it evolves through the product lifecycle	Design, implementation, testing, go live, production
Technology portfolio	The collection of workloads required for the business to operate	The scope above any single review
Level of effort	High (weeks–months), medium (days–weeks), low (hours–days)	How AWS categorises the cost of an improvement

Together

text

# The vocabulary in one sentence
A workload (checkout) is made of components (API, worker, database),
arranged in an architecture, reviewed at milestones, and is one entry
in the organisation's technology portfolio.

Remember: Six pillars: operational excellence, security, reliability, performance efficiency, cost optimization, sustainability. It is a set of questions about an architecture, not a list of services — and the vocabulary (component, workload, architecture, milestones, portfolio) is what makes reviews comparable.

Reviewing Across All Six Pillars

standardintermediate

A review that only asks the questions the room already cares about finds the problems the room already knows how to find. Running through all six pillars — even briefly — surfaces the categories nobody was primed to raise, which is where the expensive surprises usually live.

Think of it as

A pre-flight checklist is boring precisely because it covers items that are almost always fine. Its value is entirely in the rare case, and the discipline is checking them anyway rather than skipping to the interesting ones.

text

# A 30-minute review that is still worth running
For each of the six pillars:
  1. Ask the one question above
  2. Record the answer verbatim
  3. If the answer is vague, that is the finding

Reviewing only at the design milestone

Wrong

text

# Well-Architected review happens once, before the build starts

Better

text

# Review at milestones — design, implementation, testing, go live, and
# again in production, where the answers are finally real

What you see: The design review records that failover will be tested and monitoring will be added, and nothing checks a year later whether either happened.

Why: AWS defines milestones as key changes in the architecture across the product lifecycle precisely because the answers change at each. At design time most answers are intentions; only in production are they observations, and that is where a review has evidence to work with.

One useful question per pillar, for any workload

One useful question per pillar, for any workload
Pillar	Ask	A weak answer
Operational excellence	Who is paged, and what do they read?	"Whoever notices"
Security	What can a compromised component reach?	"It has the standard role"
Reliability	When did we last test the failover?	"It should work"
Performance efficiency	Which resource saturates first, and at what load?	"We have not measured"
Cost optimization	What is the largest line, and how much of it is waste?	"Finance owns that"
Sustainability	What is provisioned but not used?	"Nothing, probably"

Together

text

# A finding, written so it can be prioritised
Pillar : reliability
Risk   : single NAT gateway; AZ-b loses egress if AZ-a fails
Effort : low (hours-days)
Owner  : platform team
Status : accepted for staging, scheduled for production

Remember: Run all six pillars, even briefly — the value is in the categories nobody was going to raise. Produce risks with an owner and a level of effort rather than a verdict, review at milestones rather than once, and record accepted risks so they stay distinguishable from unknown ones.

Explicit Trade-offs, Documented Risks, and Revisiting

coreadvanced

Every architecture trades one pillar against another. The framework's real contribution is making those trades explicit: written down, with who decided, why, and under what assumptions. That turns a risk you accepted into a decision, and it makes revisiting possible when the assumptions change — which they always do.

Think of it as

An undocumented trade-off looks exactly like an oversight six months later, and nobody can tell which it was. Writing it down is the only thing that distinguishes "we knew and chose this" from "nobody thought about it".

What we're doing: See what happens to an undocumented trade-off after eighteen months.

assumption-expiry.txttext

2025: the team deliberately runs a single NAT gateway in staging. The
assumption is "staging outages cost nothing and it saves $45/month."

2026: staging becomes the environment every customer demo runs against,
and a partner integration test suite depends on it continuously.

The assumption is now false. Nobody notices, because it was never
written down — so there is nothing to re-check and no one to re-check it.

2027: an AZ event takes staging down during a customer demo. The review
concludes "single NAT gateway" and records it as an oversight, which is
unfair to the person who made a correct decision in 2025.

1: A good decision, correct on the information available at the time.
5: The change that invalidates the assumption has nothing to do with the architecture, which is exactly why nobody connects the two.
9: Undocumented, a deliberate trade-off is indistinguishable from negligence — and the lesson recorded is the wrong one.

Why this works: Assumptions expire silently, and architecture decisions outlive the context that justified them. Writing the assumption down converts a permanent decision into a reviewable one, which is the only mechanism that catches this class of drift.

Recording the decision without the assumptions behind it

Wrong

text

# ADR: "We use a single NAT gateway in staging."

Better

text

# ADR: "Single NAT gateway in staging, because staging outages cost
# nothing and it saves $45/month. Revisit if staging becomes
# customer-facing."

What you see: The decision is found and re-read years later, and nobody can tell whether the reasoning still holds, so it is either kept out of caution or reversed without understanding.

Why: The decision is the durable part and the reasoning is the perishable part, so recording only the decision keeps precisely the half that cannot go stale. The assumption is what a future reviewer needs in order to decide whether anything should change.

A trade-off that survives being revisited

Name the pillars in tension

e.g. reliability against cost and sustainability

State the choice

What was chosen, and what was given up

Record the assumptions

"Traffic under 2,000 rps", "an hour of downtime costs more than $6k/month"

Name an owner and a review date

Otherwise nobody revisits it

Re-check at the next milestone

Assumptions expire quietly

What a written trade-off contains

What a written trade-off contains
Field	Example	Why it is needed
Pillars in tension	Reliability vs cost and sustainability	Names the category, so it can be found later
Decision	Warm standby in a second Region	What was actually done
Given up	+$6.4k/month and an idle duplicate environment	Makes the cost visible rather than implied
Assumptions	An hour of payments downtime exceeds the annual cost	The part that expires
Owner	Payments team	Somebody has to be able to revisit it
Review at	The next production milestone, or a traffic doubling	Turns "revisit" into an event

Together

text

# One decision record, kept next to the architecture
Tension    : reliability vs cost + sustainability
Decision   : warm standby in eu-central-1
Given up   : +$6.4k/month; a scaled-down duplicate always running
Assumption : >1 h payments downtime costs more than $77k/year
Owner      : payments
Review at  : next production milestone, or if the assumption changes

Remember: Write the trade-off down: pillars in tension, what was chosen, what was given up, the assumptions, an owner, and a review trigger. Assumptions expire silently, and an undocumented trade-off is indistinguishable from an oversight. Accepted risks stay open — they are prioritised, not resolved.