EBS スナップショットは増分なのに全復元できる仕組み - ブロックレベルの差分管理の裏側

増分バックアップの基本概念

EBS スナップショットは増分バックアップです。最初のスナップショットはボリューム全体のコピーですが、2 回目以降のスナップショットは前回のスナップショットから変更されたブロックだけを保存します。100GB のボリュームで、スナップショット間に 5GB のデータが変更された場合、2 回目のスナップショットは 5GB 分のストレージしか消費しません。この増分方式により、スナップショットの作成時間とストレージコストが大幅に削減されます。しかし、ここで疑問が生じます。増分バックアップなら、復元時には最初のフルバックアップ + すべての増分を順番に適用する必要があるのではないか。従来のテープバックアップではそのとおりですが、EBS スナップショットは異なる仕組みで動作します。

ブロックレベルの参照構造

EBS スナップショットの内部構造は、ブロック (通常 512KB) 単位のポインタテーブルです。各スナップショットは、ボリュームのすべてのブロックに対するポインタを持っています。変更されたブロックは新しいデータとして保存され、変更されていないブロックは前のスナップショットのデータを参照します。具体例で説明します。ボリュームが 100 個のブロックで構成されているとします。スナップショット A は 100 個すべてのブロックのデータを保存します。スナップショット B は、ブロック 5 と 10 が変更されたため、この 2 つの新しいデータを保存し、残りの 98 個はスナップショット A のデータを参照します。スナップショット C は、ブロック 3 と 5 が変更されたため、この 2 つの新しいデータを保存し、残りはスナップショット B (またはその参照先の A) のデータを参照します。この構造により、どのスナップショットからでも、すべてのブロックのデータを辿ることができます。スナップショット C から復元する場合、ブロック 3 と 5 は C のデータ、ブロック 10 は B のデータ、残りは A のデータが使用されます。この参照の解決は EBS が内部で自動的に行うため、ユーザーは増分の順序を意識する必要がありません。

スナップショットの削除と参照の再構成

増分バックアップで最も混乱しやすいのが、中間のスナップショットを削除した場合の挙動です。スナップショット A → B → C がある状態で、B を削除するとどうなるでしょうか。従来の増分バックアップでは、B を削除すると C が復元不能になります。しかし、EBS スナップショットでは B を安全に削除できます。B を削除する際、B だけが保持しているブロック (B で変更され、C では変更されていないブロック) のデータが C に統合されます。つまり、C のポインタテーブルが更新され、B を参照していたポインタが A のデータまたは統合されたデータを直接参照するように変更されます。この統合処理は EBS が内部で自動的に行います。結果として、どのスナップショットを削除しても、残りのスナップショットからの復元に影響はありません。最初のスナップショット A を削除しても、B と C は正常に復元できます。A だけが保持していたブロックのデータが B に統合されるためです。

スナップショットの保存先と復元のレイテンシ

EBS スナップショットのデータは S3 に保存されます。ただし、ユーザーの S3 バケットではなく、AWS が管理する内部の S3 インフラに保存されるため、S3 コンソールからスナップショットのデータを直接見ることはできません。スナップショットからボリュームを復元する際、データは S3 から EBS のストレージインフラに転送されます。ここで重要なのは、復元は「遅延ロード」(Lazy Loading) で行われるという点です。ボリュームの作成は即座に完了しますが、すべてのブロックが S3 から転送されるまでには時間がかかります。まだ転送されていないブロックにアクセスすると、その時点で S3 からオンデマンドで取得されます。この遅延ロードにより、最初のアクセス時にレイテンシが増加する「ファーストタッチペナルティ」が発生します。本番環境でこのペナルティを回避するには、Fast Snapshot Restore (FSR) を有効にします。FSR は、スナップショットのデータを事前に EBS のストレージインフラにプリロードし、復元直後からフルパフォーマンスでアクセスできるようにします。FSR の料金は Data Services Unit-Hour (DSU-Hour) という単位で計算され、課金量は「スナップショット数 × 有効化した AZ 数 × 有効化していた時間」です。1 DSU-Hour の単価は 2026 年 8 月時点でバージニア北部が 0.75 USD、東京が 0.90 USD です。課金は分単位の按分ですが 1 時間の最低課金があるため、東京の 2 つの AZ で 1 個のスナップショットに 30 分だけ有効化した場合でも、1 スナップショット × 2 AZ × 1 時間分として 1.80 USD がかかります。FSR は明示的に無効化するまで課金が続く点、および共有されたスナップショットに FSR を有効化した場合は所有者ではなく有効化したアカウント側に課金される点も、運用設計では見落としやすい注意点です。

EBS Snapshots Archive - コスト削減の選択肢

2021 年に導入された EBS Snapshots Archive は、アクセス頻度の低いスナップショットを低単価のアーカイブ層に移動する機能です。課金される軸は 3 つあり、単価はいずれも 2026 年 8 月時点でバージニア北部と東京が同額です。復元に要する時間はスナップショットのサイズによりますが、公式ドキュメントには最大 72 時間と記載されています。

ここで見落としやすいのが、アーカイブ層のスナップショットは常にフルスナップショットになるという性質です。元が増分スナップショットであっても、アーカイブ層にはスナップショット作成時点のボリューム全体のブロックが保存されるため、格納サイズは多くの場合、元の増分より大きくなります (ボリュームのスナップショットが 1 個だけの場合は最初のスナップショット自体がフルなので、サイズは変わりません)。実サイズは describe-snapshots で確認できます。このため AWS はアーカイブの適用先として月次・四半期・年次のスナップショットを推奨しており、単一ボリュームの日次増分スナップショットをアーカイブすると標準層に置き続けるより高くなる場合があると明記しています。また、スナップショットをアーカイブすると、同じ系列の他のスナップショットから参照されているデータは標準層に残り、そのストレージ料金は系列内の次のスナップショットに帰属します。したがって Archive が向くのは、コンプライアンス要件で長期保持が必要で、かつ復元が例外的なスナップショットです。たとえば月次のフルバックアップを 7 年間保持する規制がある場合、直近 3 ヶ月分は標準層に保持し、それ以前を Archive に移す設計が成立します。ただし、アーカイブ中のスナップショットからは直接ボリュームを作成できず、共有もコピーもできません (使用する前に標準層への復元が必要で、FSR も自動的に無効化されます)。90 日以内に取り出す可能性がある世代は、早期削除料金と復元料金を含めて総額を比較してから移動を判断します。スナップショットのライフサイクル管理は、Amazon Data Lifecycle Manager (DLM) で自動化できます。DLM は、スケジュールに従ってスナップショットを自動作成し、保持期間に従って古いスナップショットを自動削除し、アーカイブ層への移動も自動化できます。