AWS Backupを利用したAuroraバックアップ：メリット・デメリット
実務でAWS BackupとAuroraを組み合わせて運用した際に、つまづいた点をまとめました。
AWS Backupは、複数のAWSサービスのバックアップを一元管理できるサービスです。
しかし、Auroraのバックアップに利用する場合、いくつか注意すべき特有の挙動があります。
この記事では、AWS BackupでAuroraを管理する際のメリット・デメリットを解説します。
一部の内容についてはAWSサポートへ問い合わせて確認した情報も含まれています。
🤖 AI利用について: 本記事の作成にあたり、文章の構成・推敲にAIツールを一部利用しています。技術的な内容についてはAWS公式ドキュメントおよびAWSサポートへの問い合わせにより確認しています。
結論：AWS Backupを使うべきか？
| ユースケース | 推奨 |
|---|---|
| 組織全体でバックアップポリシーを統一したい | ✅ AWS Backup推奨 |
| リストア時の手軽さを最優先したい | ⚠️ Aurora標準機能の方が直感的 |
AWS Backup vs Aurora標準機能の比較
| 比較項目 | AWS Backup | Aurora標準機能 |
|---|---|---|
| バックアップ管理 | 複数サービスを一元管理 | Aurora個別に設定 |
| PITR（任意時点復元） | ✅ 対応（継続的バックアップ有効時） | ✅ 対応 |
| リストア後のインスタンス | ❌ 手動作成が必要 | ✅ 自動作成 |
| クロスリージョンコピー | ✅ プラン内で自動化 | △ 手動または別途自動化 |
| クロスアカウントコピー | ✅ プラン内で自動化 | △ 手動または別途自動化 |
AWS Backupを使わない場合の運用方法
AWS Backupを使用しない場合は、Aurora標準のバックアップ機能のみで運用します。
| 項目 | 設定・運用方法 |
|---|---|
| 自動バックアップ | クラスター作成時に保持期間（1〜35日）を設定。PITRはこれで対応 |
| 手動スナップショット | 長期保存が必要な場合、手動でスナップショットを作成 |
| クロスリージョンコピー | スナップショットを手動または自動化スクリプトで別リージョンへコピー |
| 長期保存 | EventBridge + Lambdaで定期的にスナップショット作成を自動化 |
Aurora標準機能のみで運用する場合、リストア時にインスタンスも一緒に作成されるため、復旧手順がシンプルになります。ただし、複数サービスのバックアップ管理が煩雑になる点はトレードオフです。
その理由を詳しく見ていきましょう。
1. 前提知識：Auroraのバックアップ構造
AWS Backupとの連携を理解する前に、Auroraのバックアップの基本を押さえておきましょう。
Auroraのアーキテクチャ概要
バックアップは「クラスター単位」
Auroraでは、データはクラスターボリューム（共有ストレージ）に保存されます。
DBインスタンス（ライター/リーダー）は、このボリュームに接続する「コンピューティング層」に過ぎません。
そのため、バックアップはインスタンス単位ではなく、クラスター単位で取得されます。
UIの注意点：マネジメントコンソールでは「インスタンスの変更画面」にもバックアップ設定が表示されますが、ここから変更しても実際にはクラスターの設定が変更されます。
Auroraの2種類のバックアップ
Aurora自体にも、バックアップを取得する機能があります。
自動（連続）バックアップと、スナップショットの2種類が存在します。
| 種類 | 特徴 | PITR |
|---|---|---|
| 自動（連続）バックアップ | 保持期間内の全変更を増分保存。無効化不可（最短1日） | ✅ 可能 |
| スナップショット | ある時点のフルバックアップ。手動または自動で作成 | ❌ 不可 |
AWS Backup利用時の命名規則
AWS BackupでAuroraを管理すると、以下の命名でバックアップが作成されます。
| 設定 | バックアップ名の形式 |
|---|---|
| 継続的バックアップ 有効 | continuous:cluster-<クラスターID>-<番号> |
| 継続的バックアップ 無効 | awsbackup:job-<ジョブ番号> |
AWS Backup適用後、「クラスターの変更画面」には「AWS Backupのバックアッププランがあります」と表示されますが、「インスタンスの変更画面」には旧設定が残って見えることがあります。設定確認は必ずクラスター画面またはAWS Backupコンソールで行ってください。
2. AWS Backupを利用するメリット
Aurora単体で見ると「AWS Backupならでは」のメリットは限定的です。Aurora標準の自動バックアップも十分強力だからです。
ただし、運用管理の観点では以下のメリットがあります。
✅ バックアップの一元管理（最大のメリット）
EC2, EBS, RDS, DynamoDB, EFSなど、異なるAWSリソースのバックアップを**「バックアッププラン」で統一管理**できます。
- タグベースでポリシーを自動適用 → バックアップ漏れを防止
✅ クロスリージョン・クロスアカウントコピーの自動化
「バックアップ取得 → 別リージョンへコピー → 別アカウントへコピー」を1つのプラン内で完結できます。
3. AWS Backupを利用するデメリット
リストア時は「クラスターのみ」が作成される
Aurora標準のコンソールからスナップショットを復元すると、ウィザード内でインスタンスサイズも指定でき、復元完了と同時にDBへ接続できます。
しかし、AWS Backupから復元すると、クラスター（ストレージ）のみが作成され、DBインスタンスは作成されません。
この手間により、緊急時のRTO（目標復旧時間）が長くなる可能性があります。
対応策：インスタンス作成方法
復元後、以下のいずれかでインスタンスを作成してください。
方法A：AWS CLI（推奨）
スクリプト化しやすく、手順を固定化できます。
aws rds create-db-instance \
--db-instance-identifier my-restored-instance \
--db-cluster-identifier <復元されたクラスターID> \
--engine aurora-mysql \
--db-instance-class db.r6g.large
方法B：マネジメントコンソール
- RDSの「データベース」一覧を開く
- 復元されたクラスター（インスタンスなし）を選択
- 「アクション」→「リーダーの追加」を選択
- インスタンスクラスを指定して作成
方法C：AWS Systems Manager (SSM) Automation
あらかじめAutomationドキュメントを用意しておくことで、復元作業を半自動化・標準化できます。
4. 注意点：バックアップの「二重動作」
「AWS Backupで管理するなら、Aurora側の設定は不要？」と思われがちですが、Auroraの自動バックアップは無効化できません。
| バックアップ | 動作 |
|---|---|
| Aurora自動バックアップ | 常に動作（1〜35日、無効化不可） |
| AWS Backup | プランに従いスナップショットまたは継続的バックアップを取得 |
つまり、両方が並行して動作します。
運用のコツ：Aurora標準を「直近の復旧用（日次）」、AWS Backupを「長期保存用（月次・年次）」と役割分担すると、無駄なスナップショットの増加を防げます。
5. ベストプラクティス
① リストア手順を事前に確立する
AWS Backupからの復元訓練を定期的に実施し、「クラスター復元後にインスタンスを追加する」手順をドキュメント化またはIaC（Terraform等）で自動化しておきましょう。
② 継続的バックアップ（PITR）を有効化する
AWS Backupプランで「継続的バックアップの有効化」にチェックを入れると、任意の時点（例：障害発生の5分前）への復元が可能になります。
③ タグベースでバックアップ対象を管理する
リソースにタグ（例：BackupPlan: Daily）を付与し、タグベースでバックアップ対象を自動割り当てすると、設定漏れを防止できます。
よくある質問（FAQ）
Q1. AWS BackupでAuroraを管理すると、Aurora標準の自動バックアップは停止しますか？
いいえ、停止しません。 Auroraの自動バックアップは無効化できない仕様のため、AWS Backupと並行して動作します。
Q2. AWS Backupからの復元で、元と同じインスタンス構成を自動で再現できますか？
できません。 AWS Backupはクラスター（ストレージ）のみを復元します。インスタンスの構成（ライター1台、リーダー2台など）は、復元後に手動またはスクリプトで再作成する必要があります。
Q3. 継続的バックアップを有効にしないとPITRはできませんか？
Aurora標準の自動バックアップでもPITRは可能です。 ただし、AWS Backupで一元管理したい場合は、バックアッププランで「継続的バックアップの有効化」を設定する必要があります。
Q4. AWS Backupで取得したスナップショットの料金は別途かかりますか？
はい、かかります。 AWS Backupで作成したスナップショットは、Aurora標準のスナップショットと同様にストレージ料金が発生します。ただし、Auroraスナップショットは増分方式のため、極端なコスト増にはなりにくいです。
まとめ
| 項目 | 内容 |
|---|---|
| メリット | バックアップポリシーの統合管理、コンプライアンス対応、クロスアカウントコピーの自動化 |
| デメリット | リストア時はクラスターのみ復元され、インスタンス作成が別途必要 |
| 対策 | インスタンス作成手順を事前に確立し、定期的にリストアテストを実施 |
AWS Backupは強力なツールですが、Auroraでは「リストア時のひと手間」を考慮した設計が必要です。
参考ドキュメント
本記事の内容は、以下のAWS公式ドキュメントに基づいています。
| # | トピック | ドキュメント |
|---|---|---|
| 1 | AWS Backup による Aurora のリストア仕様 | Restoring an Amazon Aurora cluster - AWS Backup |
| 2 | Aurora 継続的バックアップと AWS Backup の併用 | Restoring a DB cluster to a specified time using AWS Backup |
| 3 | Aurora 自動バックアップの仕様（無効化不可など） | Overview of backing up and restoring an Aurora DB cluster |
| 4 | AWS Backup 機能のリソース別対応状況 | Feature availability by resource - AWS Backup |
| 5 | Aurora スナップショットの作成 | Creating a DB cluster snapshot |
| 6 | Aurora インスタンスの追加（CLI リファレンス） | create-db-instance - AWS CLI Command Reference |
引用（AWS公式ドキュメントより）
"AWS Backup restores your Aurora cluster; it does not create or attach an Amazon RDS instance to your cluster."