AWS Well-Architected Framework Cheat Sheet
The six pillars, design principles, and review workflow used to evaluate AWS workloads against best practices.
2 PagesIntermediateMar 19, 2026
The Six Pillars
The lenses used to evaluate any workload in a Well-Architected review.
- Operational Excellence- run and monitor systems, continuously improve processes
- Security- protect data, systems, and assets through risk assessment and mitigation
- Reliability- recover from failures, scale to meet demand, prevent disruptions
- Performance Efficiency- use computing resources efficiently, adapt as demand changes
- Cost Optimization- avoid unneeded spend, understand where money is going
- Sustainability- minimize environmental impact of running cloud workloads
Run a Review via CLI
Create and update a workload review using the AWS Well-Architected Tool API.
bash
# Register a workload for reviewaws wellarchitected create-workload \ --workload-name "orders-service" \ --description "Order processing microservice" \ --environment PRODUCTION \ --review-owner "[email protected]" \ --lenses "wellarchitected" \ --aws-regions "us-east-1"# List answers for the Reliability pillaraws wellarchitected list-answers \ --workload-id abc123 \ --lens-alias wellarchitected \ --pillar-id reliability
General Design Principles
Cross-cutting principles that show up across multiple pillars.
- Automate everything- infrastructure as code, automated testing and deployment
- Scale horizontally- prefer many smaller resources over single large ones
- Stop guessing capacity- use elasticity instead of provisioning for peak
- Test at production scale- use ephemeral environments to validate real load
- Enable evolutionary architecture- design for change via loose coupling
- Data-driven decisions- use metrics to improve architecture over time
Pre-Review Prep Checklist
What to gather before running a Well-Architected review workshop.
yaml
review_prep: - architecture_diagram: current, includes data flows and trust boundaries - workload_context: business criticality, RTO/RPO targets - stakeholders: owner, security lead, on-call engineer present - existing_metrics: cost reports, CloudWatch dashboards, incident history - prior_review: link previous HRIs (high-risk issues) and their status
Define a Custom Lens
Structure of a custom lens JSON used to extend the framework with organization-specific pillars or questions.
json
{ "schemaVersion": "2021-11-01", "name": "internal-platform-lens", "pillars": [ { "id": "data-governance", "name": "Data Governance", "questions": [ { "id": "data_classification", "title": "How do you classify and protect sensitive data?", "choices": [ { "id": "tagged", "title": "Data is tagged by sensitivity at creation" }, { "id": "encrypted", "title": "Encryption enforced via SCP/Config rule" } ], "riskRules": [ { "condition": "none-matched", "risk": "HIGH" } ] } ] } ]}
Track Milestones & Improvement Plan (CLI)
Record a workload milestone after remediation and pull the resulting improvement plan for follow-up.
bash
aws wellarchitected create-milestone \ --workload-id abc123 \ --milestone-name "post-Q3-remediation"aws wellarchitected get-lens-review-report \ --workload-id abc123 \ --lens-alias wellarchitected \ --output textaws wellarchitected list-lens-review-improvements \ --workload-id abc123 \ --lens-alias wellarchitected \ --pillar-id reliability
Reliability Pillar: Fault Injection Test
Use AWS Fault Injection Service to validate the Reliability pillar's 'test resiliency' best practice against an ASG.
json
{ "description": "Terminate 30% of instances in orders-asg", "targets": { "orders-instances": { "resourceType": "aws:ec2:instance", "resourceTags": { "Application": "orders" }, "selectionMode": "PERCENT(30)" } }, "actions": { "terminate-instances": { "actionId": "aws:ec2:terminate-instances", "targets": { "Instances": "orders-instances" } } }, "stopConditions": [ { "source": "aws:cloudwatch:alarm", "value": "arn:aws:cloudwatch:...:alarm:orders-availability" } ]}
Risk Rating & Review Cadence
How findings get scored and how often each pillar should be revisited.
- High-Risk Issue (HRI)- best practice not followed, significant exposure to cost, security, or availability
- Medium-Risk Issue (MRI)- best practice not followed, moderate exposure; addressed opportunistically
- Risk-free- all best practices for that question are in place
- Not applicable- question genuinely doesn't apply to this workload; must be justified, not skipped silently
- Review cadence- re-review after major architecture change, or at minimum annually for production workloads
- Lens vs. workload- a lens is the question set (e.g. Serverless, SaaS); a workload is the system being scored against it
Cost Optimization Pillar: Idle Resource Query
Use Cost Explorer's API to find EC2 spend with near-zero utilization, feeding evidence into the Cost Optimization pillar review.
bash
aws ce get-cost-and-usage \ --time-period Start=2026-06-01,End=2026-07-01 \ --granularity MONTHLY \ --metrics "UnblendedCost" \ --group-by Type=DIMENSION,Key=SERVICE \ --filter '{ "Dimensions": { "Key": "SERVICE", "Values": ["Amazon Elastic Compute Cloud - Compute"] } }'
Pro Tip
Treat every High-Risk Issue (HRI) from a review as a tracked backlog item with an owner and due date — reviews that don't produce a remediation plan tend to get repeated with the same findings a year later.
Was this cheat sheet helpful?
Explore Topics
#AWSWellArchitectedFramework#AWSWellArchitectedFrameworkCheatSheet#CloudComputing#Intermediate#TheSixPillars#RunAReviewViaCLI#GeneralDesignPrinciples#Pre#CheatSheet#SkillVeris
