Amazon RDSをバックアップから復元するときは、元のDBインスタンスを上書きするのではなく、新しいDBインスタンスまたはDBクラスターを作成します。そのため復元操作だけでなく、接続先エンドポイントの切り替えまで含めた手順が必要です。
この記事の要点
- スナップショット復元もPITRも、既存DBへの上書きではなく新しいDBを作成する
- RDS標準バックアップとAWS Backupは管理画面やガバナンス機能が異なるが、復元後に新しいDBができる点は同じ
- Multi-AZ DBインスタンスは、復元時にMulti-AZを指定すればプライマリとスタンバイが作成される
- 復元後は接続テストをしてから、CNAME・DB識別子のリネーム・設定管理のいずれかで切り替える
RDS標準バックアップとAWS Backupの違い
| 比較項目 | RDS標準バックアップ | AWS Backup |
|---|---|---|
| 管理場所 | RDSコンソール | AWS Backupコンソール |
| PITR | 自動バックアップで対応 | 継続的バックアップで一元管理 |
| 複数サービスの統合管理 | RDS単体 | 対応するAWSサービスを横断 |
| ガバナンス | RDSの機能中心 | バックアップポリシー、クロスアカウントコピー、Vault Lockなど |
| 復元結果 | 新しいDBを作成 | 新しいDBを作成 |
AWS Backupはバックアップの一元管理や統制に強みがあります。一方、スナップショットからDBインスタンスを復元する処理自体は、最終的にRDSの復元機能を利用します。コンソール上の入口は異なっても、「新しいDBを作り、設定を確認し、接続先を切り替える」という実務の流れは共通です。
スナップショット復元とPITRの使い分け
- スナップショット復元：保存済みスナップショットの取得時点に戻す
- PITR：保持期間内の指定時刻に戻す。誤更新や誤削除直前への復旧に向く
どちらも既存DBを巻き戻す操作ではありません。復元先のDB識別子、インスタンスクラス、VPC、サブネットグループ、セキュリティグループ、パラメータグループ、暗号化、Multi-AZなどを確認して新しいDBを作成します。
Multi-AZは何単位で復元するのか
Multi-AZ DBインスタンス配置では、スタンバイ側を個別に1台ずつ復元する必要はありません。復元時にMulti-AZを指定すると、RDSがプライマリとスタンバイを構成します。
Multi-AZ DBクラスターはDBクラスター単位で復元し、ライターとリーダーを含む新しいクラスターを作ります。なお、Multi-AZ DBクラスターのスナップショットからSingle-AZまたはMulti-AZ DBインスタンス配置へ復元できる場合もあります。エンジンやバージョン、インスタンスクラスの対応状況を事前に確認してください。
基本的な復元手順
- 復旧時点とバックアップを決める
- 新しい識別子でDBインスタンスまたはDBクラスターを復元する
- VPC、サブネット、セキュリティグループ、パラメータグループを確認する
- アプリケーションと同じ経路から疎通確認する
- データ整合性、最新時刻、必要なユーザーや拡張機能を確認する
- 書き込みを停止または調整し、接続先を切り替える
- 監視とエラー率を確認し、問題があれば切り戻す
- 旧DBは保持期限を決めてから削除する
復元後のエンドポイント切り替え方法
| 方法 | 長所 | 注意点 |
|---|---|---|
| CNAME | アプリ変更を抑えやすく、切り戻しもしやすい | TTL、DNSキャッシュ、接続プールの再接続を検証する |
| DB識別子のリネーム | 旧識別子を復元DBへ引き継げる | 旧DBと新DBを順にリネームする時間や停止影響を考慮する |
| Parameter Store | 複数アプリの設定を一元管理しやすい | アプリが値の更新を再取得する実装が必要 |
| Secrets Manager | 認証情報と接続情報を安全に管理しやすい | 取得・キャッシュ・ローテーション設計が必要 |
CNAMEは一般的で分かりやすい方法ですが、DNSを切り替えただけでは、アプリケーションが保持している既存接続は自動的に新DBへ移らないことがあります。DNS TTLだけでなく、OSやランタイムのDNSキャッシュ、コネクションプールの寿命、再接続処理をテストしてください。
Parameter Storeは「値を書き換えれば即切替」ではありません。アプリが起動時にしか値を取得しない設計なら、再起動や再デプロイが必要です。接続パスワードは通常の文字列として保存せず、Secrets Managerまたは適切に暗号化したSecureStringを検討します。
復旧訓練で確認したいチェックリスト
- 復元完了までの実測時間がRTO内か
- 復元可能な最新時刻がRPOを満たすか
- セキュリティグループやIAM認証を再現できるか
- アプリが新しいDNS/IPへ追従できるか
- 旧DBへの書き込みを止め、二重書き込みを防げるか
- 切り戻しの判断基準と担当者が決まっているか
バックアップ保存料金を含めた設計は、AWS BackupでRDSをバックアップした場合の料金と無料枠も参照してください。
まとめ
RDSの復元は「バックアップを戻す」だけでは終わりません。新しいDBが作成されることを前提に、構成確認、データ検証、エンドポイント切替、切り戻しまでを手順化しましょう。CNAMEと設定管理のどちらが適切かは、アプリの再取得方式と許容停止時間で判断します。
参考資料
※本記事は2026年8月時点のAWS公式情報とサポート回答をもとに一般化しています。実際の復元可否や設定項目はエンジン、構成、リージョンによって異なります。
