スナップショットの実装方法に関する詳細なドキュメントは見つからないと思います。それは私が遭遇したものではありません。「Projecting Costs」のドキュメントがあります。 ただ、仕組みがわかれば、直感的にお会計できるし、安心できると思います。
これらのスナップショットは、DOS オペレーティング システムでその用語を理解するようになった方法での「増分」ではないことに注意してください。DOS では、ファイルが変更されると「アーカイブ」ビットが設定され、「増分」バックアップは「アーカイブ」ビットが設定されたファイルのみをコピーしました。バックアップ プロセスはアーカイブ属性をクリアするため、今後ファイルを編集すると、再び「増分」バックアップされることになります。
スナップショットを使用すると、ボリュームの各ブロックが変更された場合にフラグが付けられます。ファイルごとに行われるわけではありません。最初のスナップショットの後、DOS の「増分」バックアップと同様に、変更済みとしてフラグが付けられたブロックのみがバックアップされます。しかし、類似点はここまでです。コピーする必要のない各ブロックでは、それをスキップするだけでなく、データの最後の (変更されていない) コピーがある場所へのポインターを書き込むためです。
ボリュームの最初のスナップショットを作成すると、データはブロックに分割されます。Amazon から: 「ボリューム データは、Amazon S3 に転送される前にチャンクに分割されます。チャンクのサイズは将来の最適化によって変更される可能性がありますが、変更されたデータのサイズを分割することで [...] 数を見積もることができます。最後のスナップショットから 4MB の差があります。」
次に作成するスナップショットは、変更されたブロックのみのデータと、変更されていないブロックへのポインターで構成されます。これらのポインタは、前のスナップショットのデータ ブロックを指しています。
次のスナップショット (n) は、前回のスナップショット (n-1) 以降に変更された各ブロックのデータと、前回のスナップショット (n-1) 以降に変更されていないブロックのポインターを記録することによって作成されます。これらのポインターは、データを含む可能性がある前のスナップショット内の対応するブロック、またはその前のスナップショットへの別のポインターを指します。最終的に、すべてのポインターは実際のデータのブロックになります (スナップショットが作成されてから変更されていません)。
ここで、スナップショット (x) を削除するとします。スナップショット (x) には、その前 (x-1) と後 (x+1) に作成されたスナップショットがあります。Amazon は、スナップショット (x+1) 内のポインターを、スナップショット (x) (削除されるもの) からのポインターとデータに置き換えます。その結果、スナップショット (x) 内の実際のデータは、スナップショット (x+1) にコピーされます。ただし、そのブロックの最新データの独自のコピーがそこにある場合を除きます。
これが、スナップショットの仕組み、データの保存場所、およびスナップショットのサイズが管理しやすい理由です。このことから、スナップショットを削除すると、他のスナップショットを使用する機能を破壊することなく、そのスナップショットが作成された時点の状態にボリュームを戻す機能のみが破壊されることを理解できます。ポインターを使用しない単純な従来の「増分」バックアップとは異なり、削除されていないスナップショットは、依存するスナップショットの 1 つが削除されたときに、その有用性を維持するために必要に応じて更新されます。これが、Amazon が EBS ボリュームの単純なコピーよりもインテリジェントなスナップショット ストレージに多くの料金を請求するのが理にかなっている理由です。最後に、スナップショット ストレージは非常に動的であるため、コストを予測するのが難しいことは理解できます。