AWS BackupによるS3バックアップ – S3レプリーションとの比較 | クラウド・AWSのIT技術者向けブログ SKYARCH BROADCASTING

はじめに

AWSのシステム構築において悩みの種のひとつが、「どうやってバックアップを行うか」になります。
EC2のAMIを保存 / RDSのスナップショットを保存 / S3に保存と バックアップ対象により、その手段を講じる必要があります。

今回、AWS Backupにおいて新たにS3がサポートされることになったので、
バックアップに焦点を当て、実際にS3のバックアップを確認してみたいと思います。

AWS Backup についておさらい

AWSにおけるバックアップ

本題に入る前に、AWSにおいてもデータのバックアップは非常に重要になるのは周知の事と思います。

基本的には、各サービスでそれぞれバックアップの取得が可能です。

RDS：スナップショットの取得  
EC2：イメージを作成(AMIを作成)  
EBS：スナップショットの作成

RDS：スナップショットの取得

EC2：イメージを作成(AMIを作成)

EBS：スナップショットの作成

これらのバックアップの取得を自動化する仕組みも様々な手段が存在し、サービス単体で実現可能なものも多いです。

RDS：自動バックアップの設定　/ リードレプリカへのレプリーケーション  
EC2：CI/CDパイプラインにバックアップを仕組む / Lambda等で定期取得  
S3 ：ライフサイクルで設定  / バージョンニング / S3レプリケーション

RDS：自動バックアップの設定　/ リードレプリカへのレプリーケーション

EC2：CI/CDパイプラインにバックアップを仕組む / Lambda等で定期取得

S3 ：ライフサイクルで設定 / バージョンニング / S3レプリケーション

※バックアップとレプリケーションは目的が違うものですが、単方向レプリケーションをバックアップに近い位置付けで記載いたします。

しかし、サービス毎に手段が存在すると、ぞれぞれに操作・参照が必要になり、管理が複雑になってしまうのが現実です。
また、当然ながら各サービスのスキルも必要になってきます。

そこで登場するのが「AWS Backup」であり、バックアップにおける管理負担を減らすことができます。

システムによってはバックアップ要件が統一されている事も多く、「バックアップ」という要件自体をAWS Backupに丸投げできてしまうメリットも出てきます。

AWS Backupのサポート対象

EC2, EBS, S3, RDS, DynamoDB, Amazon Neptune, Amazon DocumentDB, EFS, FSx, AWS Storage Gateway

※オンプレミスのVMware仮想マシンもバックアップ可能です。

AWS BackupのS3対応

今回の本題です。

バックアップは様々な方法があると前述しましたが、バックアップ先の実体はS3となっていることが多いと思います。

しかし、S3自体のバックアップは疎かにしてしまいがちです。
やはり、99.999999999％（イレブンナイン）の耐久性と99.99% （フォーナイン）の可用性を信頼している人が多いと思います。
どうしても「9」という数字魔力で、感覚的に信頼してしまいます。

また、S3単体でも「バージョニング」や「レプリケーション」を設定できることにより、既に必要十分なバックアップ機能を備えているシステムが殆どではないでしょうか。

そんな中、AWS BackupによってS3がサポートされました。
バックアップを実践してみるとともに、既存のバージョニングやレプリケーションとの違いを見ていきたいと思います。

アップデート概要

AWS Backup でサポートされる一連のサービスに Amazon S3 を追加することを発表します。コンピューティング、ストレージ、データベースに関する AWS のその他のサービスとともに、Amazon S3 に保存されているアプリケーションデータのバックアップと復元を集中的に自動化することが簡単になります。

AWS Backup for Amazon S3 の一般提供を発表

AWS Backup(S3)の実践

実際にAWS Backupを使ってS3のバックアップを試してみます。
このような形を目指します。

＜AWS Backup の用語について＞
バックアップボールト：バックアップの格納先です
バックアッププラン：スケジューリングを含めたバックアップのプランです
リソース：バックアップの対象です

＜注意点＞
- 対象のS3バケットは「ACL有効」が必要です。

- 対象のS3バケットは「バージョニング有効」が必要です。

バックアップの設定

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

AWS Backupのトップでは「バックアッププランの作成」から始まりますが、先に格納先であるバックアップボールトを作成する方がわかりやすいので、今回はバックアップボールトから作成します。

まずは、東京リージョンにて、バックアップボールト名とデフォルト暗号化キーを設定し作成します。

また、今回はリージョン間バックアップとして、大阪リージョンにもバックアップを作成します。
マネージメントコンソールのリージョンを切り替えて、同様にボールトを作成します。

※ 結論を記載してしまうとAWS BackupでのS3のクロスリージョンバックアップはサポートされていませんでした(2022年4月現在)。
S3を選択しても送信先バックアップボールトの設定は出来てしまうのでご注意ください。

バックアッププランを作成

バックアップの頻度や、スケジュールを設定するバックアッププランを作成します。

バックアップのルールの設定で、先ほど作成したバックアップボールトを指定します。
「バックアップ頻度」は毎時 12時間ごと、毎日、毎週、毎月、cron式から設定可能です。
エンジニア的にはcron式で設定する方が楽かもしれません。

＜注意点＞
- cron式であっても1時間未満の頻度は設定できません。

「バックアップウィンドウの開始時刻」は、UTCで設定します。
「バックアップ頻度」で毎時を選択している方は、初回に実行されるバックアップ時刻として捉えてください。
「コールドストレージへの移行」は、有効期限が切れる前により低単価のコールドストレージに移行させることが可能ですが、Amazon EFS、Amazon DynamoDB、VMware 仮想マシンのバックアップでのみ使用可能なため省略いたします。
「保持期間」はバックアップ世代を考慮した期間を設定します。

今回は、大阪リージョンにもバックアップを作成するので、前述の大阪リージョンのバックアップボールトを設定します。

※ AWS BackupでのS3のクロスリージョンバックアップはサポートされていませんでした(2022年4月現在)。
設定は出来てしまうのでご注意ください。

バックアップルールが作成されました。

リソースの割り当て

ここでバックアップの対象を設定します。
また、バックアップに必要なロールもここで設定します。

「特定のリソースタイプを含める」を選択し、対象のS3バケットを指定します。

＜注意点＞
- 「デフォルトのロール」を選択すると、「AWS BackupDefaultServiceRole」がアタッチされますが、S3バケットへのアクセス権が不足しています。
- バックアップおよびリストア用に下記のポリシーをアタッチし、対象バケットへのアクセス権を追加してください。

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Action": [
                "s3:Get*",
                "s3:Put*",
                "s3:List*",
                "s3:Delete*",
                "s3:Create*"
            ],
            "Effect": "Allow",
            "Resource": [
                "arn:aws:s3:::backup-target-xxxxxx-ap-northeast-1",
                "arn:aws:s3:::backup-target-xxxxxx-ap-northeast-1/*"
            ]
        },
        {
            "Action": [
                "events:List*",
                "events:Put*",
                "events:Remove*",
                "events:Delete*",
                "cloudwatch:Get*"
            ],
            "Effect": "Allow",
            "Resource": "*"
        }
    ]
}

{

"Version": "2012-10-17",

"Statement": [

{

"Action": [

"s3:Get*",

"s3:Put*",

"s3:List*",

"s3:Delete*",

"s3:Create*"

"Effect": "Allow",

"Resource": [

"arn:aws:s3:::backup-target-xxxxxx-ap-northeast-1",

"arn:aws:s3:::backup-target-xxxxxx-ap-northeast-1/*"

]

{

"Action": [

"events:List*",

"events:Put*",

"events:Remove*",

"events:Delete*",

"cloudwatch:Get*"

"Effect": "Allow",

"Resource": "*"

}

]

}

より厳密なポリシーを設定したい場合は下記をご参照ください。
Creating S3 backups

なお、ここで「すべてのリソースタイプを含める」を選択すると、
AWS Backupがサポートしているアカウント配下の全てのリソースをバックアップ対象として設定することが可能です。

システムによっては、これだけでバックアップ要件を満たしてしまうことも可能です。

バックアップの確認

ジョブを確認

バックアップ時刻を経過したら、実際のバックアップ結果を確認してみます。
無事にバックアップジョブが成功しています。

バックアップボールトの確認

格納先であるバックアップボールトを確認します。
東京リージョンにS3のバックアップが格納されています。

大阪リージョンには格納されていませんでした。。

詳細を確認するとAWS Backupの対象リソースごとにサポートされる機能が異なっており、S3については、まだクロスリージョンに対応していませんでした。対応サービスであれば同様手順でバックアップが可能です。

リソース別の機能の可用性

リストア

最後にバックアップからのリストアを実施してみます。
バックアップボールトから対象バックアップ(復旧ポイント)を選択し、[アクション > 復元] を実施します。

元のバケットに復元します。

復元に必要な権限を持つIAMロールを指定します。(バックアップと同じロールにしています)

復元ジョブが完了すると、無事にS3バケットがバックアップ時点のデータに復旧しました。

S3レプリケーションやバージョニングとの比較

厳密にはレプリケーションとバックアップは目的が異なりますが、バックアップ目的で使用しているケースも多いのではないでしょうか。
特にS3レプリケーションでは「クロスリージョン」も可能であり、「S3 RTC」をONにすることで、15分以内に99.9%のオブジェクトを複製することも可能です。

なお、AWS Backup同様、S3レプリーションを利用するにはバージョニングの有効化が必須です。

S3クロスリージョンレプリケーションとは

複数のAWS リージョンにある２つのバケット間で、オブジェクトを自動的に非同期にコピーする機能です。
注意点としては、オブジェクト削除のレプリケーションは設定次第ですが、誤ってオブジェクトを削除した場合、レプリーケーション先でも削除されてしまいます。
その場合、バージョニング機能による旧バージョンからの復旧が必要です。

レプリケーションを使用すると、Amazon S3 バケット間でオブジェクトを自動で非同期的にコピーできます。オブジェクトのレプリケーション用に設定されたバケットは、同じ AWS アカウントが所有することも、異なるアカウントが所有することもできます。オブジェクトは、単一または複数の送信先バケットにレプリケートできます。送信先バケットは、異なる AWS リージョンでも、ソースバケットと同じリージョン内でも配置できます。

オブジェクトのレプリケーション - クロスリージョンレプリケーションを使用する場合

S3 Replication Time Control (S3 RTC) を使用してコンプライアンス要件を満たす

バージョニングとは

S3オブジェクトの過去バージョンを保持する手段です。
新規バケットではデフォルトでは無効になっています。これにより誤って削除した場合でも元に戻すことが可能です。
ただし、同一バケット内で保持されるため、リージョン障害時には対応できません。

Amazon S3 のバージョニングとは、同じバケット内でオブジェクトの複数のバリアントを保持する手段のことです。S3 のバージョニング機能を使用すると、バケットに保存されたすべてのオブジェクトのすべてのバージョンを、保存、取得、復元できます。

S3 バケットでのバージョニングの使用

AWS Backup(S3) / S3レプリーション / バージョニングの比較

| 比較項目 | AWS Backup(S3) | S3レプリケーション | バージョニングのみ |
| ---- | :---- | :---- | :---- |
| バックアップタイミング | 最短1時間間隔 | 即時(オブジェクト追加、削除時) | 即時 |
| バックアップ処理時間時間 | バックアップウィンドウに依存
(開始最小1時間以内、完了最小2時間以内) | 15分以内に99.9%のオブジェクトを複製 | 即時 |
| リストア方法 | バックアップボールトから復元操作 | レプリケーション先バケットの使用
レプリケーション先バケットから再コピー
Gracierからの復元 | オブジェクト毎に旧バージョンから復旧　|
| 料金 | S3 バックアップの GB-月あたりの料金
S3 オブジェクトに対する 5 回の GET リクエスト
増分バックアップに必要な EventBridge イベントの料金 | 宛先のS3 ストレージクラスのストレージ料金
プライマリコピーのストレージの料金
レプリケーション PUT リクエストの料金
該当する低頻度アクセスストレージの取得料金
リージョン間データ転送 OUT
S3 レプリケーション時間制御
S3 Batch Replication料金
バッチ操作 – ジョブ
バッチ操作 – オブジェクト
バッチ操作 – マニフェスト(オプション) | バージョニング分のストレージ料金　|
| クロスリージョン | 不可 | 可 | 不可 |

Amazon S3 の料金 - レプリケーション

AWS Backup の料金

バージョニングについては有効化が前提のため、バックアップのコストダウンが最優先という要件にしか合致しないと感じます。

「バージョニングのみ」は除外して、「AWS Backup(S3)」と「S3レプリケーション」を比較してみると、

料金についてはAWS Backupの方が算出が容易ですが、バックアップ速度や自由度についてはS3レプリケーションの方が高いのが事実です。

実際に試してみても、S3レプリケーションの方が直感的に操作でき、エンジニアの立場であれば、実態がちゃんと見える点で、S3レプリケーションの方がしっくりきました。

しかし、AWS Backupにはマネージメントサービスならではの容易性がありました。中身はわからなくとも、おまかせでバックアップをとってくれ、リストアも容易です。

そのため、どちらのバックアップ手法が向いているかは、下記のイメージになります。

検討項目	AWS Backup(S3)	S3レプリケーション
リアルタイム制	不要	必要
バックアップ間隔	日時単位でバックアップしたい	即時バックアップをしたい
バックアップにかかる時間	数時間単位で問題ない	分単位で実施したい
リストア方法	リストアを簡単に簡単に行いたい	最適なリストア手段を検討したい
リストアにかかる時間	AWS Backupに依存	求める時間によりリストア手段を選択したい
クロスリージョン	不要	必要
管理	AWSサービス全般のバックアップを一括管理したい

おわりに

今回はAWS BackupのS3バックアップについて記載しました。

バックアップについてはS3を問わず、RPO/RTO に厳しい条件がなければ、対応AWSサービスを一括でバックアップを取得してくれる点や、ボタンひとつでリカバリできる点においてAWS Backupの便利を非常に感じました。

例えば、自社システムのバックアップは取得したいが、社員のスキルやエンジニアに依存せず、フルマネージドで取得したいといった要件には最適だと思います。

但し、逆にリアルタイムバックアップや、1時間以内のポイントに復旧といった厳しい要件があったりすると、AWS Backupのバックアップウィンドウの都合上、対応が難しいと考えられます。

システム要件に応じで、どちらのバックアップ手段を選択するか考える必要がありそうですが、「容易にバックアップを取りたい」という目的に対しては選択肢が広がったと思いました。

最後に繰り返しとなりますが、各サービスのバックアップは多種多様な方法で実現が可能です。
それを 統合的に簡易に管理したい という目的の選択肢のひとつが「AWS Backup」になるかと思います。

参考一覧

AWS Backupとは？