はじめに

※本記事は2026年4月時点の仕様と検証結果に基づいています

記事をご覧頂きありがとうございます！

RDS/Aurora のバックアップをRDS/Auroraの標準機能で行うのか、AWS Backupで行うかで悩むことがあると思います。その上で、AWS Backupは複数サービスのバックアップを一元管理でき、バックアッププラン（ルール）で統制できるので、AWS Backupに統合したいというケースが多い印象です。

一方で、AWS Backupで「継続的バックアップ」を有効にした場合、RDS/Auroraの標準のバックアップとは異なる特有の挙動があります。本記事では、RDS/AuroraをAWS Backupで運用するときにハマりやすいポイントを中心にまとめます。

1. RDS/Auroraバックアップのおさらい

1.1. スナップショットとPITR

まずは、RDS/Auroraのバックアップには大きく分けて以下の2つの種類があることをおさらいしておきましょう。

種類	内容	主な用途
スナップショット	いわゆるスナップショット。特定のタイミングの静止点。	日次・週次などの長期保管やアーカイブ
PITR	スナップショットに追加してトランザクションログを継続的に取得。	過去の特定の時点に復元可能（最新復元ポイントは最大5分前）

1.2. 自動スナップショットと手動スナップショット

次にスナップショットについてですが、スナップショットには「自動スナップショット」と「手動スナップショット」の2種類があります。それぞれの特徴については以下の通りです。

種類	内容	主な特徴
自動スナップショット	自動で取得されるスナップショット。	PITRを実施するには自動バックアップが必須。頻度は日次で最大保持期間は35日。利用者が明示的に復旧ポイントとして利用することは出来ない。
手動スナップショット	手動で取得するスナップショット。	長期保管が可能で、他リージョンへコピーすることも出来る。

2. 標準機能のバックアップとAWS Backupを使ったバックアップ

2.1. 標準機能のバックアップ

RDS/Auroraには標準でバックアップ機能があります。この機能はRDS/Auroraのコンソールで扱えるので、RDS/Aurora内で完結させたい場合は標準機能が最適です。標準機能のバックアップには、自動バックアップと手動スナップショットがありますので、以下に詳細を記載します。

2.1.1. 自動バックアップ

RDS/AuroraはDBインスタンスのバックアップウィンドウの間に、自動スナップショットを作成します。さらに、自動バックアップではトランザクションログも取得されるため、保持期間内であればPITRが可能になります。

2.1.2. 手動スナップショット

RDS/Auroraは手動でスナップショットを作成することも出来ます。ただし、手動スナップショットを定期実行したい場合、標準機能だけで完結しないことが多く、API（例：CreateDBSnapshot）をスケジュール実行する仕組み（EventBridge + Lambda など）を別途考慮する必要があります。

2.2. AWS Backupのバックアップ

RDS/AuroraはAWS Backup経由でもバックアップを取得することが可能です。AWS BackupはEC2やEBS、EFS、S3等でも利用することが多いので、AWS Backup経由にすることでバックアップを全てAWS Backupで統一管理することが可能になります。

2.2.1. 継続的バックアップ

AWS Backupのバックアップルールで「継続的バックアップ」を有効化すると、RDS/Auroraの自動バックアップがAWS Backup側に移管されます。移管後の動きは標準機能と同じで、AWS Backupが管理しつつ、自動スナップショット＋トランザクションログを取得するのでPITRが可能になります。

2.2.2. 定期バックアップ

AWS BackupでRDS/Auroraのバックアップルールを作成すると、手動スナップショットが実行されます。また、RDS/Auroraの機能で定期実行させるには工夫が必要でしたが、AWS Backup経由では始めから定期実行される形になります。

3. AWS Backupで運用する際の注意点

ここからが本題ですが、AWS Backup、特に「継続的バックアップ」を有効にした場合の挙動は、RDS/Auroraの標準機能のバックアップとは大きく異なる点があり、注意が必要です。

3.1. 継続的バックアップ有効時、自動スナップショットの時間が制御出来なくなる

「2.2.1. 継続的バックアップ」で記載した通り、AWS Backupで継続的バックアップを有効化すると、自動バックアップがAWS Backupに移管されます。

AWS Backup側に管理が移管されると、AWS Backupがメンテナンスウィンドウの時間などを考慮し、自動で判断したシステムにとって最適な時間帯に自動スナップショットを取得します。そのため、RDS/Auroraでは自動バックアップを制御することが出来なくなり、設定したバックアップウィンドウの時間は効かなくなります。以下、AWS公式ドキュメントより抜粋です。

競合を防ぐために、Amazon RDS 自動バックアップウィンドウの手動設定は利用できません。

また、AWS Backupのバックアップルールでも時間帯を指定することが出来ますが、あくまでもAWS Backupが自動で最適な時間を判断してバックアップを行うので、RDS/Auroraのバックアップウィンドウと同様に、この時間に自動バックアップは取られませんのでご注意下さい。

Note
1つのプラン内に「定期」と「継続」の両方のルールを入れた場合、AWS Backupがその両方のスケジュールを考慮して、自動スナップショットの時間を判断してくれます。

ということで、動作確認もしてみました。
RDSを構築して以下のように設定しております。

バックアップレプリケーション：On
送信先リージョン：大阪リージョン
メンテナンスウィンドウ：月曜日 1:00 - 1:30 (JST)

AWS Backupは以下のように設定しております。

継続バックアップ：有効
頻度：日次
時間：03:00 (JST)
次の時間以内に開始：1時間
次の時間以内に完了：2時間

作成してから、3日程経過した状態が以下の通りです。初日こそバックアップの設定を変更したので2回取られてますが、その後は23:14 (JST)に取得されていますので、バックアップウィンドウやAWS Backupのバックアップルールの時間とは異なる時間に取得されています。

因みに、RDSの設定でバックアップレプリケーションをOnにしていましたが、やはり大阪リージョンにコピーはされていませんでした。

3.2. 継続的バックアップ有効時のバックアップジョブ

「3.1. 継続的バックアップ有効時、自動スナップショットの時刻が制御出来なくなる」で記載した通り、継続的バックアップ有効時は、AWS Backupが自動で最適な時間を判断して自動バックアップを取得するので、バックアップルールの時間に自動バックアップが取得されるわけではありません。

一方で、この時間帯にスナップショットはとられませんが、バックアップジョブは動きます。具体的にどんなジョブが動いているかは公表されていませんが、以下のようなことをしているのではないかと言われています。

継続的バックアップ（PITR）の確認と整合性チェック
リカバリポイントのメタデータ管理
スナップショットスケジュールの「スキップ」判定

そのため、バックアップが取られないからメンテナンスウィンドウの時間と被せても良いとか、近い時間でも良いと考えると非常に危険で、スナップショット作成の負荷はかかりませんが、何かしらの処理は動いているため、念のためメンテナンスウィンドウの時間帯とは離して設定しておくのが安全です。

ということで、こちらも動作確認してみました。
RDSとAWS Backupは3.1. 継続的バックアップ有効時、自動スナップショットの時間が制御出来なくなるで動作確認した時と同じもので確認しますので、設定は割愛します。

まず、バックアップジョブを見てみますが、先ほどの23:14 (JST)に実行されているバックアップに対して、バックアップジョブはAWS Backupのバックアップルールに基づいて3:00 (JST)に実行されていますので、バックアップとは関係なくバックアップルールの時間にバックアップジョブが動いているのが分かります。

続いてバックアップジョブの詳細を見てみますが、ジョブの詳細情報が出てくるだけで、実行内容等は表示されません。

CloudTrailを見てみると、DescribeDBInstancesやListTagsForResourceなどのAPIが呼び出されている形跡はありますが、スナップショットは取得されていませんでした。そのため、スナップショット取得以外の何らかの処理が実行されていることが分かりました。

3.3. 継続的バックアップでコピーを有効化すると「手動スナップショット」が作られる

「2.2.1. 継続的バックアップ」で記載の通り、継続的バックアップの実態はRDS/Auroraの自動バックアップであり、RDS/Auroraの自動バックアップは2.1.1. 自動バックアップに記載の通り、自動スナップショット＋トランザクションログです。

一方で、AWS Backupのバックアップルールにてコピー機能を有効化すると、手動スナップショットも取得されるようになります。AWS Backupのコピー機能は別リージョンへのコピーを行うことが出来ますが、自動バックアップでとられる自動スナップショットは別リージョンにコピーが出来ないので、この設定のためにAWS Backupが手動スナップショットを取得しているのかなと思います。

また、この手動スナップショットは定期スナップショットと同様にAWS Backupのバックアップルールで指定した時間に取得されます。コピー完了後は、コピー元の手動スナップショットが自動で削除されますので、環境に残ることはありません。

これらを踏まえると、継続的バックアップでコピー機能を有効化した場合、1つのバックアップルールで以下の3つのバックアップが取られることになります。

自動スナップショット：AWS Backupがメンテナンスウィンドウを考慮して最適な時間に取得
トランザクションログ：5分おきに取得
手動スナップショット(コピー用)：AWS Backupのバックアップルールで指定した時間に取得

Note
1つのプラン内に「定期」と「継続」の両方のルールを入れた場合、どちらでコピーを行っても同じ動きとなりますが、「継続」側で実施すると時間体系が二重となり、管理が複雑になります。また、「定期」の方が意味合い的にも合致するため、「定期」側で実施するのをオススメします。

ということで、こちらも動作確認していきます。
今度は違うRDSとAWS Backupのバックアッププランを使っております。

RDSの設定は以下の通りです。

バックアップレプリケーション：Off
メンテナンスウィンドウ：月曜日 1:00 - 1:30 (JST)

AWS Backupは以下のように設定しております。

継続バックアップ：有効
頻度：日次
時間：03:00 (JST)
次の時間以内に開始：1時間
次の時間以内に完了：2時間
コピー機能：On
コピー先リージョン：大阪

取得し始めてから3日が経過した状態のリソースから、スナップショットを確認します。こちらには、同じリージョンの3つの自動スナップショットのみが表示されています。このRDSは毎日23:11 (JST)に自動スナップショットが取得されているようです。

続いてバックアップジョブは以下の通りです。こちらもバックアップルールで設定した通りの時間に動いています。

次に、バックアップジョブの中身を見てみると、コピージョブが動いております。

コピージョブの方の中身も見てみると、ちゃんとコピーが行われているように見えます。

大阪リージョン側のバックアップボールトを見ると、復旧ポイントが存在するのでコピーが正しく動いているように見えます。

バックアップジョブが実行された時間のCloudTrailを見てみると、CreateDBSnapshotが実行され、手動スナップショットが取得されていました。バックアップジョブのIDも一致しています。

大阪リージョン側のCloudTrailを見てみると、CreateDBSnapshotの15分後にCopyDBSnapshotが実行され、スナップショットがコピーされていました。こちらもバックアップジョブのID、コピージョブのID、共に一致しています。

そして、東京リージョンのCloudTrailを見ると、CopyDBSnapshotの6分後にDeleteDBSnapshotが実行され、手動スナップショットが削除されていました。こちらもバックアップジョブのIDは一致しています。

まとめ

RDS/Auroraのバックアップのおさらいから、AWS Backupで継続的バックアップを行う際の注意点として以下を記載しました。

AWS Backupで継続的バックアップを行うと、ユーザー側で制御が出来なくなる
継続的バックアップをAWS Backupで行う場合、バックアップルールの時間にバックアップは取得されないが、バックアップジョブは動く
継続的バックアップを行うバックアップルールでコピーを行うと手動スナップショットも取られる

他リソースとの兼ね合いからAWS Backupで取得することが多いと思いますが、継続的バックアップが絡むと挙動が複雑になります。業務のコア時間帯やバッチ処理との兼ね合いでバックアップ時間を気にされる際は、お気をつけ下さい。