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."

— Restoring an Amazon Aurora cluster - AWS Backup