Well-architected frameworks: common pillars across AWS, Azure and Google Cloud
In short: The big cloud providers each publish a well-architected framework: a structured set of pillars, principles and questions for designing good workloads. The pillars are broadly the same everywhere, and the real skill is balancing them, because improving one often costs another.
What the frameworks are
A well-architected framework is a provider's distilled advice on how to design and run cloud workloads. Each one breaks quality into pillars, gives design principles for each, and offers a review tool with questions. They are free, vendor-specific in detail, but surprisingly similar in substance.
Comparing the frameworks
| Theme | AWS Well-Architected | Azure Well-Architected | Google Cloud Well-Architected |
|---|---|---|---|
| Security | Security | Security | Security, privacy and compliance |
| Reliability | Reliability | Reliability | Reliability |
| Cost | Cost optimisation | Cost optimisation | Cost optimisation |
| Operations | Operational excellence | Operational excellence | Operational excellence |
| Performance | Performance efficiency | Performance efficiency | Performance optimisation |
| Sustainability | Separate pillar | Covered as guidance across pillars | Covered in the framework |
| Review tool | AWS Well-Architected Tool | Azure Well-Architected Review and Azure Advisor | Framework guidance and checklists |
Each provider also adds lenses or workload guides for areas such as machine learning, SaaS or IoT. Pillar names change slightly over time, so check the current version before an exam.
Trade-offs between pillars
The pillars pull against each other, and good architecture means making those trade-offs on purpose:
- Reliability versus cost: a second region doubles resilience but also much of the bill.
- Security versus performance: deep packet inspection and TLS inspection add latency.
- Security versus operations: strict change controls slow down deployment unless automated.
- Performance versus sustainability: over-provisioning for speed wastes energy.
Security is the pillar you should not trade away casually. A cheaper design that leaves data exposed is not cheaper once a breach happens. Document any accepted risk with an owner.
Running a review
- Choose a single workload with a clear owner.
- Gather architecture diagrams, data flows and current metrics.
- Answer the framework questions as a team, honestly.
- Rank issues by risk and agree owners and dates.
- Fix, test, and repeat the review after major changes.
Tip: in job interviews, describe a design using the pillars, for example "for reliability I used two zones, for security private subnets and KMS, for cost a savings plan". It shows structured thinking. For the AWS security pillar in depth, see the security pillar in practice.
Practice
Name four pillars common to the AWS, Azure and Google Cloud frameworks.
Give an example of a trade-off between reliability and cost.
Is a well-architected review a one-time exercise?
Key takeaways
- Each major provider publishes a well-architected framework.
- Security, reliability, cost, operations and performance are common pillars.
- Pillars trade off against each other; make choices deliberately.
- Do not trade away security without a documented, owned risk.
- Review workloads regularly and act on high risks first.
Original content written by Mohamed Fayas for FM TecHub. © 2026 FM TecHub. You're welcome to share a link to this page; please don't copy the text elsewhere without permission.