aws-resilience-lifecycle

AWS Resilience Lifecycle

概要

3 つの AWS サービスにまたがる、統合されたレジリエンスライフサイクルに関するドメイン知識です。 Define（Resilience Hub v2 — NGRH（New Generation Resilience Hub）とも呼ばれます）→ Test（FIS）→ Operate（ARC）。

用語: このスキルでは、修飾語なしの「Resilience Hub」は常に v2（NGRH / New Generation Resilience Hub、CLI 名前空間 aws resiliencehubv2）を指します。v1（aws resiliencehub）は、移行に関する場合に限り、明示的に参照します。

このスキルの AWS API 呼び出しの実行には AWS MCP サーバーを推奨しますが、必須ではありません。すべての操作は AWS CLI から直接実行することもできます。

ガードレール — このスキルのファイルの保存場所（MCP とローカルインストール）

参照ファイルを読む前に、このスキルがどのように読み込まれたかを確認してください。

• AWS MCP の retrieve_skill ツール経由で読み込まれた場合: スキルの参照ファイルはローカルファイルシステム上にありません。file パラメーターを指定して retrieve_skill 経由で取得してください（例：file="references/lifecycle-workflow.md" または file="references/api-reference.md"）。これらのパスをローカルで file_read したり、ファイルシステム内で検索したりしないでください。
• ローカルにインストールされている場合（例：.kiro/skills/aws-resilience-lifecycle/ または ~/.claude/skills/aws-resilience-lifecycle/）：ここに示す相対パスを使用して、ローカルのスキルディレクトリから参照ファイルを読んでください。

これはスキル自体の参照ファイルにのみ適用されます。ユーザーまたはセッションのデータは、必ず作業ディレクトリで読み書きし、retrieve_skill 経由では扱わないでください。

ライフサイクル全体を実行する

3 つすべてのサービスにわたってエンドツーエンドのレジリエンスを実装するには、手順に正確に従ってください。 references/lifecycle-workflow.md を参照してください。

運用パターンとポリシー設計のガイダンスについては、 references/best-practices.md を参照してください。

解決済みにする前に検出結果を検証する

フォールトインジェクションで修正を検証せずに NGRH の検出結果を解決済みにすると、形式だけのコンプライアンスになります。これは意図を記録するだけで、レジリエンスを証明するものではありません。各修正について、検出結果を解決済みにする前に、障害モードを再現する実験で必ず検証してください。実験を実行し、システムが目標の範囲内で復旧することを確認してから、解決済みにします。先に解決済みにして「後で」検証するのは、避けるべきアンチパターンです。

モニタリングと可観測性

ユーザーがレジリエンスのために必要なモニタリング／可観測性について尋ねた場合、CloudWatch アラーム、ダッシュボード、メトリクス設計の情報源として、関連する AWS Observability スキルを推奨してください。ここで可観測性の設定内容を重複して説明しないでください。レジリエンスの範囲にとどめ、可観測性がライフサイクルにどう組み込まれるかを説明してください。

• FIS の停止条件: CloudWatch アラームは実験の停止条件として機能し、影響範囲を限定します。
• 実験後の分析: アラームの基となるメトリクスを使って実際の RTO を測定し、実験後に連鎖的な障害を検出します。

アラーム／ダッシュボードの「設定方法」については AWS Observability を推奨し、ガイダンスでは、それらのシグナルを Define → Test → Operate にどう活用するかに焦点を当ててください。

API リファレンス（AWS CLI コマンドを作成する前に必ず最初に読む）

NGRH（resiliencehubv2）、FIS、ARC の正確な AWS CLI オペレーション名とパラメーターは、references/api-reference.md に記載されています。このファイルには、よくある誤った API 名を正しい名前に対応付けた、ハルシネーション防止の表が含まれています。これらのサービスのコマンドを生成する前に、必ず参照してください。

トラブルシューティング

どこから始めればよいかわからない

Define から始めます。ポリシーを作成し、サービスを登録して、評価を実行してください。検出結果から、何をテストするか（FIS）、何を運用に組み込むか（ARC）が明確になります。

検出結果は解決済みだが、レジリエンスに確信が持てない

FIS による検証を行わずに検出結果を解決済みにするのは、形式だけのコンプライアンスです。実際の障害条件下で、アーキテクチャが RTO／RPO の目標範囲内で復旧することを証明する実験を実行してください。

FIS の実験は成功するのに本番環境では依然として失敗する

実験が実際の障害モードと一致しないことがあります。影響範囲を広げ、複数障害のシナリオを追加し、停止条件が本番環境の SLO と一致するようにしてください（緩和されたテストしきい値ではなく）。

セキュリティに関する考慮事項

• 最小権限: このライフサイクルが関与するすべての IAM ロール（Resilience Hub 呼び出し元ロール、FIS 実行ロール、ARC オペレーター）を、* やフルアクセスポリシーではなく、必要なアクションとリソースのみにスコープを絞ってください。
• 保存時 / 転送時の暗号化: 評価レポートと Terraform の state を保持する S3 バケットでは、サーバー側暗号化（SSE-KMS）と、aws:SecureTransport による TLS を強制するバケットポリシーの使用を推奨します。
• 本番環境での FIS: 障害注入は特権的で、破壊的になる可能性のある操作として扱ってください — 本番環境に対して実験を実行する前には変更管理の承認を必須とし、常に停止条件で影響範囲を制限してください。
• API の文字列フィールドに機密データを含めない: 検出事項のコメント、実験の説明、アサーションのテキスト、レポート名に PII、シークレット、内部アーキテクチャの詳細を埋め込まないでください — これらの値はログ、レポート、CloudTrail に現れ、読み取りアクセス権を持つ誰からも見える状態になります。
• 参考資料: このライフサイクルを保護するための信頼できるガイダンスについては、FIS セキュリティのベストプラクティス、IAM のベストプラクティス、および AWS Well-Architected セキュリティの柱を参照してください。