按 Well-Architected 框架设计、迁移、加固 AWS 架构并优化成本。
---
name: aws-cloud-expert
description: |
基于卓越架构框架(Well-Architected Framework),专注于成本优化与安全,设计和实施 AWS 云架构。适用于以下场景:
1. 设计或评审 AWS 基础设施架构
2. 将工作负载迁移到 AWS 或在 AWS 服务之间迁移
3. 优化 AWS 成本(实例规格调整、预留实例、Savings Plans)
4. 实施 AWS 安全、合规性或灾难恢复方案
5. 排查 AWS 服务问题或性能瓶颈
---
**Region**: ${region:us-east-1}
**Secondary Region**: ${secondary_region:us-west-2}
**Environment**: ${environment:production}
**VPC CIDR**: ${vpc_cidr:10.0.0.0/16}
**Instance Type**: ${instance_type:t3.medium}
# AWS 架构决策框架
## 服务选择矩阵
| 工作负载类型 | 主要服务 | 替代方案 | 决策因素 |
|---------------|-----------------|-------------|-----------------|
| 无状态 API | Lambda + API Gateway | ECS Fargate | 请求持续时间 >15分钟 -> ECS |
| 有状态 Web 应用 | ECS/EKS | EC2 Auto Scaling | 具备容器技术能力 -> ECS/EKS |
| 批处理 | Step Functions + Lambda | AWS Batch | 需要 GPU/长时间运行 -> Batch |
| 实时流处理 | Kinesis Data Streams | MSK (Kafka) | 已使用 Kafka -> MSK |
| 静态网站 | S3 + CloudFront | Amplify | 全栈开发 -> Amplify |
| 关系型数据库 | Aurora | RDS | 高可用性需求 -> Aurora |
| 键值存储 | DynamoDB | ElastiCache | 需要亚毫秒级延迟 -> ElastiCache |
| 数据仓库 | Redshift | Athena | 即席查询 -> Athena |
## 计算决策树
```
开始:你的工作负载模式是什么?
|
+-> 事件驱动,执行时间 <15分钟
| +-> Lambda
| 考虑:内存 ${lambda_memory:512}MB,并发执行数,冷启动
|
+-> 长期运行的容器
| +-> 需要 Kubernetes?
| +-> 是:EKS(托管)或在 EC2 上自建 K8s
| +-> 否:ECS Fargate(无服务器)或 ECS EC2(成本优化)
|
+-> 需要 GPU/HPC/自定义 AMI
| +-> 使用合适实例系列的 EC2
| g4dn/p4d(机器学习),c6i(计算优化),r6i(内存优化),i3en(存储优化)
|
+-> 批处理任务,基于队列
+-> 使用 Spot 实例的 AWS Batch(最高可节省 90%)
```
## 网络架构
### VPC 设计模式
```
${environment:production} VPC (${vpc_cidr:10.0.0.0/16})
|
+-- 公共子网 (${public_subnet_cidr:10.0.0.0/24}, 10.0.1.0/24, 10.0.2.0/24)
| +-- ALB、NAT 网关、堡垒机(如需要)
|
+-- 私有子网 (${private_subnet_cidr:10.0.10.0/24}, 10.0.11.0/24, 10.0.12.0/24)
| +-- 应用层(ECS、EC2、Lambda VPC)
|
+-- 数据子网 (${data_subnet_cidr:10.0.20.0/24}, 10.0.21.0/24, 10.0.22.0/24)
+-- RDS、ElastiCache、其他数据存储
```
### 安全组规则
| 层级 | 入站来源 | 端口 |
|------|--------------|-------|
| ALB | 0.0.0.0/0 | 443 |
| 应用 | ALB SG | ${app_port:8080} |
| 数据 | 应用 SG | ${db_port:5432} |
### VPC 终端节点(成本优化)
始终为高流量服务创建:
- S3 网关终端节点(免费)
- DynamoDB 网关终端节点(免费)
- 接口终端节点:ECR、Secrets Manager、SSM、CloudWatch Logs
## 成本优化清单
### 立即行动项(第 1 周)
- [ ] 启用 Cost Explorer 并设置预算及告警
- [ ] 审查并终止未使用的资源(通过 Cost Explorer 的闲置资源报告)
- [ ] 调整 EC2 实例规格(参考 AWS Compute Optimizer 建议)
- [ ] 删除未挂载的 EBS 卷和旧快照
- [ ] 审查 NAT 网关的数据处理费用
### 成本估算快速参考
| 资源 | 月度成本估算 |
|----------|----------------------|
| ${instance_type:t3.medium}(按需) | ~$30 |
| ${instance_type:t3.medium}(1 年预留实例) | ~$18 |
| Lambda(100 万次调用,1 秒,${lambda_memory:512}MB) | ~$8 |
| RDS db.${instance_type:t3.medium}(多可用区) | ~$100 |
| Aurora Serverless v2(${aurora_acu:8} ACU 平均) | ~$350 |
| NAT 网关 + 100GB 数据传输 | ~$50 |
| S3(1TB 标准存储) | ~$23 |
| CloudFront(1TB 传输) | ~$85 |
## 安全实施
### IAM 最佳实践
```
原则:最小权限,显式拒绝
1. 为应用程序使用 IAM 角色(而非用户)
2. 要求所有人机用户启用 MFA
3. 对委托管理员使用权限边界
4. 在组织级别实施 SCP
5. 使用 IAM Access Analyzer 定期进行访问审查
```
### IAM 策略示例模式
```json
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "AllowS3BucketAccess",
"Effect": "Allow",
"Action": ["s3:GetObject", "s3:PutObject"],
"Resource": "arn:aws:s3:::${bucket_name:my-bucket}/*",
"Condition": {
"StringEquals": {"aws:PrincipalTag/Environment": "${environment:production}"}
}
}
]
}
```
### 安全检查清单
- [ ] 在所有区域启用 CloudTrail 并开启日志文件验证
- [ ] 配置 AWS Config 规则以进行合规性监控
- [ ] 启用 GuardDuty 实现威胁检测
- [ ] 使用 Secrets Manager 或 Parameter Store 存储密钥(而非环境变量)
- [ ] 为所有数据存储启用静态加密
- [ ] 对所有连接强制启用 TLS 1.2+
- [ ] 启用 VPC 流日志以进行网络监控
- [ ] 使用 Security Hub 实现集中化的安全视图
## 高可用性模式
### 多可用区架构(${availability_target:99.99%} 目标)
```
区域: ${region:us-east-1}
|
+-- AZ-a +-- AZ-b +-- AZ-c
| | |
ALB (active) ALB (active) ALB (active)
| | |
ECS 任务 (${replicas_per_az:2}) ECS 任务 (${replicas_per_az:2}) ECS 任务 (${replicas_per_az:2})
| | |
Aurora 写入节点 Aurora 只读节点 Aurora 只读节点
```
### 多区域架构(99.999% 目标)
```
主区域: ${region:us-east-1} 备用区域: ${secondary_region:us-west-2}
| |
Route 53(故障转移路由) Route 53(健康检查)
| |
CloudFront CloudFront
| |
全栈 全栈(被动或主动)
| |
Aurora 全局数据库 -------> Aurora 只读副本
(异步复制)
```
### RTO/RPO 决策矩阵
| 层级 | RTO 目标 | RPO 目标 | 策略 |
|------|------------|------------|----------|
| 第1层(关键) | <${rto:15 min} | <${rpo:1 min} | 多区域主主动模式 |
| 第2层(重要) | <1 小时 | <15 分钟 | 多区域主被动模式 |
| 第3层(标准) | <4 小时 | <1 小时 | 多可用区架构,跨区域备份 |
| 第4层(非关键) | <24 小时 | <24 小时 | 单区域,备份与恢复 |
## 监控与可观测性
### CloudWatch 实施方案
| 指标类型 | 服务 | 关键指标 |
|-------------|---------|-------------|
| 计算 | EC2/ECS | CPUUtilization, MemoryUtilization, NetworkIn/Out |
| 数据库 | RDS/Aurora | DatabaseConnections, ReadLatency, WriteLatency |
| 无服务器 | Lambda | Duration, Errors, Throttles, ConcurrentExecutions |
| API | API Gateway | 4XXError, 5XXError, Latency, Count |
| 存储 | S3 | BucketSizeBytes, NumberOfObjects, 4xxErrors |
### 告警阈值
| 资源 | 警告 | 严重 | 操作 |
|----------|---------|----------|--------|
| EC2 CPU | >${cpu_warning:70%} 持续 5 分钟 | >${cpu_critical:90%} 持续 5 分钟 | 扩容,调查原因 |
| RDS CPU | >${rds_cpu_warning:80%} 持续 5 分钟 | >${rds_cpu_critical:95%} 持续 5 分钟 | 升级配置,查询优化 |
| Lambda 错误 | >1% | >5% | 调查,回滚版本 |
| ALB 5xx | >0.1% | >1% | 检查后端服务 |
| DynamoDB 限流 | 任意 | 持续发生 | 提高容量 |
## 验证清单
### 上线前检查
- [ ] 已完成 Well-Architected 审查(全部 6 个支柱)
- [ ] 已完成负载测试,覆盖预期峰值 + 50% 余量
- [ ] 已测试灾难恢复,记录了 RTO/RPO
- [ ] 已通过安全评估(如需要,完成渗透测试)
- [ ] 已验证合规控制措施(如适用)
- [ ] 已配置监控仪表盘和告警
- [ ] 已编写常见操作的运行手册(runbooks)
- [ ] 已验证成本预测并设置预算
- [ ] 已为所有资源实施标签策略
- [ ] 已测试备份与恢复流程---
name: aws-cloud-expert
description: |
Designs and implements AWS cloud architectures with focus on Well-Architected Framework, cost optimization, and security. Use when:
1. Designing or reviewing AWS infrastructure architecture
2. Migrating workloads to AWS or between AWS services
3. Optimizing AWS costs (right-sizing, Reserved Instances, Savings Plans)
4. Implementing AWS security, compliance, or disaster recovery
5. Troubleshooting AWS service issues or performance problems
---
**Region**: ${region:us-east-1}
**Secondary Region**: ${secondary_region:us-west-2}
**Environment**: ${environment:production}
**VPC CIDR**: ${vpc_cidr:10.0.0.0/16}
**Instance Type**: ${instance_type:t3.medium}
# AWS Architecture Decision Framework
## Service Selection Matrix
| Workload Type | Primary Service | Alternative | Decision Factor |
|---------------|-----------------|-------------|-----------------|
| Stateless API | Lambda + API Gateway | ECS Fargate | Request duration >15min -> ECS |
| Stateful web app | ECS/EKS | EC2 Auto Scaling | Container expertise -> ECS/EKS |
| Batch processing | Step Functions + Lambda | AWS Batch | GPU/long-running -> Batch |
| Real-time streaming | Kinesis Data Streams | MSK (Kafka) | Existing Kafka -> MSK |
| Static website | S3 + CloudFront | Amplify | Full-stack -> Amplify |
| Relational DB | Aurora | RDS | High availability -> Aurora |
| Key-value store | DynamoDB | ElastiCache | Sub-ms latency -> ElastiCache |
| Data warehouse | Redshift | Athena | Ad-hoc queries -> Athena |
## Compute Decision Tree
```
Start: What's your workload pattern?
|
+-> Event-driven, <15min execution
| +-> Lambda
| Consider: Memory ${lambda_memory:512}MB, concurrent executions, cold starts
|
+-> Long-running containers
| +-> Need Kubernetes?
| +-> Yes: EKS (managed) or self-managed K8s on EC2
| +-> No: ECS Fargate (serverless) or ECS EC2 (cost optimization)
|
+-> GPU/HPC/Custom AMI required
| +-> EC2 with appropriate instance family
| g4dn/p4d (ML), c6i (compute), r6i (memory), i3en (storage)
|
+-> Batch jobs, queue-based
+-> AWS Batch with Spot instances (up to 90% savings)
```
## Networking Architecture
### VPC Design Pattern
```
${environment:production} VPC (${vpc_cidr:10.0.0.0/16})
|
+-- Public Subnets (${public_subnet_cidr:10.0.0.0/24}, 10.0.1.0/24, 10.0.2.0/24)
| +-- ALB, NAT Gateways, Bastion (if needed)
|
+-- Private Subnets (${private_subnet_cidr:10.0.10.0/24}, 10.0.11.0/24, 10.0.12.0/24)
| +-- Application tier (ECS, EC2, Lambda VPC)
|
+-- Data Subnets (${data_subnet_cidr:10.0.20.0/24}, 10.0.21.0/24, 10.0.22.0/24)
+-- RDS, ElastiCache, other data stores
```
### Security Group Rules
| Tier | Inbound From | Ports |
|------|--------------|-------|
| ALB | 0.0.0.0/0 | 443 |
| App | ALB SG | ${app_port:8080} |
| Data | App SG | ${db_port:5432} |
### VPC Endpoints (Cost Optimization)
Always create for high-traffic services:
- S3 Gateway Endpoint (free)
- DynamoDB Gateway Endpoint (free)
- Interface Endpoints: ECR, Secrets Manager, SSM, CloudWatch Logs
## Cost Optimization Checklist
### Immediate Actions (Week 1)
- [ ] Enable Cost Explorer and set up budgets with alerts
- [ ] Review and terminate unused resources (Cost Explorer idle resources report)
- [ ] Right-size EC2 instances (AWS Compute Optimizer recommendations)
- [ ] Delete unattached EBS volumes and old snapshots
- [ ] Review NAT Gateway data processing charges
### Cost Estimation Quick Reference
| Resource | Monthly Cost Estimate |
|----------|----------------------|
| ${instance_type:t3.medium} (on-demand) | ~$30 |
| ${instance_type:t3.medium} (1yr RI) | ~$18 |
| Lambda (1M invocations, 1s, ${lambda_memory:512}MB) | ~$8 |
| RDS db.${instance_type:t3.medium} (Multi-AZ) | ~$100 |
| Aurora Serverless v2 (${aurora_acu:8} ACU avg) | ~$350 |
| NAT Gateway + 100GB data | ~$50 |
| S3 (1TB Standard) | ~$23 |
| CloudFront (1TB transfer) | ~$85 |
## Security Implementation
### IAM Best Practices
```
Principle: Least privilege with explicit deny
1. Use IAM roles (not users) for applications
2. Require MFA for all human users
3. Use permission boundaries for delegated admin
4. Implement SCPs at Organization level
5. Regular access reviews with IAM Access Analyzer
```
### Example IAM Policy Pattern
```json
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "AllowS3BucketAccess",
"Effect": "Allow",
"Action": ["s3:GetObject", "s3:PutObject"],
"Resource": "arn:aws:s3:::${bucket_name:my-bucket}/*",
"Condition": {
"StringEquals": {"aws:PrincipalTag/Environment": "${environment:production}"}
}
}
]
}
```
### Security Checklist
- [ ] Enable CloudTrail in all regions with log file validation
- [ ] Configure AWS Config rules for compliance monitoring
- [ ] Enable GuardDuty for threat detection
- [ ] Use Secrets Manager or Parameter Store for secrets (not env vars)
- [ ] Enable encryption at rest for all data stores
- [ ] Enforce TLS 1.2+ for all connections
- [ ] Implement VPC Flow Logs for network monitoring
- [ ] Use Security Hub for centralized security view
## High Availability Patterns
### Multi-AZ Architecture (${availability_target:99.99%} target)
```
Region: ${region:us-east-1}
|
+-- AZ-a +-- AZ-b +-- AZ-c
| | |
ALB (active) ALB (active) ALB (active)
| | |
ECS Tasks (${replicas_per_az:2}) ECS Tasks (${replicas_per_az:2}) ECS Tasks (${replicas_per_az:2})
| | |
Aurora Writer Aurora Reader Aurora Reader
```
### Multi-Region Architecture (99.999% target)
```
Primary: ${region:us-east-1} Secondary: ${secondary_region:us-west-2}
| |
Route 53 (failover routing) Route 53 (health checks)
| |
CloudFront CloudFront
| |
Full stack Full stack (passive or active)
| |
Aurora Global Database -------> Aurora Read Replica
(async replication)
```
### RTO/RPO Decision Matrix
| Tier | RTO Target | RPO Target | Strategy |
|------|------------|------------|----------|
| Tier 1 (Critical) | <${rto:15 min} | <${rpo:1 min} | Multi-region active-active |
| Tier 2 (Important) | <1 hour | <15 min | Multi-region active-passive |
| Tier 3 (Standard) | <4 hours | <1 hour | Multi-AZ with cross-region backup |
| Tier 4 (Non-critical) | <24 hours | <24 hours | Single region, backup/restore |
## Monitoring and Observability
### CloudWatch Implementation
| Metric Type | Service | Key Metrics |
|-------------|---------|-------------|
| Compute | EC2/ECS | CPUUtilization, MemoryUtilization, NetworkIn/Out |
| Database | RDS/Aurora | DatabaseConnections, ReadLatency, WriteLatency |
| Serverless | Lambda | Duration, Errors, Throttles, ConcurrentExecutions |
| API | API Gateway | 4XXError, 5XXError, Latency, Count |
| Storage | S3 | BucketSizeBytes, NumberOfObjects, 4xxErrors |
### Alerting Thresholds
| Resource | Warning | Critical | Action |
|----------|---------|----------|--------|
| EC2 CPU | >${cpu_warning:70%} 5min | >${cpu_critical:90%} 5min | Scale out, investigate |
| RDS CPU | >${rds_cpu_warning:80%} 5min | >${rds_cpu_critical:95%} 5min | Scale up, query optimization |
| Lambda errors | >1% | >5% | Investigate, rollback |
| ALB 5xx | >0.1% | >1% | Investigate backend |
| DynamoDB throttle | Any | Sustained | Increase capacity |
## Verification Checklist
### Before Production Launch
- [ ] Well-Architected Review completed (all 6 pillars)
- [ ] Load testing completed with expected peak + 50% headroom
- [ ] Disaster recovery tested with documented RTO/RPO
- [ ] Security assessment passed (penetration test if required)
- [ ] Compliance controls verified (if applicable)
- [ ] Monitoring dashboards and alerts configured
- [ ] Runbooks documented for common operations
- [ ] Cost projection validated and budgets set
- [ ] Tagging strategy implemented for all resources
- [ ] Backup and restore procedures tested