What Is the AWS Well-Architected Framework?

Why this framework exists

Building a system in the cloud means making a lot of decisions. Which services to use, how to protect your data, how to handle failures, how much to spend. Each decision has trade-offs, and it is easy to pick something that looks fine today but turns out to be costly or fragile later.

The AWS Well-Architected Framework gives you a reference point. It collects the best practices that AWS Solutions Architects learned after designing and reviewing thousands of customer architectures. With it you can compare your own design against those practices and see where to improve before a problem reaches production.

What the Well-Architected Framework is

The AWS Well-Architected Framework is a set of best practices and foundational questions for designing and operating workloads in the cloud. It helps you understand the pros and cons of the decisions you make, and it gives you a consistent way to measure your architecture against AWS recommendations.

The framework is organized into three parts that are worth keeping straight:

• Six pillars, which are the qualities you expect from a good cloud system.
• A set of general design principles that apply to almost any architecture.
• Questions per pillar that you use to evaluate one specific workload.

A review, not an audit

Applying the framework to a workload is called running a Well-Architected review. You answer the questions for each pillar, and from your answers you identify risks and areas to improve.

AWS is clear on one point: this is a constructive conversation about your architectural decisions, not an audit. Nobody passes or fails you. The goal is to find where you can do better and decide which changes are worth making for your business. An architecture can move away from a best practice on purpose when that decision makes sense for your case, as long as you make it knowingly.

The six pillars at a glance

The framework rests on six pillars. Each one is an area where a good system should be solid:

1. Operational Excellence
2. Security
3. Reliability
4. Performance Efficiency
5. Cost Optimization
6. Sustainability

This lesson only names them. The next lesson covers each pillar in detail, with its definition and an example. For the exam, learn all six by name, because questions tend to use these exact terms.

The general design principles

Alongside the pillars, the framework offers six general design principles that apply to nearly any cloud architecture:

• Stop guessing your capacity needs. In the cloud you use as much or as little capacity as you need and scale automatically, so you do not have to bet on a fixed number of servers up front.
• Test systems at production scale. You can spin up a full-size test environment on demand, run your tests, and shut it down afterward. You pay only for the time it ran.
• Automate with experimentation in mind. Automation lets you create and replicate your workload at low cost, track changes, and roll back when something goes wrong.
• Consider evolutionary architectures. In the cloud it is cheap to change a design, so your architecture can keep improving over time instead of being frozen at its first version.
• Drive architectures using data. Collect data on how your workload behaves and use it to make fact-based decisions about how to improve, rather than relying on guesses.
• Improve through game days. Schedule regular game days that simulate real production events to see how your architecture and your team respond, and where you can improve.

The AWS Well-Architected Tool and lenses

The AWS Well-Architected Tool (WA Tool) is a free service inside the AWS console that guides you through a review. You answer the questions for each pillar against a workload, and the tool shows you the risks it finds and gives recommendations to reduce them. It also lets you save progress with milestones and compare how your architecture changes over time.

The core framework works for any kind of workload. When you need best practices for a specific case, you apply a lens. A lens extends the framework with recommendations for a particular workload type, for example serverless, machine learning, or high-performance computing. You apply the lens that fits your case on top of the core framework.

Key vocabulary

The framework uses a few terms worth recognizing:

• Workload: a set of components that together deliver business value. This is the unit you review.
• Component: the code, configuration, and AWS resources that meet a requirement. Several components make up a workload.
• Milestone: a marker for a key change in your architecture as it evolves through the product lifecycle.

Exam tips

• The Well-Architected Framework is a set of best practices and questions for evaluating and improving architectures. It does not run workloads.
• A review is a constructive conversation, not an audit. It does not pass or fail you.
• The AWS Well-Architected Tool is free and lives inside the AWS console.
• Remember that the framework has six pillars and six general design principles.
• Lenses extend the framework with best practices for specific workload types.