概要
2022年10月27日に、EC2のReplace Root Volumeが、更新されたAMIに対応しました！
参考：Amazon EC2 でルートボリュームを置き換えることでゲストオペレーティングシステムとアプリケーションのパッチ適用が容易に
今までのReplace Root Volumeのオプションは
- ルートボリュームの初期起動状態
- 現在のルートボリュームと同じ系統のスナップショット
を指定することが出来ました。
参考：Amazon EC2 でルートボリュームを交換することにより、迅速な復元とトラブルシューティングが可能に
今回のアップデートをもって、EC2を停止しなくても更新されたAMIでルートボリュームを置き換えられるようになりました。
参考：Replace a root volume - Amazon Elastic Compute Cloud
（11月1日現在、最新情報は英語のドキュメントにしか存在しないため注意。言語を日本語にすると古い情報になる。）
何が嬉しいのか？
今までのReplace Root Volumeのオプションである
- ルートボリュームの初期起動状態
- 現在のルートボリュームと同じ系統のスナップショット
は、トラブルシューティングがメインだと思います。
例えば障害が発生したり、作業ミスで大事なデータが無くなった時などにインスタンス作成時に利用したAMIの状態に戻したり、スナップショットによって特定地点にリストアしたりするといった具合です。
それに対して、今回のアップデートである、更新されたAMIによるReplace Root Volumeはセキュリティ対策がメインだと感じました。
「EC2上のOSやアプリケーションをアップデートしたいが、アップデートに伴うEC2の再起動によってインスタンスストアのデータやネットワーク構成などを失いたくない」といった場合に、「Replace Root VolumeによってEC2を停止する事なく、OSやアプリケーションがアップデートされているAMIとルートボリュームを置き換える」といった事が可能となります。
Replace Root Volumeによって容易かつ迅速にOSやアプリケーションのアップデートに対応できるため、EC2を常にセキュアな状態に維持することが望めます。
ちなみにアップデートを発表しているAWSブログでは「updated AMI」（更新された）と表現されているので、Replace Root Volumeに利用できるAMIは「自分でOSやアプリケーションを更新して作成したAMI」という印象を持ちますが、所有しているAMI以外にも、共有されたAMI、AWSマーケットプレイスのAMIも利用できます。
参考：Replace a root volume - Amazon Elastic Compute Cloud.
試してみた
さて実際に更新されたAMIによるReplace Root Volumeを試してみようと思います。
OSアップデート
まず最初にOSアップデートを模して、カーネルバージョン4のAmazon Linux 2のAMIから立ち上げたEC2のルートボリュームをカーネルバージョン5のAmazon Linux 2のAMIと置き換えてみます。
クイックスタートにあるカーネルバージョン4のAmazon Linux 2のAMI（①）からEC2を作成します。
作成したEC2はこちらとなります。
このEC2にSSMセッションマネージャーでログインして、現在のカーネルバージョンを確認します。
カーネルバージョン４であることを確認しました。
次にカーネルバージョン5のAmazon Linux 2のAMI（②）からEC2を作成します。
作成したEC2はこちらとなります。
このEC2からAMIを作成します。
※クイックスタートのAMIはReplace Root Volumeで利用できなかったため、クイックスタートのAMIで作成したEC2からAMIを作成しています。
AMIの詳細情報の画面でAMI IDをコピーします。
これで準備が整いました。
起動中のカーネルバージョン4のEC2を選択しますと、「アクション」→「モニタリングとトラブルシューティング」→「ルートボリュームを置き換える」（Replace Root Volume）の順にクリックします。
すると「ルートボリュームを置き換える」というページに遷移します。
リストア方法に「Image」を選択し、Imageのボックスに先ほどコピーしたAMI IDを貼り付けます。
そして「置き換えタスクを作成する」をクリックしてください。
※このスクショを撮る前に一度Replace Root Volumeを試してしまったので、「最近のルートボリュームの置き換えタスク」が表示されています。初めてのReplace Root Volumeならば、この表示はありません。
少し待った後、SSMセッションマネージャーによるログインが可能となります。
カーネルバージョン4であったEC2に再びログインした後、カーネルバージョンを確認します。
カーネルバージョン5のEC2のAMIに置き換わったことによって、カーネルバージョンが5に変更された事を確認できました。
詳細情報でもカーネルバージョン5のEC2のAMIに置き換わっていることを確認できます。
また起動時間が最初にEC2を作成した時間から変わっていないため、ルートボリュームが置き換わった際にEC2が停止していない事もわかります。
サービス起動時の挙動
EC2自体は停止しない事が分かりました。
ではサービスを起動している状態でAMIを置き換えたらどのような挙動になるのでしょうか？
Apacheを起動している状態で「index.htmlの内容を変更したAMI」に置き換えてみます。
予想ですが、AMIを置き換えている時1,2分ぐらい待ってからSSMセッションマネージャーによるログインができるようになったので、AMIを置き換えている間EC2自体は停止しないがサービスは1,2分程度のダウンタイムが発生するものと思われます。
何はともあれ試してみましょう。
まずReplace Root Volumeを行うEC2を作成します。
起動後、Apacheをインストールして「index.html」を「AMI置き換え前です」と表示するHTMLファイルにします。
（Apacheインストール手順は割愛します）
プロセスIDも見ておきましょう。
次に、置き換え後のAMIを作成するためのEC2を作成します。
起動後、Apacheをインストールして「index.html」の内容を「AMI置き換え後です」と表示するHTMLファイルにします。
AMIを作成します。
このAMIを元にReplace Root Volumeを行いましょう。Replace Root Volumeの手順は割愛します。
AMIを置き換えている間にブラウザをリロードしたところ、Bad Gatewayが発生しました。
1,2分後再度ブラウザをリロードしたところ、index.htmlの内容が変わっていました。
SSMセッションマネージャーでログインして、プロセスIDも見てみます。
プロセスIDが変わっている事も確認できました。
先程予測した通り、AMIを置き換えている間にEC2は停止しませんでしたが、サービスは1,2分程度のダウンタイムが発生しました。
利用する場合は従来通り影響が少ない時間に更新作業を行うと良いでしょう。
しかし、1,2分で更新作業が完了すると考えると、今回のReplace Root Volumeのアップデートの凄さが分かります。
最後に
今回初めてReplace Root Volumeを利用したのですが、想像以上に簡単にできてびっくりしました！
これでますますEC2のセキュリティ対応が便利になると実感しました。
注意点として、AMI IDを入力するボックスでReplace Root Volumeに利用できるAMIを選択する事が出来ますが、記事執筆時点（2022年11月）ではAMI IDと説明しか見ることが出来ません。タグ名が分からないため、AMI一覧などから目的のAMIのIDをコピーする必要があります。
また、「ルートボリュームを置き換える」というページにてカーネルバージョン5のAMIが一覧に表示されませんでした。
今後のアップデートに期待したいです！
