Edited at

snapshot取得・復元ロジックを整理し、課金も正しく理解する

More than 3 years have passed since last update.

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]をクリック