AWS Fault Injection Service

AWS Fault Injection Service（FIS）は、AWS 上のシステムに対して意図的に障害を注入し、その回復性（レジリエンス）を検証するためのマネージドなカオスエンジニアリングサービスです。インスタンスの停止や CPU・メモリ負荷、API のスロットリング、ネットワーク遅延といった現実に起こり得る障害を制御された形で再現し、システムが設計どおりに耐え、回復できるかを実際の挙動で確かめられます。

解決する課題

冗長化やフェイルオーバーの仕組みは、設計図やレビューだけでは本当に機能するか分かりません。アベイラビリティーゾーンの障害、依存サービスの遅延、インスタンスの突然死といった事象は本番でこそ起きますが、そのときに初めてフェイルオーバーの不備やタイムアウト設定の誤り、アラートの欠落が露呈するのでは手遅れです。こうした弱点を事前に、安全な条件下であぶり出したいという要求があります。

FIS は障害そのものをサービスとして提供し、どの対象にどの障害をどれだけの強さ・時間で与えるかを宣言的に定義して実行します。実験には停止条件やガードレールが組み込まれており、想定を超える影響が出たら自動で中断できます。これにより、再現性のある形で「壊して学ぶ」サイクルを回し、回復性の仮説を検証して継続的に改善できます。

主要概念と用語

• 実験テンプレート: 実験の設計図。どの対象に、どのアクションを、どのような順序・条件で実行するかを定義する再利用可能な定義。
• アクション: 注入する障害の単位。インスタンスの停止や再起動、CPU・メモリ・ディスクへの負荷、API のスロットリング、ネットワーク遅延やパケットロスなどが用意されている。
• ターゲット: アクションを適用する対象のリソース。タグやリソース ID、フィルター条件で特定し、対象集合からランダムに一定数・一定割合を選ぶといった指定もできる。
• 停止条件: 実験を安全に中断するためのトリガー。あらかじめ用意した CloudWatch アラームがアラーム状態になると、実験を即座に止めて影響の拡大を防ぐ。
• 実験: テンプレートを実際に実行した一回分のインスタンス。開始・進行・完了・停止といった状態を持ち、結果やログが記録される。
• アクションパラメータ: アクションの挙動を細かく調整する値。障害を与える時間（duration）や負荷の強さ、遅延のミリ秒数などを指定する。
• ガードレール: 実験の暴走を防ぐ安全装置の総称。停止条件、対象の絞り込み、IAM による権限の限定、実行時間の上限などが該当する。

仕様・制限・クォータ

• アクションは AWS が提供する組み込みのカタログから選び、対応するサービスや障害の種類は段階的に拡張されている。代表的には EC2、ECS、EKS、RDS、ネットワーク関連などの障害を注入できる。
• 多くのアクションは Systems Manager（SSM）と連携して実装される。インスタンス内部の CPU・メモリ負荷などはホスト上の SSM エージェント経由で与えられるため、対象が SSM で管理されている必要がある。
• 実験は IAM ロールを引き受けて対象リソースを操作する。注入できる障害の範囲はこのロールに付与された権限と、対象を特定するタグやフィルターによって厳密に制限される。
• 停止条件には事前に作成した CloudWatch アラームを関連付ける。アラームがアラーム状態に遷移すると実験は自動的に停止し、可能な範囲で対象を元の状態へ戻そうとする。
• 同時に実行できる実験の数や、テンプレート・ターゲット数などにはアカウント・リージョン単位のクォータがある。具体的な数値や対応アクションは時期・リージョンで変わり得るため、最新情報はサービスのドキュメントやサービスクォータの管理画面で確認する。

内部の仕組み

実験を開始すると、FIS はまず実験テンプレートの定義に従ってターゲットを解決します。タグやフィルターで指定された対象リソース群の中から、指定された数や割合に合致するものを選び出し、各アクションの適用先を確定します。続いて、テンプレートに記述されたアクションをその依存関係に従って順番に、あるいは並行して実行していきます。

アクションの実装方法はその種類によって異なります。インスタンスの停止や再起動、API のスロットリングのようなコントロールプレーン操作は AWS の API 呼び出しとして直接実行されます。一方、対象の内部状態に踏み込む CPU・メモリ負荷やネットワーク遅延などのアクションは、Systems Manager のドキュメントを通じてホスト上のエージェントに指示を送り、所定の時間だけ障害状態を維持します。

実験の実行中、FIS は停止条件として関連付けられた CloudWatch アラームを監視し続けます。いずれかのアラームがアラーム状態になると、FIS は進行中のアクションを止めて実験を停止し、注入した障害をできる限り解除しようとします。指定した時間が経過したアクションも自動的に終了するため、障害が無制限に続くことはありません。実験の各段階や結果は記録され、後から検証や改善に活用できます。

設計パターン / ベストプラクティス

• 仮説を先に立ててから実験する。「単一 AZ が落ちても多 AZ 構成のサービスは継続するはず」といった明確な期待値を定義し、それを反証する形で障害を注入して結果と照らし合わせる。
• まず小さく、隔離された非本番環境から始める。対象を絞り、影響範囲と障害の強さを段階的に広げながら、本番に近い環境へと慎重に進める。
• 必ず停止条件を設定する。主要なエラー率やレイテンシ、ヘルスチェックを表す CloudWatch アラームを停止条件に紐づけ、想定外の悪化が起きたら自動で実験が止まるようにする。
• ターゲットはタグとフィルターで厳密に絞り込み、IAM ロールには注入したい障害に必要な最小限の権限だけを与えて、誤って広範囲へ影響が及ばないようにする。
• 実験を再現可能なテンプレートとして管理し、定期的に繰り返す。コードとして定義してパイプラインや定期実行に組み込めば、回復性の検証を継続的な営みにできる。

運用・監視

実験の進行状況と結果は FIS のコンソールや API で確認でき、どのアクションがいつ実行され、成功・失敗・停止のいずれに至ったかを追跡できます。実験開始から完了・停止までのイベントは EventBridge へ送れるため、通知や後続処理の起動と連携させられます。

実験の本当の価値は、注入した障害に対してシステム側がどう振る舞ったかを観測することにあります。CloudWatch のメトリクスやアラーム、アプリケーションのログ、分散トレースなどを併せて見て、フェイルオーバーが想定どおり働いたか、エラー率やレイテンシがどこまで悪化したか、アラートが正しく上がったかを評価します。実験前後で監視ダッシュボードを比較できるよう、観測の仕組みを整えてから実験に臨むのが実務的です。

コスト

FIS の料金は、実行した実験のアクションが障害を注入していた時間に基づいて課金される従量制が基本です。アクションが対象に作用していた時間の長さに応じて費用が発生するため、長時間にわたる実験や同時に多数の対象へ作用する実験ほどコストは大きくなります。

加えて、実験に伴って動くリソースの費用も考慮が必要です。たとえば Blue/Green 的に立ち上げた検証用環境や、障害で再起動・再作成されたインスタンス、追加で発生したデータ転送などは別途の実リソース課金になります。コストを抑えるには、実験時間を必要十分な範囲に収め、対象を絞り、検証目的を達したら速やかに終了させるのが有効です。具体的な料金はリージョンや構成で変わるため、見積もりは料金計算ツールで確認してください。

セキュリティ

FIS の権限は IAM で厳密に制御します。実験は指定した IAM ロールを引き受けて対象リソースを操作するため、このロールに付与する権限がそのまま注入できる障害の範囲になります。最小権限の原則に従い、実験で本当に必要なアクションと対象だけに権限を限定することが、誤操作や影響の予期せぬ拡大を防ぐ最重要の防御線です。

障害を注入できる能力は強力であり、不正に悪用されれば意図的なサービス妨害の手段にもなり得ます。そのため、誰がどの実験テンプレートを作成・実行できるかを IAM ポリシーで限定し、本番に影響し得る実験の操作は限られた担当者と承認フローに紐づけるのが望ましい運用です。実験の実行は CloudTrail に記録されるため、いつ誰が何を実行したかを監査できるようにしておきます。

Well-Architected の観点

信頼性の柱において、FIS はまさに中核となるサービスです。設計上の冗長化やフェイルオーバーが実際に機能するかを、想定のままにせず障害注入で検証できるため、回復性の仮説を事実で裏づけ、弱点を本番障害が起きる前に発見して改善できます。多 AZ 構成や自動復旧、スロットリング耐性といった信頼性の作り込みは、FIS による継続的な検証とセットで初めて確かなものになります。

運用上の優秀性の面では、実験をテンプレートとしてコード化し再現可能な形で繰り返せる点が強みです。EventBridge との連携で結果を通知・自動化に流し込めば、回復性検証を運用サイクルに組み込めます。セキュリティの観点では IAM の最小権限と承認・監査が要であり、コスト最適化では実験時間と対象を必要十分に絞ることが基本になります。

試験で問われるポイント

関連サービス・比較

混同されやすいのが、システムの回復性を分析・推奨する AWS Resilience Hub との違いです。Resilience Hub は構成を評価して回復性の目標に対するギャップや改善策を示す分析寄りのサービスで、FIS は実際に障害を注入して挙動を検証する実行寄りのサービスです。両者は補完関係にあり、Resilience Hub の評価結果を FIS の実験で実証する、という使い分けが理にかなっています。

ハンズオン / CLI例

以下は、実験テンプレートを作成し、それを実行して進行状況を確認する基本的な流れの例です。テンプレートの中身（対象タグ・アクション・停止条件・ロール）は環境に合わせて置き換えてください。停止条件には事前に作成済みの CloudWatch アラームを指定します。

# 実験テンプレートを作成（タグで対象を絞り、EC2 停止アクションと停止条件を定義）
aws fis create-experiment-template \
  --description "Stop tagged EC2 instances with a stop condition" \
  --role-arn arn:aws:iam::123456789012:role/FISExperimentRole \
  --stop-conditions source=aws:cloudwatch:alarm,value=arn:aws:cloudwatch:ap-northeast-1:123456789012:alarm:HighErrorRate \
  --targets '{"target-1":{"resourceType":"aws:ec2:instance","resourceTags":{"Env":"chaos"},"selectionMode":"COUNT(1)"}}' \
  --actions '{"stop-1":{"actionId":"aws:ec2:stop-instances","targets":{"Instances":"target-1"}}}' \
  --tags Name=stop-one-instance

# 作成したテンプレートを実行
aws fis start-experiment \
  --experiment-template-id EXTxxxxxxxxxxxxx

# 実験の進行状況を確認
aws fis get-experiment --id EXPxxxxxxxxxxxxx \
  --query "experiment.{State:state.status,Reason:state.reason}"