AWS FISで本番環境の耐障害性を検証する冗長設計テスト手順｜マルチAZ構成への応用

宮崎智広 この記事の監修：宮崎智広（Linux実務・教育歴20年以上・受講者3,100名超）
ＨＯＭＥ ＞ Linux技術 リナックスマスター.JP（Linuxマスター.JP） ＞ AWS(Amazon Linux) ＞ AWS FISで本番環境の耐障害性を検証する冗長設計テスト手順｜マルチAZ構成への応用
「マルチAZで冗長構成を組んだはずなのに、AZが1つ落ちたときに本当にフェイルオーバーするか確信が持てない」

設計書通りに構築して、構成図が整っていても、実際の障害時に正しく動作するかどうかは試してみないと分かりません。障害が起きて初めて「実は冗長化が機能していなかった」と発覚するケースは、AWSの現場でも珍しくありません。

この記事では、AWSが提供するマネージドのカオスエンジニアリングサービス AWS FIS（Fault Injection Simulator） を使って、本番に近い環境でEC2インスタンスの停止やRDSのフェイルオーバーを再現し、マルチAZ冗長設計の耐障害性を安全に検証する手順を解説します。実験テンプレートの作成からAWS CLIでの実行・結果分析まで、実際のコマンドと出力例を交えて紹介します。

この記事のポイント

・aws fis コマンドでEC2停止やRDSフェイルオーバーを安全に再現できる
・StopCondition（CloudWatchアラーム）で実験の暴走を防ぐ安全装置を付けられる
・フェイルオーバーのRTOをCloudWatchで実測し冗長設計の穴を発見できる
・EC2タグとAZフィルターで障害注入対象を細かく絞り込める


「このままじゃマズい」と感じていませんか？
参考書を開く気力もない、同年代に取り残される不安——
でも安心してください。プロのエンジニアはコマンドを暗記していません。
「現場で使える型」を効率よく使いこなしているだけです。
姓・名・メールの3つだけ／30秒／解除は3秒 ／ 詳細はこちら

AWS FISとは何か？カオスエンジニアリングで冗長設計の「穴」を見つける

AWS FIS（AWS Fault Injection Simulator）は、AWSがマネージドで提供するカオスエンジニアリングサービスです。カオスエンジニアリングとは、本番を想定した環境に意図的に障害を注入して、システムの耐障害性（レジリエンス）を検証・改善する手法です。

従来、マルチAZ構成の冗長性を検証するには次のような方法が使われていました。

・EC2インスタンスを手動で停止させて様子を見る
・テスト環境でAZを切り離すシミュレーションを行う
・本番障害が起きて初めて冗長化の穴を知る（最悪のパターン）

AWS FISを使えば、これらをテンプレートとして定義し、繰り返し再現可能な形で安全に実施できます。実験の対象リソース・実行するアクション・中断条件（StopCondition）をJSONで定義するだけで、本番稼働中のEC2・RDS・ECS・EKS等への障害注入が可能になります。

2022年のGA（一般提供）以降、ネットワーク障害インジェクション（パケットロス・レイテンシ追加）にも対応し、マルチAZ冗長設計の検証ツールとして実務での採用が広がっています。

マルチAZ構成でAWS FISを使う前の準備

1. IAMロールの作成

FIS実験にはFISサービスが対象リソースを操作するためのIAMロールが必要です。まず信頼ポリシーファイルを作成し、ロールを作成します。

# fis-trust-policy.json を作成する
$ cat > /tmp/fis-trust-policy.json << 'EOF'
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {"Service": "fis.amazonaws.com"},
      "Action": "sts:AssumeRole"
    }
  ]
}
EOF

# IAMロールを作成する
$ aws iam create-role   --role-name fis-experiment-role   --assume-role-policy-document file:///tmp/fis-trust-policy.json

{
    "Role": {
        "RoleName": "fis-experiment-role",
        "Arn": "arn:aws:iam::123456789012:role/fis-experiment-role",
        "CreateDate": "2026-10-04T05:30:00+00:00"
    }
}
次に、EC2・RDSを操作するための権限をロールにアタッチします。AWSマネージドポリシー AWSFaultInjectionSimulatorEC2Access と AWSFaultInjectionSimulatorRDSAccess を使うと最小権限で済みます。

# EC2操作権限をアタッチ
$ aws iam attach-role-policy   --role-name fis-experiment-role   --policy-arn arn:aws:iam::aws:policy/service-role/AWSFaultInjectionSimulatorEC2Access

# RDS操作権限をアタッチ
$ aws iam attach-role-policy   --role-name fis-experiment-role   --policy-arn arn:aws:iam::aws:policy/service-role/AWSFaultInjectionSimulatorRDSAccess

# アタッチ確認
$ aws iam list-attached-role-policies   --role-name fis-experiment-role   --query 'AttachedPolicies[].PolicyName'

[
    "AWSFaultInjectionSimulatorEC2Access",
    "AWSFaultInjectionSimulatorRDSAccess"
]

2. StopCondition用CloudWatchアラームの準備

FIS実験の最重要の安全装置がStopConditionです。CloudWatchアラームがALARM状態になった瞬間に実験を自動停止します。5XXエラー率やヘルスチェック失敗数などを監視するアラームを事前に作成しておきます。

【重要】StopConditionを設定しないと実験が計画外のリソースに波及するリスクがあります。本番環境での実験では必ず設定してください。

# ALBの5XXエラー数を監視するStopCondition用アラームを作成
$ aws cloudwatch put-metric-alarm   --alarm-name "FIS-StopCondition-5xxRate"   --metric-name HTTPCode_ELB_5XX_Count   --namespace AWS/ApplicationELB   --statistic Sum   --period 60   --evaluation-periods 2   --threshold 10   --comparison-operator GreaterThanThreshold   --dimensions Name=LoadBalancer,Value=app/my-alb/xxxxxxxxxx   --treat-missing-data notBreaching

# アラームARNを確認する
$ aws cloudwatch describe-alarms   --alarm-names "FIS-StopCondition-5xxRate"   --query 'MetricAlarms[0].AlarmArn'   --output text

arn:aws:cloudwatch:ap-northeast-1:123456789012:alarm:FIS-StopCondition-5xxRate

3. テスト対象EC2インスタンスへのタグ付け

FISはリソースをタグで絞り込めます。本番インスタンスの中でテスト対象にするものだけに FIS-Target: true タグを付けておくと、誤って全インスタンスに影響させるリスクを防げます。

# テスト対象インスタンスにFISターゲットタグを付ける
$ aws ec2 create-tags   --resources i-0123456789abcdef0   --tags Key=FIS-Target,Value=true

# タグ付けの確認
$ aws ec2 describe-tags   --filters "Name=resource-id,Values=i-0123456789abcdef0"             "Name=key,Values=FIS-Target"   --query 'Tags[0].Value'   --output text

true

AWS FIS実験テンプレートの作成と実行手順

1. EC2停止実験のテンプレートJSONを作成する

実験テンプレートはJSONで定義します。以下は「ap-northeast-1a内のFIS-Targetタグ付きEC2を10分間停止させる」テンプレートの例です。

# fis-ec2-stop-template.json を作成する
$ cat > /tmp/fis-ec2-stop-template.json << 'EOF'
{
    "description": "AZ-a EC2 stop test for multi-AZ failover validation",
    "targets": {
        "ec2-targets": {
            "resourceType": "aws:ec2:instance",
            "resourceTags": {"FIS-Target": "true"},
            "selectionMode": "ALL",
            "filters": [
                {
                    "path": "Placement.AvailabilityZone",
                    "values": ["ap-northeast-1a"]
                }
            ]
        }
    },
    "actions": {
        "stop-ec2": {
            "actionId": "aws:ec2:stop-instances",
            "parameters": {"startInstancesAfterDuration": "PT10M"},
            "targets": {"Instances": "ec2-targets"}
        }
    },
    "stopConditions": [
        {
            "source": "aws:cloudwatch:alarm",
            "value": "arn:aws:cloudwatch:ap-northeast-1:123456789012:alarm:FIS-StopCondition-5xxRate"
        }
    ],
    "roleArn": "arn:aws:iam::123456789012:role/fis-experiment-role"
}
EOF
startInstancesAfterDuration: PT10M は「停止後10分で自動的にインスタンスを再起動する」という設定です。PT10MはISO 8601の期間形式（P=Period・T=Time・10M=10分）で、実験の暴走防止に役立ちます。

2. aws fis create-experiment-templateでテンプレートを登録する


# テンプレートをFISに登録する
$ aws fis create-experiment-template   --cli-input-json file:///tmp/fis-ec2-stop-template.json   --query 'experimentTemplate.{id:id,description:description}'

{
    "id": "EXTb12c34d56e78f90",
    "description": "AZ-a EC2 stop test for multi-AZ failover validation"
}

# 登録済みテンプレート一覧を確認
$ aws fis list-experiment-templates   --query 'experimentTemplates[].{id:id,description:description}'

[
    {
        "id": "EXTb12c34d56e78f90",
        "description": "AZ-a EC2 stop test for multi-AZ failover validation"
    }
]

3. aws fis start-experimentで実験を開始する

実験開始前に、CloudWatchのダッシュボードを別ウィンドウで開いてリアルタイムでメトリクスを監視できる状態にしておきます。ALBのヘルスチェック結果・5XXエラー率・応答時間を同時に確認しながら進めてください。

# 実験を開始する
$ aws fis start-experiment   --experiment-template-id EXTb12c34d56e78f90   --query 'experiment.{id:id,status:status.status}'

{
    "id": "EXPc23d45e67f89a01",
    "status": "initiating"
}

# 実験の進行状況を確認する（数秒後）
$ aws fis get-experiment   --id EXPc23d45e67f89a01   --query 'experiment.{id:id,status:status.status,startTime:startTime}'

{
    "id": "EXPc23d45e67f89a01",
    "status": "running",
    "startTime": "2026-10-04T10:00:00.000000+00:00"
}

# 実験完了後の最終状態確認
$ aws fis get-experiment   --id EXPc23d45e67f89a01   --query 'experiment.status.status'   --output text

completed

マルチAZ冗長設計への応用テスト

1. EC2停止によるALBフェイルオーバーの検証

ALB（Application Load Balancer）のマルチAZ構成では、あるAZのEC2インスタンスが停止した際に、ALBが自動でそのインスタンスをヘルスチェック失敗と判断してルーティングを除外し、残りのAZのインスタンスへ切り替わることを確認します。

検証の鉄則は「フェイルオーバーが完了するまでの時間（RTO：Recovery Time Objective）を実測すること」です。以下のCloudWatchメトリクスを組み合わせてRTOを計測します。

・ALBの HealthyHostCount：ヘルシーなバックエンドインスタンス数の変化を追う
・ALBの UnHealthyHostCount：フェイルオーバー開始のトリガーとなるアンヘルシーカウント
・ALBの TargetResponseTime：応答時間の劣化をミリ秒単位で確認する

# 実験開始から5分間のヘルシーホスト数の変化を取得する
$ aws cloudwatch get-metric-statistics   --namespace AWS/ApplicationELB   --metric-name HealthyHostCount   --dimensions Name=LoadBalancer,Value=app/my-alb/xxxxxxxxxx               Name=TargetGroup,Value=targetgroup/my-tg/yyyyyyyyyy   --start-time 2026-10-04T10:00:00Z   --end-time 2026-10-04T10:05:00Z   --period 60   --statistics Average   --query 'sort_by(Datapoints,&Timestamp)[*].{Time:Timestamp,Count:Average}'   --output table

---------------------------------------------
|       GetMetricStatistics                 |
+---------------------------+---------------+
|           Time            |    Count      |
+---------------------------+---------------+
|  2026-10-04T10:00:00+00:00|    4.0        |
|  2026-10-04T10:01:00+00:00|    2.0        |
|  2026-10-04T10:02:00+00:00|    2.0        |
+---------------------------+---------------+
# 実験前: 4インスタンス（AZ-a x2、AZ-c x2）
# 実験後: 2インスタンス（AZ-c x2）→ AZ-aが除外され60秒以内にフェイルオーバー完了
ALBのヘルスチェック間隔（デフォルト30秒）×失敗閾値（デフォルト2回）= 最大60秒でフェイルオーバーが完了します。SLA要件として「60秒以内の復旧」が定められているシステムであれば、この構成でクリアできることを実証できます。

2. RDSマルチAZのフェイルオーバー時間を計測する

RDS Multi-AZは書き込みエンドポイントが自動でスタンバイインスタンスに切り替わりますが、切り替えに要する時間（一般的に1分～2分）を本番稼働前に実測しておくことが重要です。

AWS FISの aws:rds:failover-db-cluster アクションを使ったテンプレートを作成します。AWSのマルチAZ設計・冗長構成を体系的に習得したい方は、AWSマスターセミナー（Amazon Linux対応）でハンズオン演習も実施しています。

# RDSフェイルオーバーテンプレートを作成する
$ cat > /tmp/fis-rds-failover-template.json << 'EOF'
{
    "description": "RDS Multi-AZ failover time measurement",
    "targets": {
        "rds-target": {
            "resourceType": "aws:rds:cluster",
            "resourceArns": [
                "arn:aws:rds:ap-northeast-1:123456789012:cluster:my-prod-cluster"
            ],
            "selectionMode": "ALL"
        }
    },
    "actions": {
        "failover-rds": {
            "actionId": "aws:rds:failover-db-cluster",
            "targets": {"Clusters": "rds-target"}
        }
    },
    "stopConditions": [
        {
            "source": "aws:cloudwatch:alarm",
            "value": "arn:aws:cloudwatch:ap-northeast-1:123456789012:alarm:FIS-StopCondition-5xxRate"
        }
    ],
    "roleArn": "arn:aws:iam::123456789012:role/fis-experiment-role"
}
EOF

$ aws fis create-experiment-template   --cli-input-json file:///tmp/fis-rds-failover-template.json   --query 'experimentTemplate.id' --output text

EXTd34e56f78a90b12
RDSフェイルオーバー実験後は、 aws rds describe-db-clusters の Status フィールドが available に戻ったタイミングを記録し、実験開始時刻との差分でRTOを計測します。

# RDSクラスターのフェイルオーバー完了を確認する
$ aws rds describe-db-clusters   --db-cluster-identifier my-prod-cluster   --query 'DBClusters[0].{Status:Status,AZ:MultiAZ}'

{
    "Status": "available",
    "AZ": true
}

# 旧プライマリのAZが切り替わったことをインスタンス一覧で確認
$ aws rds describe-db-instances   --filters Name=db-cluster-id,Values=my-prod-cluster   --query 'DBInstances[*].{Id:DBInstanceIdentifier,AZ:AvailabilityZone,Role:PendingModifiedValues}'

3. ネットワーク障害インジェクションで耐障害性を測る

EC2インスタンスへの aws:network:disrupt-connectivity アクションを使うと、AZ間の通信に意図的なパケットロスや遅延を注入できます。マイクロサービス間通信のタイムアウト設定が適切かどうかを実際に検証する際に有効です。

実務では、ネットワーク系の障害注入はアプリケーション層でのCircuit BreakerやRetry設定の検証に活用されています。運用チームと連携し、メンテナンスウィンドウ内で実施することが鉄則です。

FIS実験結果の分析と冗長設計改善サイクル

FIS実験で得られたデータを以下の観点で分析し、設計改善につなげます。

・RTOの実測値とSLA要件の比較：フェイルオーバー完了までの実時間を計測し、SLA要件との差を定量化する
・隠れた単一障害点（SPOF）の発見：フェイルオーバー後も回復しないリソースがあれば設計上の穴の発見につながる
・ユーザー影響の定量化：実験中の5XXエラー数・タイムアウト数を期間絞り込みで集計する

# 過去の実験一覧を取得する
$ aws fis list-experiments   --query 'experiments[*].{id:id,status:state.status,startTime:startTime}'   --output table

------------------------------------------------------------------
|                       ListExperiments                          |
+----------------------+-----------+----------------------------+
|          id          |  status   |        startTime           |
+----------------------+-----------+----------------------------+
|  EXPc23d45e67f89a01  | completed | 2026-10-04T10:00:00+00:00  |
|  EXPa01b23c45d67e89  | completed | 2026-09-28T10:00:00+00:00  |
+----------------------+-----------+----------------------------+
実験IDとCloudWatchのタイムスタンプを突合させて、フェイルオーバー前後の期間をドリルダウンするのが効率的な分析方法です。

トラブルシュート：FIS実験が期待通りに動かない場合

「ResourceNotFoundException: No resources found for target」が出た場合

対象リソースが見つからないエラーです。以下を確認してください。

・EC2タグが正確に付いているか（スペルミスや大文字小文字の違いに要注意）
・フィルター条件のAZ名が正しいか（ap-northeast-1aとap-northeast-1cを混同していないか）
・FISのIAMロールに対象リソースへのアクセス権限が付いているか

# タグで絞り込んだEC2インスタンスを事前確認する
$ aws ec2 describe-instances   --filters "Name=tag:FIS-Target,Values=true"             "Name=placement-availability-zone,Values=ap-northeast-1a"   --query 'Reservations[*].Instances[*].{Id:InstanceId,AZ:Placement.AvailabilityZone,State:State.Name}'

[
    [
        {
            "Id": "i-0123456789abcdef0",
            "AZ": "ap-northeast-1a",
            "State": "running"
        }
    ]
]

実験が開始直後に「failed」で終わる場合

実験開始前にStopConditionのアラームがALARM状態になっていると、実験は始まった瞬間に停止します。実験前に必ずアラームの状態がOKであることを確認してください。

# StopConditionアラームの現在状態を確認する
$ aws cloudwatch describe-alarms   --alarm-names "FIS-StopCondition-5xxRate"   --query 'MetricAlarms[0].{Name:AlarmName,State:StateValue}'

{
    "Name": "FIS-StopCondition-5xxRate",
    "State": "OK"
}

# ALARM状態の場合は原因を解消してから実験を開始すること

【注意】RDSフェイルオーバーアクションはAuroraクラスター専用

aws:rds:failover-db-cluster はRDS Auroraクラスター向けのアクションです。シングルインスタンス構成のRDS（非クラスター）には使えません。シングルAZのRDSでフェイルオーバーをテストしたい場合は、RDSをマルチAZ構成に変更してから実施するか、 aws:rds:reboot-db-instances アクションを使います。

本記事のまとめ

AWS FISを使ったマルチAZ冗長設計の耐障害性検証の主要コマンドと手順を整理します。
やりたいこと コマンド・操作
FIS用IAMロールを作成する aws iam create-role --role-name fis-experiment-role --assume-role-policy-document file://policy.json
FIS権限ポリシーをアタッチする aws iam attach-role-policy --role-name fis-experiment-role --policy-arn arn:aws:iam::aws:policy/service-role/AWSFaultInjectionSimulatorEC2Access
実験テンプレートを登録する aws fis create-experiment-template --cli-input-json file://template.json
テンプレート一覧を確認する aws fis list-experiment-templates
実験を開始する aws fis start-experiment --experiment-template-id EXTxxxxxxxxxxxxxxxx
実験の進行状況を確認する aws fis get-experiment --id EXPxxxxxxxxxxxxxxxx
過去の実験一覧を確認する aws fis list-experiments
StopConditionアラームの状態確認 aws cloudwatch describe-alarms --alarm-names "FIS-StopCondition-xxx"
AWS FISを使えば、設計書通りに冗長構成が機能しているかどうかを、実際のAWS環境で繰り返し検証できます。RTOの実測値を設計改善サイクルに組み込み、「障害が来てから慌てる」ではなく「障害を意図的に起こして鍛える」運用体制を構築してください。

現場で通用する安全なLinuxサーバー構築の「型」を体系的に身につけたい方へ、AWSマスターセミナー（Amazon Linux対応）では冗長設計・マルチAZ構成のハンズオン演習も実施しています。詳細・申込はこちら＞＞

関連記事

無料メルマガで学習を続ける

Linuxの実践スキルをメールで毎週お届け。
登録は30秒、解除もいつでも可。

登録無料・いつでも解除できます

暗記不要・1時間後にはサーバーが動く

3,100名以上が実践した「型」を無料で公開中

プロのエンジニアはコマンドを暗記していません。
「現場で使える型」を効率よく使いこなしているだけです。
その「型」を図解60Pにまとめた入門マニュアルを、完全無料でプレゼントしています。

姓・名・メールの3つだけ／30秒／解除は3秒 ／ 詳細はこちら

Linux無料マニュアル（図解60P） 名前とメールで30秒登録
宮崎 智広

この記事を書いた人

宮崎 智広（みやざき ともひろ）

株式会社イーネットマーキュリー代表。現役のLinuxサーバー管理者として20年以上の実務経験を持ち、これまでに累計3,100名以上のエンジニアを指導してきたLinux教育のプロフェッショナル。「現場で本当に使える技術」を体系的に伝えることをモットーに、実践型のLinuxセミナーの開催や無料マニュアルの配布を通じてLinux人材の育成に取り組んでいる。

趣味は、キャンプにカメラ、トラウト釣り。好きな食べ物は、ラーメンにお酒。休肝日が作れない、酒量を減らせないのが悩み。最近、ドラマ「フライトエンジェル」を観て涙腺が崩壊しました。