初めに
Amazon S3には多くのストレージクラスがあり、長期に保管されるものについてはライフサイクルを利用して別の安価なストレージに保管するということはよくあるケースかと思います。
ただそれらのストレージクラスへの途中での移行については単純に必ずしもコストを抑えられるとは限りません。
これはライフサイクル自体にコストが発生することや、メタデータのサイズを加算して計算することがあるためとなります。
ではライフサイクル移行を行うことでコスト削減になるかならないかの境界はどこになるのでしょうか。
注意
本記事で算出された値は小数の丸め計算等の影響を大きく受けているような箇所があります。
またAWS側での小数部分の丸めなどの処理による部分もあるかと思います。
あくまで傾向値として頂き、正確な値は実際の環境で各自計算いただければ幸いです。
なお記載料金は2023/05/30時点、東京リージョンのものに基づいています。
料金計算にて考慮に入れるべきこと
今回計算するにあたりサイズ計算では最小オブジェクトサイズ、とメタデータやインデックスといったオーバーヘッド部分の容量を考慮に入れる必要があります。
ファイルサイズにかかるオーバーヘッド
https://aws.amazon.com/jp/s3/pricing/
S3 Glacier Flexible Retrieval と S3 Glacier Deep Archive ストレージクラスでは、適切なストレージクラス料金が課される S3 Glacier のインデックスとメタデータに対して、オブジェクトあたり 32 KB のデータがさらに必要となります。Amazon S3 では、S3 Glacier Flexible Retrieval と S3 Glacier Deep Archive にアーカイブされるオブジェクトのユーザー定義名とメタデータを保存して維持するために、オブジェクトごとに 8 KB が必要です。
一部のストレージクラスではデータ本体とは別にメタデータ等の付随データが必要となり、ストレージ料金としては実際のファイルのサイズに加えこれらのサイズが加えて計算されます。
最小オブジェクトサイズ
https://aws.amazon.com/jp/s3/pricing/
128 KB より小さいサイズのオブジェクトを保存することもできますが、適切なストレージクラス料金で 128 KB のストレージとして課金されます。
一部ストレージクラスでは最小オブジェクトサイズが指定されており、これを下回るオブジェクトが格納された場合最低オブジェクトサイズで指定されたサイズとして計算されるようです。
[128 KB 未満のオブジェクト]
- 以下の移行で、Amazon S3 は128 KB 未満のオブジェクトを移行しません。
S3 Standard または S3 標準 – IA ストレージクラスから S3 Intelligent-Tiering または S3 Glacier Instant Retrieval へ移行します。
S3 Standard ストレージクラスから S3 Standard – IA または S3 1 ゾーン – IA への移行。
また直接格納する場合は最小オブジェクトサイズを下回る状態で格納可能なようですが、ライフサイクルでの移行は対象とならりません。
今回はライフサイクルで移行するケースを想定しているため対象ストレージクラスで最低オブジェクトサイズを満たさないものについては取り扱いません。
上記の情報をストレージクラス別にまとめると以下の通りです。
| ストレージクラス | 最低オブジェクトサイズ | ファイルあたりのオーバーヘッドサイズ |
|---|---|---|
| S3 標準 | なし | なし |
| S3 標準 -IA | 128KB | なし |
| S3 1ゾーン | 128KB | なし |
| S3 Glacier Instant Retrieval | 128KB | なし |
| S3 Glacier Flexible Retrieval | なし | 40KB |
| S3 Glacier Deep Archive | なし | 40KB |
計算式
ストレージクラスiに対してsサイズのファイルをN年間保存する場合、ライフサイクルコストを含め１ファイルあたりに発生するコストPi(N,s)について、そのストレージクラスiにおける容量単価をpi、ライフサイクル移行コストをLiとする場合、以下のように表すことができます。
今回求めるべき損益分岐点は移行前のストレージクラスP1(N,s)(標準ストレージ)から、移行後のストレージクラスP2(N,s)の差が0になる場合です。
移行前はライフサイクル移行コストを加味する必要がなく(L1 = 0)で、標準ストレージの場合はオーバーヘッドがないため無視可能です(o1 = 0)。
これを考慮に入れるとNとsの関係は以下のような関係(反比例)になります。
料金が大きく変わって新しい損益分岐点を探したくなった場合はスプレッドシート等に打ち込んでみてください。
この形だと少しわかりづらいですが、要はライフサイクルコスト移行分のコストを移行前後の保持コストの差分で取り返した時が損益分岐点です。
ストレージ単価とライフサイクル移行コスト
今回の計算で利用する各ストレージの料金は以下の通りです
| 標準 | 標準 - IA | 標準 １ゾーン - IA | Instant Retrieval | Flexible Retrieval | Deep Archive | |
|---|---|---|---|---|---|---|
| ストレージ単価($・GB/Month) | 0.025 | 0.0138 | 0.011 | 0.005 | 0.0045 | 0.002 |
| ライフサイクル移行(入)($/1000req) | - | 0.01 | 0.01 | 0.02 | 0.03426 | 0.065 |
ファイルサイズごとの損益分岐点
前述の式より、標準ストレージクラスから別のストレージクラスにライフサイクルで移行した場合、ライフサイクル移行後に1度も取り出しをせず以下の期間保存し続けることができればライフサイクル移行を行わなかった場合よりコスト削減を見込めることとなります。
| (ヶ月) | 標準 - IA | 標準 １ゾーン - IA | Instant Retrieval | Flexible Retrieval | Deep Archive |
|---|---|---|---|---|---|
| 100B | - | - | - | -190.535 | -814.681 |
| 1KB | - | - | - | -213.525 | -1119.426 |
| 10KB | - | - | - | 2209.861(約184年) | 466.468(4年弱) |
| 100KB | - | - | - | 19.301 | 30.755 |
| 128KB | 7.314 | 5.851 | 8.192 | 14.752 | 23.830 |
| 1M | 0.914 | 0.731 | 1.024 | 1.727 | 2.904 |
| 10M | 0.091 | 0.073 | 0.102 | 0.171 | 0.289 |
| 100M | 0.009 | 0.007 | 0.010 | 0.017 | 0.029 |
| 1GB | 0.001 | 0.001 | 0.001 | 0.002 | 0.003 |
※1 -部分はライフサイクル対象外サイズ
※2 小数４桁目を四捨五入
※3 1KB=1024B、1MB=1024KB、1GB=1024MBで計算
なおマイナス値が出ている箇所はオーバーヘッドを含んだ１ヶ月あたりの保存料金が、標準ストレージでの同ファイルの保存料金を超えてしまった部分、すなわちオーバーヘッドにより保管コスト自体が標準より高くなってしまうケースです。
個人的に期間的に使いそうな印象のある区間をも少しピックアップしてみます。
IA系のストレージクラスやInstant Retrievalは用途を考えると(個人的に)128KB~1MBあたりでしょうか。
| (ヶ月) | 標準 - IA | 標準 １ゾーン - IA | Instant Retrieval |
|---|---|---|---|
| 200KB | 4.464 | 3.571 | 5.000 |
| 300KB | 2.976 | 2.381 | 3.333 |
| 400KB | 2.232 | 1.786 | 2.500 |
| 500KB | 1.786 | 1.429 | 2.000 |
| 600KB | 1.488 | 1.190 | 1.667 |
| 700KB | 1.276 | 1.020 | 1.429 |
| 800KB | 1.116 | 0.893 | 1.250 |
| 900KB | 0.992 | 0.794 | 1.111 |
Flexible RetrievalとDeep Archiveは10KB~90KBあたりが壁でしょうか。
| (ヶ月) | Flexible Retrieval | Deep Archive |
|---|---|---|
| 20KB | 148.957 | 171.053 |
| 30KB | 78.759 | 106.557 |
| 40KB | 53.531 | 77.381 |
| 50KB | 40.544 | 60.748 |
| 60KB | 32.629 | 50.000 |
| 70KB | 27.299 | 42.484 |
| 80KB | 23.466 | 36.932 |
| 90KB | 20.577 | 32.663 |
小サイズのファイルの取り出しコストは重い
Glacier系のストレージはデータの取り出しに別途料金が発生します。
| データ取り出し($/1000req) | データ取り出し($/GB) | |
|---|---|---|
| Instant Retrieval | 0 | 0.03 |
| Flexible Retrieval - 迅速 | 11.00 | 0.033 |
| Flexible Retrieval - 標準 | 0.0571 | 0.011 |
| Fexible Retrieval - 大容量 | 0 | 0 |
| Deep Archive - 標準 | 0.1142 | 0.022 |
| Deep Archive - 大容量 | 0.025 | 0.005 |
容量あたりの料金についてはサイズに応じるため重いコストとはならないのですが、小サイズファイルの場合容量に応じないデータ取り出しリクエストの料金が相対的に重いものとなります。
最初の表はどの何ヶ月で損益分岐点に達するかを求めましたが具体的には標準ストレージとGracier系のストレージは1月あたり１ファイルで以下の金額差分が発生します。 (桁が小さいため単位を10^-3にしてます)
| 10^-3 $・月 | Instant Retrieval | Flexible Retrieval | Deep Archive |
|---|---|---|---|
| 100KB | - | 0.002 | 0.002 |
| 128KB | 0.002 | 0.003 | 0.003 |
| 1MB | 0.020 | 0.020 | 0.022 |
※1 -部分はライフサイクル対象外サイズ
※2 小数４桁目を四捨五入
※3 １KB=1024B、1MB=1024KB、1GB=1024MBで計算
Deep Archive - 大容量を基準にした場合、1MBのファイルであれば１回取り出しても損益分岐点が１ヶ月伸びる程となりますが、100KBだとその約10倍の10ヶ月伸びます。
あくまでこの計算はファイルあたりの計算ですの、全てのファイルを取り出すわけではなく部分的に取り出せば実質的にはファイル数で按分したものとなります。
Deep Archive自体ユースケースとしてほとんど取り出しの必要がないものとなっておりますが、仮に取り出す場合はこのくらいの影響があるというのは意識しておいた方が良いかと思います。
終わりに
今回は特定のケースではなくある程度汎用的にどの程度であればライフサイクル移行が有用となるかを確認してみました。
100KBを超えるようなファイルであればコスト削減につながらない、ということはないですがそれ未満となると少し気にする必要が出てくると言った印象です。
例えばCloudFrontやALBのログは５分毎の出力となっておりますので、アクセスの限られた開発環境やアクセス量の少ないサイトではログのサイズが平均したら1桁KBほどしかなく実はコスト増加につながってたというケースがあるかもしれません。
そもそもファイルサイズが小さいもので実数値的なコストは小さいかもしれませんが、チリも積もればということもあるかと思いますので長期＝Glacier系ストレージではなくこのケースは必要か？というのは意識してもらえれば幸いです。
0
