メニュー
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.