はじめに
前回の記事では、DRに紹介しました。
今回はDRアプローチの1つバックアップ＆リストアを行う際に有効なAWS Backupについて紹介します。
最初にざっくりの全体像です！！
AWS Backupとは？
AWSサービス全体のデータのバックアップ取得から復旧プロセスまで一元的に管理・自動化をすることが出来るサービスです
AWS Backupを利用することで以下のようなメリットがあります。
- AWSとアプリケーションリソースデータ保護を簡素化
- DRと事業継続の基盤を構築
- ランサムウェアやアカウント侵害から保護およびリカバリ
- データ保護コンプライアンスを管理
(おさらい)バックアップ＆リストアとは
データの損失や破損を軽減するアプローチです。
データをDR先にレプリケートすることでリージョンの災害を軽減したり、単一のアベイラビリティーゾーンにデプロイされたワークロードの冗長性の欠如を軽減したりするために使用できます
具体的にバックアップ＆リストアを行うためには、どんなプロセスがあるかというと以下の4つになります。
- バックアップの設計
- バックアップの保護
- バックアップの自動化
- バックアップの復旧
では、AWS Backupの各機能がこれらの4つのプロセスにどう関係していくか説明していきます。
AWS Backupの全体
まず、AWS Backupの全体としては以下のようになります。
ざっくり言うと、
- バックアップしたいAWSサービスを決めて
- どのくらいの頻度でバックアップするか決めて
- どのくらいバックアップを保存するか決める
という感じです。
図に出てくる各用語については、以下のようになります。
※詳細はこの後説明します
AWS Backupの各機能とプロセスの関係
AWS Backupの各機能がどのプロセスに対応しているかですが、以下のようになります。
各機能の説明
では、各機能について実際に触りながら説明していきます。
今回は、同一アカウントに作成した東京リージョンのS3バケットから大阪リージョンのS3バケットに、バックアップを行って、大阪リージョンで復元するところまで試してみます。
0. S3バケットの作成
まず、東京リージョンと大阪リージョンにバケットを作ります。
- 東京リージョンに
aws-backup-source - 大阪リージョンに
aws-backup-target
というバケットを作って、東京リージョンのバケットに適当なファイルをアップロードしておきます。
注意点として、AWS BackupでS3のバックアップを作成する際は、バージョニングを有効にする必要があります。
また、ライフサイクルで有効期限を設定して不要なオブジェクトの削除を行わないと、過去バージョンのオブジェクトのバックアップもしてしまうので、コストがかさんでしまいます。
S3のバージョニングとライフサイクルって何だろう？って思った方は、以前書いたこちらの記事を見てください
1. バックアップボールトの作成
ここからAWS Backupの設定をしていきます。
バックアップボールトのボールト(Vault)は日本語だと保管庫を表し、AWSの定義としては復旧ポイント(バックアップ)を保存・整理するコンテナになります。
お金を保護する金庫みたいな感じですかね？ 
プロセスとしてはバックアップの保護にあたります。
バックアップボールトで、特定の復旧ポイントを選択して復元操作を行うことで、任意の状態にデータを復元することが出来ます。
次に、バックアップボールドに付随する機能について説明します。
ボールトロック
その名の通り、指定したバックアップボールトを指定した期間ロック(変更/削除出来ないようにする)機能です。
ボールトロックにはガバナンスモードとコンプライアンスモードの2つがあり、コンプライアンスモードでロックしたバックアップボールトは、rootユーザであろうと指定した期間は削除できなくなるので、注意が必要です。
リーガルホールド
次にリーガルホールです。日本語だと法律上の保持ですかね？
これはボールトロックと似ているのですが、AWS Backupで取得したバックアップの保持期間を延長する機能です。
例えば、バックアップの保持期間が30日に設定されてバックアップされているとします。
しかし、監査や不具合調査の難航など、何かしらの理由で延長したいとなった場合に、後述のバックアッププランでの保持期間延長だと既存のバックアップに対しては適用されません。
そういったケースの場合に、リーガルホールドを適用することで、その間は保持期間のカウントを停止することが出来ます。
ボールトロックとリーガルホールドの違いは以下になります。
１．ボールトロックの適用範囲はバックアップボールトだけだが、リーガルホールドはリソースタイプとバックアップの作成日の範囲選択(過去日のみ)が可能
２．ボールトロックのコンプライアンスモードはrootユーザーであっても解除できないが、リーガルホールドはIAMで権限があれば解除できる
３．ボールトロックしていてもバックアップの保持期間が経過したものは削除される
なので、使い分けけとしては
- バックアップの手動削除を防ぎたい👉ボールトロック
- バックアップの自動削除を防ぎたい👉リーガルホールド
かなと思います。
アクセスポリシー
最後にアクセスポリシーです、
これは他のAWSサービスと同様、リソースへのアクセスを制限するポリシーです。
プロセスとしてはバックアップの保護にあたります。
大阪リージョンにもバックアップボールトを作成
クロスリージョンでS3のバックアップを取る場合は、コピー先の大阪リージョンにもバックアップボールトを作る必要があるため、先ほどと同様に作っておきましょう
2. バックアッププラン
バックアップボールドを作ったので、そこに割り当てるバックアッププランを作成していきます。
プロセスとしてはバックアップの設計、バックアップの自動化にあたります。
以下の項目を入力していき、バックアッププランを作成し、プランに対してバックアップルールの作成と、リソースの割り当てを行います。
バックアッププランはただの箱みたいなものなので、特に設定値はありません。
また、バックアップルールは複数作成でき、リソースの割り当ても複数行えます。
バックアップルールとして、以下を入力します。
- バックアップボールトに、先ほど作成したボールトを選択
- バックアップ頻度を
毎時、12時間毎、毎日、毎週、毎月、カスタムcron式から選択 - バックアップの開始時間を選択
- 保持期間を1日～永続から選択
- 1秒単位で復元したい場合は、
PITR(ポイントインタイムリカバリ)を設定 ※最大35日前まで
- 1秒単位で復元したい場合は、
- (S3とEBSの場合)
バックアップインデックスを必要に応じて指定- バックアップからファイルパスやファイルサイズなどで検索できる機能(有料)
- コピー先の大阪リージョンを指定し、先ほど作成した大阪リージョンのバックアップボールトを選択
- プロセスとしては
バックアップの保護、バックアップの自動化にあたります
- プロセスとしては
バックアップルールを作成したら、バックアップを行うリソースの割り当てを行います。
-
全てのAWSサービスまたは特定のAWSサービスを選択 - 特定のAWSサービスを選択したら、
全てのリソース or 対象のリソース(S3ならリソース=バケット)を選択- 全てのリソースを選択し、一部のバケットだけ除外なども出来ます
- 全てのリソースを選択し、一部のバケットだけ除外なども出来ます
3. バックアップが出来ていることの確認
では、ここでバックアップが東京リージョンと大阪リージョンで出来ているか確認してみます！
実行されたバックアップはジョブとして実行されるのですが、全てのジョブは一覧で確認することが出来ます。
リソースの割り当てで、デフォルトロールを利用するとバックアップの権限が不足している可能性が高いです。
失敗になっているのはそれが原因でした...
どのリソースをバックアップするかによって、付与すべきポリシーは変わるので適切なポリシーをアタッチするようにしましょう。
※S3ならAWSBackupServiceRolePolicyForS3Backupというマネージドポリシーが用意されています
復旧ポイント(バックアップ)は、保護されたリソースから確認できます。
問題なく、東京リージョンと大阪リージョンでバックアップ出来ていますね
4. モニタリング
ジョブ一覧でバックアップの結果を確認することは出来ますが、毎回結果を人が見るのは運用効率的によくないので、自動化をしたいと思うかもれません。
その場合はモニタリングを行い、バックアップの結果をメールやSlackなどに通知したり、失敗した場合に再度実行させたい場合など行う必要があります。
モニタリングに適した以下の4サービスと、LambdaやSNSなどを使って運用を自動化できます。
プロセスとしてはバックアップの自動化にあたります
5. 復元
バックアップを取得したので、実際に復元してみましょう。
プロセスとしてはバックアップの復旧にあたります
今回は大阪リージョンで試してみます。
保護されたリソースから任意の復旧ポイントを選択します
エラーになりました。どうやらバックアップ先のバケットで復元を行う場合は、ACLを有効にする必要があるようです。 参考
ACL無効化のバケットを作ってしまうと、マネジメントコンソールからは有効にすることが出来ないため、以下のCLIコマンドで有効化します。
aws s3api put-bucket-ownership-controls \
--bucket aws-backup-target \
--ownership-controls Rules=[{ObjectOwnership=ObjectWriter}]
再度、実行すると問題なく復元が完了し、対象のS3バケットにオブジェクトが保存されていました
ACLは無効化が推奨なので、復元する時だけ有効化して完了次第、無効に戻すのが良いかもしれません
aws s3api put-bucket-ownership-controls \
--bucket aws-backup-target \
--ownership-controls Rules=[{ObjectOwnership=BucketOwnerEnforced}]
6. 復元テスト
最後に復元テストです。
これは全てor特定のバックアップボールトの復元が行えるか定期的にテストをするための機能になります。
復旧にかかった時間の計測も行えるので、RTOを満たせるかどうかの確認も行え、DRの予行演習をサポートできます。
プロセスとしてはバックアップの自動化、バックアップの復旧にあたります
テスト言いつつ実際に復元をしますが、復元したデータはすぐに削除することも出来ますし、何かしらの検証プロセスが必要であれば一定時間保持することも出来ます。
試しに先ほど作成したS3のバックアップボールトのバケットに対して、毎日テストを実行するように設定してみます。
復旧ポイントは最新またはランダムを選択することが出来るので、過去分の復旧テストも簡単に行えます！
テストが問題なく実行できていることが確認出来ました！必要に応じてアプリケーションの復旧などを組み込んで、DRが正常に行えるか試すために使うといいかと思います。
各AWSサービスのバックアップ機能と何が違うのか？
一部のAWSサービスには、バックアップ機能が搭載されています。
S3であれば、バージョニング機能によって過去世代のオブジェクトは復元することが出来ますし、S3レプリケーション機能を使えば他のリージョンにバックアップを取ることも出来ます。
AWS Backupとバージョニングの違いとしては、
- バケット自体を復元できるか
- AWS Backupは復元できる
- バージョニングは復元できない
- 特定の地点にバケットを復元できるか
- AWS Backupは特定の地点に復元できる
- バージョニングは特定の地点に復元できない
AWS BackupとS3レプリケーションの違いとしては、以下があります(スカイアーチさんがまとめてくれたものです)
それぞれメリット/デメリットがありますので、用途に応じて使い分ける必要がありそうです。
料金
最後に料金ですが、AWS Backupは主に以下で課金されます。
おわりに
今回は、AWS Backupについて紹介しました。
バックアップ周りって勉強が後回しだったりするので、とてもいい勉強になりました