EBS-snapshotはS3に保存されます。
利用料金は、S3に保存されている実サイズに対して課金されます。
これは周知の事実だと思います。
今回は、S3の利用料金を正しく理解するに引き続き、
snapshotの取得ロジックを整理すると見えてくる「課金の実体」を
ひも解いてみたいと思います。
#1.snapshotの仕組み
snapshotは、ディスクイメージを取得するのですが、その容量はディスクサイズそのものではなく、
実使用容量分をさらに圧縮した結果のサイズになるので、EBSディスクのサイズよりかなり小さくなります。
しかも、同じEBSのsnapshotを複数回取得する場合、2回目以降は差分のみ取得されるため、
その実容量はとても小さくなります。
参考:snapshotの取得処理方式
「じゃ、全てのsnapshotを保存しておかないと、復元できないのでは？」とお思いになると思いますが、
心配ご無用です。AWSは、復元に必要なデータを裏で全て保存するような仕組みを担保しています。
1つのsnapshotさえ残っていれば、他の全てのsnapshotを削除しても、復元できる仕組みとなっています。
参考:snapshotのリストア処理方式
#2.課金対象の整理
「EBS-snapshotは、S3に保存される容量に対して課金される」というのは知られていますが、
具体的にはどういうことでしょうか？実際の例を見ながら整理していきます。
例）
①：100GBのEBS(使用量=50GB)のsnapshot取得
②：2GBの変更が発生した後にsnapshot取得
③：さらに4GBの変更(②とは別ファイル)が発生した後にsnapshot取得
※ちなみに本例では、話を分かりやすくするため、例圧縮率は考慮外とします。
①では、実用量50GBであるため、snapshotで使用される容量は50GBとなります。
②では、2GBの差分のみ取得されるため、2GBとなります。
③では、②と同じロジックで4GBとなります。
つまり、この3回のsnapshotの合計サイズは56GBとなり、これが課金対象になります。
#3.リストア処理方式の仕組みをもう少し具体的に整理
snapshotは、たとえ差分だけ取得したsnapshotであっても、復元が保証されます。
①②を削除しても、③の復元のためには①②のデータが必要なので、裏では③の復元のために必要なデータが残る事になります。
ここでいう削除とは、「論理削除」であり、「物理削除ではない」のです。
上記例で言えば、①②を削除して③を復元するためには以下のような考え方になります。
①：50GBのうち、2GBは②で更新されているため、2GB分のブロックデータは不要、
さらに、③で変更された4GBのブロックデータも不要、
よって、③復元のために必要な①のブロックデータは44GB
②：2GBは、③を復元するために必要なので残る
③：4GBも当然必要
つまり、①44GB + ②2GB + ③4GB = 50GB が裏で残っている、ということになります。
無駄がないですね。
#4.実サイズの確認方法（参考）
では、snapshotで使用されているS3のサイズを確認する方法はあるのでしょうか？
残念ながらsnapshotの実サイズを、snapshotの一覧画面からは確認することができません。
また、Billingレポートの詳細をみても、S3の使用量しか見えないので、確認できません。
唯一の手段は、レポート"です。
しかし、これもリージョン毎のサイズしか分からないので、個々のsnapshotがどのような履歴を持っていて、
実際どのくらい総容量になっているのか、は確認する術がありません。
課金の流れを確認できないのはちょっと残念ですね。
まぁ、、、そこまで気にする人がいないのかな。。。
というか、そんな流れを可視化されても、それが妥当なのかが判断できないか。。。
$0.095/GB/月なんだから気にすんなよ、という話なんでしょう、きっと。
■ご参考：レポート出力手順
・Management ConsoleのMy Accountページから[Reports]-[AWS Usage Report]を選択
・利用レポートのダウンロードページから、[サービス:EC2]-[使用状況のタイプ:EBS:XXX]を選択（その他は適宜）し、[Download report]をクリック
