今まで EC2 インスタンスや EBS のバックアップには cron でスクリプトを回したり CloudWatch Events のスケジュールからの Lambda とかでしかやったことなかったので、Amazon Data Lifecycle Manager (DLM) と AWS Backup を EC2 と EBS だけでですが試してみました。
Amazon Data Lifecycle Manager (DLM)
DLM はあくまでも EBS ボリュームのスナップショットが作られるだけです。リソースタイプに「インスタンス」を指定すればタグの条件は EC2 インスタンスに掛かりますが、作られるのはインスタンスにアタッチされている EBS ボリュームのスナップショットだけです。なのでインスタンスをリストアするときはスナップショットから AMI を作ってインスタンスを開始する必要があります。
そもそも、大抵のサービスでは EC2 インスタンスは Disposable なものだろうので、それでも DLM のようなものが必要だとすればそれは何かしらの事情で EC2 インスタンスで RDBMS や KVS のようなストレージ系のソフトウェアを実行しているケースで、その場合はルートボリュームとデータボリュームを分けて考えて、ルートボリュームは Disposable でインスタンスをリストアするときは別のインスタンスを新規に作ってデータボリュームをアタッチ、みたいなことをやるので、AMI を定期的に作成する必要はないことが多いように思います。
また、それを見越してかどうかわかりませんが、リソースタイプに「インスタンス」を指定した場合に「ルートボリュームのスナップショットを除外」というオプションが選択できます。
AWS Backup
バックアップ対象は DLM と同じようにタグで指定するか、特定のリソースを個別に指定することもできます。
タグを指定する場合、どの種類のリソースを対象にするかは指定できません。AWS Backup がサポートしているすべてのリソースからタグがマッチするものがバックアップ対象になります。
そのためなのかどうかわかりませんが、AWS Backup が利用可能なサービスが追加されたとき、デフォルトでは無効になっており、有効にするためには AWS Backup のマネジメントコンソールからオプトインする必要があります。
自分のアカウントでは DynamoDB / EBS / EC2 / EFS / RDS / Storage Gateway が有効になっていて、Aurora だけ無効になっていました。
もし AWS Backup がサポートするサービスが新しく追加されたときにデフォルトで有効になっていると・・たまたまタグがマッチしたリソースが知らないうちにしれっと AWS Backup の対象になってしまい困ってしまいますね。でもその心配はありません。
AWS Backup for EC2
EC2 インスタンスを AWS Backup でバックアップすると、インスタンスのすべての EBS スナップショットと AMI が作成されます。
さらに、インスタンスタイプ・VPC・サブネット・セキュリティグループ・インスタンスプロファイルの情報もバックアップされ、AWS Backup のマネジメントコンソールからバックアップを選択して「復元」すると、それらも元の情報が復元されます（復元時に変更もできる）。
ただし、インスタンスプロファイルを復元するためには AWS Backup がバックアップジョブに使用する IAM Role で追加の設定が必要です。デフォルトの IAM Role だと以下のようなエラーになりました。
You are not authorized to perform this operation. Please consult the permissions associated with your AWS Backup role(s), and refer to the AWS Backup documentation for more details.
インスタンスプロファイル無しなら AWS Backup のデフォルトのロールでも復元できるので、復元後に EC2 のマネジメントコンソールでインスタンスプロファイルを設定することもできます。
また、ユーザーガイドによると下記はバックアップされないとのことです。
- Elastic Inference アクセラレーターの構成 (インスタンスにアタッチされている場合)
- インスタンスが作成されたときに使用されるユーザーデータ
ユーザーデータで起動時に bootcmd とかでなにかやる前提になっていたりすると、「復元」しただけでは上手くリストアできないかもしれないので注意が必要そうです。
AWS Backup for EBS
EBS ボリュームがバックアップの対象になった場合は単に EBS スナップショットが作られます。 このとき、AWS Backup のマネジメントコンソール上からバックアップの復元を行なうと、EBS ボリュームだけでなく Storage Gateway のボリュームとしてもリストアできます。Storage Gateway は使ってみたことないのでよくわかりません。
試しに EBS ボリュームのバックアップから復元をしてみたのですが・・ EC2 のマネジメントコンソール上では EBS ボリュームが既に利用可能になっているにも関わらず、AWS Backup のマネジメントコンソール上ではステータスが10分ぐらい「実行中」のままになっていました（EC2 インスタンスの復元でも同じような状態だったかも）。
AWS Backup の復元ジョブがスナップショットから作成した EBS ボリュームの状態をポーリングしてステータスを把握していてその頻度が10分毎だから、とか？
なお、「実行中」になっている間に EC2 のマネジメントコンソールから復元された EBS ボリュームを削除すると、AWS Backup の復元ジョブは「失敗」になりました。あたりまえですが復元が完了した後に復元された EBS ボリュームを削除してもステータスは変わりませんでした。
AWS Backup の用語とか
バックアッププラン
バックアップルールやリソース割り当てをまとめたもの。 ひとつのバックアッププランにはバックアップルールやリソース割り当てを設定できる。
バックアップルール
バックアップのスケジュール・保持ルール・バックアップ先のバックアップボールトを持つ設定。
リソース割り当て
バックアップ対象とするタグやリソースIDの設定。
バックアップボールト (Backup vault)
バックアップを論理的にグループ化するもの。
AWS KMS キーを設定として含むけれども、それが使われるのは今のところ EFS のみ。
バックアップルールとは N:N の関係で、複数のルールに同じバックアップボールトを指定することもできる。 AWS Backup を初めて利用したときに Default というバックアップボールトが自動で作例される。 このバックアップボールトは削除できない。
ジョブ
バックアップや復元やリージョン間コピーを行なうジョブ。
クリーンアップ
素振りのための構成は CDK で作っていたので cdk destroy で綺麗さっぱり・・にはなりません。次のリソースは個別に削除する必要があります。
- DLM が作成した EBS スナップショット
- AWS Backup が作成したバックアップボールトおよび復旧ポイント
- リストアした EC2 インスタンス
- リストアした EBS ボリューム
バックアップボールトはその中に含む復旧ポイントをすべて削除しないと削除できません。 そしてマネジメントコンソールからは復旧ポイントを一括で削除できないようなので、復旧ポイントがたくさんあると削除が面倒でした・・・
さいごに
DLM は単に EBS スナップショットが自動で作られますー、というだけのものなのに対して、AWS Backup はバックアップボールトとかでバックアップそのもの（復旧ポイント）まであわせて管理されるのが大きな違いのようです。
そもそも大抵のサービスでは EC2 インスタンスは Disposable なものになるだろうと思うので、そういう場合にバックアップが必要かと言われるとうーん？という気もしていましたが、ちょっとした社内ツールで 1 インスタンスでデータもインスタンス内で持っていてRPOも24時間とかで十分ですよ、ということはよくあるので、そういうケースでは AWS Backup を使っておけばよいだろうと思いました。
あえて DLM を使うケースは・・うーん、ルートボリュームをどうしても含めたくないときでしょうか。具体的なケースは思い当たりませんが、DLM のほうがシンプルな分、運用負荷は小さいでしょうか、あまり変わらない気もしますが。
