AWS Fault Injection Service（FIS）とは？カオスエンジニアリングの仕組み・実験テンプレート・料金と採用判断を実装者目線で解説

AWS Fault Injection Service（AWS FIS）は、稼働中のAWSワークロードに対してわざと障害を起こし、システムが想定どおり耐えられるかを検証するマネージドサービスです。カオスエンジニアリングの考え方に沿って、インスタンスの停止やネットワークの遮断といった「フォールト（障害）」を実験として安全に注入し、フェイルオーバーやアラートが本当に機能するかを本番に近い環境で確かめられます。この記事では、実験テンプレートを構成するアクション・ターゲット・停止条件の3要素、主要な障害注入アクションとシナリオライブラリ、IAM権限やIaCを含む実装手順、アクション時間ごとの料金、そして導入すべき要件と内製スクリプトで足りる見送り場面までを、実装者の目線で整理します。

まとめ：AWS FISの要点とカオスエンジニアリングでの位置づけ

FISの本体は、「どのリソースに（ターゲット）」「どんな障害を（アクション）」「どうなったら止めるか（停止条件）」を1つの実験テンプレートに宣言し、AWSがマネージドに実行してくれる仕組みです。EC2の停止、AZ単位のネットワーク遮断、Lambda関数へのエラー注入などを、手作業のスクリプトではなく再現可能な定義として回せます。障害を起こした結果として何が起きたかをCloudWatchで観測し、Auto Scalingやマルチリージョン構成が設計どおりに復旧するかを、実障害の発生を待たずに前もって確かめられる点が持ち味です。

導入が効くのは、フェイルオーバーや自動復旧の仕組みを組んだうえで「本当に切り替わるか」を定期的に検証したいときです。逆に、単一構成でそもそも冗長化していない段階なら、FISで壊す前に可用性設計とマルチAZ化を先に済ませるほうが順序として正しいです。料金はアクション1分あたりの従量課金で、前払いや最低料金はありません。実験設計から復旧構成の見直しまでの相談はAWSを含むインフラ構築で対応しています。

AWS FISとは何か：定義とカオスエンジニアリングの考え方

FISを理解する起点は、「障害は避けるもの」ではなく「起こして学ぶもの」という発想の転換です。予期しない障害が本番で起きてから慌てるのではなく、管理された条件下で意図的に障害を起こし、システムの反応を先に観測します。

マネージドな障害注入サービスとしてのFISと旧称Simulatorからの改称

AWS FISは、フォールトインジェクション（障害注入）実験を実行するためのマネージドサービスです。もともとは「AWS Fault Injection Simulator」という名称で提供され、その後「AWS Fault Injection Service」へ改称されました。頭字語のFISは共通で、旧名の資料や記事も同じサービスを指します。利用者は障害を起こす仕組みを自作せず、AWSが用意したアクション群を組み合わせるだけで、EC2やECS、RDSといった各サービスへ実験を仕掛けられます。

カオスエンジニアリングの基本的な定義とFISで確かめる検証の目的

カオスエンジニアリングとは、稼働中のシステムへ擬似的な障害を加え、実際の障害に耐えられる状態かどうかを検証する手法です。目的は障害を起こすこと自体ではなく、システムの回復力・信頼性・パフォーマンスの実態をつかむことにあります。「AZが1つ落ちてもサービスは継続するはず」という設計上の仮説を立て、FISで実際にその状況を作り、仮説どおり動くかを観測する——この仮説検証のループが、カオスエンジニアリングの骨格です。この考え方は事業の継続力を指すレジリエンスを、インフラの実装レベルに落とし込んだものと捉えられます。

実障害の監視（AWS障害情報）とFISによる意図的な検証の違い

混同しやすいのが、実際に発生したAWS側のアウテージを確認する話とFISの話です。AWSリージョンやサービスで起きた本物の障害を追う手段はAWS障害の確認方法で扱う受け身の監視で、こちらは「起きてしまった障害」への対応です。対してFISは、自分の意思で障害を起こす能動的な検証で、「起きる前の備え」を確かめます。前者は障害が起きたときの調べ方、後者は障害に強いかを平時に試す道具、と役割を分けて捉えると設計を誤りません。

FISの実験テンプレートの構成：アクション・ターゲット・停止条件の3要素

FISの実験は、実験テンプレート（experiment template）という定義に集約されます。テンプレートは3つの要素で組み立て、この3点を押さえればFISの設計はほぼ理解できます。

アクション（障害注入の内容）とターゲット（対象リソースの指定）

アクションは「何を起こすか」の指定で、インスタンスの再起動や停止、CPU負荷の付与、ネットワークの遮断などをカタログから選びます。ターゲットは「どのリソースに起こすか」の指定で、タグやリソースIDでEC2インスタンス群やECSクラスターを絞り込む形です。ターゲットの選び方には、条件に合う全リソースを対象にする方法と、そのうち一定数・一定割合だけをランダムに選ぶ方法があり、後者を使うと「10台中1台だけ落とす」といった部分的な障害を作れます。1つの実験に複数のアクションを並べ、順番や同時実行を組むことも可能です。

停止条件とCloudWatchアラームによる自動ロールバック

FISの安全装置が停止条件（stop condition）です。停止条件にはCloudWatchアラームを紐づけ、実験中にエラー率やレイテンシが定めたしきい値を超えたら、実験を自動で打ち切って障害注入を取りやめます。これにより「検証のつもりが本番を巻き込む」事態を仕組みで防げます。実運用では、監視ダッシュボードで見ている主要指標をそのままアラーム化し、停止条件へ結びつけておくのが定石です。実験を止めれば注入した障害は解除され、システムは元の状態へ戻ります。

実験テンプレートで指定するIAMロールと必要な操作権限の分離

FISは指定したIAMロールを引き受けて対象リソースを操作します。実験ロールには、注入するアクションが触れるサービスへの権限だけを与え、範囲を絞るのが前提です。誰が実験を開始できるか、どのリソースを対象にできるかをIAMポリシーで制御することで、破壊的な操作が意図しない範囲へ広がるのを抑えます。権限を最小限に切り出す設計は、本番環境で実験を回すうえでの土台になります。

FISが用意する主要な障害注入アクションとシナリオライブラリの全体像

FISが用意するアクションは、コンピュート・ネットワーク・サーバーレスと幅広い層をカバーします。個別のアクションを組む方法と、あらかじめ束ねられたシナリオを使う方法の両方があります。

EC2・ECS・EKS・RDSなどコンピュート層への障害注入

もっとも使われるのが、コンピュートリソースへの障害注入です。EC2インスタンスの停止・再起動・終了、CPUやメモリへの負荷付与（ストレステスト）、ECSタスクやEKSポッドの停止、RDSのフェイルオーバー誘発などを起こせます。たとえばAuto Scalingグループの一部インスタンスを停止し、残りで処理を継続しつつ新しいインスタンスが自動で補充されるかを観測する、といった検証が代表的です。データベースのフェイルオーバーを誘発して、アプリ側の再接続処理が想定どおり働くかも確かめられます。

ネットワーク遮断（disrupt connectivity）とAZ障害の再現

ネットワーク層のアクションでは、通信の遮断を注入できます。全トラフィックの遮断に加え、特定のAZ・VPC・プレフィックスリスト・サービス（Amazon S3やDynamoDBなど）への通信に限って遮断する、といった細かい指定が可能です。これを使うと「特定AZが到達不能になった」状況を再現し、マルチAZ構成が残るAZへ処理を寄せて継続できるかを試せます。単一障害点が隠れていないか、AZ間のフェイルオーバーが設計どおりかを、実際に切断してみて確かめる用途です。

Lambdaアクション・シナリオライブラリ・Resilience Hub連携

サーバーレス領域では、2024年10月にLambda関数を対象とするアクションが加わり、関数の呼び出しにエラーや遅延を注入できるようになりました。個別アクションを一から組むほかに、AWSが用意するシナリオライブラリ（Scenario Library）から、AZ障害やリージョン障害を再現する定義済みシナリオを選んで使う方法もあります。さらにAWS Resilience Hubと連携させれば、アプリケーションの構成に合わせた実験の推奨を受け取れ、どの障害を試すべきかの当たりをつけやすくなる点も利点です。これらの検証は、AWS Well-Architected フレームワークの信頼性の柱が説く「障害を想定した設計」を、実測で裏づける営みにあたります。

FISの実装手順：実験テンプレートの作成から実行・観測・振り返りまで

FISの実験は、コンソールの画面操作でもコードとしての定義でも組み立てられます。試作はコンソール、反復運用はIaCという役割分担が実務では収まりよく機能します。

実験用IAMロールの用意とタグを使った実験対象リソースの絞り込み

着手の第一歩は、実験用IAMロールの用意です。注入するアクションが必要とする権限（例：EC2の停止権限）と、停止条件でCloudWatchアラームを参照する権限をロールへ与えます。あわせて、対象リソースにはタグを付けておき、テンプレートのターゲット指定でそのタグを条件にします。本番リソースをうっかり巻き込まないよう、まずは検証用タグを付けた限定的な範囲から始めるのが安全な立ち上げ方です。

コンソール・CLI・IaCによる実験テンプレートの定義と管理

実験テンプレートは、マネジメントコンソールのフォーム、AWS CLI、あるいはCloudFormationやTerraformといったIaCツールで定義できます。アクション・ターゲット・停止条件をJSON構造で記述するため、定義そのものをバージョン管理下に置き、差分レビューや環境ごとの再現配布に載せられる仕組みです。初回はコンソールで組んで動きを掴み、繰り返し回す段階でIaCへ書き起こす流れにすると、手作業の取りこぼしを減らせます。定期的に同じ実験を走らせる運用は、コードとして管理してこそ回るものです。

実験の実行・CloudWatchでの挙動の観測と結果の振り返り

テンプレートができたら実験を開始し、注入と並行してCloudWatchのメトリクスやダッシュボードで挙動を観測します。見るべきは、エラー率・レイテンシ・復旧までの時間や、フェイルオーバーが発火したかどうかです。停止条件に触れれば実験は自動で止まり、そうでなければ設定した時間で終了します。実験後は「仮説どおり耐えたか」「想定外の連鎖障害はなかったか」を振り返り、見つかった弱点を構成やアラート設定の修正へ回します。この仮説→注入→観測→改善のサイクルを定例化することが、検証を一度きりで終わらせないコツです。

FISの料金体系：アクション時間ごとの従量課金とコスト試算の目安

FISの料金は、障害注入アクションを実行した時間に対して発生します。以下は2026年7月時点の米国東部（バージニア北部）リージョンの公開料金をもとにした概算で、実際の金額はリージョンや条件で異なります。

障害注入アクション1分あたりの従量課金と追加アカウントの課金

FISの課金単位は「アクション分（action-minute）」です。2026年7月時点の公開料金では、多くのリージョンでアクション1分あたり0.10ドル前後、追加のアカウントを対象に含める場合はそのアカウントごとにさらに0.10ドル前後が加算されます。GovCloud（US）ではアクション1分あたり0.12ドル前後と単価が上がります。前払い費用や最低料金はなく、実験を回した分だけの支払いです。

実験で動くAWSリソース側のコストはFISとは別勘定になる点

見落としやすいのが、FISの料金は「障害注入の制御」に対する課金にとどまる点です。実験の過程で再起動・再作成されたEC2やコンテナ、負荷試験で消費したリソース、観測に使うCloudWatchの費用は、通常どおり各サービスの料金として別に発生します。つまり総コストは「FISのアクション分課金＋巻き込んだリソースの稼働費」で見積もる必要があります。短時間のアクションを対象を絞って回すぶんには、FIS本体の課金は小さく収まりやすい設計です。

個々のアクションの実行時間から見たFIS本体のコスト試算の目安

FIS本体のコストはアクションの実行時間にほぼ比例します。単一アカウント・単一アクションを前提にした概算は次のとおりで、あくまでアクション分単価からの目安です。

FIS本体は少額に収まる一方、実験で動くリソース側の費用が主になりやすい構図です。試算では巻き込むリソースの稼働費を主役に据えて見積もると外しません。

FISを導入すべきワークロード要件と内製スクリプトで足りる見送り場面

ここは判断を言い切ります。FISは冗長化や自動復旧を組んだシステムでこそ効くツールで、壊す前に「壊れても大丈夫な構造」があることが導入の前提です。

FISの導入効果が高いワークロードの要件と導入判断のための基準

導入が効くのは、マルチAZやAuto Scaling、フェイルオーバーといった復旧の仕組みを既に組み、その仕組みが「本当に切り替わるか」を継続的に確かめたいときです。とくに、本番環境で停止条件付きの管理された実験を回したい、AZ障害やネットワーク遮断のような自作しづらい障害を安全に再現したい、という要件があるなら、FISの停止条件・自動ロールバック・IAM連携が直接効きます。障害対応の手順書やアラートが形骸化していないかを、定例の実験で棚卸しできる点も、運用チームを持つ組織ほど価値が出ます。

内製スクリプトで足りるケースと過剰投資になりやすい見送り場面

逆に見送るべき場面もあります。冗長化していない単一構成で、そもそも1台落ちれば止まる段階なら、FISで壊す前に構成の見直しが先です。ごくたまにインスタンスを手で1台止めて挙動を見る程度なら、AWS CLIやスクリプトを叩くだけで足り、テンプレート管理やアクション分課金を抱える必要はありません。停止条件やタグ設計、IAMロールを整える手間に見合うだけの反復と規模がなければ、FISは過剰投資に傾きます。まず可用性の土台を作り、検証を繰り返す段階に入ってから導入する、という順序が現実的です。

内製の障害注入スクリプトとマネージドなFIS利用との選択基準

自作スクリプトとマネージドのFISは、料金だけでなく安全性と再現性で比べる対象です。内製は課金こそ無い代わりに、暴走時の停止装置・権限分離・実験履歴を全て自前で用意し、保守まで抱える負担があります。FISはアクション分課金を払う代わりに、停止条件による自動ロールバックや対象の絞り込み、実験の再現性をサービス側が肩代わりする仕組みです。本番で管理された障害試験を回す規模になり、安全装置を自作するよりAWS基盤の設計支援とマネージド機能に寄せたほうが総コストと事故リスクが下がるなら、導入の判断が立ちます。

よくある質問

AWS Fault Injection Serviceの検討でよく挙がる疑問を、実装者の視点で簡潔に答えます。

AWS Fault Injection ServiceとFault Injection Simulatorは違うものですか？

同じサービスです。もともと「AWS Fault Injection Simulator」という名称で提供され、その後「AWS Fault Injection Service」へ改称されました。頭字語はどちらもFISで、旧名で書かれた資料や記事も現行の同じサービスを指します。機能面で別物になったわけではなく、名称の変更と機能追加が続いている関係です。

本番環境でFISの実験を実行しても安全ですか？

停止条件を正しく設定すれば、本番での実行を前提に設計されています。CloudWatchアラームを停止条件へ紐づけ、エラー率などが危険域に達したら自動で実験を打ち切り、注入した障害を解除できます。加えてIAMで対象範囲と実行者を絞り、まずは影響の小さいターゲットから段階的に広げる進め方が安全です。停止条件を設けずに実行するのは避けてください。

FISの料金はどのくらいかかりますか？

2026年7月時点の米国東部では、障害注入アクション1分あたり0.10ドル前後で、前払いや最低料金はありません。追加のアカウントを対象に含めるとアカウントごとに同額程度が加算され、GovCloud（US）では単価がやや上がります。ただしこれはFIS本体の課金で、実験で再起動・消費したEC2などのリソース費用は別に発生する点に注意してください。

FISで具体的にどんな障害を起こせますか？

EC2の停止・再起動・終了、CPUやメモリへの負荷、ECSタスクやEKSポッドの停止、RDSのフェイルオーバー誘発、ネットワークの遮断、Lambda関数へのエラー注入などが代表例です。ネットワーク遮断は特定のAZやサービス向け通信に限定でき、AZ障害の再現に使えます。AWSが用意するシナリオライブラリから、定義済みのAZ・リージョン障害シナリオを選ぶこともできます。

カオスエンジニアリングを始めるにはFISが必須ですか？

必須ではありませんが、AWS上で実験するなら有力な選択肢です。停止条件による安全装置や対象の絞り込み、AWSサービスとの連携がサービス側で用意されているため、自作の障害注入スクリプトより安全に始められます。まずは冗長化された構成を用意し、影響の小さいアクションを停止条件付きで試すところから着手するのが現実的な入口です。

関連記事

• AWS障害の確認方法と原因・対策：実際に発生したAWSアウテージを調べる受け身の監視。FISの能動的な検証との役割の違い
• AWS Well-Architected フレームワークとは：FISが裏づける「信頼性の柱」と障害を想定した設計の考え方
• 可用性とは：FISで検証する前提となる稼働率の計算とマルチAZ・高可用性の設計
• レジリエンスとは何か：FISが実装レベルで支える回復力という上位概念の整理