Amazon S3で標準クラスから別ストレージクラスへのライフサイクル移行の損益分岐点を見る

初めに

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系ストレージではなくこのケースは必要か？というのは意識してもらえれば幸いです。