AWS認定資格 WEB問題集＆徹底解説セキュリティ専門知識（SCS）

会員登録/ログイン

1. サービス概要

AWS Fault Injection Service（AWS FIS、旧 AWS Fault Injection Simulator）は、AWS 上のワークロードに意図的に障害を発生させ、システムがどう振る舞うかを観察するためのフルマネージドなカオスエンジニアリングサービスです。 インスタンス停止、AZ 障害、ネットワーク遮断、API エラーなどを再現し、設計どおりに検知・自動復旧できるかを確かめます。

2023年11月に Fault Injection Simulator から改称されました（略称 FIS と API 名前空間 fis、AWS 管理ポリシー名 AWSFaultInjectionSimulator* は従来どおり）。 旧名に「Simulator」とありますが、実際の AWS リソースに対して本物の操作を行う点が重要です。そのため本番で使う前に計画を立て、ステージング環境で試すことが推奨されています。 DOP-C02 では回復性の検証手段として、SCS-C03 ではインシデント対応計画の有効性をテストする手段（Resilience Hub と並んで）として位置付けられています。

2. 主な特徴と機能

2.1 実験テンプレート

実験の設計図が実験テンプレートです。アクション（何をするか）、ターゲット（どのリソースに）、停止条件（いつ中止するか）、FIS が引き受ける IAM ロール、ログ出力先をまとめて定義し、同じ実験を何度でも再実行できます。

2.2 用意されている障害アクション

EC2 インスタンスの停止・終了・再起動、スポットインスタンスの中断通知、EBS の I/O 一時停止や I/O 遅延、サブネット単位の通信遮断、RDS / Aurora のフェイルオーバーや再起動、ElastiCache の AZ 電源断、DynamoDB グローバルテーブルや S3 のレプリケーション一時停止、ECS タスク・EKS Pod への CPU / メモリ / ネットワーク障害、Lambda 呼び出しへの遅延・エラー注入、EC2 API へのスロットリングやエラー注入、Direct Connect 仮想インターフェイスの BGP 切断などがあります。 Systems Manager ドキュメント（例: AWSFIS-Run-CPU-Stress）を使えば OS 内部の CPU 負荷やディスク逼迫も再現できます。

2.3 停止条件

停止条件には CloudWatch アラームを指定します。顧客影響の代理指標（ALB の 5xx 率やレイテンシーなど）がしきい値を超えると実験が自動で中止され、元に戻せるアクションは巻き戻されます。安全に実験するための中核の仕組みです。

2.4 シナリオライブラリ

複数のアクションを組み合わせた既製シナリオを利用できます。代表例は「AZ Availability: Power Interruption」（1 つの AZ の電源断を、EC2・EBS・RDS・ElastiCache・ネットワークなどにまたがって再現）と「Cross-Region: Connectivity」（リージョン間通信の遮断）です。

2.5 マルチアカウント実験と安全レバー

オーケストレーター用アカウントから複数のターゲットアカウントにまたがる実験を実行できます。 また安全レバー（safety lever）を使うと、アカウント内で実行中の実験をまとめて停止し、新しい実験の開始も止められます。

2.6 可観測性と自動化

実験ログを CloudWatch Logs または S3 に出力でき、実験の状態変化は EventBridge イベントとして通知されます。実験スケジューラーで定期実行でき、CloudWatch ダッシュボードの内容を含む実験レポートも生成できます。 AWS Resilience Hub が推奨するテストの実行基盤でもあり、ARC のゾーンオートシフトが AZ 電源断で機能するかの検証にも使われます。

3. アーキテクチャおよび技術要素

1. 定常状態を表す指標（成功率・レイテンシーなど）と「障害が起きても指標は保たれる」という仮説を決める。
2. 実験テンプレートでターゲットを選ぶ。リソース ARN、タグ、フィルタで指定し、選択モード（ALL、COUNT(n)、PERCENT(n)）で影響範囲を絞る。
3. アクションと継続時間を定義する。startAfter で順序を付ければ直列、指定しなければ並列に実行される。
4. 停止条件の CloudWatch アラーム、実験用 IAM ロール、ログ出力先を設定する。必要なら actions mode を skip-all にしてターゲットだけを事前確認する。
5. 実験を開始し、CloudWatch ダッシュボードやアラームでアプリケーションの反応を観察する。
6. 完了または停止後、ログ・レポートを分析して設計や運用手順を改善し、再実験する。

4. セキュリティと認証・認可

• 実験ロール: FIS はテンプレートに指定された IAM ロールを引き受けてアクションを実行する。サービスごとの AWS 管理ポリシー（例: AWSFaultInjectionSimulatorEC2Access）を基に最小権限で設計する。
• 実行者の権限: fis:CreateExperimentTemplate や fis:StartExperiment を IAM で制御し、タグ条件で実行できるテンプレートを限定する。
• 影響範囲の制限: ターゲットをタグや選択モードで絞り、停止条件を必ず設定する。安全レバーで緊急停止できるようにしておく。
• SSM 連携: Systems Manager ドキュメントを使うアクションでは、対象インスタンスに SSM Agent と必要な権限が要る。
• マルチアカウント: 各ターゲットアカウントに FIS が引き受けるロールを用意し、オーケストレーターアカウントから信頼させる。
• 監査: FIS の API 呼び出しと、FIS が実行した操作は CloudTrail に記録される。実験ログも証跡として保管できる。

5. 料金形態

FIS はアクションの実行時間（アクション分）で課金されます。前払いや最低料金はありません。

• アクション分: 1 アクション分あたり 0.10 USD（GovCloud を除く）。例: 3 つのアクションを各 10 分実行すると 30 アクション分。
• マルチアカウント実験: 追加のターゲットアカウント 1 つにつき、アクション分あたり 0.10 USD が加算される。
• 実験レポート: レポート 1 件ごとに課金される。
• その他: 停止条件のアラーム、ログ、ダッシュボード、対象リソース自体の利用料は各サービスの料金体系に従う。

6. よくあるアーキテクチャ・設計パターン

• AZ 障害訓練: シナリオライブラリの AZ 電源断で、ALB のヘルスチェックによる切り離しと Auto Scaling グループの補充、Aurora のフェイルオーバーを確認する。
• パイプラインへの組み込み: リリース前にステージングで実験を自動実行し、停止条件のアラームが発報したらデプロイを止める。
• ゲームデー / インシデント対応訓練: 障害を注入して、検知アラーム → 通知 → Systems Manager Automation による自動復旧の一連が手順どおりに動くか、復旧時間を測る。
• Resilience Hub との連携: Resilience Hub の評価で推奨された実験を実行し、推定した RTO が実際に達成できるかを確かめる。
• API スロットリング耐性: EC2 API へのスロットリングを注入し、リトライと指数バックオフの実装を確認する。
• スポット中断耐性: 中断通知を送り、ワークロードが安全に退避できるかを確認する。

7. 設定・デプロイ手順（ハンズオン例）

1. FIS が引き受ける IAM ロールを作成し、AWSFaultInjectionSimulatorEC2Access などの管理ポリシーを付与する。
2. 停止条件にする CloudWatch アラーム（例: ALB の HTTPCode_ELB_5XX_Count がしきい値超過）を作成する。
3. FIS コンソールで実験テンプレートを作成し、アクション aws:ec2:stop-instances、ターゲット（タグ Env=staging、選択モード COUNT(1)）、停止条件、ログ出力先を設定する。
4. 実験を開始し、Auto Scaling グループがインスタンスを置き換えるまでの時間と、アラーム・ダッシュボードの変化を観察する。
5. 実験ログとレポートを確認し、置き換え時間やアラームのしきい値を見直す。
6. テンプレートを CloudFormation でコード化し、実験スケジューラーやパイプラインから定期実行する。

8. 試験で問われやすいポイント