The AWS Well-Architected Framework: Running a Real Review

Most Well-Architected reviews are theatre. A partner or an internal architect books a two-hour call, walks a checklist, exports a PDF with a reassuring risk score, and everyone files it under “done.” Six months later the architecture has drifted, a launch fell over on a single-AZ database, the bill doubled on idle capacity, and nobody can find the review — let alone tell you which of its findings were ever fixed. The AWS Well-Architected Framework did not fail those teams. They ran it as a checkbox when it is designed to be a continuous operating rhythm.

The Framework is three things. It is a mental model — six pillars (Operational Excellence, Security, Reliability, Performance Efficiency, Cost Optimization, Sustainability), each with a handful of design principles and a set of pointed questions that ask how you actually do the thing, not whether you have heard of it. It is a method — the Well-Architected Framework Review (WAFR): you scope a workload, answer the question set, and the process surfaces High-Risk Issues (HRIs) you rank into a backlog. And it is a tool — the free AWS Well-Architected Tool (aws wellarchitected) that stores your answers, computes risk, tracks milestones, and generates a prioritized improvement plan you can re-run after every major change.

This article teaches the review as a senior architect actually runs it. You will learn every pillar’s design principles and the concrete questions each one asks (enumerated, not hand-waved); the general design principles that sit above all six; how to reason explicitly about trade-offs — because every choice that strengthens one pillar taxes another; how to drive the Well-Architected Tool from workload definition through HRIs, milestones and improvement plan; when to layer a lens (Serverless, SaaS, ML, Data Analytics, IoT, Financial Services); how Trusted Advisor, Security Hub and Compute Optimizer feed real evidence into your answers; and how the whole thing becomes a cadence wired into launches and change management rather than a one-off. Then you will run it for real with the CLI and Terraform, and study the anti-patterns that turn a review into theatre.

What problem this solves

The pain WA addresses is not “our architecture is bad.” It is that architecture quality is invisible until it fails, and it fails along axes nobody was watching. A team optimizes hard for shipping speed and cost, and reliability quietly rots until a Region event or an AZ failure exposes it — on the worst possible day. WA makes the invisible visible before the incident, and turns “we should probably improve that someday” into an owned, prioritized, tracked item.

Who hits this: every team past the prototype stage. Startups skip WA because “we’ll fix it when we scale” — then the scale event is the fix, at 3 a.m. Enterprises run WA as a compliance ritual and wonder why findings never close. The teams that get value treat WA as continuous risk management for architecture: a recurring conversation that produces a ranked, owned backlog and measures whether last quarter’s risks actually shrank.

Learning objectives

By the end of this article you will be able to:

• Explain all six pillars — their design principles and the specific questions each asks — well enough to run a review without reading the docs mid-call.
• Apply the general design principles (stop guessing capacity, test at production scale, automate experimentation, evolve, drive with data, game days) as the lens above the six pillars.
• Reason about trade-offs explicitly — name what each design choice costs in another pillar (reliability↔cost, performance↔cost, security↔operational friction) and defend the balance.
• Drive the Well-Architected Tool end to end — define a workload, answer the question set, read HRIs and MRIs, capture a milestone, and export the improvement plan.
• Choose and apply lenses — know when Serverless, SaaS, ML, Data Analytics, IoT or Financial Services lenses add questions your workload needs.
• Wire in evidence sources — use Trusted Advisor, Security Hub, Compute Optimizer and Config so answers are backed by data, not opinion.
• Run WA as a cadence — who attends, when to review (before launches, after change, after incidents), and how findings feed a prioritized backlog.
• Provision and review a workload as code with aws wellarchitected and Terraform, and recognize the anti-patterns that make reviews worthless.

Prerequisites & where this fits

You should have designed or operated at least one non-trivial AWS workload — something with a load balancer, compute tier, a database, IAM, and a bill you have had to explain. WA is meta-architecture: it reviews the systems you already know how to build. If a whole pillar is unfamiliar, this article is a fine map, but pair it with the hands-on pieces linked throughout.

Where it fits in the bigger picture: WA is the governance layer over everything else. It does not replace deep skills in three-tier web architecture or multi-region active-active — it audits whether you applied them well. It is a SAA-C03 and SAP-C02 staple (the “which pillar / which principle” and “improve this design” questions), and every AWS Partner engagement of any size runs a WAFR. It sits directly upstream of your FinOps practice (Cost Optimization & FinOps Rightsizing) and your DR strategy (Disaster Recovery: RTO/RPO).

Core concepts

Before the pillars, get the vocabulary and the shape of the thing exact. WA has precise terms, and reviews go wrong when people use them loosely.

The six pillars at a glance

Each pillar is a lens on the same workload. You do not pick one; you review through all six, and their tension is the point.

The general design principles

Above the six pillars sit six general design principles — cloud-native habits that make every pillar easier. Cite these when a review reveals a systemic gap.

The Well-Architected vocabulary

How risk is computed

The Tool does not average your ticks. Each best practice carries a weight; leaving a high-weight practice unselected on a question makes that whole question a High-Risk Issue. This is why “we do most of it” still shows red — you skipped the one that matters.

The six pillars, question by question

This is the core of a real review. For each pillar: the design principles, then the actual question set, then how a senior reviewer reads the answers. Question numbering follows the current Framework; AWS revises the wording and occasionally the count, so treat the numbers as a stable-enough map, not scripture.

Operational Excellence (OPS)

Operational Excellence is about running and evolving the workload: getting work into production safely, understanding health, and learning from every event. It is the pillar teams most often under-invest in because it has no launch-day glamour — until the 3 a.m. page with no runbook.

Design principles:

The question set:

How a reviewer reads it: OPS 4/8/10 are where most teams show red — they can deploy but cannot observe. Wire OPS answers to real tooling — see CloudWatch Metrics, Alarms & Dashboards and X-Ray Distributed Tracing.

Security (SEC)

Security protects information, systems, and assets while delivering business value. It is the pillar where “we think we’re fine” is most dangerous — enumerate, don’t assume.

Design principles:

The question set:

How a reviewer reads it: SEC 2/3 (identity and permissions) and SEC 8 (data at rest) are the highest-leverage HRIs — a strong identity foundation shrinks the blast radius of everything else. Back answers with real tooling: GuardDuty Threat Detection, KMS Encryption & Envelope Keys, and org-level guardrails via Organizations SCPs.

Reliability (REL)

Reliability is the ability of a workload to perform its function correctly and consistently, and to recover from failure. It has the most questions because “reliable” spans foundations, architecture, change, and failure management.

Design principles:

The question set:

How a reviewer reads it: REL 9/10/13 are the launch-blocking HRIs. “We have backups” is not an answer — “we test restores monthly and our documented RTO is 30 minutes” is. Map DR strategy against RTO/RPO in Disaster Recovery: RTO/RPO and HA patterns in RDS Multi-AZ & Read Replicas and Multi-Region Active-Active.

Performance Efficiency (PERF)

Performance Efficiency is using computing resources efficiently to meet requirements, and maintaining that efficiency as demand changes and technology evolves. The 2023 revision consolidated the older eight questions into five.

Design principles:

The question set:

How a reviewer reads it: PERF 1 and PERF 5 catch the common failure — a design that was efficient at launch and never revisited. The tell is a workload still on an older instance generation with no benchmark against a target.

Cost Optimization (COST)

Cost Optimization is running systems to deliver business value at the lowest price point. It is a practice (Cloud Financial Management / FinOps), not a one-time cleanup.

Design principles:

The question set:

How a reviewer reads it: COST 3/4/6 are where money leaks. Tie answers to real allocation via Tagging Strategy & Cost Allocation and catch regressions with Cost Spike Anomaly Detection. The deep FinOps mechanics live in Cost Optimization & FinOps Rightsizing.

Sustainability (SUS)

Sustainability, added in December 2021, addresses the long-term environmental impact of your cloud workloads — chiefly by maximizing utilization and minimizing wasted resources. It overlaps heavily with Cost and Performance: efficient designs tend to be greener and cheaper.

Design principles:

The question set:

How a reviewer reads it: SUS answers usually fall out of good Cost and Performance work. If COST 4/6 are strong, SUS 3/5 are close behind. The distinct SUS insight is Region carbon intensity (SUS 1) and shutting down non-prod (SUS 6).

Trade-offs between the pillars

Here is the sentence that separates a real review from a checklist: every choice that strengthens one pillar taxes another. A review that reports six green pillars either got lucky or is lying. The skill is not maximizing all six — it is choosing the balance deliberately, per workload, and documenting why.

The trade-off matrix

How to reason about a trade-off explicitly

Do not resolve trade-offs by instinct. Make them a decision with an owner and a rationale.

The Framework calls these conscious trade-offs: a security control that adds 20ms is fine for a banking API and unacceptable for a real-time ad bidder. The same answer can be an HRI for one workload and correct for another — which is exactly why you review a workload, not “AWS.”

The Well-Architected Tool, end to end

The AWS Well-Architected Tool (WA Tool) is a free service in the console and API that stores your review, computes risk, and tracks improvement over time. It is the system of record for the process above.

Defining a workload

A workload definition scopes and contextualizes the review. Get the scope right: too broad (“all of prod”) and answers are meaningless; too narrow (“one Lambda”) and you drown in reviews.

Answering the question set

For each question you select the best practices you follow. The Tool then computes the question’s risk.

The discipline: answer for the workload as it is today, not as you plan it to be. Aspirational ticks hide the exact risks the review exists to find.

Risk findings: HRIs and MRIs

After answering, the Tool summarizes risk per pillar and overall. The lens review returns risk counts:

An HRI is not a failing grade — it is a prioritized work item. A brand-new workload with a dozen HRIs is normal; a workload whose HRI count never drops between milestones is the actual problem.

Milestones

A milestone is an immutable snapshot of the workload’s answers and risk at a moment in time. This is how you prove improvement rather than assert it.

Milestones are immutable — you cannot edit a past snapshot, which is exactly what makes them trustworthy for audits and for measuring progress.

The improvement plan

The improvement plan is the Tool’s prioritized list of unmet best practices, HRIs first, each linking to prescriptive guidance. This is the output you turn into backlog tickets.

Export it, assign owners and due dates, and drop it into Jira/Backlog. The plan without owners is the single most common way WA dies.

Re-reviews and cadence

WA is a loop, not a line. You re-answer after change, snapshot a new milestone, and compare.

Lenses — when to apply which

The base Well-Architected Framework lens applies to every workload. Lenses add domain-specific questions and best practices on top. Apply a lens when your workload’s shape means the base questions miss things that matter.

Rules of thumb: (1) always run the base lens; (2) add one domain lens that matches the workload’s dominant pattern — a serverless SaaS product is primarily SaaS with Serverless as a strong second; (3) don’t stack five lenses on a simple app — you will drown in questions and finish nothing; (4) build a custom lens when you have internal standards (naming, tagging, guardrails) you want every team’s review to check.

Data sources that inform your answers

Answers backed by evidence beat answers backed by opinion. Wire these AWS services into the review so ticks are defensible and gaps are surfaced automatically.

The WA Tool’s Trusted Advisor integration is the tightest coupling: activate it on the workload and the Tool surfaces relevant Trusted Advisor checks next to the best practices they inform, so a failing check becomes visible risk instead of an untested claim.

The review process — who, when, and how findings flow

A review is a facilitated conversation, not a form one person fills alone. Who is in the room and when you meet decides whether findings are real.

How findings flow into work: the improvement plan → export → each HRI becomes a backlog item with an owner, a due date, and the guidance link → milestones prove the count dropped. The Framework is only as good as this hand-off; findings that never reach the backlog are the review failing silently.

Architecture at a glance

The diagram traces the review as a loop, left to right. You define a workload (with Trusted Advisor, Security Hub and Compute Optimizer wired in as evidence), answer the six-pillar question set in the Well-Architected Tool, and the Tool computes risk — surfacing High-Risk Issues and medium-risk items. HRIs become a prioritized improvement plan you turn into an owned backlog; a milestone snapshots the baseline, and every major change or scheduled cadence re-enters the loop. The point the picture makes: WA is a cycle, not a document.

Real-world scenario

Meridian Freight runs a logistics platform on AWS — a three-tier web app (ALB → EC2 Auto Scaling → RDS) plus a serverless events pipeline for shipment tracking. They had never run a formal WA review; the architecture had grown by accretion over three years. A near-miss — an AZ event that almost took the tracking API down because RDS was single-AZ — finally forced the conversation.

The facilitator (an internal architect) scoped two workloads, not one: “Tracking API” (the customer-facing path) and “Analytics pipeline” (internal reporting), because their reliability and cost requirements were completely different. For the Tracking API they ran the base lens plus the Serverless lens; for Analytics, the base lens plus Data Analytics. They activated Trusted Advisor and pulled Compute Optimizer and Security Hub reports the day before, so answers were evidence-backed.

The first review produced 11 HRIs on the Tracking API. The top three were unambiguous: REL 13 (no documented DR, no tested restores), REL 10 (single-AZ RDS — the near-miss), and SEC 3 (an over-broad IAM role the EC2 fleet had carried since a 2023 debugging session). Compute Optimizer flagged the fleet as 40% over-provisioned, which turned into two COST HRIs. Critically, they did not try to fix everything. They captured a milestone (“pre-remediation baseline”), exported the improvement plan, and put exactly five items into the next sprint — the two reliability HRIs, the IAM HRI, and two rightsizing items — each with a named owner and a due date.

The trade-off conversation was the valuable part. Moving RDS to Multi-AZ added roughly $380/month; the team quantified an outage of the Tracking API at ~$18k/hour in SLA credits and lost bookings, and the decision took ninety seconds. Rightsizing the fleet reduced cost by ~$1,100/month and, by consolidating onto fewer, better-utilized Graviton instances, quietly improved their Sustainability answers too — the same change satisfied COST 6, PERF 2, and SUS 5. Six weeks later they re-reviewed, captured a “post-sprint-1” milestone, and the HRI count on the Tracking API had dropped from 11 to 6. That delta — provable, owned, and trending down — is what a real review produces. The PDF nobody reads produces zero.

Advantages and disadvantages

When the advantages dominate: any workload heading for or already at production scale, especially before a launch or after growth. When to keep it lightweight: a two-week prototype that will be thrown away — do a conversation against the pillars, skip the formal tooling. The disadvantages are almost all process failures, not tool failures; the tool is nearly free, the discipline is not.

Hands-on lab

You will define a workload in the Well-Architected Tool, answer a representative slice across the pillars, generate HRIs, capture a milestone, and export the improvement plan — first with the aws wellarchitected CLI, then the same workload as Terraform. The WA Tool itself is free; the only caution is not leaving demo resources you create elsewhere.

Prerequisites: AWS CLI v2 configured (aws sts get-caller-identity works), permissions for wellarchitected:* (see the IAM policy in Security notes), and jq for readability.

Step 1 — Confirm access and list lenses

aws sts get-caller-identity --query Account --output text
# 123456789012

# List the lenses available to you (base + AWS official lenses)
aws wellarchitected list-lenses \
  --query 'LensSummaries[].{Alias:LensAlias,Name:LensName,Type:LensType}' \
  --output table

Expected: a table including wellarchitected (the base Framework) and AWS lenses such as serverless, softwareasaservice, dataanalytics, machinelearning, iot.

Step 2 — Create the workload

WORKLOAD_ID=$(aws wellarchitected create-workload \
  --workload-name "meridian-tracking-api" \
  --description "Customer-facing shipment tracking API (ALB -> EC2 ASG -> RDS + serverless events)" \
  --environment PRODUCTION \
  --aws-regions "ap-south-1" "us-east-1" \
  --review-owner "architecture-team@meridian.example" \
  --lenses "wellarchitected" \
  --tags Team=platform,CostCenter=logistics \
  --query 'WorkloadId' --output text)

echo "Workload: $WORKLOAD_ID"
# Workload: 1a2b3c4d5e6f...

⚠️ Cost note: creating a workload is free. The --lenses wellarchitected base lens is always applied; you can attach more in the next step.

Step 3 — (Optional) attach the Serverless lens

aws wellarchitected associate-lenses \
  --workload-id "$WORKLOAD_ID" \
  --lens-aliases "arn:aws:wellarchitected::aws:lens/serverless"

Step 4 — See the questions for a pillar

# List Reliability questions and their current answer status
aws wellarchitected list-answers \
  --workload-id "$WORKLOAD_ID" \
  --lens-alias wellarchitected \
  --pillar-id reliability \
  --query 'AnswerSummaries[].{Q:QuestionId,Title:QuestionTitle,Risk:Risk}' \
  --output table

Expected: every REL question listed with Risk: UNANSWERED — your starting point.

Step 5 — Answer a representative slice across pillars

Grab the choice IDs for one question, then select the practices you follow. (Choice IDs look like <question_id>_<choice>.)

# Inspect choices for the DR question (REL 13)
aws wellarchitected get-answer \
  --workload-id "$WORKLOAD_ID" \
  --lens-alias wellarchitected \
  --question-id "plan_for_disaster_recovery_dr_rel13" \
  --query 'Answer.Choices[].{Id:ChoiceId,Title:Title}' --output table

# Select the practices you actually do (example choice IDs)
aws wellarchitected update-answer \
  --workload-id "$WORKLOAD_ID" \
  --lens-alias wellarchitected \
  --question-id "plan_for_disaster_recovery_dr_rel13" \
  --selected-choices "choice1_id" "choice2_id" \
  --notes "Backups exist; restores not yet tested. RTO undefined."

Repeat for a slice that will produce mixed risk — e.g. answer SEC 2/SEC 8, REL 10, COST 6, OPS 4, PERF 2 honestly. Mark a genuinely irrelevant question not applicable:

aws wellarchitected update-answer \
  --workload-id "$WORKLOAD_ID" \
  --lens-alias wellarchitected \
  --question-id "some_out_of_scope_question" \
  --is-applicable false \
  --reason OUT_OF_SCOPE \
  --notes "No on-prem component in this workload."

Step 6 — Generate and read the risk findings (HRIs)

aws wellarchitected get-lens-review \
  --workload-id "$WORKLOAD_ID" \
  --lens-alias wellarchitected \
  --query '{Pillars:PillarReviewSummaries[].{Pillar:PillarName,Risks:RiskCounts}, Total:RiskCounts}'

Expected (illustrative):

{
  "Pillars": [
    { "Pillar": "Reliability", "Risks": { "HIGH": 2, "MEDIUM": 1, "UNANSWERED": 8 } },
    { "Pillar": "Security",    "Risks": { "HIGH": 1, "MEDIUM": 2, "UNANSWERED": 6 } }
  ],
  "Total": { "HIGH": 3, "MEDIUM": 5, "NONE": 4, "UNANSWERED": 40, "NOT_APPLICABLE": 1 }
}

HIGH is your HRI count. These are the backlog.

Step 7 — Export the improvement plan

aws wellarchitected list-lens-review-improvements \
  --workload-id "$WORKLOAD_ID" \
  --lens-alias wellarchitected \
  --query 'ImprovementSummaries[].{Q:QuestionTitle,Pillar:PillarId,Risk:Risk,Url:ImprovementPlanUrl}' \
  --output table

Each HIGH row becomes a ticket with the Url as the “how to fix.” Export the full report as PDF for stakeholders:

aws wellarchitected get-lens-review-report \
  --workload-id "$WORKLOAD_ID" \
  --lens-alias wellarchitected \
  --query 'Base64String' --output text | base64 --decode > wa-review.pdf

Step 8 — Capture a milestone (the baseline)

aws wellarchitected create-milestone \
  --workload-id "$WORKLOAD_ID" \
  --milestone-name "pre-remediation-baseline" \
  --query 'MilestoneNumber' --output text
# 1

aws wellarchitected list-milestones \
  --workload-id "$WORKLOAD_ID" \
  --query 'MilestoneSummaries[].{N:MilestoneNumber,Name:MilestoneName,When:RecordedAt}' \
  --output table

The milestone is immutable — re-review later, snapshot again, and compare the HRI counts.

Step 9 — The same workload as Terraform

The Terraform aws provider manages the workload (and lens shares); the answers, milestones, and reports are review-time operations you do via CLI/console/API. Provision the workload as code so it is reproducible and governed:

terraform {
  required_providers {
    aws = { source = "hashicorp/aws", version = "~> 5.0" }
  }
}

provider "aws" {
  region = "ap-south-1"
}

resource "aws_wellarchitected_workload" "tracking_api" {
  name               = "meridian-tracking-api-tf"
  description        = "Customer-facing shipment tracking API, managed as code"
  environment        = "PRODUCTION"
  aws_regions        = ["ap-south-1", "us-east-1"]
  review_owner       = "architecture-team@meridian.example"
  lenses             = ["wellarchitected"]

  # Declare which pillars matter most for this workload (drives prioritization)
  pillar_priorities  = [
    "reliability",
    "security",
    "operationalExcellence",
    "performance",
    "costOptimization",
    "sustainability",
  ]

  tags = {
    Team       = "platform"
    CostCenter = "logistics"
    ManagedBy  = "terraform"
  }
}

output "workload_id" {
  value = aws_wellarchitected_workload.tracking_api.id
}

terraform init && terraform apply
# aws_wellarchitected_workload.tracking_api: Creation complete after 3s [id=...]

⚠️ Terraform gotcha: the base wellarchitected lens is implicitly present. On some provider versions, listing it in lenses (or attaching AWS lenses out of band) causes a perpetual diff — pin your provider version and keep lens management consistent (all in Terraform or all via CLI, not both).

Step 10 — Teardown

# CLI-created workload
aws wellarchitected delete-workload --workload-id "$WORKLOAD_ID"

# Terraform-created workload
terraform destroy

Deleting a workload removes its answers and milestones. There is nothing metered to leave running, but keep your account tidy — and keep the exported PDF/plan before you delete, since the findings are the deliverable.

Common mistakes & troubleshooting

WA fails far more often on process than on tooling. This is the review anti-patterns playbook: the pattern, how it shows up, why it happens, how to confirm it, and the fix. Treat the “fix” column as the actual practice.

CLI error reference

The nastiest real failures

The confident green review. The most dangerous WA output is a review with no HRIs run by a team that has never had an incident. Green does not mean safe — it often means the questions were answered aspirationally. The confirm: cross-check the “None” answers against evidence (Trusted Advisor fault-tolerance checks, Compute Optimizer, Security Hub score). If the tools disagree with the ticks, the ticks are wrong. The fix is cultural: reward finding risk, not hiding it.

The orphaned improvement plan. A team runs a genuinely good review, exports a plan with real HRIs — and then it sits in a shared drive. Three months later the same HRIs surface in the next review, unchanged. The confirm is the flat HRI count between milestones. The only fix is the hand-off discipline: every HRI becomes a ticket with an owner and a date, and the HRI burn-down is reviewed at each cadence like any other backlog.

Scope sprawl. Someone defines “Production” as a single workload and tries to answer REL/SEC/COST for a dozen unrelated systems at once. Every answer becomes “it depends,” risk is meaningless, and the review stalls. The confirm: answers littered with “partially.” The fix is to split into workloads with coherent, distinct requirements — the tracking API and the analytics pipeline are two workloads, not one, precisely because their reliability and cost bars differ.

Best practices

• Scope workloads tightly and coherently. One system with one set of requirements per workload. Split when requirements diverge.
• Run the review before the launch, not as a post-launch audit. HRIs are cheapest to fix on a whiteboard.
• Answer honestly, for today. The review’s value is the gaps it finds; aspirational ticks destroy that value.
• Make trade-offs conscious and documented. Record what each choice costs another pillar and why you chose the balance.
• Turn every HRI into an owned, dated backlog item. No owner, no fix. This is the single highest-leverage habit.
• Prioritize ruthlessly: HRIs before MRIs, and only a handful per sprint. Do not try to green every pillar at once.
• Snapshot milestones around change — before launch, after each remediation sprint, at each cadence — to prove risk is trending down.
• Wire in evidence: activate Trusted Advisor on the workload; pull Security Hub and Compute Optimizer before answering.
• Match one lens to the workload’s dominant pattern; build a custom lens for internal standards you want every team checked against.
• Re-review on triggers: major change, post-incident, and a fixed cadence (quarterly/semi-annual). Drift is silent.
• Facilitate cross-functionally: owner, builders, security, and FinOps in the room. One person answering alone is blind.
• Treat “not applicable” as sacred: only for genuinely out-of-scope questions, always with a reason and evidence.

Security notes

The WA Tool stores your answers and notes — treat those notes as sensitive, because they describe exactly where your architecture is weak.

A minimal split-privilege pair — writers who run reviews, readers who consume them:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "WAReviewer",
      "Effect": "Allow",
      "Action": [
        "wellarchitected:CreateWorkload",
        "wellarchitected:UpdateAnswer",
        "wellarchitected:CreateMilestone",
        "wellarchitected:AssociateLenses",
        "wellarchitected:Get*",
        "wellarchitected:List*"
      ],
      "Resource": "*"
    }
  ]
}

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "WAReadOnly",
      "Effect": "Allow",
      "Action": ["wellarchitected:Get*", "wellarchitected:List*"],
      "Resource": "*"
    }
  ]
}

Tie the human identities behind these to your central IdP and SSO rather than IAM users — the same “strong identity foundation” (SEC 1/2) the review itself asks about.

Cost & sizing

The Well-Architected Tool is free — no charge for workloads, reviews, milestones, lenses, or reports. The cost of WA is entirely people-time and remediation, and the return is avoided incidents and removed waste.

Sizing the practice: review your handful of Tier-1 (customer-facing, revenue) workloads every quarter; Tier-2 semi-annually; Tier-3 and prototypes get a lightweight pillar conversation, not the full tool. The economics almost always favor the review — a single prevented single-AZ outage or one rightsizing pass typically pays for a year of reviews. Pair the cost findings with a real FinOps loop in Cost Optimization & FinOps Rightsizing and Cost Explorer, Budgets & Alerts.

Interview & exam questions

1. Name the six pillars of the Well-Architected Framework. Operational Excellence, Security, Reliability, Performance Efficiency, Cost Optimization, and Sustainability. Sustainability was added in December 2021; older material lists five. Map to SAA-C03/SAP-C02 “which pillar” questions.

2. What is a High-Risk Issue (HRI)? A question whose missing best practices are weighted high-risk. It is not a failing grade but a prioritized work item — the top of your improvement backlog. Medium-Risk Issues (MRIs) are second priority.

3. What is the difference between a pillar and a lens? A pillar is one of the six core categories the questions are grouped under. A lens is a set of questions/best practices — the base wellarchitected lens applies to every workload, and additive lenses (Serverless, SaaS, ML, Data Analytics, IoT, FSI) add domain-specific questions.

4. Give a concrete reliability↔cost trade-off and how you’d decide. Multi-AZ RDS roughly doubles database cost but removes a single-AZ failure mode. Decide against the business requirement: quantify the outage cost per hour vs the monthly delta. If an outage costs $18k/hour and Multi-AZ adds $380/month, reliability wins — and you document the conscious trade-off.

5. What is a milestone and why is it immutable? An immutable snapshot of a workload’s answers and risk at a point in time. Immutability is what lets you prove improvement between reviews and trust the record for audits — you can’t retroactively edit history.

6. How does the Tool compute risk — is it an average of ticked practices? No. Each best practice is weighted; leaving a high-weight practice unselected makes the whole question a High-Risk Issue regardless of how many others you ticked. “We do most of it” can still be red.

7. When should you run a Well-Architected review? Before major launches (2–4 weeks prior), after major architecture changes, after incidents, and on a recurring cadence (e.g. quarterly for Tier-1 workloads). It is continuous, not one-time.

8. Which AWS services provide evidence for your answers? Trusted Advisor (cost/perf/security/fault-tolerance/limits), Security Hub (security posture), Compute Optimizer (rightsizing), Config (compliance/inventory), Cost Explorer (spend), CloudWatch/X-Ray (health/latency), IAM Access Analyzer (over-broad access).

9. What are the general design principles? Stop guessing capacity; test at production scale; automate to make experimentation easier; allow evolutionary architectures; drive architectures using data; improve through game days. They sit above all six pillars.

10. When would you build a custom lens? When your organization has standards (naming, tagging, guardrails, regulatory controls) you want every team’s review to check. A custom lens adds your own questions/best practices and is shareable across accounts.

11. A team reports six green pillars on a lean startup workload. What’s your reaction? Skepticism. Green usually means aspirational answers, especially when Cost and Reliability both show no risk. Cross-check “None” answers against Trusted Advisor/Compute Optimizer/Security Hub; if the evidence disagrees, the answers are wrong.

12. How do WA findings become real change? Export the improvement plan, turn each HRI into a backlog ticket with an owner and due date and the guidance link, and track HRI burn-down against milestones each cadence. A plan without owners is the most common way WA dies.

Quick check

1. How many pillars are there, and which one was added most recently?
2. What makes a question a High-Risk Issue rather than Medium?
3. Why is reviewing a workload (not “AWS” in general) important for trade-offs?
4. Name one reliability↔cost and one security↔operations trade-off.
5. Which command exports the prioritized improvement plan, and which captures a baseline snapshot?

Answers

1. Six pillars; Sustainability was added in December 2021 (before that there were five).
2. A high-weight best practice is left unselected on that question — weighting, not the count of missing practices, drives the risk level.
3. Because the same answer can be correct for one workload and an HRI for another — a 20ms security control is fine for a bank and unacceptable for a real-time bidder. Trade-offs only make sense against a specific workload’s requirements.
4. Reliability↔cost: multi-AZ/multi-Region redundancy doubles infra spend. Security↔operations: more approval gates / inspection add friction and latency to delivery.
5. aws wellarchitected list-lens-review-improvements exports the plan; aws wellarchitected create-milestone captures the baseline snapshot.

Glossary

Next steps

• Run a real review on your most important workload using AWS Three-Tier Web Application Architecture as the reference topology, and split it into coherent workloads before you start.
• Deepen the Reliability answers with Disaster Recovery: RTO/RPO Strategies, AWS Backup & Disaster Recovery Strategies, and Multi-Region Active-Active Architecture.
• Turn Cost HRIs into an actual FinOps loop with Cost Optimization & FinOps Rightsizing and Tagging Strategy & Cost Allocation.
• Strengthen the Security pillar with GuardDuty Threat Detection, AWS Config Compliance Rules, and Organizations SCPs.
• Back your Operational Excellence and Performance answers with real telemetry via CloudWatch Metrics, Alarms & Dashboards and X-Ray Distributed Tracing.