見るからに有用そうなアップデートがリリースされていたので試してみます。
（せっかく、リリース初日に記事書いたのに公開忘れてたので今更ながら）
これまで
EC2のルートボリュームを破壊しちゃった場合、これまでは以下のような手順で実施していました。
手段①
- 破壊前のAMI Backupから新規にインスタンス起動
- バックアップ時点からのデータ変更をできる限りリカバリ
- エンドポイントを1に切り変える ex) ELBの付け替えや、EIPの差し替えなど用途に応じて
手段②
- 適当なインスタンスを起動
- 破壊されたインスタンスを停止し、rootボリュームをデタッチ
- 1のインスタンスに、データボリューム（非root）として2をアタッチして、修復
- 修復したrootボリュームを元のインスタンスに戻してインスタンスを起動し直す
①の方が、シンプルですが、エンドポイントの差し替えが可能な場合のみ、取れる手段であることに注意が必要です。
また、いずれも、サービス停止を伴っていました。
完全に破壊されつくして、サービスも止まっていたなら関係ないかもですが（すぐやるしかない）、復旧作業の実施タイミングが悩ましいところでもありました。
例えば、操作ミスでSSH無効化しちゃったりして、サービス運用は続けられているが、復旧が必要な場合とか。
これから
EC2インスタンスに対する操作で、簡単に、かつ、ダウンタイムなしでrootボリュームを差し替えられるようになりました！
手段②の改良版というイメージです。
条件
以下のいずれかでは、現時点ではこの手法はとれません。
- rootボリュームがインスタンスストアボリュームの場合
- メタルインスタンスのrootボリュームの場合
デモ
1. 下準備
Snapshot（AMIでも可）の取得
超重要です。これがないとどうしようもないことは、以前の復旧手順と変わりません。
バックアップ大事！
破壊
sshdのプロセスを止めちゃいます！
[ec2-user@ip-10-0-0-157 ~]$ sudo systemctl disable sshd
Removed symlink /etc/systemd/system/multi-user.target.wants/sshd.service.
そして、EC2インスタンスをリブート。
無事（？）、EC2インスタンスを要復旧な状態にすることが確認できました。
> ssh -i ~/hoge.pem ec2-user@52.196.184.243
ssh: connect to host 52.196.184.243 port 22: Connection refused
2. 復旧
EC2のトラブルシューティングメニューから復旧
操作は簡単。今回はマネコンで実施しましたが、CLIも提供済みです。
対象のEC2インスタンスに対し、「Monitor and troubleshoot - Replace root volume」を選択します。（下の「Storage」タブからでも可能）
Snapshotにて、予め作成しておいたバックアップを選択。
「Create replacement task」押下。
以上。とても簡単 :)
確認
実施後、すぐに完了。
無事、SSH復活。
> ssh -i ~/hoge.pem ec2-user@52.196.184.243
Last login: Fri Apr 30 01:51:34 2021 from 210.227.234.114
__| __|_ )
_| ( / Amazon Linux 2 AMI
___|\___|___|
https://aws.amazon.com/amazon-linux-2/
1 package(s) needed for security, out of 15 available
Run "sudo yum update" to apply all updates.
[ec2-user@ip-10-0-0-157 ~]$
まとめと注意点
操作があまりに簡単なので、裏で行われているであろうことを図にしてみました。
注意点としては、この操作により、rootのEBSボリュームとしては、新たに作られたものに挿し変わります。
つまり、再度、この操作を実施するためには、このEBSのスナップショットが必要になります。
次のミスに備え、再度バックアップを取っておくことをお勧めします。
参照