The major cloud providers each publish a Well-Architected Framework -- a set of pillars, design principles, and best practices for building reliable, secure, performant, and cost-effective workloads in the cloud. While the terminology and organization differ, the core concerns are remarkably consistent across all three.
This skill covers all three frameworks in a unified view, enabling cross-cloud comparison and provider-agnostic architecture reasoning.
Cross-Cloud Pillar Comparison
Concern
AWS (6 Pillars)
Azure (5 Pillars)
GCP (6 Pillars)
Operations
Operational Excellence
Operational Excellence
Operational Excellence
Security
Security
Security
Security, Privacy & Compliance
Reliability
Reliability
Reliability
Reliability
Performance
Performance Efficiency
Performance Efficiency
Performance Optimization
Cost
Cost Optimization
Cost Optimization
Cost Optimization
Sustainability
Sustainability
--
--
System Design
--
--
System Design
Key observation: All three frameworks agree on the five core concerns (operations, security, reliability, performance, cost). AWS adds Sustainability; GCP adds System Design as an explicit pillar; Azure covers both implicitly within its five pillars.
AWS Well-Architected Framework (6 Pillars)
1. Operational Excellence
Design, run, and monitor systems to deliver business value and continually improve processes and procedures.
Key principles:
Perform operations as code (Infrastructure as Code)
Make frequent, small, reversible changes
Refine operations procedures frequently
Anticipate failure; learn from all operational events
Use managed services to reduce operational burden
2. Security
Protect data, systems, and assets through risk assessments, security controls, and automated security best practices.
Key principles:
Implement a strong identity foundation (least privilege, IAM)
Architecture Framework checklists + Cloud Architecture Center
Checklist-driven review; reference architectures
Review Steps
Scope the workload -- Define the boundary of what is being reviewed (a single application, a platform, a service).
Assemble the team -- Include architects, developers, operations, security, and finance.
Walk through each pillar -- Answer the framework's questions honestly. Identify gaps.
Prioritize findings -- Rank by business impact and effort. Focus on high-risk, high-impact items first.
Create an improvement plan -- Assign owners, set deadlines, track progress.
Schedule regular reviews -- Architecture is not a one-time activity. Review quarterly or after major changes.
Review Frequency
Trigger
Action
New workload launch
Full review before production
Major architecture change
Review affected pillars
Quarterly cadence
Lightweight review of all pillars
Incident or outage
Review Reliability and Operational Excellence pillars
Cost spike
Review Cost Optimization pillar
Pillar Tensions and Tradeoffs
The pillars are inherently in tension. Optimizing one often increases costs or complexity in another:
Tradeoff
Example
Reliability vs. Cost
Multi-region deployment increases availability but doubles infrastructure cost
Security vs. Performance
Encryption at rest and in transit adds latency
Performance vs. Cost
Over-provisioning ensures headroom but wastes money
Operational Excellence vs. Speed
Comprehensive CI/CD and observability take time to set up but pay off long-term
Sustainability vs. Performance
Right-sizing reduces waste but may reduce performance headroom
Key principle: Make tradeoffs explicitly. Document which pillars are prioritized and why (use Architecture Decision Records -- see specs/documentation/adr).
Best Practices
Use the well-architected framework as a common language between architects, developers, and stakeholders -- not as a compliance checklist.
Conduct well-architected reviews early and often, not just before launch.
Prioritize the pillars that matter most for your workload (e.g., a financial system prioritizes Security and Reliability; a data pipeline prioritizes Performance and Cost).
Leverage the cloud provider's native review tooling to structure the assessment.
Document all tradeoff decisions in Architecture Decision Records.
Remember that well-architected is aspirational -- no workload scores perfectly on every pillar. The goal is continuous improvement.
When working across clouds (multi-cloud or migration), use this cross-cloud comparison to map equivalent concerns and avoid gaps.
