AWS Well-Architected Framework: A Practical Review Guide

The AWS Well-Architected Framework is AWS's set of design questions and best practices, grouped into six pillars: operational excellence, security, reliability, performance efficiency, cost optimization and sustainability. You apply it by reviewing one workload at a time in the free Well-Architected Tool, answering each question with evidence instead of opinion, and turning the high-risk issues into a dated backlog. A review is only worth the afternoon if it changes what your team ships next quarter.

Key takeaways

• Review one workload, not an account. A workload is a set of components that deliver one business outcome, and its owners must be in the room.
• Bring evidence. Config compliance, Security Hub findings, backup status and the last restore test answer most questions faster than memory does.
• High-risk issues (HRIs) become tickets with owners and dates. A report full of findings that nobody owns is the most common failure.
• The pillars trade against each other. Write the trade-off down when you accept one, so the next review does not relitigate it.
• Save a milestone at the end of every review. Progress between milestones is the only score that matters.
• Use lenses (serverless, SaaS, machine learning, or your own custom lens) when the general questions are too generic for the workload.

What the framework is, and what it is not

The framework is a question bank. For each pillar AWS publishes questions ("How do you back up data?", "How do you securely operate your workload?") and, under each question, a list of best practices. When you answer a question by ticking which practices you follow, the tool computes a risk level from what is missing.

It is not a certification and not an audit. There is no pass mark, nobody external signs it off, and a perfect set of answers is neither possible nor useful. Treat it as a structured conversation that forces the uncomfortable questions on to the table: who can delete production data, when did we last restore a backup, what happens when this dependency is slow.

Here is what each pillar asks once you strip the vocabulary away:

No pillar stands alone. Encrypting everything with customer managed KMS keys (security) adds KMS request costs (cost) and a dependency on KMS availability (reliability). Multi-AZ databases (reliability) mean paying for a standby that serves no traffic (cost). The framework does not resolve these for you. It makes sure you resolve them on purpose.

How a review works in the Well-Architected Tool

The Well-Architected Tool lives in the AWS console and has a full API. The model is simple:

• A workload is the unit of review. It has an owner, an environment (production or pre-production) and the regions it runs in.
• A lens is a question set. Every workload gets the framework lens (wellarchitected); you can add official lenses or custom ones.
• Each question has choices. The tool derives a risk of high, medium or none from the choices you leave unticked.
• An improvement plan lists the practices behind each risk, with links to AWS guidance.
• A milestone freezes the state of the review so later reviews can be compared to it.

You can drive all of it from the CLI, which matters when you review many workloads or want reviews in version control:

aws wellarchitected create-workload \
  --workload-name "checkout-api" \
  --description "Checkout API on ECS Fargate with Aurora PostgreSQL" \
  --environment PRODUCTION \
  --review-owner "platform-team@example.com" \
  --aws-regions us-east-1 \
  --lenses wellarchitected

Find other lenses you can apply with:

aws wellarchitected list-lenses \
  --lens-type AWS_OFFICIAL \
  --query 'LensSummaries[].[LensAlias,LensName]' \
  --output table

After the session, pull the risk counts per pillar and the high-risk improvements:

aws wellarchitected get-lens-review \
  --workload-id "$WORKLOAD_ID" \
  --lens-alias wellarchitected \
  --query 'LensReview.PillarReviewSummaries[].[PillarName,RiskCounts]'
 
aws wellarchitected list-lens-review-improvements \
  --workload-id "$WORKLOAD_ID" \
  --lens-alias wellarchitected \
  --pillar-id reliability \
  --query 'ImprovementSummaries[?Risk==`HIGH`].[QuestionTitle,ImprovementPlanUrl]' \
  --output table

And close the review by saving a milestone:

aws wellarchitected create-milestone \
  --workload-id "$WORKLOAD_ID" \
  --milestone-name "2026-q4-baseline"

Two features are worth knowing about once you review more than a handful of workloads. Review templates pre-fill answers that are true for every workload in your organization (for example, "all accounts are in AWS Organizations with CloudTrail enforced"), so sessions spend their time on what is specific to the workload. Profiles let you state the business priorities of a workload up front, so the tool highlights the questions that matter most for it.

Before the review: build an evidence pack

The worst reviews are an hour of people guessing. The best ones start with a short evidence pack, collected the day before by one engineer. Most of it is a few CLI calls.

Is the audit trail on everywhere, and can we trust it?

aws cloudtrail describe-trails \
  --query 'trailList[].[Name,IsMultiRegionTrail,IsOrganizationTrail,LogFileValidationEnabled]' \
  --output table

Which Config rules are failing right now?

aws configservice describe-compliance-by-config-rule \
  --compliance-types NON_COMPLIANT \
  --query 'ComplianceByConfigRules[].ConfigRuleName' \
  --output text

What critical findings are open in Security Hub CSPM (the service previously called Security Hub)?

aws securityhub get-findings \
  --filters '{"SeverityLabel":[{"Value":"CRITICAL","Comparison":"EQUALS"}],"RecordState":[{"Value":"ACTIVE","Comparison":"EQUALS"}],"WorkflowStatus":[{"Value":"NEW","Comparison":"EQUALS"}]}' \
  --query 'Findings[].[Title,Resources[0].Id]' \
  --output table

What is backed up, and when was the last backup?

aws backup list-protected-resources \
  --query 'Results[].[ResourceType,ResourceArn,LastBackupTime]' \
  --output table

How much of the spend can we attribute?

aws ce get-cost-and-usage \
  --time-period Start=2026-09-01,End=2026-10-01 \
  --granularity MONTHLY \
  --metrics UnblendedCost \
  --group-by Type=TAG,Key=team

The cost output has a bucket for spend with no team tag. If that bucket is large, the cost pillar conversation is already over: you cannot optimize spend you cannot attribute.

Add three things no API gives you: the date of the last successful restore test, the date of the last load test, and the last two incident reviews. If any of those do not exist, you have found your first high-risk issues before the meeting starts.

Pillar by pillar: what to check and what to fix first

This is where most write-ups list every best practice. We would rather tell you where reviews of real production workloads usually find the risk, and which fix to do first.

Operational excellence

Look for how a change reaches production and how a bad one leaves it. Every change, application or infrastructure, should go through a pipeline with tests and a rollback path. Console changes in production should be rare, logged and reconciled back into code. If you cannot rebuild the environment from Terraform or another IaC tool, you cannot trust any other answer in the review.

Alarms are the other half. A CPU alarm tells you a server is busy. An alarm on the error rate or p99 latency of the user-facing endpoint tells you customers are hurting. The first fix is usually to add alarms on two or three service level indicators and route them to whoever is on call, then delete the alarms nobody acts on.

Security

Start with identities, not firewalls. List the roles humans use to reach production and check what they can do; then look for IAM users with access keys, which should be close to none now that IAM Identity Center and role federation cover most cases. Our cloud IAM guide covers the policy work in detail.

Then protect the controls that let you investigate. An attacker or a tired engineer who can stop CloudTrail can erase your ability to answer "what happened". A service control policy makes that impossible from any member account:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "ProtectAuditAndDetection",
      "Effect": "Deny",
      "Action": [
        "cloudtrail:StopLogging",
        "cloudtrail:DeleteTrail",
        "config:StopConfigurationRecorder",
        "config:DeleteConfigurationRecorder",
        "guardduty:DeleteDetector",
        "securityhub:DisableSecurityHub"
      ],
      "Resource": "*"
    },
    {
      "Sid": "StayInTheOrganization",
      "Effect": "Deny",
      "Action": "organizations:LeaveOrganization",
      "Resource": "*"
    }
  ]
}

SCPs do not apply to the management account, which is one more reason to run no workloads there.

Reliability

Ask three questions in order. What happens when one Availability Zone fails? What happens when a dependency is slow rather than down? When did we last restore from backup, and how long did it take?

The first is usually answered well because managed services make multi-AZ a checkbox. The second is where outages come from: missing timeouts, retries without backoff or jitter, and connection pools that block every request thread when one downstream call hangs. The third is answered badly more often than any other question in the framework. Backups that have never been restored are a hypothesis.

A baseline worth having in code for any production relational database:

resource "aws_db_instance" "checkout" {
  identifier              = "checkout-db"
  engine                  = "postgres"
  instance_class          = var.db_instance_class
  allocated_storage       = 100
  storage_type            = "gp3"
  storage_encrypted       = true
  multi_az                = true
  backup_retention_period = 14
  deletion_protection     = true
  copy_tags_to_snapshot   = true
  skip_final_snapshot       = false
  final_snapshot_identifier = "checkout-db-final"
}

Then test failure on purpose. AWS Fault Injection Service (FIS) can stop instances, inject API errors and disrupt network paths within guardrails you define, with stop conditions tied to CloudWatch alarms. Start in staging; run the same experiment in production once it is boring. For recovery beyond one region, see our guide to cloud disaster recovery tiers.

Do not skip service quotas. Lambda concurrency, EC2 vCPU limits per instance family and API rate limits stop scaling at exactly the moment you need it, and raising a quota is a request, not a setting. Check them before a launch, not during it.

Performance efficiency

The question is whether you know your limits. Run a load test that matches real traffic shape, find the first component to saturate, and write down the number. Without that, autoscaling settings are guesses.

Then check the resource type, not just the size. A CPU-bound service on a memory-optimized family pays for RAM it does not use. Graviton (arm64) instances usually give better price-performance for workloads that build cleanly for arm64; test with your own load test rather than trusting anyone's headline number. Caching (CloudFront at the edge, ElastiCache or DAX behind the service) removes load more cheaply than scaling does, as long as you know what goes stale and for how long.

Cost optimization

Cost questions start with ownership. Every resource should carry tags that map spend to a team and a product, and those tags must be activated as cost allocation tags in the billing console before Cost Explorer can group by them. After ownership comes commitment: Savings Plans and Reserved Instances trade a commitment to spend for a lower rate on the baseline you will use anyway. Our cloud cost optimization guide walks through the mechanics, including the order in which to apply them.

Sustainability

The sustainability pillar overlaps heavily with cost: higher utilization, current instance generations, managed and serverless services that share infrastructure, and deleting data nobody needs. The practical first fix is a retention rule for every data store: S3 lifecycle rules, CloudWatch Logs retention (which defaults to never expire), and snapshot expiry. The AWS Sustainability console, which replaced the Customer Carbon Footprint Tool in June 2026, reports estimated emissions by Region and service if you need a number for reporting.

Trade-offs to decide on purpose

Write these down in the review notes when you make them. Six months later, the decision record is worth more than the decision.

Turning findings into a backlog

A review produces a list of risks. A backlog produces change. Convert every HRI, and every MRI you agree matters, into a ticket that carries:

• The question and best practice it came from, for traceability.
• The concrete change, phrased as an outcome ("restores of the checkout database are tested monthly and take a known amount of time").
• An owner who is a person, not a team.
• A due date, and the milestone at which it will be checked.

Rank by blast radius times likelihood, then by effort. Missing tested backups, admin access for every developer, and no alarm on user-facing errors are cheap to fix and expensive to leave, so they go first almost every time. Re-architecture items (moving a single-AZ queue consumer to a multi-AZ design, splitting a shared database) belong on the roadmap with an explicit decision about when.

At the next review, open the previous milestone first. Count closed HRIs before looking for new ones.

What goes wrong in production

These are the failure patterns we see when Well-Architected reviews do not translate into resilience. All of them are organizational, not technical.

The review covered an account, not a workload. Answers become averages. "Some databases are multi-AZ" is not an answer anyone can act on. Scope tightly.

Answers came from the architecture diagram. The diagram shows the intended design. Production shows what was actually built, including the manual fix from last March. Use the evidence pack.

Nobody who carries the pager was present. The people who get woken up know where the bodies are buried: the cron job on a single instance, the certificate that is renewed by hand. Without them the review is fiction.

Findings went into a document. A PDF of risks is a liability record, not a plan. If the HRIs are not in the same tracker as feature work, they will lose to feature work.

Everything was marked not applicable. The tool lets you skip questions. Some genuinely do not apply. Most "not applicable" answers in real reviews mean "we do not want to talk about this today".

The team optimized for green. The goal is not zero risks in the tool. It is a workload whose owners know its failure modes, have decided which ones to accept, and can show that the important ones are covered.

Lenses: when the general questions are not enough

The framework lens is deliberately generic. For specific architectures, add the lens that matches. The Serverless Lens asks about event source failure handling and function concurrency. The SaaS Lens asks about tenant isolation and noisy neighbors. The Machine Learning Lens covers data and model lifecycle. Run list-lenses to see what is current, because AWS adds and revises lenses regularly.

Custom lenses are the underused feature. If your organization has standards (every service exposes a health endpoint, every queue has a dead-letter queue, every public endpoint sits behind WAF), encode them as a custom lens in JSON and apply it next to the framework lens. Your standards then get reviewed with the same rigor as AWS's.

Frequently Asked Questions

What are the six pillars of the AWS Well-Architected Framework?

The six pillars are operational excellence, security, reliability, performance efficiency, cost optimization and sustainability. Each pillar is a set of questions and best practices about one dimension of a workload. Sustainability is the newest; AWS added it in late 2021.

Is the AWS Well-Architected Tool free?

Yes. The Well-Architected Tool in the AWS console has no charge of its own, and the official lenses are included. What costs money is the time of the people in the review and the work to fix what it finds.

How often should you run a Well-Architected review?

Run a full review when a workload is new or has changed shape, for example a new region, a new data store or a big traffic increase. Between full reviews, revisit the high-risk items quarterly and save a milestone each time so you can compare progress.

What is a high-risk issue in a Well-Architected review?

A high-risk issue (HRI) is an answer that shows a missing best practice AWS considers likely to cause significant harm, such as no tested backups or broad human access to production. The tool marks it automatically from the choices you select. HRIs should become dated tickets with an owner, not notes in a report.

What is the difference between the framework and a Well-Architected lens?

The framework is the general question set that applies to any workload. A lens adds questions for a specific technology or domain, such as serverless, SaaS or machine learning. You can apply several lenses to one workload, and you can write custom lenses for your own standards.

Need help with a Well-Architected review?

We run reviews as engineers who will own the fixes, not as auditors who leave a report. We collect the evidence, sit with the people who carry the pager, and turn high-risk issues into changes that ship. If we build it, we are on the pager for it.

• Cloud architecture and infrastructure
• Cybersecurity and compliance
• Talk to an engineer