はじめに

AWSの利用にあたって、バックアップの取得はユーザーの責務となります。
自分たちで、自分たちの要件のもと、設定する必要があります。
近年、AWS Backup(*)の登場によって一元的に設定可能になりましたが、より適切なバックアッププランを検討・選択するには、概要を知っておいた方がいいので、簡単に解説しておきます。

(*) AWS Backup
AWS Backupとは、対応するサービスインスタンスのバックアップを一元的に管理するサービスです。
AWSの各サービスではBackupの仕組みは提供されているものの、以前は自動化するには、こんな感じで実装する必要がありました。

AWS Backupの登場により、複雑な独自要件がない限りは、自前実装がお役御免になりました。
当初は、マルチリージョンやタグなどの機能がなかったり、対応サービス数が少なかったのですが、今となっては非常に幅広い要件に対応しています。

リテンションポリシー

データ管理要件において、バックアップのリテンションポリシー（保管に関する仕様）を定義することがほとんどです。
バックアップのリテンションポリシーは、期間と世代管理(間隔)の概念があります。

以下に例示します。
言い換えれば、24時間ごとに72時間まで確保するとも言えます。

当然、短い間隔で長期間保管すると、より求める状態に近い復元が可能になる確率が上がりますが、コストは上がります。
要件をもとに落とし所をつけましょう。

ただし、AWSの場合、バックアップは差分バックアップ方式が暗黙的に実現されています。
そのため、世代数の等倍でストレージ費用が増えるのではなく、変更量に応じたコスト増になります。この辺りはクラウドの恩恵を非常に感じるところです。

少し踏み込んだ話になりますが、RDSのリテンションポリシーには少し戸惑われる可能性があるポイントがあるので補足しておきます。
RDSのバックアップは、頻度と期間で設定します。
この期間には注意が必要です。停止中の時間は含みません。
したがって、頻度：毎日、期間：3日間の設定をしていた場合、常時起動のインスタンスであれば、３世代のバックアップになりますが、一時的な停止を行ったインスタンスについてはより多くのバックアップが作成されます。
ただし、先述のとおり、差分バックアップ方式のため、コストの観点では心配ご無用です。

本件はドキュメントにも記載されています。
https://docs.aws.amazon.com/ja_jp/AmazonRDS/latest/UserGuide/USER_WorkingWithAutomatedBackups.html#USER_WorkingWithAutomatedBackups.BackupRetention

冗長化の種類と目的

私が知る限り、AWSでのBackupで保存するバックアップファイルは、裏側ではS3で保存されています。
S3自体が冗長化されているため可用性が高いのですが、より可用性を上げるために、マルチリージョンとマルチアカウントといった選択肢がとれます。
それぞれについて、どんな目的で設定するのかを紹介します。

マルチリージョン

S3による冗長化は、リージョン内で行われています。
リージョン障害に備えておくには、別のリージョンにバックアップを複製しておく方が安全です。
リージョン障害の内容によりますが、状況によっては、せっかくバックアップをとっていても、そのバックアップファイルにアクセスできずに、DRを実行できないというようなことが起こりえます。

マルチアカウント

アカウントを間違って削除してしまう。
ありえないように思われるかもですが、想定されるミスは実際に発生する可能性があります。
必要に応じて、バックアップ専用のアカウントに集約保管する戦略も検討しましょう。

まとめ

RDSのスナップショット保管について、今更ながら知ったことを契機に、改めてバックアップに関する基本的な考え方を書いてみました。
AWSでは、オンプレよりもお手軽に、さまざまな形のバックアップを取ることができるため、要件に応じて適切なバックアップ戦略をとりましょう！