mcpField
A
aws-well-architected-review

aws-well-architected-review

github.com/github云与 DevOps40.6k86 次安装1 天前更新
代码仓库

关于 aws-well-architected-review

用于依据 AWS Well-Architected Framework 审查云工作负载的工作流，面向维护 AWS 基础设施的团队。它分析 IaC 和已部署资源，按六大支柱归类风险，并生成架构图及 GitHub 跟踪议题。

主要功能

  1. 01扫描 Terraform、CloudFormation、CDK 和 SAM
  2. 02检查六大架构支柱
  3. 03识别并分级风险
  4. 04生成 Mermaid 架构图
  5. 05提供修复建议与 IaC 示例
  6. 06创建 GitHub 议题跟踪整改

适用场景

  1. 01评估现有 AWS 工作负载架构
  2. 02审查基础设施代码中的安全与可靠性风险
  3. 03将发现分配给团队并跟踪修复
  4. 04在缺少 IaC 时检查已部署资源

MCP 相关

工作流要求配置并认证 GitHub MCP 服务，以创建和跟踪审查发现的议题。

安装

复制下面的命令，在终端中运行。

$npx skills add https://github.com/github/awesome-copilot --skill aws-well-architected-review

安装后在 Claude Code 中输入/aws-well-architected-review确认已加载。

详细介绍

AWS Well-Architected 审查

该工作流会针对你的工作负载的 IaC 文件和已部署基础设施，执行一次结构化的 AWS Well-Architected Framework (WAF) 审查。它会识别全部 6 个 WAF 支柱中的风险，并创建 GitHub issue 来跟踪修复情况。

前提条件

  • 已配置并完成身份验证的 AWS CLI
  • 仓库中存在 IaC 文件（Terraform、CloudFormation、CDK 或 SAM）
  • 已配置并完成身份验证的 GitHub MCP 服务

工作流步骤

步骤 1：加载 Well-Architected Framework 参考

获取当前的 AWS WAF 最佳实践：

  • https://docs.aws.amazon.com/wellarchitected/latest/framework/welcome.html
  • 与工作负载类型（Serverless、SaaS 等）相关的支柱特定 lens
步骤 2：发现 IaC 与架构

扫描仓库中的 IaC 文件：

  • Terraform：**/*.tf
  • CloudFormation/SAM：**/*.yaml、**/*.json（CFn 模板）
  • CDK：lib/**/*.ts、bin/**/*.ts、cdk.json

识别正在使用的关键 AWS 服务（计算、数据、网络、安全、可观测性），并生成 Mermaid 架构图。

步骤 3：逐支柱审查
支柱 1：卓越运营
  • 所有基础设施都定义为 IaC（无手动控制台更改）
  • 对所有资源应用一致的标签策略
  • 为关键指标定义 CloudWatch 告警
  • 存在自动化部署流水线（无手动部署）
  • 启用 CloudTrail 以进行审计日志记录
  • 存在运行手册或运维文档
支柱 2：安全性
  • IAM 角色使用最小权限策略（无无正当理由的 * 操作）
  • IaC 或代码中没有硬编码凭证
  • 通过 Secrets Manager 或 SSM Parameter Store 管理密钥
  • S3 存储桶已阻止公共访问并启用服务器端加密
  • 敏感资源放置在私有子网中
  • 安全组将入站限制为最低必需的端口/CIDR
  • 对敏感数据存储（RDS、EBS、S3、SQS、DynamoDB）启用 KMS 加密
  • 在所有端点上强制使用 SSL/TLS（enforceSSL: true）
  • 启用 GuardDuty（aws guardduty list-detectors）
  • 在面向公众的 API 和 CloudFront 分配上配置 AWS WAF
  • 在关键 S3 存储桶上启用 MFA delete
支柱 3：可靠性
  • 生产数据库采用多可用区部署（RDS Multi-AZ、DynamoDB Global Tables）
  • 为 EC2/ECS 配置具有适当策略的 Auto Scaling
  • 配置 S3 版本控制和生命周期策略
  • 启用具有适当保留期的 RDS 自动备份
  • 启用 DynamoDB 时间点恢复（PITR）
  • 为 Lambda、SQS、SNS 配置死信队列（DLQ）
  • 为 DNS 故障转移配置 Route 53 健康检查
  • 设置 Lambda 预留并发以防止吵闹邻居限流
支柱 4：性能效率
  • 实例类型大小合适（Lambda 内存、EC2 类型、RDS 类别）
  • 在可用的情况下使用 Graviton/ARM 实例（Lambda arm64、EC2 Graviton）
  • 实现缓存（ElastiCache、DAX、CloudFront、API Gateway 缓存）
  • 使用 CloudFront 进行全球静态内容分发
  • 针对可变负载模式使用 Aurora Serverless 或 DynamoDB On-Demand
  • 对延迟关键的同步路径使用 Lambda 预置并发
支柱 5：成本优化
  • 对稳态工作负载使用 EC2 预留实例或 Savings Plans
  • S3 生命周期策略将数据移动到更便宜的存储层
  • 采用 Lambda arm64 架构（成本降低 20%）
  • 为 S3/DynamoDB 使用 VPC 端点以避免 NAT Gateway 费用
  • 将 gp2 EBS 卷迁移到 gp3（性能相同，便宜 20%）
  • 开发/测试环境具有自动关机计划
  • 配置 AWS Budgets 和 Cost Anomaly Detection
  • 识别未挂载的 EBS 卷和空闲的 EC2 实例
支柱 6：可持续性
  • 在可用的情况下选择 Graviton/ARM 实例
  • 优先选择无服务器/托管服务，而非始终开启的 EC2
  • S3 生命周期策略减少不必要的长期数据存储
  • 配置 Auto Scaling 以避免过度配置
  • 区域选择考虑 AWS 可再生能源承诺
步骤 4：风险分类

对每项发现进行分类：

  • 高风险：安全漏洞、单点故障、无备份/恢复
  • 中风险：可靠性欠佳、成本效率低下、性能问题
  • 低风险：偏离最佳实践、轻微的优化机会
步骤 5：用户确认
🏗️ AWS Well-Architected Review Summary

📊 Review Results:
• IaC Files Analyzed: X
• AWS Services Identified: Y
• Total Findings: Z
  • High Risk: A (immediate action required)
  • Medium Risk: B (should address soon)
  • Low Risk: C (nice to have)

🔴 Top High Risk Findings:
1. [Pillar]: [Finding] — [Why it matters]
2. [Pillar]: [Finding] — [Why it matters]

💡 This will create Z individual GitHub issues + 1 EPIC issue.

❓ Proceed with creating GitHub issues? (y/n)
步骤 6：创建单独的发现 Issue

使用 "well-architected" 和支柱名称（例如 "security"、"reliability"）添加标签。

标题：[WAF-<PILLAR>] [简要发现] — [风险级别]

正文：

## 🏗️ Well-Architected Finding: [Brief Title]

**Pillar**: [Name] | **Risk Level**: [High/Medium/Low] | **Effort**: [Low/Medium/High]

### 📋 Description
[Clear explanation of the finding and why it matters]

### 🔧 Remediation

**IaC Fix** (preferred):
```hcl
# Terraform example
resource "aws_s3_bucket_server_side_encryption_configuration" "example" {
  bucket = aws_s3_bucket.example.id
  rule {
    apply_server_side_encryption_by_default {
      sse_algorithm = "aws:kms"
    }
  }
}
```

**AWS CLI fallback**:
```bash
aws s3api put-bucket-encryption --bucket <name> \
  --server-side-encryption-configuration '{"Rules":[{"ApplyServerSideEncryptionByDefault":{"SSEAlgorithm":"aws:kms"}}]}'
```

### 📚 AWS Reference
- [WAF Best Practice Link]
- [AWS Documentation Link]

### ✅ Validation
- [ ] Change implemented in IaC and deployed
- [ ] AWS Config rule passes (if applicable)
- [ ] Security Hub finding resolved (if applicable)

**Well-Architected Question**: [WAF question this maps to]
步骤 7：创建 EPIC 跟踪 Issue

使用 "well-architected" 和 "epic" 添加标签。

标题：[EPIC] AWS Well-Architected 审查 — 6 个支柱中的 X 项发现

正文：执行摘要，包含支柱细分表（按支柱和风险级别统计发现数量）、Mermaid 架构图、链接所有单独 Issue 的优先级检查清单（高 → 中 → 低），以及成功标准：

  • 所有高风险发现均已解决
  • 中等发现已有认可的缓解计划
  • 现有 CloudWatch 告警或 Config 规则无回归

错误处理

  • 未找到 IaC 文件：将审查限制为通过 AWS CLI 进行实时资源发现，并记录该缺口
  • AWS 权限不足：列出审查所需的只读权限
  • GitHub 创建失败：将所有发现以格式化 markdown 输出到控制台

成功标准

  • ✅ 已针对 IaC 和实时基础设施审查所有 6 个 WAF 支柱
  • ✅ 所有发现均已按风险级别和支柱分类
  • ✅ 每项发现均包含可操作的修复步骤及 IaC 示例
  • ✅ 已创建 GitHub Issue 供团队跟踪
  • ✅ 已生成架构图用于 EPIC 上下文
  • ✅ 已包含 AWS 文档参考

评论

支持 Markdown