Cloud Concepts · Topic 2 of 4
Design Principles and Well-Architected
Learn the six pillars of the AWS Well-Architected Framework and key design principles such as loose coupling, automation and designing for failure.
- 4 min
- The six pillars are operational excellence, security, reliability, performance efficiency, cost optimization and sustainability.
- Reliability is about recovering from failure and meeting demand. Spreading across Availability Zones supports it.
- Security includes least privilege, protecting data and tracing actions.
What it is
A design principle is a general rule for building systems that work well in the cloud. AWS collects these rules in the AWS Well-Architected Framework.
The framework is a set of questions and best practices that help you judge a workload. It is organised into six pillars.
The exam does not ask you to design a system. It asks you to recognise which pillar a statement belongs to and which principle fits a situation.
How it works
The six pillars
| Pillar | Main question | Example practice |
|---|---|---|
| Operational excellence | Can we run and improve the system well? | Automate changes and learn from incidents |
| Security | Is data and access protected? | Least privilege and encryption |
| Reliability | Does it recover and keep working? | Spread across Availability Zones |
| Performance efficiency | Do we use resources efficiently? | Pick the right instance or service type |
| Cost optimization | Do we avoid waste? | Remove unused resources and right size |
| Sustainability | Do we reduce environmental impact? | Use resources efficiently and avoid idle capacity |
Sustainability was added after the original five pillars. If a question lists six pillars, it is the one that covers environmental impact.
Design principles that appear on the exam
Design for failure. Assume that any component can fail and build so the system survives it. For example, run copies in more than one Availability Zone (a group of data centers in a Region).
Loose coupling. Parts of a system should depend on each other as little as possible. A queue placed between two components lets one slow down or fail without stopping the other.
Scale horizontally. Add more small resources instead of making one resource bigger. Horizontal scaling (scaling out) supports automatic growth and helps avoid a single point of failure.
Automate. Use code and tools to create and change infrastructure. Automation reduces human error and makes environments repeatable.
Use managed and serverless services. Let AWS run the undifferentiated work, such as patching a database, so your team can focus on the product.
Stateless where possible. Keep user session data outside the server, so any server can handle any request.
Treat infrastructure as disposable. In the cloud you can replace a bad server instead of repairing it.
Scaling directions
| Type | Meaning | Limit |
|---|---|---|
| Vertical (scale up) | Make one resource larger | There is a maximum size, and it may need a restart |
| Horizontal (scale out) | Add more resources | Works well with load balancing and Auto Scaling |
Shared Well-Architected tools
The AWS Well-Architected Tool is a free service in the console. You answer questions about a workload, and it shows risks and suggested improvements.
AWS also publishes lenses, which add guidance for specific areas such as serverless or machine learning. Know that a lens exists, but you do not need to memorise any of them.
Related design ideas
- Pay for what you use: this follows from cost optimization and elasticity.
- Test at production scale: because resources are cheap to create and delete, a full size test environment can be built for a short time.
- Evolve the architecture: change the design as new services appear.
What to remember for the exam
- The six pillars are operational excellence, security, reliability, performance efficiency, cost optimization and sustainability.
- Reliability is about recovering from failure and meeting demand. Spreading across Availability Zones supports it.
- Security includes least privilege, protecting data and tracing actions.
- Cost optimization is about avoiding waste, not simply choosing the cheapest option.
- Loose coupling uses services such as queues so that components do not depend on each other directly.
- Scaling out (horizontal) is preferred in the cloud over scaling up (vertical).
- Automation and infrastructure as code make environments repeatable.
- The AWS Well-Architected Tool reviews a workload against the pillars at no charge.
When a question describes one component failing and the rest continuing, think loose coupling and reliability. When it describes a team reviewing an existing workload, think the Well-Architected Tool.
Common mistakes
Mixing up reliability and performance efficiency. Reliability is about surviving failure. Performance efficiency is about using the right resources for the load.
Thinking cost optimization means the cheapest service. It means getting the needed result without waste, which can include paying more for a better fit.
Forgetting sustainability. Older study notes list five pillars. The current framework has six.
Treating servers as pets. Designs that depend on one special server break the "disposable" principle.
The Well-Architected Framework does not enforce anything. It gives guidance and a review process, but it does not block or fix your workload by itself.
Check yourself
Which Well-Architected pillar covers recovering from failures and meeting demand?
Reliability.
Why is a queue between two components considered good design?
It creates loose coupling, so one component can fail or slow down without stopping the other.
What is the difference between scaling up and scaling out?
Scaling up makes one resource bigger, while scaling out adds more resources and is preferred in the cloud.
Topic 2 of 4 in Cloud Concepts
Test yourself on Cloud Concepts
The full AWS CLF-C02 question bank has 832 questions, with timed practice exams and an explanation for every answer.
This study guide is independent and is not affiliated with, endorsed by, or sponsored by AWS. Vendor names, certification names and exam codes are trademarks of their respective owners and are used for identification only.