In the previous subchapter, we looked at the six pillars of the Well-Architected Framework. But reading best practices is one thing, and rigorously evaluating your specific architecture against them is another. How do you systematically review, without missing anything, whether your system meets those best practices? For that, AWS offers the Well-Architected Tool: a free tool that guides you through a structured review of your architecture.

Imagine you want to check if your system is well designed according to the six pillars. You could do it “from memory,” but it’s easy to:

• Forget to check important aspects.
• Be too optimistic (“I’m sure it’s fine...”) without evidence.
• Not have a record of what you reviewed and what you decided to improve.
• Do it inconsistently (each person reviews different things).

You need a structured and guided way to evaluate, that asks you the right questions and records the results.

The AWS Well-Architected Tool is a free tool within AWS that guides you to evaluate your architecture against the six pillars through a structured questionnaire. It asks you questions about your system, identifies risks, and gives you recommendations for improvement.

Analogy: the Well-Architected Tool is like a vehicle technical inspection (MOT) guided by an official checklist. You don’t check the car “by eye”: you follow a structured list of checks (brakes, lights, emissions, steering...), each point is evaluated, and at the end you get a clear report of what’s good and what needs fixing, with its severity level. The tool does the same with your architecture: a rigorous and systematic review, not improvised.

You indicate which system or application you want to review. In the framework’s vocabulary, a specific application or system being evaluated is called a workload.

The tool asks you a series of questions for each pillar. For example, for the reliability pillar it might ask: “How do you handle component failures?”, “Do you have a disaster recovery strategy?” (remember Chapter 26). You answer according to how your system is actually designed, honestly.

Based on your answers, the tool detects risks and classifies them by severity (for example, high risk or medium risk). A high risk is something important you should fix soon; a medium one, something to improve when you can.

For each risk, the tool suggests how to improve it, often linking to specific AWS documentation and best practices. You get a prioritized action list to improve your architecture.

The great value of the Well-Architected Tool is that it gives you an honest and structured evaluation of your architecture, with a concrete action plan. Instead of “we think it’s fine,” you get: “these are your 3 high risks and this is what you should do.” Additionally:

• Record and tracking: you save the reviews and can repeat them over time to see your progress (have we reduced high risks compared to the previous review?).
• Common language: gives the team a shared framework to talk about architecture quality.
• It’s free: it costs nothing to use, so there’s no excuse not to review.

Real-world example: before launching an important application to production, a team does a review with the Well-Architected Tool. The questionnaire makes them realize, in the reliability pillar, that they have no disaster recovery strategy (a high risk they had overlooked in the rush). It also detects a security risk: certain data is unencrypted. Thanks to the review, before launching, they add a DR plan (Chapter 26) and enable encryption (Chapter 23). Three months later they repeat the review: the high risks have disappeared. The tool turned “we think it’s ready” into “we know it’s well designed, and we’ve verified it.”

• Before launching an important system to production (to catch problems in time).
• Periodically on existing systems (architectures degrade over time; regular reviews maintain quality).
• After major changes in the architecture.
• As a learning exercise: the questionnaire itself teaches you best practices you might not have known.

• Reviewing an architecture “from memory” is prone to oversights, optimism, and lack of record; you need a structured and guided approach.
• The AWS Well-Architected Tool is a free tool that guides a structured evaluation of your architecture (your “workload”) against the six pillars, through a questionnaire. Like an MOT guided by a checklist.
• The process: define the workload → answer the questionnaire pillar by pillar (honestly) → it identifies risks (high/medium) → gives prioritized recommendations for improvement.
• Its value: an honest evaluation with a concrete action plan, record to track progress, a common language for the team, and it’s free.
• Use it before launching to production, periodically, after major changes, and as a learning exercise.

In the last subchapter of the chapter, we’ll see how to apply the framework and the tool in practice in your day-to-day work, so they don’t just become a one-off review.