beginnerintermediateadvanced

AWS · Well-Architected

AWS Well-Architected Framework

The six pillars, reviewing across all of them, and recording trade-offs that can be revisited

Six pillars, not fivesustainability was added
Questions, not servicesno service configures a runbook for you
Risks with owner and efforthigh / medium / low, so they can be ranked
Assumptions expire silentlythe decision outlives the reasoning

1.The Six Pillars

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.

Key features

Operational excellence: the ability to support development and run workloads effectively, gain insight into their operations, and continuously improve supporting processes and procedures to deliver business value
Security: how to take advantage of cloud technologies to protect data, systems, and assets in a way that can improve your security posture
Reliability: the ability of a workload to perform its intended function correctly and consistently when it is expected to, including operating and testing it through its total lifecycle
Performance efficiency: the ability to use computing resources efficiently to meet system requirements, and to maintain that efficiency as demand changes and technologies evolve
Cost optimization: the ability to run systems to deliver business value at the lowest price point
Sustainability: the ability to continually improve sustainability impacts by reducing energy consumption and increasing efficiency across all components of a workload

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

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

Signature

operational excellence · security · reliability · performance efficiency · cost optimization · sustainability

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.

2.Reviewing Across All Six Pillars

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.

Key features

AWS positions the framework as a set of questions you use to evaluate how well an architecture aligns to best practices
Milestones — design, implementation, testing, go live, in production — are the natural review points, because the answers change at each
The review's output is a list of risks with an owner and a level of effort, not a pass or fail verdict
AWS categorises level of effort as high (weeks to months), medium (days to weeks), or low (hours to days), which makes findings comparable
A finding you consciously accept is a recorded decision; a finding nobody raised is an unknown risk, and the two look identical afterwards
Reviews are per workload, and the same organisation will reasonably reach different conclusions for different workloads

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"

Command

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

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.

3.Explicit Trade-offs, Documented Risks, and Revisiting

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.

Key features

AWS states that when architecting workloads you make trade-offs between pillars based on your business context, and that these business decisions can drive engineering priorities
AWS gives both directions: sustainability and cost over reliability in development environments, and reliability over cost and sustainability for mission-critical solutions
Security and operational excellence are generally not traded off against the other pillars
Milestones exist because architecture evolves — a trade-off correct at design time can be wrong once the workload is in production
A documented risk carries an owner and a level of effort, which is what lets it be prioritised rather than merely noted
The assumptions behind a trade-off are the part worth writing down: they are what a future review can check, and they are what silently expires

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

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

Signature

tension + decision + what was given up + assumptions + owner + review trigger

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.

Spotted a mistake on this page? Tell us.

Read Sheet