菜单
Use when reviewing AWS architecture, designing cloud systems, addressing operational issues, security concerns, reliability problems, performance bottlenecks, cost overruns, or sustainability goals
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
| name | aws-well-architected-framework |
| description | Use when reviewing AWS architecture, designing cloud systems, addressing operational issues, security concerns, reliability problems, performance bottlenecks, cost overruns, or sustainability goals |
Expert guidance for designing, reviewing, and improving AWS architectures using the six pillars of the Well-Architected Framework.
Use this skill when:
Systematic architecture evaluation across 6 pillars ensures balanced, well-designed systems that meet business objectives.
The AWS Well-Architected Framework provides a consistent approach for evaluating cloud architectures and implementing scalable designs.
| Pillar | Focus | Key Question |
|---|---|---|
| Operational Excellence | Run and monitor systems | How do we operate effectively? |
| Security | Protect information and systems | How do we protect data and resources? |
| Reliability | Recover from failures | How do we ensure workload availability? |
| Performance Efficiency | Use resources effectively | How do we meet performance requirements? |
| Cost Optimization | Avoid unnecessary costs | How do we achieve cost-effective outcomes? |
| Sustainability | Minimize environmental impact | How do we reduce carbon footprint? |
CRITICAL: You MUST review ALL 6 pillars systematically. Never skip a pillar because it "seems not applicable" - every workload has considerations across all pillars.
digraph review_flow {
"Architecture review needed" [shape=doublecircle];
"Identify workload scope" [shape=box];
"Review each pillar systematically" [shape=box];
"Document findings per pillar" [shape=box];
"Prioritize improvements" [shape=box];
"Create action plan" [shape=box];
"All pillars reviewed?" [shape=diamond];
"Complete" [shape=doublecircle];
"Architecture review needed" -> "Identify workload scope";
"Identify workload scope" -> "Review each pillar systematically";
"Review each pillar systematically" -> "Document findings per pillar";
"Document findings per pillar" -> "All pillars reviewed?";
"All pillars reviewed?" -> "Review each pillar systematically" [label="no"];
"All pillars reviewed?" -> "Prioritize improvements" [label="yes"];
"Prioritize improvements" -> "Create action plan";
"Create action plan" -> "Complete";
}
Red Flags - You're Skipping the Framework:
Goal: Support development and run workloads effectively, gain insight into operations, and continuously improve processes.
Organization:
Prepare:
Operate:
Evolve:
| Issue | Solution |
|---|---|
| Manual deployments | Implement CI/CD with CloudFormation/CDK/Terraform |
| No visibility into system health | Add CloudWatch dashboards, metrics, alarms |
| Operational procedures outdated | Regular runbook reviews, post-incident learning |
| Slow incident response | Create automated remediation with Lambda/Systems Manager |
Goal: Protect data, systems, and assets through cloud security practices.
Security Foundations:
Identity and Access Management:
Detection:
Infrastructure Protection:
Data Protection:
Incident Response:
Never Do:
// ❌ DANGEROUS: Hardcoded credentials
const AWS = require('aws-sdk');
const s3 = new AWS.S3({
accessKeyId: 'AKIAIOSFODNN7EXAMPLE',
secretAccessKey: 'wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY'
});
Always Do:
// ✅ CORRECT: Use IAM roles
const AWS = require('aws-sdk');
const s3 = new AWS.S3(); // Credentials from IAM role
// Lambda function with IAM role
const lambda = new lambda.Function(this, 'MyFunction', {
// IAM role with least privilege
role: myRole,
// ...
});
Goal: Ensure workload performs its intended function correctly and consistently.
Foundations:
Workload Architecture:
Change Management:
Failure Management:
Multi-AZ Deployment:
Region
├── AZ-1: Application + Database
├── AZ-2: Application + Database (standby)
└── AZ-3: Application + Database (standby)
Multi-Region Deployment:
Primary Region Secondary Region
├── Active workload ├── Standby/Active
├── Database (primary) ├── Database (replica)
└── Route 53 health check monitoring
| Data Type | Solution | RPO | RTO |
|---|---|---|---|
| RDS | Automated backups + snapshots | < 5 min | < 30 min |
| DynamoDB | Point-in-time recovery | Seconds | Minutes |
| S3 | Versioning + cross-region replication | Real-time | Immediate |
| EBS | Snapshots via AWS Backup | Hours | Hours |
Goal: Use computing resources efficiently to meet requirements and maintain efficiency as demand changes.
Selection:
Review:
Monitoring:
Trade-offs:
Caching Strategy:
Client → CloudFront (edge cache)
→ API Gateway
→ Lambda
→ ElastiCache (data cache)
→ DynamoDB/RDS
Database Selection:
| Use Case | Recommended Service |
|---|---|
| Relational, complex queries | RDS (PostgreSQL/MySQL) |
| High throughput, simple queries | DynamoDB |
| Graph relationships | Neptune |
| Search and analytics | OpenSearch |
| Time-series data | Timestream |
| In-memory cache | ElastiCache (Redis/Memcached) |
Goal: Run systems to deliver business value at lowest price point.
Practice Cloud Financial Management:
Expenditure and Usage Awareness:
Cost-Effective Resources:
Manage Demand:
Optimize Over Time:
| Strategy | Implementation | Potential Savings |
|---|---|---|
| Right-sizing | Use Compute Optimizer recommendations | 20-40% |
| Reserved Instances | 1-year or 3-year commitments | 30-75% |
| Savings Plans | Flexible compute commitments | 30-70% |
| Spot Instances | Fault-tolerant workloads | 50-90% |
| S3 Intelligent-Tiering | Automatic storage class optimization | 40-60% |
| Auto Scaling | Scale resources with demand | 30-50% |
| Lambda instead of EC2 | For appropriate workloads | Varies |
// CDK Example: Set up budget alerts
import * as budgets from 'aws-cdk-lib/aws-budgets';
new budgets.CfnBudget(this, 'MonthlyBudget', {
budget: {
budgetType: 'COST',
timeUnit: 'MONTHLY',
budgetLimit: {
amount: 1000,
unit: 'USD',
},
},
notificationsWithSubscribers: [{
notification: {
notificationType: 'ACTUAL',
comparisonOperator: 'GREATER_THAN',
threshold: 80, // Alert at 80%
},
subscribers: [{
subscriptionType: 'EMAIL',
address: 'team@example.com',
}],
}],
});
Goal: Minimize environmental impact of running cloud workloads.
Region Selection:
User Behavior Patterns:
Software and Architecture:
Data Patterns:
Hardware Patterns:
Development Process:
Questions to ask:
For each pillar, use this template:
Current State:
Gaps:
Risks:
Recommendations:
| Priority | Criteria |
|---|---|
| High | Security vulnerabilities, critical availability risks, major cost waste |
| Medium | Performance issues, moderate cost optimization, operational improvements |
| Low | Nice-to-haves, future considerations, minor optimizations |
## Pillar: [Name]
### Issue: [Description]
- **Risk Level:** High/Medium/Low
- **Impact:** [Business impact]
- **Effort:** Low/Medium/High
### Recommendation:
[Specific actions]
### Implementation Steps:
1. [Step 1]
2. [Step 2]
3. [Step 3]
### Success Criteria:
- [Measurable outcome 1]
- [Measurable outcome 2]
### Resources:
- [AWS documentation links]
- [Blog posts or examples]
| Anti-Pattern | Issue | Better Approach |
|---|---|---|
| Single AZ deployment | No fault tolerance | Multi-AZ architecture |
| No IaC | Manual config, drift | CloudFormation/CDK/Terraform |
| Hardcoded secrets | Security vulnerability | Secrets Manager/Parameter Store |
| No monitoring | Blind operation | CloudWatch dashboards + alarms |
| No backups | Data loss risk | Automated backup strategy |
| Over-provisioning | Cost waste | Right-sizing + Auto Scaling |
| No cost tracking | Budget overruns | Tags + Budgets + Cost Explorer |
| Monolithic architecture | Hard to scale | Microservices or serverless |
Scenario: Serverless API with authentication
Architecture Review:
Operational Excellence:
Security:
Reliability:
Performance:
Cost:
Sustainability:
Priority Actions:
| Mistake | Why It's Wrong | Correct Approach |
|---|---|---|
| "Sustainability doesn't apply to this workload" | Every workload consumes resources and energy | Review all 6 pillars, even if findings are minimal |
| Skipping current state documentation | Can't measure improvement without baseline | Always document "Current State" before recommendations |
| Generic recommendations | Not actionable or specific to this workload | Provide specific AWS services, code examples, priorities |
| No prioritization | Everything seems equally important | Use HIGH/MEDIUM/LOW risk levels, create phased plan |
| Forgetting about trade-offs | Optimizing one pillar at expense of others | Explicitly call out trade-offs (e.g., multi-region cost vs reliability) |
When conducting architecture reviews:
Remember: Architecture is about trade-offs. A perfect architecture doesn't exist - aim for a well-balanced one that meets business needs.
No exceptions to reviewing all 6 pillars - even if a pillar seems "not applicable", document why and what the current state is.