An AWS bill that quietly climbs 20% a quarter, a single-AZ database that takes down checkout for six hours, an S3 bucket with public read left over from a demo two years ago — none of these show up until they cost real money. The AWS Well-Architected Framework exists to catch exactly this class of problem before it becomes an incident report. As of September 2026, the framework runs on six pillars, ships as a free tool inside every AWS account — AWS’s own Well-Architected page, refreshed that same month, still confirms there’s no charge to use it — and is increasingly treated as a gate before production sign-off rather than a nice-to-have audit. This tutorial walks through running a real Well-Architected Framework Review (WAFR) end to end: setting up the tool, answering the pillar questions honestly, wiring up cost-optimization signals, and turning the output into a prioritized backlog your team will actually work through.
This is a hands-on walkthrough, not a marketing overview. You will use the AWS Well-Architected Tool console, the AWS CLI wellarchitected commands, and Terraform to review a real (small) workload — a three-tier web app on ECS Fargate with an RDS backend — and come out the other side with a milestone, a risk list, and a remediation plan you can hand to a sprint.
Don't miss new tech stories on Google
Add Tech Insider once in the Google app and our stories appear in your news suggestions.
What the AWS Well-Architected Framework Actually Is
The AWS Well-Architected Framework is a structured set of questions and best practices AWS publishes for evaluating cloud architectures across six pillars: Operational Excellence, Security, Reliability, Performance Efficiency, Cost Optimization, and Sustainability. Each pillar has a whitepaper, a set of design principles, and a list of foundational questions (“How do you manage identity for people and machines?” or “How do you monitor your resources?”) that map to specific best practices. AWS describes the review itself in plain terms: “The purpose of reviewing an architecture is to identify any critical issues that might need addressing or areas that could be improved,” according to AWS’s official documentation.
Crucially, AWS is explicit that this is not meant to be a compliance audit with a pass/fail grade. “It should be a lightweight process (hours not days) that is a conversation and not an audit,” per AWS documentation on the review process. That framing matters because teams that treat WAFR like a checklist to rubber-stamp tend to skip the parts that would actually surface risk — usually Reliability and Security, since those questions require admitting gaps.
The review process itself runs in three phases, and AWS lays them out directly: “There are three phases to conduct a successful Well-Architected Framework Review or WAFR: Prepare, Review and Improve,” according to an AWS blog on performing the review. This tutorial follows that same three-phase structure, with the CLI and Terraform steps mapped to each phase so you are not just reading questions off a screen — you are producing artifacts (a milestone snapshot, a risk report, a remediation Kanban) that survive after the review meeting ends.
Why Use the Tool Instead of a Spreadsheet Checklist
Plenty of teams ran informal architecture reviews long before AWS shipped a dedicated tool for it — a shared spreadsheet, a wiki page with a checklist, a recurring “architecture review board” meeting with no fixed structure. Those approaches still work in a pinch, but they lose three things the Well-Architected Tool provides automatically: consistent question sets across every workload, machine-readable risk classification you can query and chart over time, and a built-in comparison between milestones so drift is visible instead of anecdotal.
The tool also enforces a shared vocabulary. When one team calls something a “High Risk Issue” and another team calls the same gap a “concern,” those two findings never get compared or prioritized against each other at the org level. Standardizing on the framework’s own severity labels means a platform team overseeing 40 workloads can pull a single query and rank every open High Risk Issue across the entire portfolio by pillar, by team, or by age — something a pile of spreadsheets scattered across Google Drive folders cannot do.
Where the Tool Falls Short
It is worth being honest about the limits, too. The tool has no live integration with your actual infrastructure — it does not scan your account and pre-fill answers. Every response is manually entered by whoever runs the review, which means the output is only as accurate as the humans answering it. It also does not track ownership or deadlines natively; that has to live in whatever ticketing system your team already uses, as covered in Step 9 below. Treat the Well-Architected Tool as the question bank and the risk ledger, not as a project management system.
Prerequisites and Versions
Confirm you have the following before starting. Version drift is the single biggest cause of “the console doesn’t match the tutorial” complaints, so pin these where you can.
- An AWS account with IAM permissions for
wellarchitected:*,ce:*(Cost Explorer), and read access to the services in your workload (EC2, ECS, RDS, S3, CloudWatch) - AWS CLI v2.27 or later (
aws --version— thewellarchitectedsubcommands have been stable for years, but Cost Explorer and Compute Optimizer integration flags need a recent build) - Terraform 1.10 or later with the
hashicorp/awsprovider pinned to~> 5.90 - A workload already running in AWS — this tutorial uses a three-tier app (ALB → ECS Fargate → RDS PostgreSQL) as the running example, but the steps apply to any workload type
- AWS Cost Explorer enabled on the account (it takes up to 24 hours to populate after first enabling, so turn it on before you start if it is not already active)
- Optional: access to AWS Compute Optimizer’s idle-resource detection, which by mid-2026 expanded coverage to DynamoDB, ElastiCache, MemoryDB, DocumentDB, WorkSpaces, and SageMaker alongside its original EC2, EBS, ECS, and Lambda coverage
- A calendar block of 90–120 minutes with the people who actually own the workload — the tool takes minutes to click through, but the review only produces value if the right engineers are in the room answering honestly
One clarification worth making up front: the Well-Architected Tool is free. AWS refreshed its guidance on this in April 2025, and the position hasn’t changed since: there is no charge for creating workloads, running reviews, or generating reports inside the AWS Well-Architected Tool itself. You only pay for the underlying AWS resources the review touches (Cost Explorer API calls are free for console use, CloudWatch queries you were already running, and so on).
Step 1: Enable Cost Explorer and Baseline Your Spend
Do this first because Cost Explorer data takes time to populate and you will need it for the Cost Optimization pillar later. From the AWS Billing console, go to Cost Explorer and click Enable Cost Explorer if it is not already active. Then pull a baseline via CLI so you have a number to compare against once remediation work ships:
aws ce get-cost-and-usage \
--time-period Start=2026-07-01,End=2026-08-31 \
--granularity MONTHLY \
--metrics "UnblendedCost" \
--group-by Type=DIMENSION,Key=SERVICE \
--output tableSave this output somewhere durable — a doc, a pinned Slack message, whatever survives past this quarter. This is your “before” number. Without it, the Cost Optimization pillar’s payoff is unmeasurable, and unmeasurable savings claims get deprioritized fast when the next planning cycle comes around.
Step 2: Create a Workload in the Well-Architected Tool
Open the AWS Well-Architected Tool console (search “Well-Architected” in the console search bar) and click Define workload. A “workload” in WAFR terms is any unit of software delivering business value — a single microservice, an entire product, or a shared platform layer. Do not try to review your entire AWS footprint as one workload; split by team ownership or blast radius instead. For this tutorial, the workload is the checkout service: ALB, ECS Fargate tasks, and an RDS PostgreSQL instance.
You can also do this from the CLI, which is the better option if you want workload creation to be reproducible across accounts or captured in version control:
aws wellarchitected create-workload \
--workload-name "checkout-service-prod" \
--description "ALB + ECS Fargate + RDS PostgreSQL checkout path" \
--environment PRODUCTION \
--aws-regions "us-east-1" \
--review-owner "[email protected]" \
--lenses "wellarchitected" \
--pillar-priorities "security" "reliability" "costOptimization"The --pillar-priorities flag does not skip other pillars — it just changes how AWS orders and weights recommendations in the generated report. For a checkout path handling payments, prioritizing Security and Reliability ahead of Sustainability is the right call; a batch analytics pipeline might reasonably flip that order.
Step 3: Understand the Six Pillars Before You Answer Anything
Reading the pillar names is not the same as understanding what each one is actually asking. Here is the plain-language version of each pillar and the kind of evidence you need on hand to answer its questions credibly.
| Pillar | Core question | Evidence you need ready |
|---|---|---|
| Operational Excellence | Can you run and improve this system without heroics? | Runbooks, deploy pipeline config, incident postmortems |
| Security | Is access, data, and the network locked down and auditable? | IAM policies, Security Hub findings, encryption config |
| Reliability | Does it recover from failure and handle real load? | Multi-AZ config, backup/restore tests, load test results |
| Performance Efficiency | Are you using the right resource types and sizes? | CloudWatch utilization metrics, instance/task sizing history |
| Cost Optimization | Are you paying for capacity you actually use? | Cost Explorer baseline, Compute Optimizer recommendations |
| Sustainability | Are you minimizing the resource footprint per unit of work? | Region selection rationale, idle resource inventory |
Skip the temptation to answer from memory. The Well-Architected Tool asks specific, falsifiable questions like “How do you back up data?” and “How do you select the appropriate instance type for your compute-based workload?” Answers based on what you assume is true rather than what CloudWatch and Config actually show tend to produce a report that looks clean and hides the real risk.
Security and Reliability Deserve Extra Time
Of the six pillars, Security and Reliability tend to surface the most High Risk Issues on a first-time review, and for the same underlying reason: both pillars ask about failure scenarios, and most teams have spent far more time building the happy path than testing what happens when something breaks. Security questions cover identity boundaries, detective controls, and data protection — areas where a single overlooked IAM policy or an unencrypted snapshot can undo months of otherwise solid engineering. Reliability questions cover backup and restore testing, failover behavior, and whether the team has actually run a game day rather than just assuming failover works because it is configured. Budget extra discussion time for these two pillars rather than rushing through them at the same pace as Sustainability or Performance Efficiency.
Step 4: Work Through the Prepare Phase
Before opening the questionnaire, spend 15–20 minutes gathering artifacts. This is the “Prepare” phase AWS calls out explicitly as one of the three stages of a successful review. In practice, prepare means:
- Pull an architecture diagram that reflects what is actually deployed, not the one from the original design doc (these drift constantly — verify against Config or a live
aws ecs describe-servicescall) - Export the last 90 days of CloudWatch alarms that fired, so Reliability answers are backed by real incident data instead of guesses
- Run AWS Trusted Advisor’s cost and security checks and have the results open in a second tab
- Identify the actual owners in the room — a WAFR review with only managers present tends to produce optimistic answers that the engineers who get paged would disagree with
Skipping prepare is the single most common reason a WAFR session runs long or produces a shallow report. AWS’s guidance that the review should take “hours not days” only holds if the prep work happens beforehand, not live in the meeting.
Step 5: Run the Review Phase — Answer the Pillar Questions
In the Well-Architected Tool console, open your workload and click into each pillar’s question list. AWS’s own framing of this stage is direct: “During the Well-Architected Framework Review (WAFR), you will answer a set of foundational questions to learn how well your architecture aligns with cloud best practices and receive guidance for implementing improvements,” according to AWS documentation. For each question you will:
- Read the question and its “best practices” sub-list
- Select every best practice you actually have in place — partial credit exists, so check the boxes that are true, not just the top one
- Leave unchecked best practices you have not implemented — this generates a High or Medium Risk Issue (HRI/MRI) automatically
- Add notes in the free-text field explaining context (for example: “single-AZ RDS is intentional for this dev-tier workload, will change before GA”)
The tool auto-flags a question as “High Risk” if you leave out foundational best practices (like Multi-AZ for a production database) and “Medium Risk” for less critical gaps. Do not argue with the tool’s severity classification mid-review — capture disagreements as notes and revisit them in the Improve phase, otherwise the meeting turns into a debate about the tool instead of the architecture.
Step 6: Pull Real Cost Data Into the Cost Optimization Pillar
The Cost Optimization pillar questions ask about visibility, forecasting, and rightsizing — but answering them well needs live data, not opinions. Compute Optimizer’s idle-resource detection covers most of a typical workload’s footprint. Query it directly for the resources in scope:
aws compute-optimizer get-idle-recommendations \
--resource-arns "arn:aws:rds:us-east-1:123456789012:db:checkout-prod" \
--output table
aws compute-optimizer get-ec2-instance-recommendations \
--instance-arns "arn:aws:ec2:us-east-1:123456789012:instance/i-0abc123456789" \
--output json | jq '.instanceRecommendations[].recommendationOptions'Feed these numbers directly into the Cost Optimization pillar’s notes fields. A question like “Do you monitor cost anomalies?” answered with “yes, weekly Compute Optimizer export reviewed in FinOps sync” is a real, checkable practice — a lot stronger than checking the box because it sounds like the right answer.
Step 7: Generate the Milestone Report
Once every pillar’s questions are answered, save a milestone. A milestone is a frozen snapshot of your answers at a point in time — this is what lets you measure progress on the next review instead of just re-answering questions from scratch.
aws wellarchitected create-milestone \
--workload-id "abcd1234ef567890abcd1234ef567890" \
--milestone-name "wafr-review-2026-08-31"
aws wellarchitected get-consolidated-report \
--include-shared-resources \
--format PDF \
--output-uri s3://my-wafr-reports/checkout-service-2026-08.pdfStore the milestone ID somewhere your team will find it in six months. Re-reviewing the same workload without comparing against the prior milestone is one of the most common ways teams waste the exercise — they redo the same conversation every quarter instead of tracking whether last quarter’s fixes actually shipped.
Reading the Consolidated Report
The exported PDF is organized by pillar, and each pillar section lists the questions in order, your selected best practices, and any notes attached. Do not just skim the risk summary page at the front — the notes field is where the actual reasoning lives, and it is what a reviewer six months from now will need to understand why a particular gap was accepted rather than fixed. A report with risk counts but no notes is close to useless for anyone who was not in the original meeting. Before closing out the review, have one person read through every note and flag any that just say “TODO” or “will fix later” without a name or date attached — those are the ones that will still be open at the next review.
Step 8: Automate Workload Definition With Terraform
If you run WAFR reviews across dozens of workloads, clicking through the console each time does not scale. Define the workload as code so new services get a Well-Architected workload automatically when they are provisioned:
resource "aws_wellarchitected_workload" "checkout" {
workload_name = "checkout-service-prod"
description = "ALB + ECS Fargate + RDS PostgreSQL checkout path"
environment = "PRODUCTION"
review_owner = "[email protected]"
aws_regions = ["us-east-1"]
lenses = ["wellarchitected"]
tags = {
Team = "checkout"
CostCenter = "eng-platform"
ReviewCycle = "quarterly"
}
}
resource "aws_wellarchitected_lens_share" "shared" {
workload_id = aws_wellarchitected_workload.checkout.id
lens_alias = "wellarchitected"
shared_with = "arn:aws:organizations::123456789012:organization/o-exampleorgid"
}Pin the AWS provider to ~> 5.90 or later — earlier provider versions have inconsistent support for lens-sharing resources, which is a common source of apply failures when teams copy Terraform snippets from older blog posts.
Step 9: Triage High Risk Issues Into a Remediation Backlog
Pull every High Risk Issue (HRI) out of the tool and put it somewhere your team already works — a Jira epic, a GitHub Projects board, whatever is not the Well-Architected console itself, because nobody checks that dashboard between reviews. Use the CLI to export the raw list programmatically instead of transcribing by hand:
aws wellarchitected list-answers \
--workload-id "abcd1234ef567890abcd1234ef567890" \
--lens-alias "wellarchitected" \
--pillar-id "security" \
--query "AnswerSummaries[?Risk=='HIGH_RISK']" \
--output jsonRank the resulting list by blast radius, not by pillar. A Medium Risk gap in Cost Optimization that is wasting $400 a month is real but not urgent; a High Risk gap in Security around an IAM role with unscoped s3:* permissions on a production bucket needs to jump the queue regardless of which pillar it came from.
Step 10: Fix the Easy Wins First
Most WAFR reviews surface a handful of fixes that take under a day and remove a High Risk flag outright. Common ones from the Reliability and Security pillars:
- Enabling Multi-AZ on an RDS instance that was left single-AZ from initial setup
- Turning on S3 bucket versioning and blocking public access at the account level via S3 Block Public Access
- Adding a CloudWatch alarm for the metrics you are already collecting but never alerted on
- Enabling deletion protection on production RDS and DynamoDB resources
- Rotating an IAM access key that has not been rotated in over 90 days
Ship these before the next standup, and re-run the specific question in the Well-Architected Tool to clear the flag immediately rather than waiting for the next full review cycle. Momentum matters here — teams that see risk counts drop quickly stay engaged with the process; teams that wait three months to see any movement stop taking the exercise seriously.
Step 11: Schedule the Improve Phase as a Recurring Cadence
The “Improve” phase is not a one-time cleanup sprint — it is the ongoing work of closing HRIs and MRIs against a schedule. AWS’s own three-phase framing (Prepare, Review, Improve) implies a loop, not a line. Set a recurring milestone cadence:
| Workload tier | Review cadence | Who attends |
|---|---|---|
| Production, customer-facing | Quarterly | Service owner, SRE lead, security rep |
| Production, internal-only | Semi-annually | Service owner, one platform engineer |
| Staging / pre-prod | Before GA promotion | Service owner |
| Sandbox / experimental | On demand | Individual engineer |
Attaching the review cadence to a calendar reminder tied to the milestone name (not a generic “quarterly review” event) keeps it from silently dropping off when the person who set it up changes teams.
Step 12: Use Custom Lenses for Workload-Specific Standards
The default “wellarchitected” lens covers general best practices, but it will not catch domain-specific requirements — PCI DSS scoping for a payments workload, HIPAA data handling for a health record system, or your own internal platform standards. AWS supports custom lenses for exactly this, and it also maintains its own specialized lenses — AWS shipped an updated Generative AI Lens in November 2025 covering best practices for LLM-based workloads, worth importing alongside the standard lens if your workload touches generative AI. Define one as JSON and import it alongside the standard lens:
aws wellarchitected import-lens \
--lens-alias "internal-payments-standard" \
--json-string file://payments-lens.json
aws wellarchitected update-workload \
--workload-id "abcd1234ef567890abcd1234ef567890" \
--lenses "wellarchitected" "internal-payments-standard"Teams that skip custom lenses tend to bolt on a separate compliance checklist outside the Well-Architected Tool, which means two disconnected review processes instead of one — and the compliance checklist is usually the one that gets skipped when deadlines slip.
5 Common Pitfalls to Avoid
1. Reviewing an architecture diagram instead of what is actually deployed. Config drift between the design doc and the live environment is the norm, not the exception. Pull real resource state (via Config or CLI describe calls) before answering any question, not the diagram from the original design review.
2. Treating the review as a one-time audit. A milestone from a single review has a shelf life of maybe a quarter before the workload has drifted enough to make it stale. Build the review into a recurring cadence from day one, not as an afterthought once someone asks whether it was already done.
3. Letting managers answer questions engineers should answer. Reliability and Operational Excellence questions especially need answers from whoever gets paged, not whoever runs the roadmap. A manager’s optimistic “yes, we have runbooks” often means a stale wiki page nobody has opened in a year.
4. Skipping the Sustainability and Operational Excellence pillars because they feel less urgent. Security and Cost get the attention because they map to visible incidents and visible dollars. But Operational Excellence gaps, like missing runbooks or no game days, are frequently what turns a minor Reliability incident into a multi-hour outage.
5. Generating the report and never assigning owners to the risk items. A PDF full of High Risk Issues that sits in a shared drive changes nothing. Every HRI needs a name and a target sprint attached within a week of the review, or it will not get fixed before the next review surfaces the same gap again.
Output Example: What a Completed Review Looks Like
A well-run WAFR session for a mid-sized workload typically produces something like this after the Review phase:
| Pillar | Questions answered | High risk issues | Medium risk issues |
|---|---|---|---|
| Operational Excellence | 10 | 1 | 3 |
| Security | 10 | 2 | 2 |
| Reliability | 9 | 3 | 1 |
| Performance Efficiency | 7 | 0 | 2 |
| Cost Optimization | 10 | 1 | 4 |
| Sustainability | 6 | 0 | 1 |
Seven High Risk Issues out of roughly 50 questions is a normal, unremarkable result for a workload that has never been through a formal review — it is not a sign of a badly built system, it is a sign the review is doing its job. What matters is the trend on the next milestone: that count should be visibly lower, not the same or higher.
Troubleshooting: Common Issues and Fixes
1. “AccessDeniedException” when calling wellarchitected CLI commands. Your IAM identity is missing the wellarchitected:* permission set, or you have a permissions boundary blocking it. Attach the AWS-managed WellArchitectedConsoleFullAccess policy or a scoped equivalent.
2. Cost Explorer data is empty or shows $0 for recent dates. Cost Explorer takes up to 24 hours after activation to populate, and it only reports finalized billing data — the current day and often the prior day will always be incomplete. Query a date range that ends at least 48 hours in the past.
3. A shared workload shows different answers to different reviewers. This usually means the workload was shared without a locked lens version, so reviewers on different sessions saw different question sets. Re-share with an explicit lens version pinned via the share-invitation parameters.
4. Custom lens import fails with a JSON schema error. The Well-Architected custom lens schema is strict about required fields like pillarId and bestPractices ordering. Validate the JSON against AWS’s published lens schema before importing rather than debugging the import error message alone.
5. Terraform apply fails on aws_wellarchitected_lens_share. This resource type needs a sufficiently recent AWS provider. Bump to ~> 5.90 and re-run terraform init -upgrade.
6. The consolidated report export to S3 fails silently. Check that the target bucket policy allows the Well-Architected service principal to write, and that the bucket is not blocking uploads via a default-deny bucket policy left over from a security hardening pass.
7. Compute Optimizer returns no recommendations for a resource. Compute Optimizer needs at least 14 days of CloudWatch utilization history before it can generate a recommendation. New resources or ones with monitoring recently enabled will return an empty result until that window passes.
8. Risk counts do not drop after fixing the underlying issue. Fixing the infrastructure does not automatically update the Well-Architected Tool’s answers — you have to go back into the console (or call the update-answer API) and re-check the best practice box manually. The tool has no automated drift detection against your live environment.
9. Milestone comparison shows no meaningful change between reviews. This is often a review fatigue symptom — teams start clicking through without re-verifying evidence. Rotate who leads the review each cycle so the same assumptions do not go unchallenged twice in a row.
Advanced Tips
Once the basic review cadence is running, a few practices separate teams that get real value from WAFR from teams that treat it as a box-checking exercise:
- Wire risk counts into a dashboard, not just a PDF. Pull
list-workloadsandlist-answersacross every workload in the account via a scheduled Lambda, and push the aggregate HRI/MRI count into whatever dashboard your org already watches (Grafana, QuickSight, an internal status page). Visibility outside the review meeting is what keeps leadership funding the remediation work. - Use the AWS Well-Architected Tool’s API, not just the console, for org-wide rollups. If you own dozens of workloads across an AWS Organization, script a monthly export of every workload’s risk summary rather than opening each one by hand.
- Pair WAFR with Trusted Advisor and Security Hub, not instead of them. WAFR is a human-driven, periodic exercise; Trusted Advisor and Security Hub are continuous automated checks. The overlap is intentional — use WAFR to catch the architectural and process gaps those tools cannot see, like whether your team actually runs game days.
- Give new engineers a scoped, single-pillar review as onboarding. Walking a new hire through the Security pillar for a service they will own is a faster way to build real system knowledge than reading a wiki page.
- Track time-to-remediation, not just risk count. A workload with five open HRIs that get fixed within two weeks is healthier than one with two HRIs that have sat open for eight months.
Complete Working Project: End-to-End Review Script
Combining the CLI steps above into a single reusable script gives you something you can hand to any team starting their first review. Save this as run-wafr-review.sh:
#!/bin/bash
set -euo pipefail
WORKLOAD_NAME="$1"
OWNER_EMAIL="$2"
REGION="${3:-us-east-1}"
echo "Creating Well-Architected workload: $WORKLOAD_NAME"
WORKLOAD_ID=$(aws wellarchitected create-workload \
--workload-name "$WORKLOAD_NAME" \
--description "Automated WAFR intake for $WORKLOAD_NAME" \
--environment PRODUCTION \
--aws-regions "$REGION" \
--review-owner "$OWNER_EMAIL" \
--lenses "wellarchitected" \
--query "WorkloadId" --output text)
echo "Workload created: $WORKLOAD_ID"
echo "Pulling 60-day cost baseline..."
aws ce get-cost-and-usage \
--time-period Start=$(date -d '60 days ago' +%Y-%m-%d),End=$(date +%Y-%m-%d) \
--granularity MONTHLY \
--metrics "UnblendedCost" \
--group-by Type=DIMENSION,Key=SERVICE \
--output json > "cost-baseline-${WORKLOAD_NAME}.json"
echo "Pulling idle resource recommendations..."
aws compute-optimizer get-idle-recommendations \
--output json > "idle-resources-${WORKLOAD_NAME}.json" || echo "No idle recommendations available yet"
echo "Open this URL to begin answering questions:"
echo "https://console.aws.amazon.com/wellarchitected/home?region=${REGION}#/workload/${WORKLOAD_ID}"
echo ""
echo "After answering all pillars, run:"
echo " aws wellarchitected create-milestone --workload-id ${WORKLOAD_ID} --milestone-name \"initial-review-$(date +%Y-%m-%d)\""Run it with ./run-wafr-review.sh checkout-service-prod [email protected] us-east-1. It creates the workload, snapshots your cost baseline and idle-resource findings before anyone opens the console, and prints the direct link to start answering questions — removing the friction that usually causes teams to keep postponing their first review.
How This Fits Into a Broader FinOps and Governance Strategy
A Well-Architected review is not a substitute for landing zone governance, budget alerts, or IAM guardrails — it is the periodic human check that catches what automated controls miss. Pair it with a landing zone setup for baseline account governance, budget alerts for continuous spend monitoring between reviews, and centralized identity management so the Security pillar questions have a clean answer instead of a scramble to document a decade of ad-hoc IAM users. Teams that run WAFR in isolation from these other controls tend to find the same handful of governance gaps every single review, because nothing structural changed between cycles — only the review happened again.
Who Should Be in the Room
A WAFR review works best with a small, specific group rather than an open invite. Four to six people is the practical sweet spot: too few and you miss the perspective a security-focused engineer would bring to a Reliability question; too many and the meeting turns into a status update instead of a working session. A reasonable default lineup:
- The service owner or tech lead — the person who can answer questions about current architecture decisions with authority, not secondhand knowledge
- One on-call engineer — whoever actually gets paged when this workload breaks, since their answer to Reliability questions will be more honest than a manager’s
- A security representative — either embedded on the team or from a central security function, to keep the Security pillar answers from being self-graded
- A platform or FinOps representative — someone who can speak to Cost Optimization with real billing data rather than a guess at monthly spend
- A facilitator — often a platform engineer running reviews across many teams, whose job is to keep the session moving and make sure risk items get written down with an owner attached before the meeting ends
Skip inviting an entire team of ten-plus engineers to every pillar. It is fine — and often faster — to split the review into shorter, pillar-specific sessions with different attendees: a Security-focused 30-minute session with the security rep and the tech lead, followed by a separate Cost Optimization session with the FinOps rep. What matters is that whoever answers a question actually owns the area it covers.
What It Costs to Skip This
It is fair to ask whether a 90-minute meeting and a follow-up remediation sprint are worth the engineering time, especially on a team already stretched across a roadmap. The honest answer is that WAFR does not prevent every incident — it is a periodic sampling exercise, not continuous monitoring. What it reliably catches is the class of problem that sits quietly for months because no single sprint ever prioritizes “audit our own architecture” over shipping the next feature: a database backup that was never actually tested for restore, an IAM role granted broad access during an early prototype that never got scoped down, a Reserved Instance commitment that expired and silently reverted the account to On-Demand pricing.
None of these show up in a normal sprint retro because nothing broke yet. They show up in a WAFR review because the questionnaire forces someone to actually check, rather than assume. The cost of the review is a couple of engineering-hours per quarter; the cost of skipping it is whatever the first incident caused by one of these gaps ends up costing — in downtime, in an unplanned weekend page, or in a security finding that should have been caught internally instead of by a customer or an auditor.
Frequently Asked Questions
Does the AWS Well-Architected Tool cost money to use?
No. Creating workloads, answering questions, generating milestones, and exporting reports through the AWS Well-Architected Tool is free — AWS’s Well-Architected page, last refreshed in September 2026, still states this plainly. You only pay for the underlying AWS resources (Cost Explorer, CloudWatch, Compute Optimizer) the review references, and most of those have free usage tiers for console access.
How long does a full Well-Architected review actually take?
For a single workload with proper preparation, expect 90 minutes to two hours to answer all six pillars with a small group. AWS’s own guidance describes the target as “hours not days” — sessions that stretch beyond half a day usually indicate the prep work was skipped.
What is the difference between a High Risk Issue and a Medium Risk Issue?
The tool auto-classifies severity based on which best practices you leave unchecked for each question. High Risk Issues map to foundational practices AWS considers critical, like Multi-AZ for production databases. Medium Risk Issues cover practices that improve the architecture but are not immediately dangerous to skip.
Can I review a workload that spans multiple AWS accounts?
Yes. Define the workload once and list every relevant account and region in the workload configuration, or use AWS Organizations sharing to let reviewers across accounts see the same workload definition without duplicating it.
Is the Well-Architected Framework the same as a security audit or SOC 2 assessment?
No. WAFR is a self-service architectural review focused on best practices across six pillars; it is not a formal compliance audit and does not produce a certification. Use custom lenses to layer in compliance-specific requirements like PCI DSS or HIPAA alongside the standard lens, but treat WAFR and formal compliance audits as separate, complementary processes.
Do I need special AWS access to run a Well-Architected review?
You need IAM permissions scoped to the wellarchitected service plus read access to whatever resources the workload touches. No special account tier or paid support plan is required — the tool is available on every AWS account by default.
How often should we re-review the same workload?
Quarterly for production, customer-facing workloads; semi-annually for internal-only production systems; and always before promoting a workload from staging to general availability. Anchor the cadence to a calendar reminder tied to the milestone name so it survives team turnover.
Can I automate answering Well-Architected questions instead of doing it manually?
Partially. You can script the creation of workloads, the pulling of supporting evidence such as cost data, idle resources, and CloudWatch alarms, and the export of milestone reports via the CLI and Terraform. The actual judgment calls on each best-practice question still require a human who understands the workload — automating that step defeats the purpose of the review.
Related Coverage
- AWS Systems Manager Azure Setup: 12 Steps, 90 Min [2026]
- AWS Step Functions Terraform Tutorial: 12 Steps, 90 Min [2026]
- How to Set Up AWS Cost Explorer & Budgets: 12 Steps, 90 Min [2026]
- How to Deploy AWS ECS Fargate: 12 Steps, 90 Min [2026]
- How to Set Up AWS Glue: 12 Steps, 90 Min [2026]
