はじめに
お疲れ様です。yuki_inkです。
AWS Backupについて調べる機会があったので、トライ&エラーを含めて記事としてまとめておきます。
今回の設定にあたり参考にした手順は以下です。
クラメソ様、いつもありがとうございます！！
下準備
今回はAWS Backupによるバックアップの取得対象として、EBS、RDS、S3を対象にしてみます。
- EBS
- RDS
- S3
AWS BackupでS3のバックアップを作成するには、対象のS3バケットでバージョニングを有効にする必要があります。
AWS Backup for Amazon S3 を使用するには、S3 バケットで S3 バージョニングを有効にする必要があります。 AWS ではデータ保護のベストプラクティスとして S3 バージョニングを推奨しているため、この前提条件を維持しています。
S3 バージョンのライフサイクル有効期限を設定することをお勧めします。 ライフサイクルの有効期限を設定しないと、AWS Backup が S3 データの期限切れになっていないバージョンをすべてバックアップして保存するため、S3 のコストが増加する可能性があります。 S3 ライフサイクル ポリシーの設定の詳細については、このページの手順に従ってください。
バックアップの作成
バックアップボールトの作成
まず、バックアップボールトを作成します。バックアップボールト（Backup Vault）は、バックアップを格納する倉庫のようなものです。作成されたバックアップは、こちらのバックアップボールトに保存されます。
以下のように作りました。
バックアッププランの作成
バックアッププランは、いつ、どのように、どのリソースのバックアップを取得し、どこに格納するか、を定義するポリシーです。
次のようなことを定義できます。
- 利用するバックアップボールト
- バックアップの頻度
- バックアップの時間帯
- ポイントインタイムリカバリの設定
- ライフサイクルの設定（一定期間後にバックアップをウォームストレージからコールドストレージに移動）
- 対象リソースの選択
今回は以下のように作りました。
AWS Backupでは、直接的に保管世代数を設定することはできません。
「バックアップ頻度」と「合計保持期間」を調整することで、保管世代数を設定します。
「次の時間以内に開始」と「次の時間以内に完了」の設定項目については、以下記事のご説明が分かりやすかったです。
今回は検証なので、それぞれ短めの値にしました。
例えば、「次の時間以内に開始」を最低値の 1 時間に設定した場合、何らかの問題でバックアップを開始できない場合、1時間で「Expired」となります。
そのため、許容できる時間範囲内を広めに設定し、その時間範囲内にて定期的にバックアップを実行するといった形が想定されます。
また、大規模なデータをバックアップする場合は、「次の時間以内に終了」を十分長い期間に設定する必要がありそうです。
要件に合わせて適切な値を設定することが望ましいと考えられます。
次の画面でリソースの割り当てを行います。
ますはEBSのみ設定しました。
リソースの割り当てはかなり柔軟に行える印象です。
雑に「すべてのボリューム」とすることもできますし、個別にボリュームを指定することもできます。
タグの値で対象を指定することもできるようです。
バックアッププランができました。
以下のように表示されます。
「リソースの割り当て」にRDSとS3も追加していきます。
-
RDS
ついでにAuroraも対象にしておきました。
-
S3
S3はバケット指定で設定してみました。
設定完了！
繰り返しになりますが、AWS BackupでS3のバックアップを作成するには、対象のS3バケットでバージョニングを有効にする必要があります。
バージョニングが有効化されていないバケットを割り当てに追加しようとすると、以下の通りエラーが表示されます。
取得されたバックアップの確認（失敗例）
「ジョブ」画面から、各バックアップの取得のステータスを確認します。
…おや（ ＾ω＾）？
以下、失敗例としてありのままお届けします。
あるあるなミスだと思うので、他山の石としていただければと思います・・・
失敗① RDS停止時はバックアップの取得ができない
まず、RDSのバックアップが失敗していました。
費用削減のためにRDSを停止してしまっていたんですが、それが原因でバックアップの取得に失敗しました。
この挙動はRDSのバックアップウィンドウと一緒ですね。
おとなしくRDSを起動させました。
失敗② IAMロールの権限不足
S3のバックアップも失敗していました。
詳細を確認すると、 Your backup job failed as AWS Backup does not have permission to describe resource arn:aws:s3:::awsbackup-test-1. Please review your IAM policies to ensure AWS Backup can protect your resources. とのこと。
いや、「デフォルトのロール」にその権限付いてないんかい！
以下の記事に助けられました。
AWS Backupにはデフォルトロールの用意がありますが、S3のポリシーは含まれていません。
AWS管理ポリシーにS3Backupのポリシーは用意されています。
（出展）AWS Backup for Amazon S3を使ってみた
というわけで、デフォルトのIAMロール AWSBackupDefaultServiceRole に以下のAWS管理ポリシーを追加。
- AWSBackupServiceRolePolicyForS3Backup
- AWSBackupServiceRolePolicyForS3Restore
取得されたバックアップの確認（成功例）
いろいろありましたが、結果的にバックアップが取得されていることが確認できました。
「バックアップボールト」画面からも、復旧ポイントという形で確認できます。
各サービスの画面上での確認
AWS Backupにより取得されたバックアップが、各サービスの画面上でどのように表示されるのか、確認してみました。
EBSのバックアップ
普通のスナップショットと同様に、スナップショットとして表示されました。
説明欄で This snapshot is created by the AWS Backup service. と記載されているのがポイントですね。
RDSのバックアップ
RDSの「スナップショット」画面の「バックアップサービス」のタブから確認できました。
スナップショット名にジョブIDが付与されています。
S3のバックアップ
見つけられませんでした。。
そもそもS3ってそもそもが高可用性で、バックアップ取る必要ないよね！！
いやいや、ランサムウェア対策としては、定期的にS3の断面をバックアップとして取得しておくのは大事なんですよ、
という話は後日続編で書こうと思いますw
(追記) AWS Backupの設定後に追加したリソースのバックアップ取得について
EBSとRDSについては、リソースの割り当ての際にすべてのリソースを指定しました。
とはいえ、その設定時点では作成されていなかったリソースについては、ちゃんとバックアップを取ってくれるのだろうか？
心配になって確認してみました。
結果、設定後に追加したリソースのバックアップについても問題なく取得してくれました。
EBSのバックアップ
EBS「test3」を新規作成。
次回のバックアップのタイミングで、「test3」のスナップショットが作成されていました。
RDSのバックアップ
RDS「database-2」を新規作成。
次回のバックアップのタイミングで、「database-2」のスナップショットが作成されていました。
終わりに
思ったより長い（冗長な…）記事になってしまったので、ここで区切りたいと思います。
次はバックアップからの復元と、ランサムウェア対策たりえる「ボールトロック」機能の検証をやってみます。
最後までお目通しいただき、ありがとうございました。