[アップデート]AWS Fault Injection Serviceがマルチアカウントに対応しました #AWSreinvent

AWS re:Invent 2023

#AWS

#AWS Fault Injection Simulator

杉金晋

2023.11.28

みなさんこんにちは、杉金です。
AWS Fault Injection Service(FIS)がマルチアカウントに対応しました。複数アカウントをまたいだ障害テストができるようになったぞおおおお！！

試しに使ってみましたので、操作感や設定の流れの把握に役立ててもらえればと思います。

やってみた

事前準備（IAMロール作成）

事前準備として、各AWSアカウントにIAMロールを作成します。

FISを管理、実行するオーケストレーションの役割を持つアカウントAと、障害が注入されるターゲットのアカウントBそれぞれにIAMロールを作成します。関係性を下の図に表します。

IAMロールBはIAMロールAからアクセスできるよう、信頼ポリシーを設定します。後ほど画面でも紹介しますが、ターゲットアカウントは複数設定できます。
前述したリンクにあるサンプル設定をもとに、まずはアカウントBでIAMロールBを作ります。カスタム信頼ポリシーから、以下のようにポリシーを設定します。

{
    "Version": "2012-10-17",
    "Statement": [
        {
           "Effect": "Allow",
            "Principal": {
                "AWS": "AccountIdA"
            },
            "Action": "sts:AssumeRole",
            "Condition": {
                "StringLike":{
                    "sts:ExternalId": "arn:aws:fis:region:accountIdA:experiment/*"
                },
                "ArnEquals": {
                    "aws:PrincipalArn": "arn:aws:iam::accountIdA:role/role_name"
                }
            }
        }
    ]
}

上記のaccountIdA、region やrole_nameを適切なものに置き換えてください。注意点として、AWS公式ドキュメント上ですとArnEqualsでAccountIdBを指定していますが、正しくはAccountIdAです。フィードバックはしましたが、修正されるまでご注意ください。

次に、IAMロールに権限を付与します。カスタムポリシーを作成してアタッチするか、インラインポリシーで定義します。今回付与する権限は、公式ドキュメントに記載のEBSボリュームのIO一時停止に関するアクションを指定しています。シナリオによって付与する権限を変更してください。

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": [
                "ec2:DescribeVolumes"
            ],
            "Resource": "*"
        },
        {
            "Effect": "Allow",
            "Action": [
                "ec2:PauseVolumeIO"
            ],
            "Resource": "arn:aws:ec2:region:accountIdB:volume/*"
        },
        {
            "Effect": "Allow",
            "Action": [
                "tag:GetResources"
            ],
            "Resource": "*"
        }
    ]
}

上記のaccountIdBはアカウントBのAWSアカウントIDに置き換えてください。regionも適切なリージョンを指定ください。
続いてはアカウントAでIAMロールAを作成します。IAMロールAはFISから呼び出されるよう、信頼ポリシーを次のように設定します。

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Principal": {
                "Service": [
                    "fis.amazonaws.com"
                ]
            },
            "Action": "sts:AssumeRole"
        }
    ]
}

IAMロールAに付与する権限は以下です。

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": "sts:AssumeRole",
            "Resource": [
                "arn:aws:iam::accountIdB:role/role_name"
            ]
        }
    ]
}

上記のaccountIdBとrole_nameは適切な値に置き換えてください。IAMロールの設定は以上です。

事前準備（EC2インスタンス作成）

アカウントBにて、障害テストを起こさせるEC2インスタンス（EBSボリューム）を作成します。作成手順は割愛しますが、FISのアクションからEBSボリュームを操作する際は、Nitro System上で稼働するEC2インスタンスタイプを指定します。

Nitro System上で稼働するEC2インスタンスタイプは、次のリンクに記載されています。

事前準備は以上で完了です。ようやく本機能について説明します。

実験テンプレートの作成、実行

FISのコンソールから、[実験テンプレートを作成]を選びます。

実験のタイプは、[複数のアカウント]を選びます。

説明、アクションとターゲットを設定します。

アクションはEBSボリュームのIO一時停止アクションを選びました。Durationは適当です。

ターゲットは次のように設定します。EBSボリュームのARNはarn:aws:ec2:ap-northeast-1:012345678901:volume/vol-01234567のような記述です。

ターゲットアカウントの設定では、作成したIAMロールBのARNを入力し、サービスアクセスは作成したIAMロールAを指定します。

ターゲットとターゲットアカウントで追加のアカウントを設定することで、アカウントBだけでなく、より多くのアカウントにまたがった動作も可能です。Service Quotasで実験テンプレートあたりのターゲットアカウント数の上限が設定されていますので、必要に応じてクォータの引き上げを申請します。

実験テンプレート作成の話に戻しまして、あとの設定はスキップしてテンプレートの作成へと進みます。補足ですが、停止条件を設定するにはクロスアカウントでCloudWatchアラームを設定します。（参考URL）

作成後、テンプレートが存在することが確認します。それでは、右上の[実験を開始]から実行してみましょう。

開始後は状況が表示され、停止ボタンから停止できます。

アカウントBからEBSボリュームを見ると、ボリュームのステータスが障害となりました。

しばらくして、実験が完了となります。

完了後はEBSボリュームのステータスは「OK」に戻っていました。

以上がマルチアカウントによるFISの実行です。IAMロールの設定さえできれば、あとは個別アカウントでの操作とほとんど変わりありません。

料金

今回のマルチアカウント機能を使用するための追加料金は発生しません。FISは、アクティブなアクションの期間とアクション数をもとに利用料が発生します。料金の詳細は以下のページをご確認ください。

さいごに

マルチアカウントに対応したFISを試してみて、思ったほど操作が難しくなかったことが大きな気づきでした。マルチアカウントに対応したことで、AWSアカウント全体を統制する部隊で定期的に個々のアカウントに対して障害訓練を主導して実施していくイメージがなんとなく浮かびました。freeeさんのブログを読んでから障害訓練をしたいなと常々思っています。機会があれば実際のアカウントで使ってみたいですね！

余談ですが、AWS Fault Injection SimulatorなのかAWS Fault Injection Serviceなのかでサービス名にブレがあるのめっちゃ気になります。
→2023/12/1追記：AWS Fault Injection Serviceに名称変更したようです。