Amazon RDSとは何か、そしてバックアップが重要な理由
Amazon RDSは、AWSが提供するマネージドリレーショナルデータベースサービスです。MySQL、PostgreSQL、MariaDB、Oracle、SQL Server、Amazon Auroraを実行し、パッチ適用、フェイルオーバー、基盤となるインフラストラクチャの管理を代行するため、チームがこれらを自ら行う必要はありません。
「マネージド」だからといって「保護されている」わけではありません。サービスを運用しているのはAWSですが、データの所有権、復旧計画、そして問題が発生した場合の責任は依然としてユーザー側にあります。RDSはアプリケーションの下層に位置しており、1時間のトランザクション損失が実際の請求額に直結する環境では、バックアップに関する課題は「スナップショットが正常に実行されているか」というよりも、「リージョン全体やアカウント全体に問題が発生した場合でも、RTO（復旧目標時間）とRPO（復旧ポイント目標）を満たせるか」という点に重きが置かれます。
AWSが標準で提供する機能
RDSには、追加の機能を導入する前から、2つのバックアップメカニズムが標準で備わっています。
自動バックアップ。 RDSは、バックアップウィンドウ中に毎日スナップショットを取得し、その日のトランザクションログを記録します。これらを組み合わせることで、最大35日間という保持期間内の任意の秒単位の時点への復旧（PITR）が可能になります。インスタンスを削除すると、デフォルトでは自動バックアップも一緒に削除されます。
手動スナップショット。 ユーザー（またはスクリプト）がフルスナップショットをトリガーすると、そのスナップショットは削除されるまで保持されます。これらはインスタンスの削除後も残存し、より長い保存期間やリージョン間の耐久性を確保するためにコピーされるものです。
単一のアカウント内の単一のデータベースであれば、これでほぼカバーできます。問題は、リカバリ要件がリージョン、アカウント、または保存期間の境界を越える場合に生じます。
AWS Backup と RDS の連携方法
AWS Backup は、サービス横断的なポリシーベースの管理を行うために AWS が推奨する中核となるサービスです。RDS におけるワークフローは以下の通りです。
AWS Backup を通じてバックアップが実行されると、既存の RDS 自動バックアップの有無が確認されます。既存の自動バックアップがある場合、`copy-db-snapshot` 操作を使用して最新の自動バックアップをコピーし、増分スナップショットを作成します。存在しない場合は、`create-db-snapshot` を使用して新しいスナップショットを取得します。最初のスナップショットは常にフルスナップショットとなり、それ以降は増分スナップショットとなるため、ストレージコストを抑えることができます。
注意すべき点として、AWS Backup のバックアップウィンドウは、RDS が自身の自動バックアップ用に設定したバックアップウィンドウと重複してはなりません。重複すると、ジョブが競合してしまいます。
ネイティブの RDS バックアップではセキュリティ上のリスクが生じる
AWS Backup は管理を一元化しており、手作りのスクリプトに比べて格段に進化しています。しかし、本番環境のデータベースや災害復旧（DR）要件が加わると、いくつかの制限がすぐに明らかになります。
インスタンスレベルのみ。 AWS Backupは、RDSバックアップをインスタンス全体の完全なDBスナップショットとして扱います。インスタンス内でのデータベース単位のバックアップや復元はできず、AWS Backupを介したSQL Serverネイティブの差分バックアップやトランザクションログバックアップも利用できません。きめ細かなエンジンネイティブの復元が必要な場合、ネイティブの方法ではそれを実現できません。
アカウント間の移行は困難です。 RDSの自動バックアップは、アカウントの境界を一切越えることができません。復元可能なコピーを別のアカウントに取得するには（ランサムウェアやアカウントの侵害といったシナリオで実際に必要となること）、AWS Organizationsの設定、バックアップ・ヴォールト、KMSキーの共有、そして自身で構築・管理するコピージョブが必要となります。
リージョン間でのコピーはコストと管理の複雑さを増します。 DRのためにスナップショットを別のリージョンにコピーすることは可能ですが、自動化、ライフサイクル、および各リージョンに保存されるすべてのコピーの請求額は、すべてユーザー自身の責任となります。
保存期間とPITRには制約があります。 自動バックアップの保存期間は最大35日間であり、PITRはその期間内かつソースリージョン内でのみ機能します。それ以上の保存期間が必要な場合は、自身で管理する手動のスナップショットを作成する必要があります。
スナップショットはデフォルトでは不変ではありません。 攻撃者（または不具合のあるスクリプト）によって削除され得るスナップショットは、復旧計画としては機能しません。真に隔離され、改ざん防止が施されたコピーを構築するのは、ユーザー自身の責任です。
AWS RDS バックアップのベストプラクティス
使用するツールに関わらず、基本は依然として重要です。
1. 自動バックアップを有効にし、保持期間はデフォルト設定ではなく、復旧ニーズに合わせて設定してください。
2. バックアップの実施時間帯を、アクセスが集中しない時間帯に設定し、I/O 負荷が最もコストの低い時間帯に発生するようにしましょう。
3. スナップショットを別のリージョンにコピーし、特定のリージョンで障害が発生しても、唯一のコピーが失われることがないようにしてください。
3. 少なくとも 1 つのコピーは別のアカウントに保管してください。そうすることで、アカウントレベルの侵害があっても、すべてのバックアップが影響を受けることを防げます。
4. 定期的に復元テストを実施してください。 一度も復元したことがないスナップショットは、単なる推測に過ぎず、バックアップとは言えません。
5. リスクを伴う変更（メジャーバージョンのアップグレードやスキーマの移行など）を行う前には、手動でスナップショットを取得してください。
6. 保存期間をコンプライアンス上の義務に合わせて設定し、その内容を文書化してください。
これらの対策の多くは、簡単なようですが、環境全体で手動で実行するのは面倒な作業です。しかし、N2WSが解決できる問題なのです。
N2WSによるRDSの保護方法
N2WSは、お客様のAWSアカウント内でソフトウェアとして動作し、ネイティブなAWS APIを通じてバックアップと復旧を実行します。RDS向けにはエージェントレスであり、データがお客様のアカウント外に出ることはありません。実際の仕組みは以下の通りです。
ポリシーベースのバックアップと保存期間管理。 標準のRDSおよびRDS Customを含むRDSデータベースを対象としたバックアップポリシーを作成します。このポリシーでは、バックアップの実行頻度、保持する世代数、保存期間、およびN2WSによるDRコピーの作成の有無を設定します。1つのポリシーでRDSに加え、EC2、EBS、Aurora、Redshiftのリソースもカバーできるため、サービスごとに設定を個別に管理する手間が省け、環境全体で統一されたスケジュールに従うことができます。
高頻度のスケジュール。 N2WSは最大60秒ごとにスナップショットバックアップを実行できるため、ワークロードにより厳しいRPOが求められる場合でも、1日1回の自動バックアップ時間帯に縛られることはありません。
復元先を完全に制御して復元。 RDSデータベースを復元する際、N2WSはスナップショットから復元を行い、復元時に以下の重要な設定項目を指定できます：
- ・DBインスタンスIDおよびインスタンスクラス
- ・ストレージタイプおよびプロビジョニングされたIOPS
- ・マルチAZまたはシングルAZ
- ・サブネットグループとポート
- ・DBパラメータグループ
- ・パブリックアクセス
- ・復元先のAWS認証情報およびアカウント
これにより、単に元のインスタンスのクローンを作成するだけでなく、適切なネットワーク内の適切なサイズのインスタンスに復元することが可能です。
リージョン間およびアカウント間のDR。 DRを有効にすると、N2WSはRDSスナップショットを他のリージョンにコピーし、適切なライセンスと設定があれば、他のアカウントにもコピーします。これは、ネイティブのバックアップだけでは実現できないRDS復旧のケースであり、ユーザーが管理するスクリプトではなく、ポリシーによって処理されます。（別のアカウントに復元する場合は、事前に宛先のサブネットグループが存在することを確認してください。そうしないとジョブが失敗します。）
AuroraおよびRDS Customのサポート。 Auroraも対象となっており、スナップショットへのリソースタグのコピーといったAWSの挙動も考慮されています。RDS Customの復旧も、IAM権限の設定を少し追加するだけでサポートされています。
不変の、エアギャップ化されたコピー。 N2WSは、S3 Object Lockを有効にした、別のアカウントまたはリージョンにあるお客様所有のストレージにコピーを保存できます。これにより、侵害された本番アカウントからはアクセスや削除ができないコピーが存在することになります。ここでいう真のエアギャップとは、アカウント間またはクラウド間の隔離を意味し、最初のコピーの隣に2つ目のコピーを置くことではありません。
ストレージコストの削減。ライフサイクル自動化機能を活用し、自身のアカウント内のより安価な階層（S3、Glacier、Wasabi）へ増分アーカイブを行うことで、N2WSはすべてのデータを標準スナップショットに保持する場合と比較して、バックアップストレージコストを最大92%削減します。
災害復旧テスト – 復元検証、DR演習、メタデータ復旧を自動化することで、N2WSはAmazon RDSデータベースだけでなく、EC2インスタンスやその他のAWSリソースを組み合わせたマルチターゲット復旧シナリオの調整を可能にします。
知っておくべきいくつかの注意点があります。S3からPostgreSQL RDSデータベースを復元する場合、ユーザーパスワードは復元されません（AWSの制限による）。そのため、データベースはRDS管理者アカウントで復元され、残りのパスワードは手動でリセットする必要があります。また、一部のプライベートMySQLユーザーメタデータは、S3からの復元時に引き継がれない場合があります。いずれも通常のデータベース利用には影響しませんが、復元手順を計画する際には、これらの点を事前に把握しておく必要があります。
N2WSが競合製品に勝る点
ネイティブのAWS Backupと比較した場合、N2WSの優位性は、ポリシー単位でのアカウント間およびリージョン間のDRコピーの作成、ユーザーが管理するストレージ上の不変コピー、より頻繁なバックアップ実行、そしてインフラの構築や保守を自ら行う必要がないことによる実質的なストレージコストの削減にあります。
Rubrik、Commvaultといった大手スイートと比較した場合、N2WSの強みはクラウドネイティブに特化している点とコストにあります。AWSおよびAzure向けに専用に設計されており、完全にユーザー自身のアカウント内で動作します。また、オンプレミスで開発されたツールに見られるような、煩雑なライセンス管理や汎用性による機能の肥大化もありません。クラウドデータベースを適切かつ低コストで保護することが課題である場合、その特化性はセットアップ時間と請求額の双方に反映されます。
N2WSはオンプレミスのVMwareの代替品ではなく、その基盤となるスナップショットモデルについても率直に説明しています。このツールが実現するのは、ネイティブツールでは手作業で組み立てる必要があったRDSの復旧シナリオを、一度設定するだけで済むポリシーに変えることです。
RSSフィードを取得する
