The Well-Architected Framework

By the end you'll know

What the AWS Well-Architected Framework is, and the six pillars it's built on
What each pillar asks, in plain words, with the bakery as the example
How a review works in the free AWS Well-Architected Tool: questions, best practices, risks, an improvement plan
Why doing some of the right things can still count as high risk
Where each pillar comes up in the rest of this track

Before you start

You need: the juniper-rye profile from Lesson 4, signed in.
Cost: $0. The AWS Well-Architected Tool is free.
The script: wa-review.py from the practice folder's lesson-06. It creates one workload in the tool, named juniper-rye-shop, and deletes it at the end. It prints titles and counts, never an account ID or an ARN.
Where you run things: your own machine, labelled (Your machine).
Every output below is from a real run on November 9, 2026.

The short version

The Well-Architected Framework is AWS's written advice on building well, grouped into six pillars: operational excellence, security, reliability, performance efficiency, cost optimization and sustainability.
A review is a set of questions, 57 of them across the six pillars. For each one you tick the best practices you really follow.
The free Well-Architected Tool turns your answers into high and medium risks, and an improvement plan.
Partly right is still a risk. The bakery follows three of six identity practices and one of six cost-monitoring practices; both came back high risk.
The pillars pull against each other. More reliability usually costs more. A review makes those trade-offs visible, and you choose.

What this lesson costs

Part	Cost
A workload and review in the Well-Architected Tool	$0
This lesson	$0, and nothing left behind

A checklist, not a rulebook

Lessons 1 to 5 covered a lot of separate advice: watch the bill, lock the account, use roles, choose a Region for a reason, know which security jobs are yours. The AWS Well-Architected Framework is AWS's attempt to put advice like that in one place, as questions you can ask about anything you build.

It isn't a standard you pass or fail, and nobody certifies you. It's closer to a building inspector's checklist that you run yourself: it doesn't build the shop for you, but it asks the questions you'd be embarrassed to be asked after something goes wrong.

The six pillars

Pillar	What it asks	At the bakery	Lessons
Operational excellence	Can you run it, change it and learn from what goes wrong?	Changes go out through a pipeline, problems show up on a dashboard, and after an outage someone writes down why	29 to 33
Security	Are the right people, and only them, able to reach the right things?	MFA, roles instead of keys, encrypted data, a log of who did what	2 to 4, 33 to 36
Reliability	Does it keep working when something fails, and come back when it doesn't?	The shop stays up if one Availability Zone fails; orders can be restored from a backup	13, 19
Performance efficiency	Are you using the right kind and size of resources, and keeping up as things change?	Photos served from the edge; a server sized for the real traffic	10, 14
Cost optimization	Are you paying only for what you need, and do you know where the money goes?	A budget alarm; no NAT gateway idling at $32.85 a month	1, 2, 37
Sustainability	Are you using no more energy and hardware than the job needs?	Graviton servers, nothing left running overnight for no reason	1, 10

Sustainability is the newest; AWS added it in 2021. The pillars often agree, as when deleting what you don't use saves money and energy at once, but they also pull against each other. Running the shop in two Availability Zones makes it more reliable and costs more. The framework doesn't decide for you; it makes sure you decide on purpose.

Review the bakery's shop

The AWS Well-Architected Tool runs reviews in the console or from the CLI. A review is of a workload, a set of resources and code that does one job for the business: here, the bakery's online shop.

Start a review

In the console: AWS Well-Architected Tool > Workloads > Define workload.

(Your machine)

BASH

cd ~/Apps/aws-practice/lesson-06
chmod +x wa-review.py
./wa-review.py start

OUTPUT

== Created workload juniper-rye-shop, reviewed against the wellarchitected lens
== The six pillars, and how many questions each asks
  Operational Excellence      11 questions
  Security                    11 questions
  Reliability                 13 questions
  Performance Efficiency       5 questions
  Cost Optimization           11 questions
  Sustainability               6 questions
  Total                       57

A lens is a set of questions. wellarchitected is the general one; AWS also publishes lenses for particular kinds of workload, such as serverless applications or software sold as a service, which add their own questions.

Answer two questions honestly

Each question lists best practices. You tick the ones you really follow, and the tool works out the risk from what's missing. The script answers two questions with what this track has actually done so far:

In the console: Open the workload > Continue reviewing, then work through the questions pillar by pillar.

(Your machine)

BASH

./wa-review.py answer

OUTPUT

== How do you manage identities for people and machines?
  [x] Use strong sign-in mechanisms
  [x] Use temporary credentials
  [ ] Store and use secrets securely
  [x] Rely on a centralized identity provider
  [ ] Audit and rotate credentials periodically
  [ ] Employ user groups and attributes
  risk: HIGH
== How do you monitor your cost and usage?
  [ ] Configure detailed information sources
  [ ] Identify cost attribution categories
  [ ] Establish organization metrics
  [x] Configure billing and cost management tools
  [ ] Add organization information to cost and usage
  [ ] Allocate costs based on workload metrics
  risk: HIGH

The three ticks under identities are Lessons 2 to 4: MFA on the Builder ID, temporary credentials from roles and aws login, and AWS's managed sign-in through the Builder ID. The one tick under cost is Lesson 2's budget and anomaly monitor.

Both came back high risk. Half the identity practices are in place, and still: high. The tool looks at what's missing, and some of the missing practices are ones the framework counts as high risk, like storing secrets securely. Doing the easy half doesn't average out the gap. That's the most useful thing a review does: it stops "we've done a lot of the right things" from sounding like "we're fine".

See the whole picture

In the console: The workload's Overview shows high and medium risks by pillar.

(Your machine)

BASH

./wa-review.py review

OUTPUT

== Risks found so far, by pillar
  Pillar                      high  medium  none  not answered
  Operational Excellence         0       0     0            11
  Security                       1       0     0            10
  Reliability                    0       0     0            13
  Performance Efficiency         0       0     0             5
  Cost Optimization              1       0     0            10
  Sustainability                 0       0     0             6

Two questions answered, two high risks, 55 to go. A real review answers all 57 with the people who build and run the workload, often over a few sessions. The tool then lists improvement items for each risk, linked to AWS's guidance on fixing it, and you save a milestone, a snapshot, so the next review can show what improved.

Clean up

In the console: Workloads > pick the workload > Delete.

(Your machine)

BASH

./wa-review.py cleanup

OUTPUT

== Deleted workload juniper-rye-shop
== Left over: nothing

The workload costs nothing to keep. It's deleted here because every lab in this track leaves the account as it found it; Lesson 38 reviews everything you've built, for real.

Answer honestly

A review is only as good as its ticks. Ticking a practice you mean to follow, or follow sometimes, turns a high risk into "none" on paper and leaves it in place in reality. If you're not sure, leave it unticked and write a note; an honest high risk is useful, a false "none" is worse than no review.

Design principles worth remembering

Each pillar comes with design principles. A handful of them run through the whole track:

Stop guessing capacity. Measure, and scale up or down with what's really used, instead of buying for the busiest day you can imagine.
Make changes small and reversible. Small changes are easy to check and easy to undo.
Assume things fail. Servers, zones and even Regions fail, so design for it rather than hoping.
Automate, and test the automation. A recovery plan nobody has run is a guess.
Pay for what you use, and measure it. If you can't say where the money goes, you can't spend it better.

In real systems

Reviews happen before launch and then on a schedule, often yearly or after big changes, with the people who build and run the workload in the room.
AWS account teams and partners run reviews with customers, and some partners offer credits to fix what a review finds.
The improvement plan becomes work items: high risks first, each with an owner and a date.
Teams add lenses for what they build, such as serverless or machine learning, and companies can write custom lenses for their own rules.

Spot the problem

Work out what's wrong before you read the explanation.

"Our review came back clean." A team's first Well-Architected review shows no high risks at all. Looking closer, every question had most of its boxes ticked, and the notes are empty. Two months later, a server is restored from a backup for the first time, and the backup turns out to be from the wrong database. What went wrong? The review recorded what the team intended, not what was true. "Back up data" was ticked; nobody had tested a restore. The fix: tick a practice only if you can point to it working, a test restore, a log, a setting, and write that evidence in the question's notes. Then check: for each tick, could you show someone the proof in under five minutes?

Keep this

Remember	Why
Six pillars: operational excellence, security, reliability, performance efficiency, cost optimization, sustainability	Every design choice touches several of them
A review is questions and best practices	57 questions in the general lens
Risk comes from what's missing	Doing some of the right things can still be high risk
The Well-Architected Tool is free	Reviews, improvement plans and milestones
Tick only what you can prove	A false "none" is worse than an honest high risk
Pillars trade off	Decide on purpose: more reliable usually costs more

Where you are now

That's the end of Part 1. You know what AWS solves and how its bill works, you have an account that's safe and watched, you understand IAM and work from your own machine without keys, you can choose a Region and say who secures what, and now you have the framework the rest of the track hangs on, with a real review showing where the bakery stands. Part 2 starts building: Lesson 7 is Lightsail, the simplest way to put a website on AWS, before Lesson 8 builds the network underneath everything else.

Check yourself

Which of these is not one of the six pillars?
The bakery ticked three of six identity practices. What risk did the tool give?
What does the Well-Architected Tool cost?
Running the shop across two Availability Zones improves reliability. Which pillar usually pays for it?
What's a milestone in a Well-Architected review?
When should you tick a best practice in a review?

Key terms

AWS Well-Architected Framework: AWS's written guidance for building well, organized into six pillars.
Pillar: one area of the framework: operational excellence, security, reliability, performance efficiency, cost optimization or sustainability.
Design principle: a short rule of thumb behind a pillar, like "stop guessing capacity".
Workload: the resources and code that do one job for the business; what a review is about.
Lens: a set of review questions. The general one is the Well-Architected Framework lens; others cover serverless, machine learning and more.
Best practice: one item under a question; you tick the ones you follow.
High and medium risk: what the tool finds from missing best practices.
Improvement plan: the list of risks to fix, each linked to AWS's guidance.
Milestone: a saved snapshot of a review, to compare against later.
AWS Well-Architected Tool: the free console and CLI tool for running reviews.

Go deeper

AWS: The AWS Well-Architected Framework (opens in a new tab), with every pillar's questions and best practices.
AWS: Tutorial: document a workload in the Well-Architected Tool (opens in a new tab), including improvement plans and milestones.
Try: open the Well-Architected Tool in the console, create a workload for something you run, even a hobby site, and answer just the six Sustainability questions. How many risks?