aws-fault-injection-service

AWS Fault Injection Service（FIS）実験

概要

AWS Fault Injection Service（AWS FIS）に関するドメイン知識です。AWS FIS は、実際の AWS リソースに対して制御されたフォールトインジェクション実験を実行するマネージド型のカオスエンジニアリングサービスです。アプリケーションが障害にどのように応答するかを観察し、レジリエンスを向上させることができます。

このスキルを使うと、エージェントは次の 3 つのことを行えます。

1. 適切な実験を提案する — ユーザーの障害シナリオやレジリエンスに関する質問を、適切な FIS アクション、シナリオ、または実験設計に対応づけ、トレードオフを説明します。
2. 実験を作成して実行する — 実験テンプレート（アクション、ターゲット、停止条件、ロギング、レポート）を作成し、実験用 IAM ロールを設定して、CLI、SDK、または CloudFormation を使って実行、監視、停止のライフサイクルを進めます。
3. ユーザーに情報を提供する — FIS の用語、安全性、料金、サポート対象サービス、レジリエンスプログラムにおける FIS の位置づけに関する概念的な質問に回答します。

AWS FIS は、実際の AWS リソースに対して実際のアクションを実行します。 本番環境で実験を実行する前に計画を立て、まず本番前環境で実行し、必ず停止条件を設定して影響範囲を制限してください。フォールトインジェクションは、権限を要する、潜在的に破壊的な操作として扱ってください。

このスキルの AWS API 呼び出しを実行するには、AWS MCP サーバーの使用を推奨します。サンドボックス化された実行と監査ログが提供されます。ただし、必須ではありません。すべての操作は AWS CLI（aws fis ...）から直接実行することもできます。

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

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

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

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

まずここから — リクエストの振り分け

• 「FIS とは何か／いつ使うべきか／X という用語の意味は何か／Y をサポートしているか？」 → references/fis-concepts.md を読んでください。
• 「障害モードをテストするには、どの実験／アクションを実行すべきか？」 → references/fis-actions-reference.md（アクションの選択マップと全カタログ）を読み、アクションまたはシナリオを提案してください。
• 「実験を作成／構築／実行する」（テンプレート、ターゲット、停止条件、ロギング、レポート、シナリオ、マルチアカウント、監視）→ references/fis-workflow.md に正確に従ってください。
• FIS に関する AWS CLI または API コマンド → まず references/fis-api-reference.md を参照してください。これは操作とパラメーターの正式なリファレンスであり、誤った API 名／アクション名と正しい名称を対応づける表も含まれています。
• IAM ロール、権限、信頼ポリシー、混乱した代理人の問題、影響範囲の安全性 → references/fis-security.md を読んでください。

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

aws fis の正確なオペレーション名とテンプレートのパラメーターは、references/fis-api-reference.md に記載されています。よくある誤った API 名／アクション名を正しい名称に対応づける表も含まれています。コマンドを生成する前に、必ずこのリファレンスを参照してください。 アクション ID とリソースタイプは変更されるため、記憶に頼らず、aws fis list-actions と aws fis get-action --id <action-id> で確認してください。

実験の提案（動作上の契約）

ユーザーが実行したいコマンドではなく、テストしたい障害について説明した場合：

1. 障害モード（AZ の機能低下、リージョンの分離、API エラー／スロットリング、コンピューティング／DB／キャッシュの喪失、レイテンシー、パケット損失、リソース枯渇）を特定します。
2. references/fis-actions-reference.md の選択マップを使って、対応するシナリオ（適合するものがあれば優先します。事前構築済みで AWS が管理しています）または具体的なアクションに対応付けます。
3. ターゲット（リソースタイプとスコープの設定方法）および停止条件（定常状態のメトリクスに対する CloudWatch アラーム）を示し、影響範囲を制限します。
4. まず本番前環境で実行し、その後、変更管理のもとで本番環境でも実行することを推奨します。
5. 実験テンプレートの生成を提案し、その後は references/fis-workflow.md に従います。

アクション ID、リソースタイプ、パラメーターをでっち上げないでください。不明な場合はその旨を伝え、aws fis list-actions／aws fis get-action または FIS のドキュメントで確認してください。

トラブルシューティング

「実験が直ちに失敗した／ターゲットが見つからない」

FIS は実験開始時にすべてのターゲットを解決します。ターゲットの解決結果がリソース 0 件の場合、実験は失敗します（emptyTargetResolutionMode が skip の場合を除きます）。タグ、フィルター、リージョン、アカウントを確認してください。実行前にターゲットのプレビューを使用してください（ワークフローのリファレンスを参照）。

「権限エラーによりアクションが失敗した」

FIS 実験 IAM ロールに、基盤となるサービス API（または SSM）の権限が不足しているか、混乱した代理人対策の信頼条件によって引き受けがブロックされています。references/fis-security.md を参照してください。

「実験が予期せず停止した」

停止条件（CloudWatch アラーム）が発動した可能性があります。これはガードレールが機能したことを示します。実験の state.reason とアラーム履歴を確認してください。停止した実験は再開できません。テンプレートから新しい実験を開始してください。

「EBS またはネットワーク障害のテストで Nitro／インスタンスタイプのエラーが発生する」

一部のアクションには Nitro ベースのインスタンスまたは SSM Agent が必要です。references/fis-actions-reference.md で、アクションごとの前提条件を確認してください。

オブザーバビリティの補足

FIS の停止条件と実験レポートを支える CloudWatch アラーム、ダッシュボード、メトリクスの設定には、アラーム／ダッシュボードのセットアップを行うAWS Observability スキルを推奨してください。このスキルのガイダンスは、それらのシグナルが実験の安全性と実験後の分析にどう役立つかに留めてください。

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

FIS は、実際の、潜在的に破壊的なアクションを実行します。重要な点は以下のとおりです（詳しくは references/fis-security.md を参照してください）。

• **最小権限：**実験ロールのスコープは、各実験に必要なアクションとターゲット ARN のみに設定し、* は決して使用しないでください。fis:StartExperiment の呼び出しを許可する人間／CI のプリンシパルも、スコープを限定してください。
• **混乱した代理人への対策：**実験ロールの信頼ポリシーには、aws:SourceAccount と aws:SourceArn（実験 ARN のパターンにスコープを限定）を条件として必ず含めてください。
• **影響範囲の制限：**CloudWatch アラームの停止条件を必ず設定してください。ターゲットを狭く（COUNT(1)／低い PERCENT）設定し、本番環境より先に本番前環境で開始してください。
• **文字列フィールドに機密データを含めない：**実験／テンプレートの説明、タグ、ログは、CloudTrail、CloudWatch Logs、S3 レポート、（マルチアカウントの場合は）ターゲットアカウントの Health ダッシュボードに表示されます。PII、シークレット、機密性の高いアーキテクチャの詳細を決して含めないでください。
• **ログ／レポートを暗号化する：**実験ログと PDF レポートから、レジリエンスの状況が明らかになります。S3 バケットで SSE-KMS を使用し、TLS を強制し、レポート用バケットでの S3 Object Lock の使用を検討してください。
• 関連資料：FIS Security と AWS Well-Architected Reliability Pillar を参照してください。