The AWS Well-Architected Tool is one of those AWS services that most teams know exists but few actually use correctly. They open the console, create a workload, click through a few questions, see a list of risk items, and close the tab. The improvement plan just sits there.
This guide covers all eight steps of the console workflow, from creating your first workload to connecting Trusted Advisor and Jira, including the three AI/ML lenses added or updated in 2025:
- Create your workload
- Select your lenses
- Apply a profile
- Work through the review questions
- Read and act on your improvement plan
- Save a milestone
- Enable Trusted Advisor integration
- Set up Jira sync
What the AWS Well-Architected Tool Does (And What It Costs)
The AWS Well-Architected Tool measures your workload against the AWS Well-Architected Framework and surfaces a prioritized list of High Risk Issues (HRIs) and Medium Risk Issues (MRIs). It is not an infrastructure scanner. It evaluates the architectural decisions behind how your system is designed, based on answers you document about your practices.
The tool is completely free. You pay only for the underlying AWS resources running in your account. Any standard AWS account can access it at https://console.aws.amazon.com/wellarchitected/. There is no special enrollment, no subscription, no per-question charge. This is confirmed on both the AWS Well-Architected Tool pricing page and the FAQ.
One cost caveat worth knowing upfront: the Trusted Advisor integration (covered in Step 7) requires a Business or Enterprise Support plan. The integration with the WA Tool itself adds no cost, but Trusted Advisor has its own Support plan requirement. For the full cost picture including partner-led reviews, see the full cost breakdown including partner-led review options.
Before You Start: IAM Permissions and Account Setup
Two managed policies cover the tool. WellArchitectedConsoleFullAccess grants full access for creating workloads, editing answers, and sharing. WellArchitectedConsoleReadOnlyAccess covers view-only access (Get*, List*, ExportLens).
One integration note: the Jira connector requires wellarchitected:ConfigureIntegration on the IAM user or role you connect in Jira. Trusted Advisor creates its own service role automatically on first activation. No manual setup needed.
Step 1: Create Your Workload
A workload in the AWS WA Tool is a set of components that delivers a specific business outcome: a SaaS backend, an analytics pipeline, or a mobile app API. One workload = one unit of evaluation.
Required Fields and What to Enter
When creating a workload, five fields are required:
| Field | Notes |
|---|---|
| Name | 3–100 characters. Spaces and capitalization are ignored for uniqueness, so "SaaS Backend" and "saasbackend" would conflict. |
| Description | 3–250 characters. Be specific enough that someone unfamiliar with the system understands the scope. |
| Review owner | Name, email, or role of the person responsible for this review. |
| Environment | Production or Pre-production. This affects how risk items are weighted. |
| AWS Regions | One or more regions where the workload runs. |
For a SaaS web application backend, you might enter: Name = "SaaS Product Backend", Environment = Production, Regions = us-east-1 + eu-west-1.
Optional Fields Worth Configuring Now
Two optional fields unlock later steps. Account IDs (up to 100, comma-separated) are required for Trusted Advisor integration, so enter them now to make Step 7 work on first activation. Application ARN links an AppRegistry application for resource-based Trusted Advisor discovery via CloudFormation stacks.
Service quotas are non-adjustable: 1,000 workloads per account per region, 100 milestones per workload.
Step 2: Select Your Lenses
The AWS Well-Architected Framework lens is applied automatically to every workload and cannot be removed. It covers all six pillars. Beyond that, you can apply up to 20 additional lenses per workload (5 at a time) from the Lens Catalog or custom lenses.
The Default Framework Lens
In April 2025, AWS refreshed the framework with 78 new best practices across all six pillars. The Reliability Pillar was updated entirely: 14 best practices revised for the first time since 2022. If your team last ran a review before mid-2025, the questions have changed.
Which Additional Lens Fits Your Workload
Most workloads need the base lens plus one or two technology-specific lenses. The Lens Catalog currently contains 16 AWS-official lenses. A few common pairings:
| Workload Type | Recommended Lens |
|---|---|
| Serverless (Lambda, API Gateway, SQS) | Serverless Applications |
| SaaS product | SaaS |
| Generative AI / LLM application | Generative AI |
| Traditional ML (vision, forecasting, recommendations) | Machine Learning |
| AI with bias, hallucination, or safety risks | Responsible AI |
| Healthcare | Healthcare Industry |
| Financial services | Financial Services Industry |
| Migrating to AWS | Migration |
| Acquiring a company's infrastructure | Mergers and Acquisitions |
The Three AI/ML Lenses Added in 2025
Three lenses target AI workloads specifically, announced at re:Invent 2025. They are distinct:
Responsible AI lens (new, November 2025). Use when bias, hallucination, data leakage, or adversarial attack risks need structured evaluation. Covers ten dimensions including controllability, fairness, veracity, safety, and governance.
Generative AI lens (April 2025, updated November 2025). Use for LLM applications, RAG architectures, or agentic AI on Bedrock or SageMaker. Updated guidance covers SageMaker HyperPod and agentic AI patterns.
Machine Learning lens (updated November 2025). Use for traditional ML workloads: computer vision, fraud detection, predictive analytics, SageMaker training and inference pipelines.
Building a Bedrock application on top of a SageMaker pipeline? Apply both the Generative AI and ML lenses. They complement rather than duplicate.
Step 3: Apply a Profile (The Feature Most Teams Skip)
Most getting-started guides skip profiles entirely. Here is what you miss: a profile adds business context to your workload (regulated or not, revenue criticality, recovery requirements), and the tool uses that context to surface the questions most relevant to your situation.
When a profile is active, a "Prioritized" section appears in the review's left navigation. Instead of working through every question across all six pillars, you start with the subset that matters most for your context. Only one profile can be associated per workload. You can apply one at workload creation or add it later through the workload settings.
Profiles are not available in AWS GovCloud (US) regions. GovCloud users skip this step.
Step 4: Work Through the Review Questions
Two patterns make the review pages go faster and produce defensible answers.
Pillar-by-Pillar Pacing
Work one pillar at a time. A full review in a single session leads to fatigue and lower-quality answers. Security and Reliability tend to surface the most HRIs, so they are good starting points. If you applied a profile, start with the Prioritized section instead. After each pillar, save a milestone (Step 6) before picking up the next one.
See what each of the six pillars tests for the intent behind each, and the Well-Architected review checklist for the full question list.
Handling Best Practices You Have Not Implemented
When you encounter a best practice your workload does not implement, you have three options: leave it unchecked (the tool flags it), mark "Question does not apply" if genuinely irrelevant, or add a note explaining the gap. The third option is the most defensible. For compliance reviews or due diligence, documented exceptions in the Notes field are far better than unexplained gaps.
Step 5: Read and Act on Your Improvement Plan
This is where most teams disengage. They see the risk items, feel overwhelmed, and close the tab. The fix is treating the improvement plan as a triage exercise, not a to-do list.
HRIs vs MRIs: What the Labels Mean
High Risk Issues (HRIs) are "architectural and operational choices that AWS has found might result in significant negative impact to a business": outages, data loss, security breaches, cost overruns. Medium Risk Issues (MRIs) are similar but to a lesser extent; they belong in the backlog, not the first sprint.
HRIs are guidelines, not verdicts. If there is a legitimate business or technical reason you cannot implement a best practice, document it in the Notes field. A well-documented exception is more defensible than a silent gap. The Dashboard shows HRIs and MRIs per pillar, and clicking an HRI count takes you directly to the recommended improvement plan items.
A 90-Day Triage Sequence
Getting the plan in front of the right people quickly matters more than perfecting your review first.
| Timing | Action |
|---|---|
| Day 1 | Share the improvement plan. Orient your team on what an HRI means and which pillars have the most risk. |
| Days 2-3 | Run an HRI prioritization meeting. Sort by effort and impact. Look for HRIs where one fix resolves multiple items. |
| Week 1 | Begin remediation. Target a 90-day window. Assign owners to each HRI. |
| Ongoing | Follow-up reviews. Re-answer updated questions. Save a milestone after each remediation cycle. |
The Dashboard filters improvement plan items by pillar and severity, which is useful for leadership presentations. One caveat: the Dashboard only surfaces issues from the base Framework lens. Additional lenses (Serverless, Generative AI, etc.) track their own issues separately.
Step 6: Save a Milestone
A milestone captures a point-in-time snapshot of your workload's review state: all answers, risk counts, and notes. Save one immediately after completing a session, before making any changes.
Milestones are how you show improvement over time and provide dated evidence for audits. You can save up to 100 per workload. Use a naming convention with the date and a short descriptor (for example, "2026-04-11 Initial assessment" or "2026-08-01 Post-Security remediation") so comparisons across months are readable.
Step 7: Enable Trusted Advisor Integration
Trusted Advisor integration adds automated evidence to specific review questions. Instead of relying on manual answers alone, the tool periodically fetches Trusted Advisor check results and maps them to Well-Architected best practices. To enable it, open the workload, go to the Trusted Advisor section, and select Activate. Then choose your resource definition:
- Workload Metadata: uses the Account IDs and Regions from Step 1
- AppRegistry: uses resources linked via the Application ARN
- All: combines both
An IAM service role is created automatically on first activation. For multi-account workloads, each associated account must also create an IAM role with a trust policy granting wellarchitected.amazonaws.com permission scoped to the workload owner's account ID. If missing, the tool shows an error for that account. Trusted Advisor checks also link only to the Framework lens, not to additional lenses.
WA Tool vs Trusted Advisor: Two Different Tools, One Workflow
Trusted Advisor scans your live resources and flags configuration issues: open S3 buckets, unused IAM credentials, underutilized instances. It tells you what is wrong with your current deployment. For the full list of Trusted Advisor checks, the dedicated guide covers each check category and how to act on findings.
The WA Tool evaluates the architectural decisions behind your system (how you handle backups, manage identity, structure your recovery strategy) based on what you document, not just what is deployed.
They are complementary. Enable the integration and Trusted Advisor's live findings flow into your WA Tool review, reducing manual effort on questions where you already have hard evidence.
Step 8: Set Up Jira Sync (Optional but Valuable)
The Jira connector turns your improvement plan into a structured backlog. The sync hierarchy is:
| WA Tool Concept | Jira Artifact |
|---|---|
| Workload | Epic |
| Question | Task |
| Best Practice | Sub-task |
| Pillar | Label |
Installation happens in Jira (Apps > search "AWS Well-Architected" > install the connector), not in the AWS console. Connect with IAM credentials that hold wellarchitected:ConfigureIntegration. Only Scrum and Kanban projects are supported.
Start with Manual sync rather than Automatic. Automatic mode updates Jira on every best practice selection, which creates noise in active review sessions. Manual gives you control over when items land in your backlog.
Security note: everything you write in the WA Tool's Notes field syncs to Jira. Do not enter passwords, account details, or PII in Notes when the connector is active.
The Jira connector is not available in AWS GovCloud (US) regions.
When the Tool Reaches Its Limits
A self-service review scores what you know and are willing to document. It does not challenge assumptions your team has held for years. I have seen teams run solid self-assessments and still miss HRIs where everyone shared the same blind spot.
Three situations call for going further: HRIs your team cannot remediate alone, audits requiring independent review (SOC 2, ISO 27001, investor due diligence), and workloads where you need remediation tied to actual infrastructure changes, not just a findings document.
Self-service and partner-led reviews compare like this:
| Dimension | Self-Service (WA Tool) | Partner-Led Review |
|---|---|---|
| Cost | Free | Often free via AWS partner funding |
| Guidance depth | Documentation links only | Practitioner walkthrough plus IaC remediation |
| Speed | Self-paced, hours to days | Structured engagement, 2 to 6 weeks |
| Shared access | Single team or via Resource Access Manager | Reviewer joins as external stakeholder |
| Formality | Internal record only | Formal report, often required for audits and due diligence |
| External validation | None | Independent sign-off from an AWS Partner with WAFR expertise |
AWS Partner-led reviews access funding programs through the AWS Partner Network, though specific amounts are not publicly listed. See the full cost breakdown for details, and the review process guide for the engagement structure.
Next step
Turn Your WA Tool Findings into a Remediation Roadmap
We work with engineering teams to validate self-assessments, identify gaps that automated tools miss, and deliver IaC-based remediation for high-risk issues, not just a list of recommendations.
Frequently Asked Questions
Is the AWS Well-Architected Tool free?
What is the difference between the AWS Well-Architected Tool and Trusted Advisor?
How many lenses can I apply to a workload?
What is a High Risk Issue (HRI) in the AWS Well-Architected Tool?
What is a profile in the AWS Well-Architected Tool and do I need one?
What gets created in Jira when I enable the WA Tool connector?
Which lens should I use for an AI workload?
Where to Go From Here
The AWS Well-Architected Tool is operational in under 20 minutes and costs nothing. Start with a single workload (your most business-critical system). Apply a profile so the Prioritized view focuses your time. Triage the improvement plan within days, not weeks. Save milestones consistently. They are the only way to show progress over time.
For the full question list, the Well-Architected review checklist covers all pillars. For the project management view, the review process guide has the meeting cadence and remediation sprint structure.
If your team has a way of keeping HRI remediation moving after the initial review (a sprint structure, a tracking method, anything), I'd be interested to hear it in the comments.