The AWS Well-Architected Framework

By the middle of October Gwen has a first design for Cascade Ridge on a single page: VetLedger on EC2 and RDS, images in S3, BookVet behind a load balancer, backups in a second Region. Before anyone builds it, she wants to review it. "A design that works on day one is easy," she tells Mateo. "A design that is still secure, reliable and affordable in year three is the hard part." Her review tool is the AWS Well-Architected Framework, and the CLF-C02 exam guide asks candidates to describe its pillars and tell them apart.

The framework is a set of design principles, questions and best practices that AWS has collected from reviewing thousands of customer workloads. It does not prescribe one correct architecture. Instead it asks structured questions, such as how a team detects a failure or how it controls who can change production, and it helps the team see where its design is strong and where it carries risk. A workload in the framework's language is a set of resources and code that delivers business value together, such as VetLedger or BookVet.

The six pillars

The framework is organized into six pillars. Each has a short definition, a set of design principles and a list of questions. Gwen gives Mateo a one-line version of each and a Cascade Ridge example, then makes him say them back from memory the next morning.

Operational excellence

The operational excellence pillar is about how a team runs its systems: how it makes changes, how it responds to events and how it learns. Its design principles include performing operations as code, making frequent, small, reversible changes, refining procedures often, anticipating failure and learning from every operational event. The core idea is that operations should be engineered like software rather than improvised.

For Mateo, this is the biggest change in habit. Today he logs into a server and fixes things by hand, and the knowledge lives in his head. In AWS he will describe infrastructure in templates, keep runbooks for common tasks and review each incident afterwards to find the cause rather than the culprit.

Security

The security pillar covers protecting information, systems and assets. Its design principles include implementing a strong identity foundation with least privilege, enabling traceability so that every action is logged, applying security at all layers, automating security best practices, protecting data in transit and at rest, keeping people away from data where possible, and preparing for security events. Hannah adopts the list almost word for word as the outline of Cascade Ridge's new cloud security policy. AWS-102 covers these topics in depth.

Reliability

The reliability pillar is about a workload performing its intended function correctly and consistently, and recovering quickly when something fails. Its design principles include recovering automatically from failure, testing recovery procedures, scaling horizontally to increase aggregate availability, stopping guessing capacity, and managing change through automation. Lesson 7 is largely about this pillar, because Dr. Kaur's July outage was a reliability failure.

Performance efficiency

The performance efficiency pillar asks whether resources are used efficiently to meet requirements, and whether that efficiency holds as demand changes and technology evolves. Its design principles include using advanced technologies as managed services, going global in minutes, using serverless architectures, experimenting more often and considering how data is accessed. For Kwame, it means measuring BookVet's real load and choosing instance types and services that fit it, then revisiting the choice as AWS releases new options.

Cost optimization

The cost optimization pillar is about running systems to deliver business value at the lowest price point. Its design principles include implementing cloud financial management, adopting a consumption model, measuring overall efficiency, stopping spending on undifferentiated heavy lifting and analysing and attributing expenditure. Lorraine's note about tagging every resource belongs here: without knowing what each system costs, no one can optimize it. Lesson 10 and AWS-104 develop this pillar.

Sustainability

The sustainability pillar, the newest of the six, focuses on reducing the environmental impact of running cloud workloads. Its design principles include understanding the workload's impact, setting sustainability goals, maximizing utilization, adopting more efficient hardware and software, using managed services and reducing the downstream impact of the workload. AWS describes a shared responsibility for sustainability: AWS makes its infrastructure efficient, and customers make their use of it efficient.

Mateo notices that many sustainability actions are also cost actions. A server running at a tenth of its capacity wastes both money and energy. Moving rarely viewed radiographs to an archive storage class uses less energy-intensive storage and costs less. Gwen agrees, and adds that the pillars often reinforce each other, but sometimes they pull in different directions, which is exactly why the framework asks teams to make trade-offs deliberately.

General design principles

Alongside the pillar-specific principles, the framework lists general principles that apply to every cloud design. Gwen considers them the quickest summary of how cloud thinking differs from server-room thinking.

• Stop guessing your capacity needs. Scale with demand instead of buying for the peak.
• Test systems at production scale. Create a full-size test environment when needed and delete it afterwards, paying only while it runs.
• Automate with architectural experimentation in mind. Automation makes it cheap to try and to reproduce designs.
• Consider evolutionary architectures. Designs can change as requirements change, rather than being fixed at the start.
• Drive architectures using data. Measure how the workload behaves and let facts guide changes.
• Improve through game days. Rehearse failures and events on a schedule so the team is practised when real ones happen.

Trade-offs between pillars

The pillars are not a checklist to maximize all at once. Running a second copy of every system in another Region improves reliability but doubles some costs. Encrypting everything adds a little processing. The framework's guidance is to make trade-offs consciously, based on business needs, and to write down why. For Cascade Ridge the emergency hospital's systems justify spending on reliability; the old intranet wiki does not.

# A simple Well-Architected review tally: questions answered, and how many risks each pillar shows.
# H = high risk, M = medium risk, OK = no risk found. Illustrative answers for VetLedger.
answers = {
    "operational excellence": ["H", "M", "OK", "OK", "M"],
    "security":               ["OK", "M", "OK", "H", "OK"],
    "reliability":            ["H", "H", "OK", "M", "OK"],
    "performance efficiency": ["OK", "OK", "M", "OK"],
    "cost optimization":      ["M", "OK", "M", "OK"],
    "sustainability":         ["OK", "M", "OK"],
}
for pillar, a in answers.items():
    print(f"{pillar:24} high {a.count('H')}  medium {a.count('M')}  of {len(a)} questions")
worst = max(answers, key=lambda p: (answers[p].count("H"), answers[p].count("M")))
print("Start improvement work with:", worst)

operational excellence   high 1  medium 2  of 5 questions
security                 high 1  medium 1  of 5 questions
reliability              high 2  medium 1  of 5 questions
performance efficiency   high 0  medium 1  of 4 questions
cost optimization        high 0  medium 2  of 4 questions
sustainability           high 0  medium 1  of 3 questions
Start improvement work with: reliability

The AWS Well-Architected Tool and lenses

AWS provides the AWS Well-Architected Tool in the console at no extra charge. A team defines a workload, answers the framework's questions, and the tool records high-risk and medium-risk issues, links to guidance for each, and tracks progress over time as improvements are made. Reviews can be repeated at milestones, such as before launch and every year after.

Lenses extend the framework for particular technologies or industries, such as a serverless lens, a SaaS lens or a lens for a regulated industry. They add questions specific to that context. AWS Partners can also run formal Well-Architected reviews for customers. Gwen will run the first review for VetLedger herself, with Mateo, Hannah and Kwame answering the questions in a two-hour session, and she will schedule a second one after the spring cutover.

How a review session runs

Gwen describes how she will run the two-hour review so that Mateo can run the next one himself. Before the session she defines the workload in the Well-Architected Tool: its name, its Regions, its business owner and a short description. During the session she reads each question aloud and asks the person who knows the answer, not the most senior person, to respond. Answers are recorded honestly; the purpose is to find risk, not to score well. Questions that do not apply are marked as such with a reason.

After the session the tool produces a list of high-risk and medium-risk issues with links to guidance. Gwen turns each issue into an improvement item with an owner and a target date, and sets a milestone in the tool so that the next review can be compared with this one. Over several reviews the number of high risks should fall, and the milestones show the progress to the steering group.

The pillars and the exam

Exam questions about the framework usually describe a goal and ask which pillar it belongs to. A question about recovering from failure points to reliability; one about least privilege or encryption points to security; one about running operations as code or learning from incidents points to operational excellence; one about choosing efficient resource types or using serverless points to performance efficiency; one about paying only for what is needed points to cost optimization; one about reducing energy or maximizing utilization points to sustainability. Mateo makes a set of flash cards with a design principle on the front and the pillar on the back, and works through them on the bus.

Two pillars cause most confusion. Reliability and performance efficiency both mention scaling, but for different reasons: reliability scales horizontally so that the failure of one server matters less, while performance efficiency chooses the right resources so that the work is done efficiently. Cost optimization and sustainability also overlap, because waste costs both money and energy; the clue is whether the question is about price or about environmental impact.

Mateo leaves the review with fourteen improvement items, four of them marked high risk. Gwen is pleased; finding risks before launch is the whole point. Lesson 7 tackles the reliability findings first.