aws-best-practice-research

AWS 最佳实践研究（含可选的实时评估）

使用 aws knowledge mcp server 文档搜索工具，为任意 AWS 服务研究并整理全面的最佳实践检查清单。也可以根据整理好的检查清单评估实时 AWS 资源。

前提条件

此技能需要能够使用 aws knowledge mcp server 工具：

• aws___search_documentation — 搜索 AWS 文档中的主题
• aws___read_documentation — 阅读完整的文档页面
• aws___recommend — 获取相关文档推荐

如需进行可选的实时评估（步骤 8）：

• AWS CLI（aws）— 必须配置具有目标服务读取权限的凭证
• jq — 用于解析 AWS CLI 命令的 JSON 输出

工作流

步骤 1：确定目标服务和评估范围

根据用户输入确定：

• AWS 服务 — 例如 ElastiCache Redis、RDS MySQL、MSK、EKS、Aurora、DynamoDB 等
• 关注领域 — HA/DR、安全，或全部（默认：全部）
• 实时评估信息（可选） — 用户是否提供以下任一信息？
  • AWS 凭证（环境变量、配置文件或凭证文件路径）
  • AWS 区域（例如 us-west-2）
  • 资源标识符（集群名称、实例 ID、表名称等）

如果服务不明确，请要求用户澄清（例如：“RDS MySQL 还是 RDS PostgreSQL？”）。

记录用户是否请求进行实时评估：

• 如果用户提供凭证 + 区域 + 资源信息 → 在整理检查清单后进行实时评估
• 如果用户只提供部分信息 → 继续之前，请询问缺少的信息
• 如果用户未提供实时资源信息 → 跳过实时评估，仅生成检查清单

步骤 2：依次搜索文档

使用 aws___search_documentation，一次一个、依次运行以下 5 个搜索查询。 不要并行运行——aws knowledge mcp server 有速率限制，并行请求会触发“Too many requests”错误。

等待每个查询返回结果后，再发送下一个查询。将 {SERVICE} 替换为实际服务名称（例如“ElastiCache Redis”、“Amazon RDS MySQL”、“Amazon MSK”）。

Query 1: "{SERVICE} best practices high availability disaster recovery"
  topics: ["general"]
  limit: 10

Query 2: "{SERVICE} Well-Architected reliability resilience best practices"
  topics: ["general"]
  limit: 10

Query 3: "{SERVICE} replication multi-AZ failover cluster mode backup"
  topics: ["reference_documentation", "troubleshooting"]
  limit: 10

Query 4: "{SERVICE} security encryption authentication access control"
  topics: ["general"]
  limit: 10

Query 5: "{SERVICE} Well-Architected security best practices"
  topics: ["general"]
  limit: 10

速率限制保护：如果任何查询返回“Too many requests”错误，请等待 5 秒后重试一次。如果再次失败，则跳过该查询并继续下一个。

步骤 3：阅读关键文档页面

根据搜索结果，找出并阅读最重要的页面；使用 aws___read_documentation 一次一页、依次阅读。不要并行阅读多个页面，以避免触发速率限制。优先选择以下文档类型：

1. 该服务的 Well-Architected Lens 页面（可靠性、安全性、性能、卓越运营支柱）
2. 官方最佳实践页面
3. 弹性 / 灾难恢复页面
4. 整体最佳实践页面

每页使用 max_length: 15000 以获取全面内容。通常需要阅读 3-5 个页面。

如果该服务有 Well-Architected Lens，它就是最有价值的单一信息源——务必阅读。

步骤 4：提取并分类检查项

从收集的所有文档中提取各项检查项，并将其归入5 个必选类别（确切格式请参阅 references/output-template.md）：

类别 1：高可用架构 相关检查项：集群模式、复制、每个分片的副本数、多可用区（Multi-AZ）、可用区分布、节点类型、仲裁。

类别 2：灾难恢复 相关检查项：自动／手动备份、保留策略、RPO／RTO 文档、全局数据存储（Global Datastore）／跨区域复制、故障转移测试、复制延迟监控。

类别 3：故障转移规划 相关检查项：Test Failover API、FIS 弹性测试、客户端超时／拓扑配置、SNS 事件通知、优雅降级、WAIT 命令。

类别 4：安全配置 相关检查项：静态／传输中加密、身份验证（AUTH／RBAC／IAM）、子网组、安全组、KMS 密钥、危险命令重命名、RBAC 指标监控、IAM 控制平面策略。

类别 5：其他 未涵盖在上述 4 个类别中的检查项，包括但不限于：自动次要版本升级、引擎版本、节点类型选择（Graviton）、CloudWatch 监控、预留内存、连接池、读取路由、高开销命令、慢日志、IaC 管理、自动扩缩、成本标签、客户端重试逻辑、性能调优、运维最佳实践。

容器 / 编排平台的范围边界

当目标服务是容器或编排平台（EKS、ECS、Fargate、App Runner、Elastic Beanstalk）时，此技能仅专注于 AWS 基础设施层。所有检查项都必须可通过 AWS API（aws eks、aws ecs、aws ec2、aws iam 等）验证。

不要包含需要使用 kubectl、ECS Exec，或需要在集群 / 任务内部检查才能验证的检查项。这些内容属于专门的工作负载级评估技能。

对于 Amazon EKS，基础设施层范围包括：

范围内（可通过 AWS API 验证）	范围外（需要 kubectl / 工作负载上下文）
控制平面配置（K8s 版本、平台版本、API 端点访问、日志记录）	Pod 中断预算（PDB）
节点组配置（实例类型、扩缩容、AMI、可用区分布、磁盘大小）	拓扑分布约束
集群网络（VPC、子网、安全组、服务 CIDR）	存活 / 就绪 / 启动探针
附加组件的存在情况和版本（VPC CNI、CoreDNS、kube-proxy、EBS CSI 等）	容器资源请求 / 限制
Secrets 信封加密（KMS 密钥）	Pod securityContext（runAsNonRoot、capabilities）
身份验证模式（ConfigMap 与 API）和访问条目	Pod 安全准入（PSA）命名空间标签
控制平面审计日志记录	automountServiceAccountToken
集群删除保护	网络策略（K8s 资源级别）
节点自动修复和节点监控代理附加组件	Pod 优雅终止（terminationGracePeriodSeconds、preStop）
集群标签和节点组标签	工作负载级 Velero 备份
升级洞察和弃用警告	应用健康检查路径
OIDC 提供程序配置（用于 IRSA）	服务网格（mTLS）配置
GuardDuty EKS 防护（账户级别）	OPA Gatekeeper / Kyverno 策略

对于 Amazon ECS / Fargate，采用相同原则：检查集群、容量提供程序、服务自动扩缩、任务定义注册、VPC 配置和 IAM 角色，但不要检查容器级健康检查、资源限制或任务内部配置。

生成检查清单后，附加一则范围说明（确切格式请参见 references/output-template.md），引导用户使用工作负载级技能检查范围外的项目。

对于每个检查项，记录：

• ID — 类别前缀 + 顺序编号 + 优先级后缀（例如，HA-01-hi、DR-02-md、SEC-03-lo）
  • 优先级后缀：-hi（高）、-md（中）、-lo（低）
  • 将优先级直接编入 ID，便于快速浏览
• 检查项名称 — 简洁且可执行
• 描述 — 检查内容及原因；适用时注明具体阈值或值
• 来源 — 所依据的文档 / 控制项（请参见下方的来源标注规则）
• 优先级 — 高 / 中 / 低（同时作为独立列保留，以便筛选）

步骤 5：编制来源标注

在整个检查清单中统一使用来源标签：

标签	含义
WA-REL / WA-RELn	Well-Architected Lens — 可靠性支柱（问题 N）
WA-SEC / WA-SECn	Well-Architected Lens — 安全性支柱
WA-PE / WA-PEn	Well-Architected Lens — 性能效率支柱
WA-OE / WA-OEn	Well-Architected Lens — 卓越运营支柱
WA-CO	Well-Architected Lens — 成本优化支柱
Security Hub [{Service}.N]	AWS Security Hub CSPM 控制项（例如，[ElastiCache.1]）
re:Post	AWS re:Post 知识中心文章
Official Docs	服务用户指南 / 官方文档
AWS Blog	AWS Database Blog 或其他官方博客
Whitepaper	AWS 白皮书

步骤 6：生成输出（条件式）

输出取决于用户是否在步骤 1 中提供了实时评估信息：

如果未提供实时评估信息 → 仅生成检查清单

使用 references/output-template.md 中定义的确切格式生成检查清单内容， 然后使用 Write 工具将其写入本地 Markdown 文件。

文件命名：YYYY-mm-dd-HH-MM-SS-{SERVICE}-best-practice-checklist.md

• 将 YYYY-mm-dd-HH-MM-SS 替换为当前时间戳（例如，2025-07-15-14-30-00）
• 将 {SERVICE} 替换为全小写、以连字符分隔的服务名称（例如，elasticache-redis、amazon-eks）
• 示例：2025-07-15-14-30-00-elasticache-redis-best-practice-checklist.md
• 将文件保存到当前工作目录

检查清单输出必须包含：

1. 带有服务名称的标题
2. 每个类别一张表（共 5 张表）
3. 来源注释图例
4. 关键参考链接部分

写入文件后，告知用户文件路径。

如果已提供实时评估信息 → 跳过检查清单，继续执行步骤 8

不要生成单独的检查清单文件。评估报告（步骤 8）将在一份完整文档中包含带有评估结果的完整检查清单。生成两份文件会造成重复。

直接继续执行步骤 8。

步骤 7：提供后续选项（仅检查清单路径）

仅当你在步骤 6 中生成了检查清单（未进行实时评估）时，此步骤才适用。

写入检查清单文件后，建议用户：

• “如果你愿意，我可以将其导出为电子表格。”
• “如果你提供 AWS 凭证和资源标识符，我可以根据此检查清单评估实时资源。”

如果用户在步骤 1 中提供了实时评估信息，则完全跳过此步骤——此时应继续执行步骤 8。

步骤 8：实时资源评估（可选）

仅当用户提供了凭证、区域和资源标识符时，才执行此步骤。 如果用户未提供这些信息，则完全跳过此步骤。

有关各服务评估流程的详细说明，请参阅 references/assessment-workflow.md。总体流程如下：

8.1 准备环境

如果用户提供了凭证文件路径（例如，env.sh），请加载该文件：

source <credential-file-path>

对目标服务和区域运行简单的 describe 命令，以验证访问权限。

8.2 收集资源配置

运行特定于服务的 AWS CLI 命令，收集目标资源的完整配置。 并行执行互不依赖的命令，以节省时间。

对于 ElastiCache Redis，关键命令包括（完整列表请参阅 references/assessment-workflow.md）：

• aws elasticache describe-replication-groups
• aws elasticache describe-cache-clusters --show-cache-node-info
• aws elasticache describe-cache-subnet-groups
• aws elasticache describe-cache-parameters
• aws elasticache list-tags-for-resource
• aws elasticache describe-snapshots
• aws elasticache describe-events

对于其他服务，请使用对应的 describe/list 命令。

8.3 将配置映射到检查清单

对于检查清单中的每个检查项，确定评估状态：

状态	含义
🟢 PASS	资源配置达到或超过建议要求
🔴 FAIL	资源配置未达到建议要求
🟡 WARN	仅凭基础设施无法完全验证（例如，客户端设置），或仅部分符合建议要求
⚪ N/A	此检查不适用于该资源（例如，不需要跨区域灾难恢复时的 Global Datastore 检查）

对于每个检查项，记录：

• 检查 ID 和名称（来自检查清单）
• 评估状态（PASS / FAIL / WARN / N/A）
• 描述观察结果的具体发现（包括实际值）

8.4 生成评估报告

使用 references/output-template.md 中定义的格式生成评估结果，然后使用 Write 工具将其写入本地 Markdown 文件。

**如果提供了目标资源，这是唯一的输出文件。**评估报告内容完整，并包含所有清单信息（Description、Source、Priority）以及评估结果。不要生成单独的清单文件。

文件命名：YYYY-mm-dd-HH-MM-SS-{RESOURCE_ID}-assessment-report.md

• 将 YYYY-mm-dd-HH-MM-SS 替换为当前时间戳（例如：2025-07-15-14-30-00）
• 将 {RESOURCE_ID} 替换为实际的资源标识符，使用小写字母，并以连字符分隔
• 示例：2025-07-15-14-30-00-my-redis-cluster-assessment-report.md
• 将文件保存到当前工作目录

报告必须包括：

1. 资源摘要 — 被评估资源的关键属性（引擎、版本、节点类型、拓扑等）
2. 按类别划分的评估结果 — 每个类别一个表格，包含完整的清单列（Check Item、Description、Source、Priority）以及评估列（Status、Finding）
3. 评估摘要 — 按类别统计 PASS/FAIL/WARN/N/A 的数量
4. 严重问题 — 列出所有 Priority=High 的 FAIL 项，并提供具体的修复指导
5. 建议 — 按紧急程度分组（Immediate / Short-term / Medium-term）
6. 来源注释 — 来源缩写说明
7. 关键参考链接 — 所用的文档页面

写入文件后，告知用户文件路径。

8.5 提供修复建议

呈现评估结果后，建议用户：

• 哪些 FAIL 项可以就地修复（例如，启用备份、添加标签）
• 哪些 FAIL 项需要重新创建资源（例如，静态加密）
• 你是否可以帮助执行修复命令

重要指南

• 全面评估：广泛搜索，深入阅读。这项技能的价值在于完整性。 宁可纳入某项检查并将其标记为较低优先级，也不要遗漏。
• 始终注明来源：每项检查都必须附带来源注释。 用户需要了解每条建议的依据。
• 始终按顺序请求：所有搜索和页面读取都必须逐一按顺序执行。切勿并行发送多个 aws knowledge mcp server 请求。 MCP 服务有速率限制，并发请求会因 "Too many requests" 错误而被拒绝。按顺序执行虽然较慢，但更可靠。
• 防止触发速率限制：如果任何 MCP 请求返回 "Too many requests" 错误，等待 5 秒后重试同一请求一次。如果第二次仍然失败，则跳过该请求并继续下一步。每个请求最多重试一次。
• 侧重可操作的检查项：每项检查都应当能让用户对照实际配置进行验证。避免含糊的建议。
• 包含具体阈值：如果文档规定了数值（例如，“至少 2 个副本”、“reserved-memory-percent >= 25%”），请在检查描述中注明。
• 注明服务特有的注意事项：如果某项检查仅适用于特定条件（例如，“仅在启用集群模式时”），请在描述中注明。
• 实时评估为可选项：用户未提供凭据时，绝不要因此失败或中止。仅清单本身就是完整且有价值的交付内容。
• 遵循语言要求：始终使用与用户对话相同的语言输出。