AWS Cloud Practitioner Study Notes · Part 8
AWS Well-Architected Tool: Review Workloads and Track Risks
AWS Cloud Practitioner study notes on using the Well-Architected Tool to review workloads, identify risks, generate reports, and track improvements.
Knowing the six Well-Architected pillars is useful, but teams also need a repeatable way to apply them to a real workload. The AWS Well-Architected Tool provides that review workflow: answer foundational questions, identify risks, and turn the findings into improvement work.
This is Part 8 of the AWS Cloud Practitioner Study Notes series. Part 7 introduced the framework and its six pillars; this note focuses on the AWS service used to review a workload against those practices.
Framework versus Tool
The distinction is one of the most important exam points:
| Item | AWS Well-Architected Framework | AWS Well-Architected Tool |
|---|---|---|
| What it is | A set of architectural principles, best practices, and questions | An AWS service for documenting and reviewing workloads |
| Main purpose | Guide architecture and design decisions | Assess a workload against the framework and lenses |
| Output | Pillars, design principles, and best practices | Risk findings, notes, reports, and improvement items |
| Automatically fixes resources? | No | No |
The framework is the knowledge and evaluation model. The Tool is the workspace that helps a team apply that model to a particular workload and track the result over time.
What the Tool reviews
The Tool reviews a defined workload against questions covering the six pillars:
| Pillar | Example review focus |
|---|---|
| Operational Excellence | Operating procedures, automation, observability, and continuous improvement |
| Security | Identity, least privilege, data protection, detection, and incident response |
| Reliability | Failure recovery, backups, resilience, and change management |
| Performance Efficiency | Resource selection, scaling, caching, and changing demand |
| Cost Optimization | Usage awareness, right-sizing, purchasing options, and waste |
| Sustainability | Resource efficiency, demand alignment, and reducing environmental impact |
The exact questions depend on the selected lens and the workload context. A workload is more than a collection of AWS resources: it can also include the people, teams, processes, runbooks, and dependencies that deliver the business outcome.
How a review works
AWS describes a Well-Architected Framework Review (WAFR) in three broad phases:
- Prepare: define the workload, its owner, scope, business impact, environment, and stakeholders.
- Review: answer questions across the selected pillars and record which best practices are implemented.
- Improve: prioritise risks, make changes, and measure progress through later reviews and milestones.
1. Define the workload
Start by describing the system being reviewed. For example, a customer-facing website might include:
- Application Load Balancer
- EC2 instances in one or more Availability Zones
- Amazon RDS
- Amazon S3 for object storage
- Monitoring, deployment, and backup processes
- The team responsible for operating the service
The scope should be clear enough that the review can answer questions consistently. It may cover resources in one account or a collection of resources across accounts and Regions.
Useful preparation questions include:
- What business outcome does this workload provide?
- Who owns it and who responds when it is disrupted?
- Is it production, development, or another environment?
- What are its dependencies and boundaries?
- What is the impact of data loss or downtime?
2. Answer the review questions
The Tool presents questions and related best practices for each pillar. The team selects the practices currently followed and records notes where context is important.
The Tool does not simply infer that an architecture is safe from the existence of an EC2 instance or an RDS database. The review captures the team’s documented understanding of how the workload is designed and operated. AWS also allows a practice to be marked as not applicable when there is a valid workload-specific reason, which should be documented in the notes.
For example, a reliability question might prompt the team to examine whether the application has:
- More than one Availability Zone
- A way to replace or recover unhealthy compute
- Backups and tested restoration procedures
- Recovery objectives that match the business requirement
The review can be paused and continued later. It is intended to support a structured conversation among the people who understand the workload, not just a one-person checkbox exercise.
3. Read the improvement plan
After the questions are answered, the Tool identifies areas of risk based on the selected best practices. It organises improvement items by pillar and risk level, helping the team decide what to address first.
The two key risk categories are:
- High Risk Issue (HRI): an architectural or operational choice that may cause a significant negative business impact. AWS describes these as foundational, must-do practices within a pillar.
- Medium Risk Issue (MRI): a choice that may also negatively affect the business, but with a lower expected impact than an HRI. These practices can substantially improve a workload.
An HRI or MRI is a prioritisation signal, not an automatic incident report. The business context matters. If a recommendation is not suitable for a workload, the team should document the reason, the trade-off, and any approval for accepting the risk.
4. Generate reports and save milestones
The Tool can generate a workload report containing the review responses, notes, identified risks, and suggested improvements. A report is useful for sharing the current state with engineering, security, operations, and business stakeholders.
A milestone records the state of a workload at a particular point in time. Teams can save an initial milestone, make improvements, and save later milestones to compare progress. Milestones are snapshots, so they provide a useful history of how the workload’s risk profile changed.
Example: a single-instance website
Suppose a website runs on one EC2 instance:
Users
|
v
EC2 instance
|
Application and databaseDuring a review, the team may discover that the workload has no automatic recovery, no tested backup, and no second Availability Zone. The Tool may identify reliability risks and direct the team to relevant best practices.
An improvement plan could then propose:
- Placing application capacity behind an Application Load Balancer
- Running capacity across multiple Availability Zones
- Using Auto Scaling or another recovery mechanism
- Separating the database and implementing an appropriate backup strategy
- Testing restoration and documenting recovery objectives
- Adding monitoring and operational runbooks
The Tool does not deploy this architecture. The team implements the changes, updates the review answers, and saves a new milestone to measure the result.
What the Tool does not do
The AWS Well-Architected Tool is easy to confuse with other AWS services. It does not:
- Automatically repair the architecture
- Deploy an Application Load Balancer or Auto Scaling group
- Automatically enable encryption or least-privilege access
- Replace CloudWatch infrastructure monitoring
- Replace GuardDuty threat detection
- Replace Security Hub security findings and aggregation
- Replace Cost Explorer cost analysis
The Tool can recommend that a team review monitoring, threat detection, or cost controls. The specialised AWS services perform those operational functions.
How the Tool fits into continuous improvement
One review is only a starting point. A useful cycle is:
- Review the workload against the relevant pillars.
- Identify HRIs and MRIs.
- Prioritise them by business impact, effort, and urgency.
- Assign owners and implement mitigations.
- Update the workload review and notes.
- Save a milestone and repeat the review as the system changes.
This matters because workloads evolve. New services, traffic patterns, teams, dependencies, and regulations can change the original trade-offs. A previously reasonable decision may need to be revisited after a major architectural change.
Exam-ready memory aid
- Framework: AWS best practices and the six pillars.
- Tool: AWS service that reviews a workload against those practices.
- WAFR: prepare, review, and improve.
- HRI: high-risk architectural or operational choice.
- MRI: medium-risk improvement opportunity.
- Milestone: snapshot of workload state used to measure progress.
- CloudWatch: monitor resources and applications, not review the architecture against the framework.
- Cost Explorer: analyse spending, not conduct a Well-Architected review.
Conclusion
The AWS Well-Architected Tool turns the Well-Architected Framework from a reference document into a repeatable workload-review process. It helps teams document their architecture, answer questions across six pillars, identify high- and medium-risk issues, generate reports, and track improvements through milestones.
For the Cloud Practitioner exam, remember the boundary: the Tool evaluates and recommends; engineers and teams decide, implement, validate, and operate the changes.