はじめに
AWS News Blog（13 JAN 2020）で発表された３つの新機能の中で特に気になったのが、EC2インスタンスを丸ごとバックアップ／リストアできる様になったこと。
・Amazon Elastic Compute Cloud（EC2）インスタンス全体をバックアップできるようになりました。
・バックアップを他のAWSリージョンにコピーできるようになりました。
・完全なファイルシステムではなく、Elastic File Systemファイルシステムから単一のファイルを復元できるようになりました。
これはオンプレミス環境と同等のバックアップ運用ができる様になったと言う理解。
インフラエンジニアにとっては、とてもうれしいことだと思ったので簡単に検証してみた。
結果
バックアップ時にPingが２〜３回ほど落ちた（Ping打っていた端末側の問題か？）、タグが引き継がれ無いなど、正確な評価にはもうちょっと真面目に検証する必要があると思うけど、実運用に耐えれそうな感じがしました。リリースされたばかりなので、細かい設定の検証はこれから。今後のアップデートにも期待できそう。
検証メモ
ⅰ）前提
検証用として適当なインスタンスを作り、適当なアプリをインストールしておく。今回はチャットツールを事前にインストールし適当にコメントを書き込んでおく。
ⅱ）AWS Backupコンソール
マネジメントコンソールで、AWS Backupを開き「バックアッププランを作成」をクリック。
https://console.aws.amazon.com/backup/home
「新しいプランを立てる」をクリックし、適当なバックアッププラン名を入力する。
ⅲ）バックアップルールの設定
適当なルール名を入力して、スケジュールを設定。
バックアップウィンドウの開始時刻は「UTC」なので注意。
「プランを作成」ボタンをクリック。
バックアップルールが作成された。
ⅳ）リソースの割り当て
作成したバックアップルールを選択し「編集する」ボタンをクリック。
適当なリソース割り当て名を入力し、バックアップ対象のリソースを設定。今回はEC2をインスタンスIDを選択しています。その後「リソースを割り当てる」をクリック。
ⅴ）実行待ち
設定した時刻に実行されるのをのんびり待つ、問題なく完了したらしい。
ちなみに自宅のMacからEC2へPingを実行して確認していたところ、バックアップ時にPingが２〜３回ほど落ちた。
64 bytes from 3.214.4.84: icmp_seq=2785 ttl=231 time=299.146 ms
64 bytes from 3.214.4.84: icmp_seq=2786 ttl=231 time=413.337 ms
64 bytes from 3.214.4.84: icmp_seq=2787 ttl=231 time=227.798 ms
ping: sendto: Network is down
Request timeout for icmp_seq 2788
Request timeout for icmp_seq 2789
64 bytes from 3.214.4.84: icmp_seq=2790 ttl=231 time=272.853 ms
64 bytes from 3.214.4.84: icmp_seq=2791 ttl=231 time=205.645 ms
64 bytes from 3.214.4.84: icmp_seq=2792 ttl=231 time=212.596 ms
64 bytes from 3.214.4.84: icmp_seq=2793 ttl=231 time=215.758 ms
64 bytes from 3.214.4.84: icmp_seq=2794 ttl=231 time=232.996 ms
64 bytes from 3.214.4.84: icmp_seq=2795 ttl=231 time=257.120 ms
64 bytes from 3.214.4.84: icmp_seq=2796 ttl=231 time=270.620 ms
64 bytes from 3.214.4.84: icmp_seq=2797 ttl=231 time=286.021 ms
Request timeout for icmp_seq 2798
64 bytes from 3.214.4.84: icmp_seq=2798 ttl=231 time=1012.919 ms
64 bytes from 3.214.4.84: icmp_seq=2799 ttl=231 time=321.436 ms
64 bytes from 3.214.4.84: icmp_seq=2800 ttl=231 time=233.779 ms
Ⅵ）リストア
先ほどバックアップした復旧ポイントを選択し「復元」ボタンをクリック。
復元先のネットワーク設定を選択。
今回は検証なのでインスタンスタイプをあえて変更（t3.smail→t2.micro）、セキュリティグループを異なるもの（default）に設定してみる。その後「バックアップを復元」ボタンをクリックししばらく待つ。
ⅶ）復元後の設定
復元された。インスタンスは指定していた通り「t2.micro」で、セキュリティグループは「Default」だったけど、タグ「Name:AWS Backup」が引き継がれていないこと、IPv4パブリックIPが設定されていない状態だったことは想定外。（良く考えれば当たり前か）
バックアップ元のインスタンスが起動しっぱなしだったので停止。IPv4パブリックIPの付け替え、セキュリティグループの変更を実施。
ⅷ）復旧確認
サーバにアクセスしデータが残っている（正しく復旧できている）ことを確認。投稿していたコメントとかアバター画像とか。あと、キーペアを使用したSSHでのリモートアクセスも出来た。
最後に
今回は単純なバックアップ／リストアの検証を行ったが、インフラエンジニアにとってはうれしいアップデートだった。ますます便利になり素直にうれしい。今回検証した環境は全削除しておいた。