Background

Introduction and design principles¶

Well-Architected is a way of judging how well a workload is built and run, by asking the same set of questions about it from six angles. Each angle is a pillar. This course uses the pillars to explain why the patterns it teaches are worth the effort.

What Well-Architected is¶

Most workloads work. The harder questions are how well they keep working: when an instance fails, when load doubles, when someone makes a change on a Friday afternoon, or when the invoice arrives. Well-Architected turns those questions into a structured review, so a team can see where a workload is strong, where it carries risk, and what to improve first.

AWS publishes a Well-Architected Framework, and other cloud providers publish similar ones. They share the idea of pillars and a review process. The version in this course is written for Breqwatr Cloud: the same idea, our own wording, and examples from this platform.

Why pillars¶

A workload is never good or bad overall. It can be highly reliable and expensive to run, or very cheap and fragile. Splitting the review into pillars keeps those qualities apart, so each one gets a clear answer.

Pillar	The question it asks
Operational excellence	Can you change and run this workload safely, and know when something is wrong?
Security and sovereignty	Is access limited to the people and systems that need it, and are the layers you own protected?
Reliability	Does the workload keep working when parts of it fail, and can it recover?
Performance efficiency	Does the workload use the right amount of resources for its load, and keep doing so as load changes?
Spend efficiency	Do you pay for what the workload needs, and nothing it doesn't?
Sustainability	Does the workload use as few resources as it needs, for as long as it needs them?

The pillars pull against each other. Running a workload in both regions improves reliability and increases spend. Right-sizing improves spend efficiency and sustainability and can reduce headroom for performance. A review doesn't remove those trade-offs; it makes them visible, so each one is a decision rather than an accident.

General design principles¶

These principles cut across every pillar. Each pillar page shows how they apply to it.

Principle	What it means in practice
Build from code	Define infrastructure and configuration in files, so an environment can be rebuilt, reviewed and repeated. See GUI, API and infrastructure as code
Treat instances as replaceable	Keep state off instances so any one of them can be rebuilt. See Pets vs cattle
Plan for failure	Decide which failures a workload must survive, and build for them. See Regions and failure domains
Make small, reversible changes	Change one thing at a time, in a way that can be undone quickly
Measure before deciding	Base sizing, scaling and spend decisions on what the workload actually does
Know who owns what	Breqwatr runs the platform; you run what's on it. See Shared responsibility
Review regularly	Workloads change. A review done once goes out of date

How this course uses Well-Architected¶

Background pages explain the concepts each pillar relies on, and link to the pillars they support.
Pillar pages, starting with this one, set out each pillar's design principles, what the pillar looks like on Breqwatr Cloud, and the anti-patterns to watch for.
Tutorials each name the pillar they demonstrate, so the builds tie back to the principles.
Running a Well-Architected review gives you a question set to apply to your own workloads.

The pillar pages describe patterns, not a required architecture. The right answer for a workload depends on what it does and what it's worth to you, and that judgement stays with you.

Impact¶

A shared vocabulary for talking about a workload's strengths and risks.
Trade-offs between reliability, spend and the other pillars become explicit decisions.
A repeatable way to check a workload, so improvement doesn't depend on who happens to look at it.

Common anti-patterns¶

One pillar at a time: optimizing hard for one pillar, such as spend, without checking what it does to the others.
Review once, then forget: a review that isn't repeated describes a workload that no longer exists.
Framework as checklist: answering every question "yes" without evidence. The value is in the honest answers.