Skip to content

AWS Well-Architected Tool

The AWS Well-Architected Framework is a set of questions to ask about a workload, and the AWS Well-Architected Tool is the service that keeps the answers. Together they turn a set of architecture opinions into a documented position and a prioritised list of things to fix.

The tool is free and runs in the AWS console. You define a workload, answer the framework’s questions against it, and get back the risks your answers imply, grouped by severity, with links to the guidance behind each one. Answers are saved, so a review six months later shows what changed rather than starting again.

PillarThe question it asks
Operational excellenceCan you run and monitor this system, and improve how you run it?
SecurityAre data, systems and assets protected, and can you tell when they are not?
ReliabilityDoes the workload do what it is supposed to, and recover when it does not?
Performance efficiencyAre you using the right resources, and are you still using them as demand changes?
Cost optimizationAre you getting the business value at the lowest price?
SustainabilityWhat is the environmental impact of running this, and how is it reducing?

The pillars are deliberately in tension. A design that maximises reliability rarely minimises cost, and the value of the review is in making those trade-offs explicit and deliberate rather than accidental.

A lens extends the framework with questions specific to a technology or domain — serverless, SaaS, financial services, machine learning, data analytics and others. Applying a lens to a workload adds its questions to the review.

Custom lenses carry your own standards. If the organisation has rules that are not in any AWS lens — a data residency requirement, a mandatory logging pattern, an approved-runtime list — a custom lens puts them in the same review, scored the same way, rather than in a document nobody reads at design time.

The output is a set of identified risks, each classified as high or medium. Treated properly, that list is a backlog:

  1. Run the review with the people who actually built the workload, not about them.
  2. Accept some risks explicitly. “We know, and here is why” is a legitimate answer and the tool records it — an unrecorded accepted risk is indistinguishable from an oversight.
  3. Turn the rest into tickets with owners.
  4. Re-run the review after significant change, or on a fixed cadence. The saved milestone lets you show movement.

The tool integrates with AWS Trusted Advisor and AWS Service Catalog AppRegistry, so some questions can be answered from the account’s actual state rather than from memory.

For the cost pillar in particular, the practical detail lives in AWS cost optimization strategies.