ただのやってみた系で個人の感想です。

はじめに

対象リソースはAurora, DDB, EBS, EC2, EFS, FSx, RDS, Storage Gateway などありますが今日はEBS(ただ、考え方や基本操作はRDSでもEC2でも同じです)
ここではタグをbackup:trueで付けているEBSを対象としました。試す場合はタグを付けておいてください。
- 途中からEC2とRDSも同じタグを付けて、本文修正したので若干画面キャプチャがアレですが、EBSを軸に見てもらえればだいじょぶです。
AWS Backup ではバックアップ対象のリソースをタグベースで指定することが基本。環境とかチームとか言うタグで環境単位/チーム単位でバックアップという世界観がありそう。対象リソースが限られてる。
この記事では、アクセス管理には踏み込みません

AWS Backup用語

用語の理解が最初難しいかも。今はざっくりと理解してもらいあんまり気にせず、実際のEBSのバックアップ復元操作を進め最後に用語の意味を振り返ります

バックアップボールト：EC2のバックアップである AMI 、RDS のバックアップであるスナップショットなどをまとめて管理する単位。暗号化や権限管理もこの単位。
バックアッププラン：バックアップのスケジュールと対象リソースを定義
復旧ポイント：リストアする単位で、バックアップ時の情報が記録されている。EBSならスナップショットIDとか。
ジョブ：バックアップや復元の処理のこと。ジョブのメニューからジョブのステータスが確認出来てジョブ停止操作も出来て、ジョブの履歴が残り確認出来る
保護されたリソース：バックアップしたリソース。EBSとかRDSとかのリソースIDがリストされる。

AWS Backup操作

EBSを例にバックアップやリストアをやってみます

バックアップボールト作成

とりあえず意味は考えず作っちゃいます。

"バックアップボールト"をクリックし、[バックアップボールトを作成]をクリック

以下を入力して右下の[バックアップボールトを作成]をクリック

バックアップボールト名：demo-vault
暗号化キー：(デフォルト)aws/backup

オンデマンドバックアップ

名前の通りだけどオンデマンドでバックアップすること。
"保護されたリソース"をクリックし、[オンデマンドバックアップを作成]をクリック

次の値を入れて右下の[オンデマンドバックアップを作成]をクリック

リソースタイプ：EBS
ボリュームID：任意のボリュームID
今すくバックアップを作成(1時間以内に実行)：チェック
保持期間：常時(これは常時取っておく。バックアップを消さないという意味。期間を指定すれば期間が来たら自動削除ができます)
バックアップボールト：demo-vault
IAMロール
- デフォルトのロール：チェック

すぐにジョブが作成されます。ただ、デフォルトでは1時間以内のタイムウインドウでの実行になります(1時間が最短)。タイムウインドウをカスタマイズした場合はそのタイムウインドウでの実行になります。つまり、オンデマンドバックアップは、指定したタイムウインドウでバックアップを行うジョブの定義で、バックアップそのものはバックアップウインドウに従い実行されます。

注意点としては、オンデマンドバックアップのこの定義自体は残りません。
あと、オンデマンドバックアップだと、クロスリージョン、クロスアカウントの設定項目がないので出来なそう

EBSの復元

"復旧ポイント"はバックアップで作成したリソース(EBSであればボリュームIDやスナップショットIDを示します)やバックアップした時間を示すものです。AWS Backupではこの復旧ポイントからAWSリソース(データ)を復元します。
復旧ポイントは以下の2箇所(以下の①と②)から辿れます

①バックアップボールト=>demo-vault=>復旧ポイントID(対象のバックアップ)にチェック=>右上の[アクション]から[復元]をクリック

復元するEBSのタイプや容量やAZなど任意で変更し復元できます。

②保護されたリソース=>対象の復旧ポイントID(バックアップ)にチェック=>右上の[復元]をクリック

あとの操作は①と同じです。

スケジューリング

AWS Backupでバックアップのスケジューリングは"バックアッププラン"で行います。

AWS Backupの"バックアッププラン"をクリックし、右上の[バックアッププランを作成]をクリック

次を入力し、[プランを作成]をクリック

新しいプランを立てる：チェック
バックアッププラン名：demo-plan
バックアップルール名：demo-rule
バックアップボールト：demo-vault (事前に作ったもの)
バックアップ頻度：カスタムcron式
cron式：cron(0 0/1 ? * * *) (1時間おき)
バックアップウインドウをカスタマイズ
- 次の時間以内に開始：1時間
- 次の時間以内に完了：2時間

※ あとで出てきますが、コピー先として別リージョンの指定もできます。コピー先として別アカウントのボールトの指定も出来る(つまり別アカウントの別リージョンへのコピー)。

作成したバックアッププランをクリックし、[リソースを割り当てる]をクリックし、このバックアッププランの対象となるリソースを定義します。

リソース名：demo-resource
リソースにアクセスするIAMロール:デフォルト
リソースを特定するタグ：backup:true

リソースはタグで指定する感じです(またはリソースIDを直接指定)。ここではタグをbackup:trueで付けているEBSを対象としてます。

時間になったら動き出します。基本的にタイムウインドウをベースに動くので、ジョブとしては指定した毎時の14:00に実行され(多分キューイングされ)、実際のバックアップはタイムウインドウの1時間以内の開始である14:04:40に開始されています(多分)。対象のEBSリソースもタグで指定したものになってます。

バックアッププランのイメージ図はこんな感じ

この辺ほしい

作成したバックアッププランを任意のタイミングで手動実行は出来なそう。バックアッププランはジョブの定義としても残るので、なにかの原因で失敗したとか、データやアプリに手を加える直前などの任意のタイミングでも実行できたらいいなと思う。

リトライとかなさそうなので欲しい。スケジュールの簡単なスケジュールオンオフがない。欲しい

あと、Glacierへのローテーション設定はないっぽい。

クロスリージョン/クロスアカウント

クロスリージョンにバックアップ実行

先程のバックアッププランを、大阪リージョンにもバックアップを取得するように修正します。

バックアッププランで作成されたバックアップルールを選択し、[編集する]をクリック

以下の修正を加える

コピー先にコピー - オプション：アジア・パシフィック(大阪)
送信先バックアップボールト：Default

スケジュールされた時間になると実行されます。

実行結果

メニューの"ジョブ"=>"コピージョブ"タブをクリック。別リージョンにバックアップジョブ、つまり別リージョンへのコピージョブの履歴が確認できます。EBSが大阪リージョンへコピーされていることがわかります(※EC2, RDSにも後からタグ付けたのでバックアップ対象になってます)。EBSのコピージョブIDをクリックしてみます。

ジョブが完了したこと、復旧ポイントがわかります。
あと、アカウントIDxxのソースリージョン東京のバックアップボルトtmp-vaultから、アカウントIDxxの送信先リージョン大阪のバックアップボルトDefaultにEBSのスナップショットがコピーされていることがわかります。
大阪リージョンのEBSスナップショットIDは"snap-02aaa..."です。実際に存在するか確認してみます。

スナップショットID"snap-02aaa..."のスナップショットが大阪リージョンにできていることが確認できます。"説明"にもAWS Backupからコピーされていることがわかる内容が書かれてます。

クロスアカウント

また、クロスアカウントへのコピーは以下の画面のように"別のアカウントのボールトにコピー"をクリックし、"外部ボールトARN"にARNを入力します。今回は試してない。

運用時のよくありそうな操作

リソース単位で確認
- "保護されたリソース"をクリックし、AWS Backupの管理下にあるリソースの確認。対象リソースをクリックしてバックアップや復元操作
すぐにバックアップ取得
- 保護されたリソース=>対象のリソース(EBSとかEFSとかそれぞれのID)選択=>[オンデマンドバックアップを作成]クリック=>対象リソースに対するバックアップ(対象リソースが選ばれた状態で、オプション設定し[オンデマンドバックアップを作成]で実行)
復元
- 保護されたリソース=>対象のリソース(EBSとかEFSとかそれぞれのID)選択=>対象の復旧ポイントにチェックを入れ[復元]をクリックし、復元のオプション入れて[バックアップを復元]
ジョブの確認
- "ジョブ"をクリックして、バックアップ/復元/コピーのジョブの履歴を確認する。完了やエラーなどのステータス、対象リソースID、実施日、復旧ポイントARNなど
- Organizationの親で有効化していれば、"クロスアカウントモニタリング"をクリックして、他のAWSアカウントのジョブの状態確認も可能
ボールト単位で確認
- "バックアップボールト"をクリックし、AWS Backupのバックアップボールトの管理下にある復旧ポイントの確認。復旧ポイントを選択してコピー,削除,編集,復元の操作が出来る
  - ※"保護されたリソース"からの復旧ポイントへの操作時は復元のみなので、この点は出来る操作に違いがある。
  - 復旧ポイントIDを見つけたり絞り込むには「リソースID」でフィルタリングするのがお勧め。例えばEBSだったら"volume/vol-05003f8ba0f210ab3"でフィルタすると、このリソースIDの復旧ポイントIDのみリストが出来て、削除する時など捗る。
  - ちなみに削除は、保護対象のネイティブサービスから行うことは出来ない。EBSスナップショットをEBSの画面から行うとエラーになる。ここからしかできない。
バックアップ失敗をSNS通知
- SNSトピックを作り、AWS Backupのput-backup-vault-notifications APIでAWS Backupの通知をSNSトピックに送信する設定する。SNSでCompleted以外を通知するフィルタリングする感じ
モニタリング
- NumberOfBackupJobsAborted「AWS Backup がスケジュールしたのに開始しなかったバックアップジョブの数」、NumberOfBackupJobsFailed「AWS Backup が試行したが完了できなかったバックアップジョブの数」など、バックアップジョブの状態を確認するメトリクスは揃ってる印象。あとはCWのアラーム機能で検知すればモニタリングは良さそう

用語の振り返り

バックアップボールト：
- AWS公式ではバックアップが保存されるコンテナという説明。
- 定義する項目は、名前、暗号キー(デフォルトでaws/backupというキーあり)、タグ。あとからアクセスポリシーをアタッチできる
- アクセスポリシーは、組織からバックアップボルトへのアクセスを許可する。バックアップボルトへのアカウントレベルのアクセスを許可する。などが設定できるもの。
- オンデマンドバックアップ、バックアッププランのいずれでもバックアップボールトは必須の設定
- アクセスポリシーや暗号化キーなどが含まれることから、これらの観点で管理する単位と考え作成すると良さそう。大きい組織では分ける。権限分けたければ組織やチームで分ける。他チームから見られたり操作されたくない単位で分ける感じか。

復旧ポイント："バックアップボールト"で任意のバックアップボールトを選びその中に"復旧ポイント"がある。あと、"保護されたリソース"で任意のリソースを選びその中に"復旧ポイント"がある。

保護されたリソース
- "バックアップボルト"内の取得されたバックアップのリソースは、バックアップの基となるリソースとして"保護されたリソース"に登録される
- "保護されたリソース"側からリソースの削除はできない。復旧ポイントの削除もできない。これらはボルト側から復旧ポイントを削除する形で行い、復旧ポイントの削除がされ、復旧ポイントの削除に伴い対象のリソースがなくなれば結果的にリソースが削除されることになる
- 簡単な操作として、ボルトを横断したリソース確認が出来る。リソースのオンデマンドバックアップを簡単に設定実施が出来る。復旧ポイントからの復旧が簡単に行える
- バックアップが1度でも実行したら表示される。一度も実行してないと表示されない

感想

基本は「タグでリソース指定」「タイムウインドウ制御でのバックアップやリストア実行」。これらの制約が問題なければいいかも
バックアップの一元管理として、バックアップボルトの中に復旧ポイントが作られる。バックアップの取得状態、対象を選択してリストア。実行した各処理のジョブ履歴管理。管理するリソースのリスト表示。などはバックアップという観点で見通しがいい。RDSやEBSなどそれぞれでバックアップの操作をする必要がなくなるメリットは大きい
ボルトを決めないと始められず、どのような単位で切るべきか自由度が高くそこが手始めしずらいかも。ボルトが決まってしまえば、ボルトの単位でバックアップの状況の整理と見通しは良くなる
タグなどを使い大量なリソースに対して、正確な時間は気にせずリトライなども気にせずざっくりとバックアップを実現したい時は楽が出来る。一定期間残す設定もありバックアップのライフサイクルを作れ、別リージョンへのバックアップを含めて一元的な管理は満たせると思う

参考

AWS Backupの薄い教科書
https://qiita.com/pioho07/items/68ccbc7b974b1466e7a6