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 つの検索クエリを1 つずつ、順番に実行します。 並列で実行しないでください。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 秒待ってから 1 回再試行します。再試行でも失敗した場合は、そのクエリをスキップして次のクエリに進みます。

ステップ 3：主要なドキュメントページを読む

検索結果から最も重要なページを特定し、aws___read_documentation を使用して1 ページずつ、順番に読み込みます。レート制限を避けるため、複数のページを並列で読み込まないでください。以下の種類のドキュメントを優先します。

1. 対象サービスの Well-Architected Lens ページ（信頼性、セキュリティ、パフォーマンス、運用上の優秀性の柱）
2. 公式のベストプラクティスページ
3. レジリエンス／災害復旧ページ
4. ベストプラクティス全般のページ

包括的な内容を取得するため、各ページを max_length: 15000 で読み込みます。通常、3～5 ページを読み込む必要があります。

対象サービスの Well-Architected Lens がある場合、それは最も価値の高い単一の情報源です。必ず読み込んでください。

ステップ 4：チェック項目の抽出と分類

収集したすべてのドキュメントから個々のチェック項目を抽出し、5 つの必須カテゴリに分類します（正確な形式については references/output-template.md を参照してください）。

カテゴリ 1：高可用性アーキテクチャ 対象項目：クラスター モード、レプリケーション、シャードあたりのレプリカ数、マルチ AZ、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 による管理、Auto Scaling、コストタグ、クライアントの再試行ロジック、パフォーマンスチューニング、運用のベストプラクティス。

コンテナ／オーケストレーションプラットフォームのスコープ境界

対象サービスがコンテナまたはオーケストレーションプラットフォーム（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 Disruption Budget（PDB）
ノードグループの設定（インスタンスタイプ、スケーリング、AMI、AZ の分散、ディスクサイズ）	Topology Spread Constraints
クラスターのネットワーク（VPC、サブネット、セキュリティグループ、サービス CIDR）	Liveness／readiness／startup プローブ
アドオンの有無とバージョン（VPC CNI、CoreDNS、kube-proxy、EBS CSI など）	コンテナのリソース要求／上限
シークレットのエンベロープ暗号化（KMS キー）	Pod の securityContext（runAsNonRoot、capabilities）
認証モード（ConfigMap と API のどちらか）および Access Entries	Pod Security Admission（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. カテゴリごとに1つの表（計5つ）
3. ソース注釈の凡例
4. 主な参考リンクのセクション

ファイルを書き込んだ後、ユーザーにファイルパスを伝えます。

ライブ評価情報が提供されている場合 → チェックリストを省略し、ステップ8に進む

別個のチェックリストファイルは生成しないでください。評価レポート（ステップ8）には、評価結果を含む完全なチェックリストが1つの包括的なドキュメントとして含まれます。両方を生成すると内容が重複します。

ステップ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	このリソースには該当しないチェックです（例：リージョン間の DR が不要な場合の 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）を加えた表を1つ作成
3. 評価の概要 — カテゴリごとの PASS／FAIL／WARN／N/A の件数
4. 重大な問題 — Priority=High のすべての FAIL 項目と、具体的な修正方法の一覧
5. 推奨事項 — 緊急度（Immediate／Short-term／Medium-term）ごとに分類
6. ソース注釈 — ソース略語の凡例
7. 主な参照リンク — 使用したドキュメントページ

ファイルを書き込んだ後、ユーザーにファイルパスを伝えてください。

8.5 修正の提案

評価結果を提示した後、次の内容を提案してください。

• その場で修正できる FAIL 項目（例：バックアップの有効化、タグの追加）
• リソースの再作成が必要な FAIL 項目（例：保存時の暗号化）
• 修正コマンドの実行を支援できるかどうか

重要なガイドライン

• 網羅的に確認する：幅広く検索し、十分に読み込んでください。このスキルの価値は網羅性にあります。 チェック項目を見落とすよりも、項目を含めて優先度を低く設定する方が適切です。
• 必ず出典を引用する：すべてのチェック項目にソース注釈を付けてください。 それぞれの推奨事項の根拠をユーザーが確認できるようにします。
• リクエストは必ず順番に実行する：検索とページの読み取りはすべて、1つずつ順番に実行してください。複数の aws knowledge mcp server リクエストを並列で送信しないでください。 MCP サーバーにはレート制限があり、同時リクエストは「Too many requests」エラーで拒否されます。順次実行は遅くなりますが、確実です。
• レート制限への対処：MCP リクエストが「Too many requests」エラーを返した場合は、5 秒待ってから同じリクエストを1回再試行してください。2回目も失敗した場合は、そのリクエストをスキップして次の手順に進んでください。リクエストごとの再試行は1回までとします。
• 実行可能な項目に重点を置く：各チェック項目は、ユーザーが実際の設定と照らし合わせて確認できる内容にしてください。曖昧な推奨事項は避けてください。
• 具体的な基準値を含める：ドキュメントに数値（例：「レプリカを2つ以上」「reserved-memory-percent >= 25%」）が記載されている場合は、チェックの説明に含めてください。
• サービス固有の注意点を記載する：チェックが特定の条件でのみ適用される場合（例：「クラスター モードが有効な場合のみ」）は、その条件を説明に記載してください。
• ライブ評価は任意です：ユーザーが認証情報を提供しなくても、失敗したりブロックしたりしないでください。チェックリストだけでも、完全で価値のある成果物になります。
• 言語を遵守する：常にユーザーとの会話と同じ言語で出力してください。