kayaman/aws-well-architected-framework

AWS Well-Architected Framework

Reference: AWS Well-Architected Framework (updated Nov 2024)

When to Apply

• Preparing for or conducting a Well-Architected Review
• Designing new AWS workloads or evaluating existing ones
• Making trade-off decisions between pillars (e.g., cost vs reliability)
• Selecting a Well-Architected Lens for a specialized workload
• Teaching or learning the framework's principles and review methodology
• Aligning architecture decisions with organizational goals

This skill provides knowledge and guidance. For enforcement rules during code reviews and IaC development, see the aws-well-architected skill.

---

General Design Principles

These cross-cutting principles apply to all six pillars:

1. Stop guessing capacity needs — use auto-scaling and monitoring to match supply to demand
2. Test systems at production scale — create production-scale test environments on demand; decommission after testing
3. Automate with experimentation in mind — create and replicate workloads at low cost; track changes via automation
4. Allow for evolutionary architectures — design for change; reduce the cost of experimentation
5. Drive architectures using data — collect data on how your architecture choices affect workload behavior
6. Improve through game days — simulate events in production to understand behavior and test responses

---

The Six Pillars

Pillar 1: Operational Excellence

Focus: Build and run workloads effectively while continuously improving processes.

8 Design Principles (expanded June 2024):

1. Organize teams around business outcomes
2. Implement observability for actionable insights
3. Safely automate where possible (with guardrails)
4. Make frequent, small, reversible changes
5. Refine operations procedures frequently
6. Anticipate failure — run simulations and game days
7. Learn from all operational events
8. Use managed services to reduce operational burden

Key Areas: Organization → Prepare → Operate → Evolve

Key Services: CloudWatch, Systems Manager, Config, EventBridge, Fault Injection Service, CloudFormation

---

Pillar 2: Security

Focus: Protect data, systems, and assets using cloud-native controls.

7 Design Principles:

1. Implement a strong identity foundation (least privilege, no long-term credentials)
2. Maintain traceability (real-time monitoring, auditing)
3. Apply security at all layers (defense in depth)
4. Automate security best practices (security as code)
5. Protect data in transit and at rest
6. Keep people away from data (minimize direct access)
7. Prepare for security events (incident response playbooks)

Key Areas: Identity & Access → Detection → Infrastructure Protection → Data Protection → Incident Response

Key Services: IAM, GuardDuty, Security Hub, CloudTrail, KMS, WAF, Shield, Secrets Manager, Macie

---

Pillar 3: Reliability

Focus: Ensure workloads perform their intended function correctly and consistently.

5 Design Principles:

1. Automatically recover from failure
2. Test recovery procedures
3. Scale horizontally to increase aggregate availability
4. Stop guessing capacity
5. Manage change through automation

Key Areas: Foundations → Workload Architecture → Change Management → Failure Management

Key Services: Route 53, ELB, Auto Scaling, SQS, Resilience Hub, Elastic Disaster Recovery, Fault Injection Service

Critical Rules:

• MUST design for multi-AZ deployments for all production stateful services
• MUST define and test RTO/RPO targets
• MUST implement health checks and automatic replacement of unhealthy instances
• SHOULD implement circuit breakers and retry with exponential backoff

---

Pillar 4: Performance Efficiency

Focus: Use computing resources efficiently as demand and technologies evolve.

5 Design Principles:

1. Democratize advanced technologies (consume as managed services)
2. Go global in minutes (multi-Region, edge)
3. Use serverless architectures
4. Experiment more often
5. Apply mechanical sympathy (match technology to access patterns)

Key Areas: Selection (Compute, Storage, Database, Networking) → Review → Monitoring → Trade-offs

Key Services: EC2 Graviton, Lambda, ECS/EKS, ElastiCache, DAX, CloudFront, DynamoDB, Aurora, Global Accelerator

---

Pillar 5: Cost Optimization

Focus: Achieve business value at the lowest price point.

5 Design Principles:

1. Implement Cloud Financial Management (FinOps)
2. Adopt a consumption model (pay only for what you use)
3. Measure overall efficiency (cost per business unit)
4. Stop spending on undifferentiated heavy lifting
5. Analyze and attribute expenditure (tagging, cost allocation)

Key Areas: Cloud Financial Management → Expenditure Awareness → Cost-Effective Resources → Demand/Supply Management → Optimization Over Time

Key Services: Cost Explorer, Budgets, Cost Optimization Hub, Compute Optimizer, Savings Plans, Spot Instances, Trusted Advisor

---

Pillar 6: Sustainability (added 2021)

Focus: Minimize environmental impact of cloud workloads.

6 Design Principles:

1. Understand your impact
2. Establish sustainability goals
3. Maximize utilization
4. Anticipate and adopt more efficient offerings
5. Use managed services
6. Reduce downstream impact

Key Areas: Region Selection → User Behavior → Software/Architecture Patterns → Data Patterns → Hardware Patterns → Development/Deployment Patterns

Key Strategies: Right-size compute, use Graviton (ARM) instances, S3 Lifecycle policies, serverless for variable workloads, eliminate idle resources

---

Well-Architected Reviews

A Well-Architected Review is a constructive conversation about architectural decisions, not an audit mechanism.

Three Phases

| Phase | Activities | Output | |-------|-----------|--------| | Prepare | Identify workload, sponsors, and stakeholders; select pillars and lenses | Review scope and participants | | Review | Walk through per-pillar questions in the WA Tool; identify High/Medium Risk Issues (HRIs/MRIs) | Documented risks and findings | | Improve | Create improvement plan; prioritize by business impact; implement and track via milestones | Measurable risk reduction |

The Well-Architected Tool

• Free in the AWS Console — guides teams through pillar questions
• Tracks improvement plans and milestones over time
• Supports custom lenses for domain-specific evaluation
• Integrates with AWS Trusted Advisor for automated checks

---

Lenses

Lenses extend the framework for specific workload types or industries:

| Lens Category | Examples | |--------------|---------| | Technology | Serverless, SaaS, IoT, Container Build, Data Analytics | | AI/ML | Machine Learning, Generative AI, Responsible AI | | Industry | Financial Services, Healthcare, Games | | Custom | Organization-specific lenses via JSON templates |

• SHOULD select the most relevant lens(es) for the workload type
• MAY create custom lenses to encode organization-specific architectural standards

---

Pillar Trade-off Guidance

| Tension | Guidance | |---------|---------| | Security vs Performance | TLS termination at the load balancer, not per-instance; use regional endpoints for latency | | Cost vs Reliability | Multi-AZ for stateful tiers; accept single-AZ for stateless compute in non-critical environments only | | Cost vs Performance | Reserved capacity for baseline; on-demand/Spot for burst; cache aggressively | | Operational Simplicity vs Reliability | Prefer managed services even at higher unit cost — reduced operational burden outweighs marginal cost | | Sustainability vs Performance | Right-sizing and Graviton generally improve both; optimize per-transaction cost | | Security vs Operational Simplicity | Automate security controls; manual security processes cause drift and become a bottleneck |

---

Checklist

When conducting or preparing for a Well-Architected Review:

• [ ] Workload scope is clearly defined (not the entire organization)
• [ ] Relevant pillars and lenses have been selected
• [ ] Stakeholders from operations, security, development, and finance are involved
• [ ] Each pillar's design principles have been reviewed against the architecture
• [ ] High Risk Issues are identified, prioritized, and assigned to owners
• [ ] An improvement plan with milestones exists in the WA Tool
• [ ] Trade-offs between pillars are documented and accepted consciously
• [ ] The review is treated as a periodic practice, not a one-time event

Key References

| Book / Resource | Author(s) | Publisher | Year | |------|-----------|-----------|------| | AWS Well-Architected Framework (official) | AWS | AWS Docs | 2024 | | Designing Data-Intensive Applications | Martin Kleppmann | O'Reilly | 2017 | | Software Engineering at Google | Winters, Manshreck, Wright | O'Reilly | 2020 | | Fundamentals of Software Architecture | Richards, Ford | O'Reilly | 2020 | | AWS for Solutions Architects (2nd ed.) | Shrivastava et al. | Packt | 2023 | | Cloud Native Patterns | Cornelia Davis | Manning | 2019 |