The Well-Architected Framework
The six pillars and how to apply them.
A home inspector doesn't design your house. They walk through it with a clipboard, checking the things that have gone wrong in thousands of other houses: undersized wiring, a cracked foundation, water pooling against a wall. At the end you get a ranked list of what to worry about. The AWS Well-Architected Framework (AWS being Amazon Web Services) is that clipboard for cloud systems. Amazon took thousands of real customer architecture reviews, boiled them down to a fixed set of questions and best practices, and published the result. So "is this design any good?" stops being an argument between two engineers and becomes an inspection anyone can repeat.
Three words first, because the rest of the lesson leans on them. A *workload* is the thing being inspected: one application plus the resources that serve it, not your whole account. A *lens* is a question set. The default wellarchitected lens asks about the framework itself, and specialized lenses (Serverless, SaaS) bolt extra domain questions on top. The Well-Architected Tool is the free AWS service that stores a review: your answers, the risks it works out from them, and the improvement plan that falls out of both. It has a full API (application programming interface, the machine-readable way to drive a service), so a review is something you can script. Script it.
Six pillars you have already been building
The questions are grouped into six *pillars*, and here is the good news: you have already done the hands-on work behind every one of them. Operational Excellence asks whether you can run the system, see what it is doing, and change it without breaking it. That is the tagging discipline, the CloudWatch alarms (CloudWatch is the AWS monitoring service), and the automation habits running through this course. Security covers who gets in, how you spot trouble, and how data is protected: the IAM lessons (IAM is Identity and Access Management, the service that decides who can do what) plus the tour of KMS (Key Management Service, which holds encryption keys), CloudTrail (the audit log of every API call) and GuardDuty (the threat detector). Reliability asks whether the workload survives a bad day and still carries the load it is given: spreading across Availability Zones, planning your RTO and RPO (recovery time objective, how long you can be down; recovery point objective, how much data you can afford to lose), Auto Scaling, and pulling components apart with SQS (Simple Queue Service) queues.
Performance Efficiency is about fitting the resource to the job: the Lambda versus containers versus EC2 decision (Lambda runs your code with no server for you to manage; EC2, Elastic Compute Cloud, hands you plain virtual machines), the right S3 (Simple Storage Service) storage class, CloudFront caching in front of the content everyone hits. Cost Optimization kills spend that buys you nothing: Savings Plans, Spot capacity, S3 lifecycle rules. Sustainability joined as the sixth pillar in late 2021 and targets environmental footprint, which you mostly hit by doing Cost and Performance properly, because fewer and busier resources in efficient Regions is the same lever behind all three. Look at how complete that mapping is. Every lesson you have taken here is an implementation detail of one pillar or another. The framework is the index of the course.
Register a workload in the Well-Architected Tool
The tool is free, and it stores everything per Region. A workload record lives in whichever Region your CLI (command line interface, the aws command in your terminal) was pointed at when you created it, and nowhere else. Start by listing the lenses on offer, then register the system you want inspected. --environment takes PRODUCTION or PREPRODUCTION. At least one Region is required, via --aws-regions, so the tool knows where the workload actually runs. One quirk worth knowing about: the API reference lists --review-owner as optional, then tells you in a callout that the service demands it anyway. Pass it.
# Which question sets (lenses) are available?aws wellarchitected list-lenses \--query 'LensSummaries[?LensType==`AWS_OFFICIAL`].[LensAlias,LensName]' \--output table# | wellarchitected | AWS Well-Architected Framework |# | serverless | Serverless Lens |# Register the workload under reviewaws wellarchitected create-workload \--workload-name payments-api \--description "Card payments: ALB -> ECS Fargate -> Aurora" \--environment PRODUCTION \--lenses wellarchitected \--aws-regions eu-west-1 \--review-owner [email protected]{"WorkloadId": "9f3c1e0a8b7d6c5e4f3a2b1c0d9e8f7a","WorkloadArn": "arn:aws:wellarchitected:eu-west-1:111122223333:workload/9f3c1e0a8b7d6c5e4f3a2b1c0d9e8f7a"}
Behind the scenes, the tool pinned your workload to the current version of the wellarchitected lens: several dozen questions spread across the pillars, every one of them sitting at UNANSWERED. The CLI refers to pillars by id rather than by their friendly names, so learn the six: operationalExcellence, security, reliability, performance, costOptimization, sustainability.
Answer the questions, then read the risk
Here is how the risk score really works, because it is simpler and blunter than most people assume. Every question offers a list of *choices*, and each choice is one concrete best practice ("rely on a centralized identity provider", "use temporary credentials"). The lens carries a risk rule for each question. Leave the highest-impact choices unchecked and the question scores HIGH. Check some of them and it scores MEDIUM. Check the lot and it scores NONE. Nothing you type is graded. Only the choice ids you select count, which is exactly why the whole review can be driven from a script. List the questions to get their ids, open one with get-answer to see its choice ids, then record what is *actually true* today.
# Security-pillar questions and their current riskaws wellarchitected list-answers \--workload-id 9f3c1e0a8b7d6c5e4f3a2b1c0d9e8f7a \--lens-alias wellarchitected --pillar-id security \--query 'AnswerSummaries[].{id:QuestionId,risk:Risk}' --output table# | securely-operate | UNANSWERED |# | identities | UNANSWERED |# | permissions | UNANSWERED |# | detect-investigate-events | UNANSWERED |# ...# Record what is true for SEC 1 (choice ids come from get-answer)aws wellarchitected update-answer \--workload-id 9f3c1e0a8b7d6c5e4f3a2b1c0d9e8f7a \--lens-alias wellarchitected \--question-id securely-operate \--selected-choices sec_securely_operate_multi_accounts sec_securely_operate_aws_account \--notes "Org from the accounts lesson; no aggregated CloudTrail yet" \--query 'Answer.{QuestionId:QuestionId,PillarId:PillarId,Risk:Risk}'{"QuestionId": "securely-operate","PillarId": "security","Risk": "MEDIUM"}
Two best practices out of several, so the risk engine moves that question down from HIGH to MEDIUM. Once you have worked through the questions, pull the aggregate numbers, pull the prioritized fix list, then cut a *milestone*: a frozen snapshot of the review that the next one can be compared against.
# Aggregate risk across all pillarsaws wellarchitected get-lens-review \--workload-id 9f3c1e0a8b7d6c5e4f3a2b1c0d9e8f7a \--lens-alias wellarchitected \--query 'LensReview.RiskCounts'{"UNANSWERED": 43,"HIGH": 5,"MEDIUM": 7,"NONE": 2,"NOT_APPLICABLE": 0}# Prioritized fixes, each linked to the framework's prescriptive guidanceaws wellarchitected list-lens-review-improvements \--workload-id 9f3c1e0a8b7d6c5e4f3a2b1c0d9e8f7a \--lens-alias wellarchitected --pillar-id costOptimization \--query 'ImprovementSummaries[?Risk==`HIGH`].{q:QuestionTitle,url:ImprovementPlanUrl}'# Snapshot before remediating, so improvement is provableaws wellarchitected create-milestone \--workload-id 9f3c1e0a8b7d6c5e4f3a2b1c0d9e8f7a \--milestone-name "2026-07-baseline"# { "WorkloadId": "9f3c1e0a8b7d6c5e4f3a2b1c0d9e8f7a", "MilestoneNumber": 1 }
update-answer will cheerfully accept best practices nobody has built. (There is an optional Trusted Advisor integration that can show supporting checks beside a question, but it never selects a choice for you.) A team under deadline pressure checks the boxes for the things they intend to do, and out comes a review with zero HIGH risks while production still runs single-Availability-Zone databases behind public buckets. Treat every checked choice as a claim that owes you a verifying command. And remember the record is Regional and destructible: delete-workload wipes the review history for good, milestones included.Audit with commands you already know
An answer is worth exactly as much as the evidence behind it, and you already own the commands that produce that evidence. Each pillar has a one-liner from an earlier lesson that turns a checkbox into a fact. Run them before you go anywhere near update-answer, and paste what comes back into --notes.
# Security (IAM lesson): do human users still exist at all?aws iam list-users --query 'Users[].UserName' --output text# deploy-ci sarah.admin <- users at all is a finding; roles were the goal# Reliability (HA & DR lesson): AZ spread of running instancesaws ec2 describe-instances --filters Name=instance-state-name,Values=running \--query 'Reservations[].Instances[].Placement.AvailabilityZone' --output text \| tr '\t' '\n' | sort | uniq -c# 4 eu-west-1a# 1 eu-west-1b <- one AZ failure removes 80% of capacity# Cost (cost-optimization lesson): last month's spend, by serviceaws ce get-cost-and-usage \--time-period Start=2026-06-01,End=2026-07-01 \--granularity MONTHLY --metrics UnblendedCost \--group-by Type=DIMENSION,Key=SERVICE \--query 'ResultsByTime[0].Groups[].[Keys[0],Metrics.UnblendedCost.Amount]' \--output text# Amazon Relational Database Service 412.5800538# Amazon Elastic Compute Cloud - Compute 268.1043921# Amazon Simple Storage Service 41.2210031
Now read that output the way a reviewer reads it. Four instances in one Availability Zone and a single one in another is a Reliability HIGH, whatever the checkbox says. RDS (Relational Database Service) sitting at the top of the bill is a Cost Optimization prompt: is that Aurora instance the right size, and did anybody ever price a reserved commitment against it? That translation is the real skill on offer here. Raw CLI output goes in, pillar-labeled risk comes out.
Trade-offs, and what the exam does with them
The pillars pull against each other on purpose. Want a tighter recovery time objective? That means warm standby infrastructure sitting there costing money while it does nothing, so Reliability wins and Cost pays. Put a cache in front of Aurora and queries get faster, but now you have cache invalidation to reason about and one more thing to monitor: Performance wins, Operational Excellence pays. One account is easier to run than five, and isolates far less. No architecture maxes out all six pillars. A good one matches its *requirements*, with every sacrifice made deliberately and written down where the next person can find it. That is what the review's --notes field is for.
For the exam, treat this section as the marking scheme. The four domains of SAA-C03 (the current Solutions Architect Associate exam code) are secure, resilient, high-performing and cost-optimized architectures, worth roughly 30, 26, 24 and 20 percent. They are four of the pillars wearing different hats. The question stem tells you which pillar is being graded, and it does it with one qualifier word. *MOST cost-effective* means both options work and Cost breaks the tie. *LEAST operational overhead* means take the managed service even when it costs more. If two answers both look right, go back and read the qualifier. It names the pillar.
Where this course leaves you
Fifteen lessons ago you started with Regions and Availability Zones. Since then you have built identity with IAM and AWS Organizations, compute from EC2 up to Lambda, storage across S3, EBS (Elastic Block Store) and EFS (Elastic File System), networks with VPCs (virtual private clouds) and global edge locations, plus databases, failover, scaling, decoupling, and the security and cost habits that keep the whole thing defensible. Well-Architected is how you keep that system honest after launch: a review each quarter, milestones as receipts, a command standing behind every answer. Pass the exam, then go run create-workload against something real. The second habit is the one that compounds.
Nobody hands you a certificate at the end of a Well-Architected review. What you walk out with is a structured argument about risk: which questions score high, which fixes you will fund this quarter, and which risks you are accepting on purpose, with somebody's name written next to each one.
Pillars trade off. Cut cost hard enough and reliability starts to bleed. Chase reliability hard enough and you burn money and capacity you never needed. The Tool exists to make those trades visible, so "we will fix it later" turns into a dated milestone that somebody owns.
Reuse the checks you already run: public buckets, missing Multi-AZ, IAM policies that hand out far too much. They belong inside the review as evidence, not off to one side as a separate audit hobby.
Write down the failure you genuinely fear, not the one on the marketing slide. Then make sure the architecture, the alarm and the runbook all describe that failure in the same words.
Try this
List the Well-Architected workloads and milestones in your account. If there are none, create a throwaway workload with the skeleton below, then delete it when you are finished.
aws wellarchitected list-workloads --query 'WorkloadSummaries[].{Id:WorkloadId,Name:WorkloadName,Risks:RiskCounts}' --output tableaws wellarchitected get-workload --workload-id aa11bb22cc33 \--query '{Name:Workload.WorkloadName,Lenses:Workload.Lenses,Improved:Workload.ImprovementStatus}' --output json
---------------------------------------------| ListWorkloads |+---------------+------------+--------------+| Id | Name | Risks |+---------------+------------+--------------+| aa11bb22cc33 | checkout | {HIGH:2,...} |+---------------+------------+--------------+{"Name":"checkout","Lenses":["wellarchitected"],"Improved":"NOT_APPLICABLE"}
Takeaway
Remember: Well-Architected turns "is this any good?" into a review you can repeat, with risks that have names attached. The six pillars are the checklist. The Tool is the filing cabinet.
Next: run one lightweight review against a real application, pick the top three high risks, and put an owner and a date on each one before the meeting breaks up.