2024年8月27日から EC2 のステータスチェックの対象が2つから3つに増えました。

AWS社による「Amazon EC2 ステータスチェック、アタッチされた EBS ボリュームの到達可能性の状態のサポートを開始」の記事で報告されています。

変更前	変更後

何が増えたかというと、「アタッチ済みの EBS ステータスチェック」です。
突然増えたので驚かれた方も多いかと思います。

ただ、すべての EC2 に対して反映されたかというと、そうではありません。
以下のように 2/2 チェックと 3/3 チェックが混在している状況です。

今回の記事では EC2 画面に新しく追加された「アタッチ済みの EBS ステータスチェック」について、どんなチェックなのか、どんな条件で表示されるのか、失敗時にはどのような動きをするのか、といったことを検証します。

1. 「アタッチ済みの EBS ステータスチェック」とは

そもそも「アタッチ済みの EBS ステータスチェック」とは何かというと、インスタンスにアタッチされている Amazon EBS ボリュームが到達可能か、および I/O 操作を完了できるかどうかをモニタリングするチェックとなります。

以下の記載の通りですが、EC2 にアタッチされている EBS ボリュームの問題をチェックしてくれます。

区分	内容
機能	インスタンスにアタッチされている Amazon EBS ボリュームが到達可能かどうか、および I/O 操作を完了できるかどうかをモニタリングします。ステータスチェックメトリクスが失敗した場合は、AWS を待って問題を解決するか、影響を受けたボリュームの置き換えやインスタンスの停止および再起動などのアクションを取ることができます。
メトリクス	StatusCheckFailed_AttachedEBS
失敗の原因	・EBS ボリュームの基盤となるストレージサブシステムのハードウェアまたはソフトウェアの問題・EBS ボリュームの到達可能性に影響する、物理ホスト上のハードウェアの問題・インスタンスと EBS ボリューム間の接続に関する問題
条件	アタッチ済みの EBS ステータスチェックメトリクスは、Nitro インスタンスでのみ使用できます。

この機能ですが、実は2023年10月頃にリリースされた機能です。

なので以前から利用できたのですが、今回は EC2 画面上で3つのステータスチェックの1つとして表示されるようになったのがポイントです。

利用者が見やすい場所に表示されることにより、意識する人も増えそうです。

なお、先ほどから3つのステータスチェックのお話をしていますが、あとの2つも復習のために記載しておきます。

１つは「システムステータスのチェック」です。

区分	内容
機能	インスタンスが実行されている AWS システムをモニタリングします。これらのチェックでは、修復には AWS の関与が必要なインスタンスの基盤の問題が検出されます。
メトリクス	StatusCheckFailed_System
失敗の原因	・ネットワーク接続の喪失・システム電源の喪失・物理ホストのソフトウェアの問題・ネットワーク到達可能性に影響する、物理ホスト上のハードウェアの問題

もう１つは「インスタンスステータスのチェック」です。個々のインスタンスのソフトウェアとネットワークの設定をモニタリングします。

区分	内容
機能	個々のインスタンスのソフトウェアとネットワークの設定をモニタリングします。Amazon EC2 は、ネットワークインターフェイス (NIC) にアドレス解決プロトコル (ARP) リクエストを送信することでインスタンスのヘルスをチェックします。これらのチェックでは、ユーザーが関与して修復する必要のある問題が検出されます。
メトリクス	StatusCheckFailed_Instance
失敗の原因	・失敗したシステムステータスチェック・正しくないネットワークまたは起動設定・メモリの枯渇・破損したファイルシステム・互換性のないカーネル・[Windows インスタンス] インスタンスの再起動中、または Windows の instance store-backed インスタンスがバンドルされている間は、インスタンスが再度使用可能になるまで、インスタンスステータスのチェックで失敗がレポートされます。

新しく追加された「アタッチ済みの EBS ステータスチェック」も含めて、今後はこの3つのステータスチェックを利用することができます。

種類	補足
システムステータスのチェック
インスタンスステータスのチェック
アタッチ済みの EBS ステータスチェック	※今回EC2画面に追加されたチェック

2. EC2 画面に「アタッチ済みの EBS ステータスチェック」が表示される条件

さて、ステータスチェックについて復習できたところで、ステータスチェックに「2/2 のチェックに合格しました」と「3/3のステータスチェックに合格しました」が混在して表示されている現象について説明します。

この違いが何かというと、インスタンスタイプのハイパーバイザーの違いです。AWS のハイパーバイザーには大きく「Nitro」と「Xen」の2種類があります。

「アタッチ済みの EBS ステータスチェック」が対応しているハイパーバイザーは「Nitro」のみです。

現在表示されている2つのインスタンスタイプのハイパーバイザーの種類は以下の通りです。

インスタンスタイプ	ハイパーバイザーの種類
t3.micro	Nitro
t2.micro	xen

ですから、この種類であれば「t3.micro」のみが「アタッチ済みの EBS ステータスチェック」に対応していることになります。

2.1. EC2 におけるハイパーバイザーの確認方法

EC2 のインスタンスタイプのハイパーバイザーはどのように確認するのか…と疑問に思われる方もいるかと思います。ここでは確認方法について説明します。

EC2 のインスタンスタイプのハイパーバイザーは、EC2 のインスタンスタイプ検索画面で確認できます。

検索条件としてハイパーバイザーを選択するとハイパーバイザーの種類を選択できます。

例えば「ハイパーバイザー=nitro」を条件にすれば、対象のインスタンスタイプのみが表示できます。今回の場合、こちらが「アタッチ済みの EBS ステータスチェック」に対応しているインスタンスタイプです。逆に「ハイパーバイザー=xen」で表示されるインスタンスタイプでは「アタッチ済みの EBS ステータスチェック」は利用できません。

もし、一覧画面でハイパーバイザー項目が表示されていない場合は、画面右上の「設定」ボタンを押してください。

属性列で「ハイパーバイザー」を ON にして「確認」を選択します。

これで一覧画面からハイパーバイザーの種類を確認できるようになります。

なお、ハイパーバイザーはインスタンスタイプの詳細画面でも確認できます。

2.2. EC2 におけるハイパーバイザーの種類

次は、2種類のハイパーバイザー「Nitro」と「Xen」の違いについて触れておきます。

AWS の EC2 サービスは元々 Xen ベースのハイパーバイザーを利用していました。2017年11月頃に新世代のハイパーバイザーとして KVM ベースの Nitro ハイパーバイザー提供が始まっています。

区分	xen	Nitro
世代	旧世代	新世代(2017～)
ベース	xen	KVM
特徴	元々利用されていたハイパーバイザー	独自のハードウェアやハイパーバイザーにより最適化された性能を提供

新しいインスタンスタイプでは「Nitro」が利用されています。
例として以下に3つのリージョンのインスタンスの内訳を集計しました。
インスタンスタイプは「Xen」と「Nitro」のハイパーバイザーと、ベアメタルの3つに分類されます。以下を見て頂ければわかる通り、各リージョンとも全体の8割前後が「Nitro」ハイパーバイザーのインスタンスタイプです。

リージョン	Xen	Nitro	ベアメタル	合計
東京	80	589	62	731
大阪	41	183	22	246
バージニア北部	87	650	69	806

東京	大阪	バージニア北部

また、代表的なインスタンスファミリーごとのハイパーバイザーの違いについても触れます。インスタンスタイプの名称ルールは以下の通りで、インスタンスファミリーは先頭の1文字目です。

今回は利用率が高いインスタンスファミリーである「C」、「M」、「R」、「t」のハイパーバイザーについて確認します。インスタンスタイプはリージョンごとに異なりますが、今回は東京リージョンの対応状況が前提です。

インスタンスファミリー	xen	Nitro
t	t1, t2	t3, t3a, t4g
C	c1, c3, c4	c5, c5a, c5d, c5n, c6a, c6g, c6gd, c6gn, c6i, c6id, c6in, c7a, c7g, c7gd, c7gn, c7i, c7i-flex
M	m1, m2 ,m3 ,m4	m5, m5a, m5ad, m5d, m5dn, m5n, m5zn, m6g, m6gd, m6i, m6id, m6idn, m7a, m7g, m7gd, m7i, m7i-flex
R	r3, r4	r5, r5a, r5ad, r5b, r5d, r5dn ,r5n, r6a, r6g, r6gd, r6i, r6id, r6idn, r6in, r7a, r7g, r7gd, r7i, r7iz

上記の表を見やすくするために属性情報を集約すると、以下のように特定世代から「Nitro」に切り替わっていることが分かります。

区分	xen	Nitro
t	1, 2	3, 4
C	1, 3, 4	5, 6, 7
M	1, 2 ,3 ,4	5, 6, 7
R	3, 4	5, 6, 7

インスタンスファミリー「t」の区分を参照頂くと分かる通り2世代目までは「xen」で3世代目以降が「Nitro」です。今回利用したのは「t2.micro」と「t3.micro」だったので「xen」と「Nitro」に別れた結果、「t3.micro」だけが「アタッチ済みの EBS ステータスチェック」が可能となっていたわけです。

新しい世代のインスタンスタイプが「Nitro」ですので、「ほぼ Nitro のハイパーバイザーしか利用しないのではないか」と思うかと思いますが、そうでもありません。例えば、AWSのEC2は12か月間750時間まで無料で利用できる無料利用枠があります。現在東京リージョンにおいて無料利用枠で利用できるインスタンスタイプを確認すると「t2.micro」が表示されます。「t2」は「xen」がハイパーバイザーになるので、多くの場面で意識せずに「xen」ベースのハイパーバイザーを利用していることになります。

そのため、今後も利用する可能性があるため、ハイパーバイザーによる仕様の違いは記憶しておいてもらった方が良いかと思います。

3. 「アタッチ済みの EBS ステータスチェック」失敗時の動作検証

次は「アタッチ済みの EBS ステータスチェック」で実際に失敗した場合の動作検証です。新しいチェックですので、実際にチェックが失敗した場合にどのような動作をするのか確認したいところです。

チェック内容から考えると、以下の2つのどちらかを満たせばエラーを発生できます。

#	失敗条件
1	インスタンスにアタッチされている Amazon EBS ボリュームに到達可能できない
2	インスタンスにアタッチされている Amazon EBS ボリュームのI/O 操作ができない

ただ、これを疑似的に発生させるのは、難しいところです。
AWSでは、そんな対応のために「AWS Fault Injection Service (AWS FIS) 」というサービスが準備されています。

「AWS Fault Injection Service (AWS FIS)」はサービス名を日本語にすると「障害注入サービス」です。障害イベントの実験テンプレートを作成して実行することで、疑似的に障害を発生させて動作確認することができます。

設定内容は非常にシンプルで「実験テンプレートの作成」「実験を開始」「結果の表示」の流れです。

3.1. AWS FIS 画面からの検証手順

まずは、AWS FIS でどのような手順で設定するかを説明します。設定方法としては「AWS Command Line Interface （AWS CLI）」や「SDK」でも対応可能ですが、今回の記事では「AWS Management Console」からの設定を前提とします。

今回の検証設定の前提条件は以下とします。

#	前提条件
1	1台の EC2 に1個の EBSボリュームがアタッチされている
2	「アタッチ済みの EBS ステータスチェック」で失敗状態にする
3	失敗状態にするための方法として AWS FIS を利用する
4	AWS FIS のターゲット設定時はリソース ID で対象を指定する

図にすると以下のようになります。1台の EBS のみを対象としたシンプルな構成です。
ターゲットは「EC2 単位」ではなく「EBS 単位」になるところは注意が必要です。

そして実施手順は以下の通りです。

#	サービス	手順	補足
1	EC2	EC2 起動（Nitro対応インスタンスタイプ）	インスタンスタイプ「t3.micro」を指定
2	AWS FIS	実験テンプレートを作成
3	AWS FIS	実験テンプレートを作成（アクションを追加）	「EBS」「aws:ebs:pause-volume-io」を指定
4	AWS FIS	実験テンプレートを作成（ターゲットを追加）	リソースIDで対象 EBS を指定
5	AWS FIS	実験を開始	正常実施
6	EC2	EC2のステータスチェックの状況確認	ステータスチェックが2/3になる
7	AWS FIS	結果を確認

ここから具体的な設定手順を説明します。

まずは、今回テストする EC2 インスタンスの現状のステータスチェックの状況を確認します。
下記の通り問題なく稼働しています。

AWS FIS のホーム画面から「実験テンプレートを作成」を選択します。

「この AWS アカウント：～」を選択して「確認」を選択します。

説明と名前を入力して、「アクションを追加」を選択します。

名前と説明を入力します。
アクションタイプに「EBS」「aws:ebs:pause-volume-io」を選択します。
Duration（間隔）に時間を設定します。この値の時間、検証が継続されます。
「保存」を選択します。

以下のようにアクションとターゲットが作成されます。
作成されたターゲット「Volumes-Target-1」を選択します。

リソースIDでテストしたい対象の EBS ボリュームを選択して「保存」を選択します。

サービスアクセスは「実験テンプレート用の新しいロールを作成する」を選択します。

「実験テンプレートを作成」を選択します。

入力欄に「作成」と入力し、「実験テンプレートを作成」を選択します。

実験テンプレートが作成されるので、「実験を開始」を選択します。

再度確認画面が表示されるので、「実験を開始」を選択します。

入力欄に「開始」と入力し、「実験を開始」を選択します。

実験が正常に開始されます。

開始直後はステータスチェックにはエラーが出力されていません。

数分経過すると「アタッチ済みの EBS の接続性チェックに失敗しました」のメッセージが出力します。これが発生させたい失敗の状況です。

実験開始から5分後には実験が終了するため、その後は正常な状態に戻ります。

実験結果については、「AWS FIS ＞実験」の画面で確認することが可能です。

ここまでが、AWS FIS 画面からの検証手順でした。

3.2. EBS ボリューム画面から設定する検証手順

実はもう1つ検証方法があります。EBS ボリュームの画面から対象の EBS ボリュームを指定して設定を実施する方法です。

今回の検証設定の前提条件は以下とします。

#	前提条件
1	1台の EC2 に1個の EBS ボリュームがアタッチされている
2	「アタッチ済みの EBS ステータスチェック」で失敗状態にする
3	失敗状態にするための方法として EBS ボリュームから実施する

図にすると以下のようになります。AWS FIS 画面から実施した内容とほぼ同じです。
異なるのは設定画面への入り方が EBS 画面からになるだけです。

そして実施手順は以下の通りです。
見て頂いたら分かる通り、設定項目が減り、非常にシンプルです。

#	サービス	手順	補足
1	EC2	EC2 起動（Nitro 対応インスタンスタイプ）	インスタンスタイプ「t3.micro」を指定
2	EBS	ボリュームI/Oを一時停止の登録	実質的にはFIS設定
3	EBS	ボリュームI/Oを一時停止実験の開始	実質的にはFIS設定
4	EC2	EC2 のステータスチェックの状況確認	ステータスチェックが 2/3 になる
5	AWS FIS	結果を確認

EBS画面で、検証したい対象の EC2 にアタッチされている EBS を選択します。「アクション＞フィールド挿入＞ボリューム I/O の一時停止」を選択します。

Duration（間隔）に時間を設定し、「ボリューム I/O の一時停止」を選択します。
EBS 画面から設定していますが、画面左上に「AWS FIS」と表示されており、実質的には「AWS FIS」です。そのため、実験の結果は「AWS FIS」の画面で確認することになります。ただ、EBS ボリュームを直接指定して設定しているので、「AWS FIS」の時のような「アクションの設定」や「ターゲットの指定」といった手順が不要です。

入力欄に「開始」と入力し、「実験を開始」を選択します。

実験が正常に開始されます。

この後の検証動作については先ほどと同様のため説明を省略します。EBS ボリューム画面から簡易に検証作業の設定を実施できますが、実質的には「AWS FIS」が動作しています。実験結果も「AWS FIS」に残ります。

3.3. 2つの検証手順の比較

EBS ボリュームを直接指定する手順は細かい設定を省略できるので簡単に実行できます。
ただし複数の EBS ボリュームに対する同時実行設定は実施できまません。
複数の EBS ボリュームを対象にするのであれば、AWS FIS 画面から実行する必要があります。

区分	FIS 画面からの設定	EBS 画面からの設定
アクションの設定	△ 個別指定が必要	〇個別設定が不要
ターゲットの指定	△ 個別指定が必要	〇個別設定が不要
複数ターゲットの指定	〇可能	× 不可（1台のみ）

4. 「アタッチ済みの EBS ステータスチェック」の AWS FIS を利用した各種動作検証

今回の動作検証は、EBS ボリュームから直接設定する手順は利用せず、AWS FIS 画面から起動テンプレートを作成して実行する手順で統一して実施します。

動作検証内容は以下の通りです。

#	動作検証内容
1	Nitro 未対応インスタンスタイプのEC2にアタッチされた EBS ボリュームで実行した場合の動き
2	タグ指定で6台の EBS ボリュームに対して実行した場合の動き
3	リソース ID 指定で6台の EBS ボリュームに対して実行した場合の動き
4	複数 AZ の EBS ボリュームを対象にした場合の動き
5	追加 EBS ボリュームで障害が発生した場合の動き
6	EBS マルチアタッチ環境で障害が発生した場合の動き

4.1. Nitro 未対応インスタンスタイプのEC2にアタッチされた EBS ボリュームで実行した場合の動き

まずは Nitro 未対応のインスタンスタイプで起動した EC2 において、AWS FIS を利用した場合の動きについて確認します。 Nitro 未対応のインスタンスタイプを利用しているので、「アタッチ済みの EBS ステータスチェック」は利用不可のはずです。その場合はどう動くのでしょうか。

まずは前提条件です。#5が追加条件です。

#	前提条件
1	1台の EC2 に1個の EBS がアタッチされている
2	「アタッチ済みの EBS ステータスチェック」で失敗状態にする
3	失敗状態にするための方法として AWS FIS を利用する
4	AWS FIS のターゲット設定時はリソース ID で対象を指定する
5	EC2　のインスタンスタイプは Nitro 未対応

具体的にはインスタンスタイプ「t2.micro」です。

インスタンスタイプ「t2.micro」のハイパーバイザーは Nitro ではありません。

図にすると以下のようになります。

実験結果：エラー

結果的に実験開始後にエラーとなります。

実施手順は以下の通りです。#5の実験を開始した段階でエラーとなります。

#	サービス	手順	補足
1	EC2	EC2　起動（Nitro 未対応インスタンスタイプ）	インスタンスタイプ「t2.micro」を指定
2	AWS FIS	実験テンプレートを作成
3	AWS FIS	実験テンプレートを作成（アクションを追加）	「EBS」「aws:ebs:pause-volume-io」を指定
4	AWS FIS	実験テンプレートを作成（ターゲットを追加）	リソース ID で対象インスタンスを指定
5	AWS FIS	実験を開始	エラーで終了

出力されるエラーは以下の通りです。「ターゲットボリュームは、Nitro システムに基づいたインスタンスタイプに接続する必要があります。」と表示されますので、「Nitro 未対応のインスタンタイプで起動した EC2 を利用したことが原因です。

区分	内容
英文	The experiment EXPmgLYMuiZWbrM3A2 has failed. InvalidTarget for action EBSPauseVolumeIO in AWS account ID 05872*******. Unable to start Pause Volume IO. Target volumes must be attached to an instance type based on the Nitro system. VolumeId(s): [vol-005dc5157d3f1c165]
和訳	実験 EXPmgLYMuiZWbrM3A2 は失敗しました。 AWS アカウント ID 05872******* のアクション EBSPauseVolumeIO のターゲットが無効です。ボリューム IO の一時停止を開始できません。ターゲットボリュームは、Nitro システムに基づいたインスタンスタイプに接続する必要があります。ボリューム ID: [vol-005dc5157d3f1c165]

これで、この検証は終了です。

4.2. タグ指定で6台の EBS ボリュームに対して実行した場合の動き

次はタグ指定で6台の EBS ボリュームを対象にして実行した場合の動きについて確認します。

前提条件です。今回は6台の EBS ボリュームを対象にするので、AWS FIS の設定はリソースタグで指定します。

#	前提条件
1	6台の EC2 にそれぞれ1個の EBS がアタッチされている
2	「アタッチ済みの EBS ステータスチェック」で失敗状態にする
3	失敗状態にするための方法として AWS FIS を利用する
4	AWS FIS のターゲット設定時はリソースタグで対象を指定する（6つの EBS ボリューム）

実験対象のターゲットはリソースタグで指定できるので、以下のようなタグを作成します。

そのタグを6個の EBS ボリュームに設定します。

そのあと、実験テンプレートを作成しますが、その際にターゲットメソッドとして「リソースタグ、フィルター、パラメータ」を選択します。そしてリソースタグを6つの EBS にアタッチしたものと同様のものを設定します。この際にリソースパラメータ「availabiliryZoneIdentifier」(リージョン指定）が必須になるので注意が必要です。

万一、リソースパラメータ「availabilityZoneIdentifier」を設定しなくても実験テンプレート自体は登録できますが、実行時に以下のエラーが出力されます。なので、必ず入力が必要です。

区分	内容
英文	The experiment EXP25bijbLLwphFvwxE has failed. ConfigurationFailure for target Volumes-Target-1 in AWS account ID 05872*******.Error resolving targets. 'availabilityZoneIdentifier' is a required parameter when filtering by tags.
和訳	実験 EXP25bijbLLwphFvwxE は失敗しました。 AWS アカウント ID 05872******* のターゲットボリューム -Target-1 の構成障害。ターゲットの解決中にエラーが発生しました。「availabilityZoneIdentifier」は、タグでフィルタリングする場合の必須パラメータです。

リソースパラメータ「availabiliryZoneIdentifier」はきちんと設定した前提で話を進めます。

今回の実施内容を図にすると以下のようになります。

実験結果：エラー

結果的に実験開始後にエラーとなります。

実施手順は以下の通りです。#6の実験を開始した段階でエラーとなります。

#	サービス	手順	補足
1	EC2	6台の EC2 を起動（Nitro対応）	インスタンスタイプ「t3.micro」を指定
2	EBS	6個の EBS ボリュームにタグ付け	タグ（key:fis-test Value：ebs-io）を設定
3	AWS FIS	実験テンプレートを作成
4	AWS FIS	実験テンプレートを作成（アクションを追加）	「EBS」「aws:ebs:pause-volume-io」を指定
5	AWS FIS	実験テンプレートを作成（ターゲットを追加）	タグ（key:fis-test Value：ebs-io）とリージョンを指定
6	AWS FIS	実験を開始	エラーで終了（タグで指定できるEBS数のクォータ設定が5台のため）

出力されるエラーは以下の通りです。「実験ターゲットあたりのリソース数は 5 を超えることはできません」と表示されますので、実験対象とする EBS ボリューム数が問題であると分かります。今回のエラー原因は、6台の EBS ボリュームを検証対象にしていますが、タグで指定できる EBS ボリュームの上限は5個までのためです。

区分	内容
英文	The experiment EXPQQ5ZQKaCYA7dQDp has failed. QuotaExceededFailure for target Volumes-Target-1 in AWS account ID 05872*******.Number of resources per experiment target cannot exceed 5
和訳	実験 EXPQQ5ZQKaCYA7dQDp は失敗しました。 AWS アカウント ID 05872******* のターゲットボリューム-Target-1 の QuotaExceededFailure。実験ターゲットあたりのリソース数は 5 を超えることはできません

ただし、この検証はこれで終わりではありません。
この上限値は「Service Quotas」におけるリクエストで引き上げることができるからです。

手順としては「Service Quotas」の「Target Volumes for aws:ebs:pause-volume-io」に遷移します。

上限値が「5]に設定されています。

「Target Volumes for aws:ebs:pause-volume-io」の説明文は以下の通りです。

区分	内容
英文	The maximum number of Volumes that aws:ebs:pause-volume-io can target when you identify targets using tags, per experiment.
和訳	タグを使用してターゲットを識別するときに aws:ebs:pause-volume-io がターゲットにできるボリュームの最大数 (実験ごと)。

画面右上の「アカウントレベルでの引き上げをリクエスト」を選択します。

以下の通り現状のクォータ値「5」が設定されています。

今回は6個同時にテストを実施するため、クォータ値を「6」に変更してリクエストします。

リクエストが実行されます。ここでステータスが「保留中」になるので回答を待ちます。

ステータスが「承認済み」に変更となります。これでクォータ値が「6」に引き上げられます。

それでは、再度動作確認を実施します。
図にすると以下のようになります。先ほどとの変更点はクォータ値の変更のみです。

実験結果：正常実施

今回は実験を実施すると、以下の通りステータスチェックが「2/3」となり、想定していた状態となります。

実施手順は以下の通りです。#1、#2の手順のみ追加となっており、それ以外の手順は先ほどと同じです。クォータのリクエストにより問題が解決しました。

#	サービス	手順	補足
1	Service Quotas	クォータ引き上げリクエスト	「Target Volumes for aws:ebs:pause-volume-io」の EBS 数を5個から6個に上限引き上げリクエストを実施
2	Service Quotas	クォータ引き上げ承認	引き上げリクエストがAWSに承認される
3	EC2	6台の EC2 を起動（Nitro対応）	インスタンスタイプ「t3.micro」を指定
4	EBS	6個の EBS ボリュームにタグ付け	タグ（key:fis-test Value：ebs-io）を設定
5	AWS FIS	実験テンプレートを作成
6	AWS FIS	実験テンプレートを作成（アクションを追加）	「EBS」「aws:ebs:pause-volume-io」を指定
7	AWS FIS	実験テンプレートを作成（ターゲットを追加）	タグ（key:fis-test Value：ebs-io）とリージョンを指定
8	AWS FIS	実験を開始	正常実行
9	EC2	6台の EC2 のステータスチェックの状況確認	ステータスチェックが2/3になる
10	AWS FIS	結果を確認

このように、対象 EBS ボリューム数はクォータ設定に依存しており、引き上げることで EBS ボリューム数を増やした実験も実施可能です。

これで、この検証は終了です。

4.3. リソース ID 指定で6台の EBS ボリュームに対して実行した場合の動き

クォータ「Target Volumes for aws:ebs:pause-volume-io」の説明を読むと「タグを使用してターゲットを識別するときに aws:ebs:pause-volume-io がターゲットにできるボリュームの最大数 (実験ごと)。」と記載があるので、「タグ指定ではなくリソース ID 設定の場合は6台以上でも実施可能なのか」は気になるところです。そのため、ターゲットとしてリソースタグではなくリソース ID を指定てテストを実施します。

今回の検証設定の前提条件は以下とします。#4が先ほどのテストと異なり「リソース ID」を指定する前提です。

#	前提条件
1	EC2 6台にそれぞれ1個の EBS がアタッチされている
2	「アタッチ済みの EBS ステータスチェック」で失敗状態にする
3	失敗状態にするための方法として AWS FIS を利用する
4	AWS FIS のターゲット設定時はリソース ID で対象を指定する（6つの EBS ボリューム）

「Target Volumes for aws:ebs:pause-volume-io」のクォータ「5」の際は以下の通りのメッセージが出力されます。5個までの制限があります。

それでは、クォータを「6」に引き上げて、動作確認を実施してみましょう。

図にすると以下のようになります。

実験結果：エラー

実施手順は以下の通りです。#7の設定時に入力エラーとなります。

#	サービス	手順	補足
1	Service Quotas	クォータ引き上げリクエスト	「Target Volumes for aws:ebs:pause-volume-io」の EBS 数を5個から6個に上限引き上げリクエストを実施
2	Service Quotas	クォータ引き上げ承認	引き上げリクエストがAWSに承認される
3	EC2	6台の EC2 を起動（Nitro対応）	インスタンスタイプ「t3.micro」を指定
4	EBS	6個の EBSボリュームにタグ付け	タグ（key:fis-test Value：ebs-io）を設定
5	AWS FIS	実験テンプレートを作成
6	AWS FIS	実験テンプレートを作成（アクションを追加）	「EBS」「aws:ebs:pause-volume-io」を指定
7	AWS FIS	実験テンプレートを作成（ターゲットを追加）	リソースIDで対象の6台のEBSを指定しようとするとエラー ※6台に引き上げ実施後もエラー

「Target Volumes for aws:ebs:pause-volume-io」のクォータ「6」に引き上げましたが、以下の通り5台までの制限が残っていることが分かります。「Target Volumes for aws:ebs:pause-volume-io」はあくまでターゲットメソッドとして「リソースタグ、フィルター、パラメータ」を指定した場合のクォータ制限です。リソースID側の上限は引き上げられないのでご注意ください。

これで、この検証は終了です。

4.4. 複数AZのEBSボリュームを対象にした場合の動き

次は複数の EBS ボリュームを指定する際に、その EBS ボリュームの AZ が異なった場合にどうなるかの確認です。今回のターゲット指定時はリソース ID で指定します。リソースタグで指定する場合は、1つのリージョンを指定する必要があり、複数リージョンを設定するような入力ができないためです。

今回の検証設定の前提条件は以下とします。#5が今回の追加条件です。

#	前提条件
1	EC2 6台にそれぞれ1個の EBS ボリュームがアタッチされている
2	「アタッチ済みの EBS ステータスチェック」で失敗状態にする
3	失敗状態にするための方法として AWS FIS を利用する
4	AWS FIS のターゲット設定時はリソース ID で対象を指定する（6つの EBS ボリューム）
5	6つの EBS ボリュームの AZ は2つに AZ に分かれる

図にすると以下のようになります。

実験結果：エラー

実施手順は以下の通りです。#6の設定時に入力エラーとなります。

#	サービス	手順	補足
1	EC2	AZ の異なる EC2 を起動（Nitro対応）	インスタンスタイプ「t3.micro」を指定
2	EBS	6 個の EBS ボリュームにタグ付け	タグ（key:fis-test Value：ebs-io）を設定
3	AWS FIS	実験テンプレートを作成
4	AWS FIS	実験テンプレートを作成（アクションを追加）	「EBS」「aws:ebs:pause-volume-io」を指定
5	AWS FIS	実験テンプレートを作成（ターゲットを追加）	タグ（key:fis-test Value：ebs-io）とリージョンを指定
6	AWS FIS	実験テンプレートを作成（ターゲットを追加）	リソース ID で AZ の異なる EC2 にアタッチされた複数の EBS を指定しようとするとエラー

対象として指定する EBS ボリュームの AZ がすべて同じでないとエラーになります。

そのため対象の EBS ボリュームが異なる AZ の場合には設定することができないのですが、もし実施したい場合は、以下の通り、AZ ごとに実験テンプレートを分けて登録することで実行できます。無理に1つの起動テンプレートにこだわる必要はありません。

これで、この検証は終了です。

4.5. 追加 EBS ボリュームで障害が発生した場合の動き

1台の EC2 には複数の EBS ボリュームをアタッチできます。
1台の EC2 を起動して、その EC2 に追加 EBS ボリュームをアタッチし、追加 EBS ボリュームを障害対象に設定してテストします。その場合に「アタッチ済みの EBS ステータスチェック」がエラーとなるかの検証です。

今回の検証設定の前提条件は以下とします。

#	前提条件
1	1台の EC2 に2個の EBS ボリュームがアタッチされている（追加 EBS ボリュームを1個アタッチ）
2	「アタッチ済みの EBS ステータスチェック」で失敗状態にする
3	失敗状態にするための方法として AWS FIS を利用する
4	AWS FIS のターゲット設定時はリソース ID で対象を指定する（追加EBSボリュームのみ）

この追加 EBS ボリュームでエラーが発生した時に、ステータスチェックがどのようになるかを確認します。今回もターゲットの設定はタグで実施します。

以下のように１つの EC2 に追加の EBS ボリュームをアタッチします。

その上で追加 EBS ボリュームのみ以下のタグを付けます。

実験テンプレートの作成時にはターゲットとしてタグを設定します。

図にすると以下のようになります。

実験結果：正常実施

全体の流れとしては、以下の通りです。

#	サービス	手順	補足
1	EC2	EC2 起動（Nitro対応）	インスタンスタイプ「t3.micro」を指定
2	EC2	EC2 に追加 EBS ボリュームをアタッチ）	追加 EBS ボリュームをアタッチする
3	EBS	追加 EBS ボリュームにタグ付け	タグ（key:fis-test Value：ebs-io-ebs2）を設定
4	AWS FIS	実験テンプレートを作成
5	AWS FIS	実験テンプレートを作成（アクションを追加）	「EBS」「aws:ebs:pause-volume-io」を指定
6	AWS FIS	実験テンプレートを作成（ターゲットを追加）	タグ（key:fis-test Value：ebs-io-ebs2）とリージョンを指定
7	AWS FIS	実験を開始	正常実施
8	EC2	EC2 のステータスチェックの状況確認	ステータスチェックが2/3になる
9	AWS FIS	結果を確認

今回は実験を実施すると、以下の通りステータスチェックが「2/3」となり、想定していた状態となります。追加 EBS ボリュームのみがエラーとなった場合も、ステータスチェックに影響することが分かります。

これで、この検証は終了です。

4.6. EBS マルチアタッチ環境で障害が発生した場合の動き

1つの追加 EBS ボリュームを2つの EC2 にアタッチする「EBS マルチアタッチ」の設定があります。これを実施した場合に、その追加 EBS ボリュームで障害が発生した場合はどうなるのでしょうか。

今回の検証設定の前提条件は以下とします。

#	前提条件
1	2台の EC2 に1個の追加 EBS ボリュームを共有する形でアタッチする（追加 EBS ボリュームを1個を共有する形でアタッチ）
2	「アタッチ済みの EBS ステータスチェック」で失敗状態にする
3	失敗状態にするための方法として AWS FIS を利用する
4	AWS FIS のターゲット設定時はリソース ID で対象を指定する（追加 EBS ボリュームのみ）

まず、マルチアタッチが可能な追加 EBS ボリュームを作成する必要があります。
「Windows インスタンスは、マルチアタッチが有効な io2 ボリュームのみをサポートします。」との仕様のため、ボリュームタイプは io2 の EBS ボリュームを作成します。
以下の画面にある通り「マルチアタッチの有効化」にチェックを入れて作成します。

作成したボリュームは以下の通り「マルチアタッチ有効」が「はい」になります。

作成した EBS ボリュームを2つの EC2 にアタッチします。こちらは最大16個の EC2 までアタッチ可能です。

その上で追加 EBS ボリュームのみ以下のタグを付けます。

実験テンプレートの作成時にはターゲットとしてタグを設定します。

図にすると以下のようになります。

実験結果：正常実施

全体の流れとしては、以下の通りです。

#	サービス	手順	補足
1	EC2	2台の EC2 起動（Nitro対応）	インスタンスタイプ「t3.micro」を指定
2	EC2	2台の EC2 に同一の追加 EBS ボリュームをアタッチ）	ボリュームタイプが「IOPS(io2)」の追加ボリュームをアタッチする
3	EBS	追加の EBS ボリュームにタグ付け	タグ（key:fis-test Value：ebs-multi-attach）を設定
4	AWS FIS	実験テンプレートを作成
5	AWS FIS	実験テンプレートを作成（アクションを追加）	「EBS」「aws:ebs:pause-volume-io」を指定
6	AWS FIS	実験テンプレートを作成（ターゲットを追加）	タグ（key:fis-test Value：ebs-multi-attach）とリージョンを指定
7	AWS FIS	実験を開始	正常実施
8	EC2	2台の EC2 のステータスチェックの状況確認	2台の EC2 のステータスチェックが2/3になる
9	AWS FIS	結果を確認

実験を実施する2台の EC2 におけるステータスチェックが2/3になるため、マルチアタッチを設定している場合、複数の EC2 のステータスチェックに影響することが分かります。

4.7. 検証結果のまとめ

ここまでの検証結果をまとめた内容が以下の通りです。いくつかのエラーに対応することで。「アタッチ済みの EBS ステータスチェック」と AWS FIS の特性を確認できました。

#	動作検証内容	結果	説明
1	Nitro 未対応インスタンスタイプのEC2にアタッチされた EBS ボリュームで実行した場合の動き	エラー	Nitro 未対応のインスタンタイプで起動した EC2 にアタッチされた EBS で実験を開始するとエラーで終了する。
2	タグ指定で6台の EBS ボリュームに対して実行した場合の動き	エラー	標準では同時実施可能な EBS ボリュームは5個までのためエラーで終了する。ただし、「Service Quotas」の「Target Volumes for aws:ebs:pause-volume-io」でクォータの上限を「6」に変更することでエラーを回避することが可能。
3	リソース ID 指定で6台の EBS ボリュームに対して実行した場合の動き	エラー	標準では同時実施可能な EBS ボリュームは5個までのため画面入力時に登録不可となる。「Service Quotas」の「Target Volumes for aws:ebs:pause-volume-io」はタグ指定の場合の上限のため、上限値を変更しても、こちらの上限は引き上げられないので注意。
4	複数 AZ の EBS ボリュームを対象にした場合の動き	エラー	対象として指定する EBS ボリュームの AZ がすべて同じでないとエラーになる。もし実施したい場合は、AZ ごとに起動テンプレートを分けて登録することで実行する。
5	追加 EBS ボリュームで障害が発生した場合の動き	正常実施	追加 EBS ボリュームのみがエラーとなった場合も、ステータスチェックが失敗する。
6	EBS マルチアタッチ環境で障害が発生した場合の動き	正常実施	マルチアタッチを設定している場合、アタッチしている複数の EC2 のステータスチェックが失敗する。

5. まとめ

それでは最後にまとめです。

「アタッチ済みの EBS ステータスチェック」についての要点は以下の通りです。

#	要点
1	「アタッチ済みの EBS ステータスチェック」が対応しているハイパーバイザーは「Nitro」の場合のみ
2	AWS のハイパーバイザーは「Xen」と「Nitro」で、インスタンスタイプごとに設定されている
3	「アタッチ済みの EBS ステータスチェック」を利用したい場合は「Nitro」のインスタンスタイプを選択すること

次に「アタッチ済みの EBS ステータスチェック」の AWS FIS 検証についての要点は以下の通りです。

#	要点
1	AWS FIS は、障害イベントの実験テンプレートを作成して実行することで、疑似的に障害を発生させて動作確認することができる
2	アクションタイプ「aws:ebs:pause-volume-io」で「アタッチ済みの EBS ステータスチェック」失敗の実験を実施できる
3	ターゲットは「リソースID」と「リソースタグ」で設定可能
4	標準の同時実行 EBS ボリュームの数が5個のため、6個以上を実施する場合は「Service Quotas」で「Target Volumes for aws:ebs:pause-volume-io」の引き上げリクエストを実施する必要あり
5	「Target Volumes for aws:ebs:pause-volume-io」の引き上げリクエストは、リソースタグ設定の上限値引き上げには反映されるが、リソース ID による設定には反映されない
6	ターゲットに指定する EBS ボリュームは同一 AZ である必要がある
7	追加EBSボリュームでも EC2 のステータスチェックが失敗する。
8	マルチアタッチを設定している場合、アタッチしている複数の EC2 の EC2 のステータスチェックが失敗する。

新しく増えたステータスチェックを是非活用してみてください。

今回の記事がご参考になれば幸いです。