Amazon Auroraにおけるバックアップの仕組みを理解する

本記事は 2026 年 6 月4日に公開された「Understanding how backups work in Amazon Aurora」を翻訳したものです。

Amazon Aurora のお客様から、バックアップストレージのコストが変動する理由や、データの変更がバックアップ課金にどう影響するかについてよく質問をいただきます。Amazon Aurora のパブリックドキュメントではバックアップの設定方法を説明していますが、バックアップストレージの消費・課金の内部メカニズムを把握すれば、さまざまなワークロードパターンでのコスト最適化に役立ちます。

本記事では、Aurora バックアップアーキテクチャの詳細、Amazon Relational Database Service (Amazon RDS) バックアップとの違い、バックアップストレージ使用量を監視する Amazon CloudWatch メトリクスについて解説します。詳細なシナリオと図解を通じて、ワークロードパターンと保持期間がバックアップコストにどう影響するかを示します。さらに、クロスリージョンバックアップの選択肢と、バックアップストレージ消費量の最適化プラクティスを紹介します。

Aurora のバックアップの概要

Amazon Aurora は、さまざまなユースケースに対応する以下のバックアップ機能を提供しています。

• 自動バックアップ – 保持期間 1〜35 日で毎日自動的にバックアップを作成します。各 Aurora クラスターのデータベースストレージ合計の 100% までのバックアップストレージに追加料金は発生しません。バックアップストレージ料金の詳細は Amazon Aurora の料金を参照してください。
• 手動スナップショット – 明示的に削除するまで保持されるオンデマンドの DB スナップショット。
• クロスリージョンバックアップ – 災害対策のために AWS リージョン間でスナップショットをコピー。
• バックアップウィンドウ – 通常はピーク外の時間帯に自動バックアップを実行するタイミングの設定。
• AWS Backup との統合 – 長期の自動バックアップ保持を一元管理するマネージドバックアップサービスとの統合。

アーキテクチャレベルでは、Aurora は継続的バックアップの手法を採用しています。継続的にバックアップされたデータは内部の Amazon Simple Storage Service (Amazon S3) バケットに非同期で格納され、保持期間内の任意の秒単位でのポイントインタイムリカバリ (PITR) が可能です。Aurora バックアップアーキテクチャは分散ストレージレイヤーを活用し、データベースパフォーマンスに影響を与えずにバックアップを実行します。また、高い耐久性のために 3 つのアベイラビリティーゾーンにまたがってデータを自動的にレプリケーションします。

Aurora のバックアッププロセスの動作を理解するには、Aurora のストレージ構成を知ることが役立ちます。Aurora のデータベースボリュームはセグメントと呼ばれる 10 GB のチャンクに分割され、数百のストレージノードに分散されます。各セグメントは、フルセグメント (データページとログレコードの両方を含む) とテールセグメント (ログレコードのみを含む) を組み合わせたプロテクショングループとして、3つのアベイラビリティーゾーンにまたがって 6 つのコピーが分散して保持されます。これにより、ストレージコストを最適化しつつフォールトトレランスを実現しています。このパーティション分割アーキテクチャは Aurora のバックアップの基盤であり、各プロテクショングループは個別かつ並行してバックアップされます。

次の図は、各プロテクショングループのログレコードとセグメントスナップショットの継続的バックアップが並行して個別に行われる仕組みと、特定のスナップショットリストアのリカバリポイントとしてセグメントスナップショットとログレコードの組み合わせでクラスターストレージが再構成される仕組みを示しています。

Aurora はバックアップ実行時、DB インスタンスから直接読み取りを行いません。代わりに、バックアッププロセスはストレージレイヤーで動作し、分散ストレージボリュームからデータを直接キャプチャします。ストレージレイヤーで直接動作するこのアプローチには、以下のアーキテクチャ上の利点があります。

• バックアッププロセスは DB インスタンスのリソースを消費せず、パフォーマンスに影響を与えません。処理がストレージレイヤーにオフロードされるためです。
• Aurora は 10 GB のセグメントに分割してデータを数百のストレージノードに格納する分散ストレージシステムを維持しており、ストレージ要件に応じてプロテクショングループとして構成されます。バックアップ時にはプロテクショングループが並行してバックアップされるため、データベースサイズに関係なく高速にバックアップできます。リストアも各プロテクショングループとそのセグメントに対して並行して実行されます。リカバリポイントは各プロテクショングループの最新のセグメントスナップショットから開始し、続いてそれぞれの差分変更レコードが適用されます。
• 継続的バックアップ機能はストレージレベルの変更追跡メカニズムで実装されています。データ変更がストレージボリュームに書き込まれると、その変更は非同期で内部の S3 バケットにストリーミングされ、継続的なバックアップストリームが作成されます。
• PITR では、Aurora はベースバックアップと変更の継続的ストリームを組み合わせることで、保持期間内の任意の時点（秒単位）にリストアできます。
• 自動バックアップ設定の一部としての日次バックアップは、最初のフルバックアップ以降は増分変更のみをバックアップし、ストレージコストを最小化します。
• クラスターストレージレイヤーは、ソースデータベースが暗号化されている場合、バックアップチェーン全体のセキュリティを維持しながらバックアップ暗号化を透過的に処理します。

Aurora はこのアーキテクチャにより、テーブルのロック、トランザクションのブロック、I/O 操作の停止なしに一貫性のあるバックアップを取得でき、データ保護と安定したデータベースパフォーマンスを両立します。AWS Backup を使用してバックアップを管理する場合、作成されたスナップショットは手動 DB クラスタースナップショットとして扱われます。これらはフルバックアップとなり、作成時点のクラスターサイズと同じサイズになります。AWS Backup の使用について詳しくは、「Using AWS Backup to protect Amazon Aurora databases」を参照してください。

Aurora バックアップと Amazon RDS バックアップの違い

Aurora と標準的な RDS バックアップは、バックアップウィンドウ、リストアオプション、AWS Backup との統合など共通の原則を持ちますが、Aurora クラスターストレージアーキテクチャと RDS の Amazon Elastic Block Store (Amazon EBS) 使用の違いにより、内部の仕組みは大きく異なります。

Aurora バックアップの CloudWatch メトリクス

Amazon CloudWatch は Aurora バックアップに関連する 3 つのメトリクスを提供しており、Aurora バックアップのストレージ使用量を確認・監視できます。

これらのメトリクスに CloudWatch アラームを設定し、バックアップストレージ使用量をプロアクティブに監視することをお勧めします。BackupRetentionPeriodStorageUsed の値が着実に増加している場合、保持ウィンドウ内でのデータ変更率が高いことを示しており、保持期間を見直す機会かもしれません。SnapshotStorageUsed の値が高い場合、手動スナップショットが保持期間を超えて蓄積されていることを示しています。不要なスナップショットを確認して削除してください。TotalBackupStorageBilled を経時的に追跡することで、バックアップコスト全体のトレンドを把握し、予期しないスパイクを特定できます。一般的な目安として、TotalBackupStorageBilled が一貫してクラスターボリュームサイズの合計を超えている場合、保持期間、スナップショット管理プラクティス、データ変更パターンを最適化できるかどうか調査する価値があります。

ワークロードパターンと保持期間がバックアップコストに与える影響

前述のとおり、バックアップは継続的に行われ、自動バックアップは保持ウィンドウ内の任意の時点にクラスターをリストアするために必要な情報を保存します。変更が頻繁に発生するデータベースでは、自動バックアップのサイズは時間とともに増加します。データベースへの変更が止まると、新たに蓄積されるデータが減る一方で、過去の変更データは保持期間の経過に伴い順次保持ウィンドウから出ていくため、自動バックアップのサイズは縮小していきます。

シナリオ 1: 単一テーブル操作での手動バックアップ

このシナリオでは、単一テーブルに対する挿入と削除の操作が手動バックアップサイズにどう影響するかを検証します。

1. 新しいテーブルを作成し、10 GB のデータを挿入して、scenario-1-backup-1 という手動バックアップを取得します。
2. 同じテーブルにさらに 10 GB を挿入して合計 20 GB にし、scenario-1-backup-2 という手動バックアップを取得します。
3. 手順 2 で追加した 10 GB のデータを削除し、scenario-1-backup-3 という手動バックアップを取得します。
4. 同じテーブルに新しい 10 GB のデータを挿入 (手順 3 で解放されたスペースを再利用) し、scenario-1-backup-4 という手動バックアップを取得します。
5. 同じテーブルにさらに 10 GB の新しいデータを挿入して合計 30 GB にし、scenario-1-backup-5 という手動バックアップを取得します。

注意: Aurora PostgreSQL では、バキュームの動作により解放量にわずかな差異が生じる場合があります。

次の表は、各手動スナップショットのおおよそのサイズとその理由を示しています。

手動スナップショットのサイズは通常 VolumeBytesUsed の値に近くなります。このシナリオで重要なのは、scenario-1-backup-3 が 20 GB のままであることです。テーブルからデータを削除してもボリュームサイズは減少せず、スペースが将来の使用のために解放されるだけだからです。Aurora の動的リサイズは DELETE ステートメントを使用した行の削除では適用されません。ただし、パーティション分割されたテーブルを使用してパーティションをドロップすると、次のシナリオで示すようにサイズの削減が確認できます。コストに関しては、Aurora は自動バックアップ保持期間内の手動スナップショットに対して無制限の無料ストレージを提供しています。手動スナップショットがこの期間を超えると、前述のスナップショットサイズに基づいて GB-月単位で課金されます。

シナリオ 2: 複数テーブル操作での手動バックアップ

このシナリオでは、テーブルの作成とドロップが手動バックアップサイズにどう影響するかを検証します。

1. 新しいテーブルを作成し、10 GB のデータを挿入して、scenario-2-backup-1 という手動バックアップを取得します。
2. もう 1 つテーブルを作成し、10 GB のデータを挿入して、scenario-2-backup-2 という手動バックアップを取得します。
3. 先に作成したテーブルの 1 つをドロップし、scenario-2-backup-3 という手動バックアップを取得します。
4. 新しいテーブルを作成し、10 GB を挿入して、scenario-2-backup-4 という手動バックアップを取得します。

次の表は、各手動スナップショットのおおよそのサイズとその理由を示しています。

この場合も、手動スナップショットのサイズはおおよそ VolumeBytesUsed の値と等しくなります。このシナリオで注目すべきは、3 番目のステップで動的リサイズがトリガーされ、テーブルをドロップした際にストレージが縮小したことです。これが scenario-2-backup-3 のバックアップが約 10 GB に減少した理由です。先のシナリオと同様に、保持期間内の手動バックアップには課金されません。保持期間を過ぎると、前述のサイズに基づいて GB-月単位で課金されます。

シナリオ 3: 挿入のみのテーブルでの自動バックアップ

このシナリオでは、挿入のみのワークロードで自動バックアップストレージがどのように増加するか、保持ウィンドウが保持される変更レコードにどう影響するかを示します。

設定:

• 最初に 10 GB を挿入したテーブル。
• 保持期間 3 日で自動バックアップを有効化。
• ワークロードは挿入のみ。更新や削除なし。

データが挿入されると、Aurora の自動バックアップは 2 つのコンポーネントを追跡します。

• ベースイメージ – すべてのデータページの累積スナップショット。新しいデータが挿入されると増加し、挿入のみのワークロードでは縮小しません。
• 変更レコード – 保持期間内のポイントインタイムリカバリに必要なページレベルの変更で、3 日間の保持ウィンドウ内に保持されます。保持ウィンドウが前方にスライドすると、古い変更レコードはベースイメージに適用されます。

次の表は、各日の BackupRetentionPeriodStorageUsed のおおよその計算を示しています。

バックアップは各プロテクショングループの個々のページレベルで、ベースイメージと変更レコードの両方に対して行われます。ここで重要なのは、変更レコードがトランザクションログではなくデータページレベルの変更である点です。つまり、変更レコードのサイズは実際のデータ変更量に比例します。たとえば、10 GB のデータを更新する単一の UPDATE クエリを実行した場合、変更レコードとして保存されるのはクエリ自体ではなく、任意の時点へリストアするための 10 GB 分のデータページ変更です。

データの挿入を続けると、ベースバックアップイメージは増加し続け、保持ウィンドウの移動は変更レコードにのみ影響します。たとえば、4 日目には 1 日目の 10 GB の変更レコードが 3 日間のウィンドウ外になるため保持されなくなります。挿入のない日はバックアップストレージを時間とともに削減します。古い変更レコードが保持ウィンドウから出ていき、新しいものが追加されないためです (8〜10 日目参照)。毎日計算されるバックアップストレージのコストは、BackupRetentionPeriodStorageUsed の値 (個々のバックアップ作成時点の実データページとバックアップ保持ウィンドウの変更レコードストレージ使用量を合計したもの) からバックアップ作成時点の VolumeBytesUsed の値を差し引いたものです。たとえば、7 日目の課金対象バックアップストレージはおおよそ 70 GB 分の変更レコードです。110 GB のベースイメージは無料枠 (クラスターボリュームサイズの 100% まで) でカバーされるためです。

シナリオ 4: 更新と削除を伴うテーブルでの自動バックアップ

このシナリオでは、同じデータ領域が繰り返し更新される場合に自動バックアップストレージがどう影響を受けるかを示します。新しいデータのみを挿入するシナリオ 3 と異なり、更新は既存のデータページを変更するため、Aurora は保持ウィンドウ内のポイントインタイムリカバリをサポートするためにそれらのページの以前のバージョンを保持する必要があります。削除も同様の動作をしますが、解放されたページは同じテーブル内での将来の挿入に再利用できるという違いがあります。

設定:

• 最初に 100 GB を一括挿入したテーブル。
• 保持期間 3 日で自動バックアップを有効化。
• ワークロードはテーブルの同じ 10 GB の領域を繰り返し更新。新しいデータは追加されないため、テーブルサイズは 100 GB で一定。

更新ワークロードでは、Aurora の自動バックアップは 2 つのコンポーネントを追跡します。

• ベースイメージ – 現在のデータページに加え、保持ウィンドウ内の PITR に必要な更新済みページの以前のバージョン。これによりベースイメージがテーブルサイズを一時的に超えて増加します。
• 変更レコード – 3 日間の保持ウィンドウ内に保持されるページレベルの変更。ウィンドウが前方にスライドすると、古い変更レコードと対応する以前のページバージョンがベースイメージに適用されます。

次の表は、各日の BackupRetentionPeriodStorageUsed のおおよその計算を示しています。

ベースイメージに関して、データベースのテーブルレベルの行変更は新しいベースイメージを直接作成するのではなく、最初は変更レコードとしてのみ永続化されます。新しいベースイメージの作成は、変更レコードの数とその変更サイズに依存する内部しきい値に基づいています。これらの条件により、リストアプロセス中にセグメントが処理する変更レコードの量が許容範囲内に制約されます。

以前のページバージョンは保持ウィンドウが必要とする間だけ保持されます。たとえば、更新されたページの 1 日目のバージョンは 3 日目まで保持されますが、1 日目が 3 日間のウィンドウから出る 4 日目に削除されます。バックアップストレージは更新アクティビティを反映する周期的パターンに従います。更新が発生すると増加し、それらの変更が保持ウィンドウから出ると縮小します。変更されていないデータ (残り 90 GB) は、保持期間を超えてもベースイメージに保持されます。保持ウィンドウ内の任意の時点でテーブル全体をリストアするために必要だからです。

クロスリージョンバックアップの選択肢

Aurora はマルチリージョンデータベースアーキテクチャに対して、グローバルデータベース、クロスリージョンリードレプリカ、クロスリージョンスナップショットコピーの 3 つの異なるアプローチを提供しています。これらすべてマルチリージョンを実現しますが、用途が異なり、コスト影響もそれぞれ異なります。

グローバルデータベース

Amazon Aurora Global Database は高度なアプローチであり、セカンダリリージョンがプライマリデータベースのストレージレベルのコピーを維持し、読み取りスケーリング機能を提供します。さらに、専用のコンピューティングリソースなしのヘッドレスクラスター構成が可能です。このアーキテクチャは、災害対策シナリオでセカンダリリージョンを昇格させる機能を維持しながらコストを大幅に削減します。通常、Recovery Point Objective (RPO) は数秒、Recovery Time Objective (RTO) はヘッドレスクラスターへのインスタンス追加時間であり、一般的に 10 分未満です。ただし、セカンダリリージョンに事前のリーダーインスタンスがあれば、シナリオに応じた直接のスイッチオーバー/フェイルオーバーアクションにより、RTO を 1 分未満に短縮できます。セカンダリリージョンクラスターは独自の自動バックアップと保持期間が設定されており、独自の PITR が可能です。セカンダリリージョンクラスターもプライマリリージョンと同じパターンでバックアップストレージが課金されるため、要件に応じたバックアップ保持ウィンドウの制御による最適化をお勧めします。

Aurora MySQL のクロスリージョンリードレプリカ

クロスリージョンリードレプリカは、セカンダリリージョンにアクティブなコンピューティングリソースを配置するより従来型のアプローチです。このアプローチも読み取りワークロードをグローバルに分散するのに役立ちますが、セカンダリリージョンでコンピューティングリソースを常時稼働させる必要があるため、コンピューティングコストが高くなります。レプリケーションはセカンダリリージョンでトランザクションログ、すなわち MySQL のバイナリログを適用することで動作するためです。クロスリージョンリードレプリカのレプリケーションラグは、実際のクエリの論理的な再生のため通常変動し、RPO は長時間実行クエリやその他のワークロードパターンなどの要因に依存します。アクティブなリーダーインスタンスを持つグローバルクラスターと同様に、スタンドアロンクラスターとして昇格するアクションにより RTO は 1 分未満です。グローバルクラスターと同様に、セカンダリリージョンクラスターは独自の自動バックアップと保持期間が設定されており、独自の PITR が可能です。

クロスリージョンスナップショットコピー

クロスリージョンスナップショットコピーは、指定した Aurora クラスタースナップショット (手動スナップショットまたは自動バックアップのスナップショット) のコピーをセカンダリリージョンに持つ方法を提供します。これらの操作は Amazon EventBridge や AWS Lambda などの AWS サービスとの連携で自動化できますが、主な考慮事項としてスナップショット作成タイムスタンプへのリカバリに限定されるという制限があります。これにより RPO が大きくなり、スナップショット作成の頻度とセカンダリリージョンへのコピーアクションによって変動します。また、RTO はセカンダリリージョンでコピーされたスナップショットからのリストアとして新しいクラスターを作成することに依存し、全体のストレージサイズとインスタンスの作成時間によって変わります。コスト面での追加のデメリットとして、スナップショットの各コピーはフルスナップショットであり、作成時のボリュームサイズと等しくなります。スナップショットのサイズに基づくデータ転送コストも含める必要があります。詳しくは Amazon Aurora の料金を参照してください。この災害対策アプローチを使用する必要がある場合、セカンダリリージョンで災害対策用に管理しているウィンドウを超えた古いスナップショットを手動で削除することを検討してください。

クロスリージョンバックアップアプローチの選び方

アプローチの選択は、最終的に具体的な要件に依存します。ヘッドレスクラスターを使用したグローバルデータベースアプローチは、コスト最適化が重要で、セカンダリリージョンでの即時読み取りアクセスが不要な災害対策シナリオで特に魅力的です。最小限の RPO 要件で主に災害対策に焦点を当てている場合、ヘッドレスクラスターアプローチの方がコスト効率が高く、従来のグローバルデータベースデプロイメントと比較してセカンダリリージョンのコストを削減できます。ただし、RPO が追加の遅延を許容でき、セカンダリリージョンでのスナップショット管理の負荷を許容できる場合は、クロスリージョンスナップショットコピーの維持もオプションとなり得ます。

バックアップストレージ消費量の最適化方法

バックアップストレージの使用量は主に以下の要因に依存します。

• PITR の柔軟性を確保する自動バックアップの保持期間。
• バックアップ保持ウィンドウ内のデータ変更率。保存される変更量に影響します。
• バックアップウィンドウを超えて作成・保持されるスナップショットの数。
• 自動バックアップのベースラインを決定するクラスターストレージのサイズ。

各ワークロードのデータ保持ポリシーと災害対策要件に基づき、自動バックアップと手動スナップショットの使用を慎重に評価してください。各 DB クラスターに設定された自動バックアップの保持期間が、想定されるワークロードと保持ポリシーに合致していることを確認してください。

自動バックアップに保存されるデータ変更量を削減するために、適切な場合は保持期間を短縮してください。自動バックアップのストレージ使用量はデータ変更率に依存するため、保持期間の短縮はデータ変更速度が高いワークロードで最も大きなコスト削減効果をもたらします。日次データリフレッシュや、大規模な日次またはそれ以上の頻度の ETL (抽出、変換、ロード) ジョブなど、データセット全体の大部分に影響するデータ変更が含まれます。

データ変更率が低く、35 日以下の期間バックアップを保持する必要がある場合、短い保持期間と手動スナップショットを使用するよりも、バックアップ保持期間を延長する方がコスト効率が高い場合があります。各手動スナップショットは作成時のストレージボリュームサイズと同等で課金されます。データ保持ポリシーに基づいて定期的に保存されている手動スナップショットを一覧・確認し、不要なスナップショットを削除してください。

スナップショットコピー操作とプロセスを確認し、要件を満たしつつ過剰にならないようにしてください。各コピーは元のスナップショット作成時のソースボリュームのフルストレージサイズで課金される新しいスナップショットになります。スナップショットを異なるリージョンにコピーすると、すべてのリージョンにわたってバックアップに保存されるデータ変更量が倍増します。

まとめ

本記事では、Amazon Aurora が独自の分散ストレージアーキテクチャを活用して堅牢で継続的なバックアップ機能を提供する仕組みについて説明しました。変更がリアルタイムで非同期に S3 バケットにストリーミングされる継続的バックアップアプローチにより、データベースパフォーマンスに影響を与えることなくポイントインタイムリカバリが可能になります。

Aurora バックアップの CloudWatch メトリクスにより、バックアップストレージ消費量とコストへの影響を可視化できます。自動バックアップストレージの使用量は、ワークロードパターン、データ変更率、設定された保持期間によって大きく変動します。手動スナップショットの適切な管理、不要なスナップショットコピー操作の最小化、自動バックアップ保持期間の適正化により、Aurora バックアップストレージの消費量とコストを最適化できます。

まず Amazon RDS コンソールで現在のバックアップ設定を確認してください。Aurora のバックアップとリストアの詳細については、Aurora ドキュメントの「Backing up and restoring an Amazon Aurora DB cluster」を参照してください。

著者について

この記事はSolutions ArchitectのShinya Sugiyama が翻訳を担当しました。