「S3の保管料金が高いから、あまり使わないログファイルは全部 Glacier に移してしまおう」

そう考えてライフサイクルポリシーを設定した結果、請求額が安くなるどころか、逆に跳ね上がってしまった経験はありませんか？

実は、S3 Glacier（および Glacier Deep Archive）には、ファイルサイズが小さい場合に発動する「課金の罠」が存在します。この記事では、なぜ小さいファイルをGlacierに入れると損をするのか、その仕組みと対策をまとめます。

TL;DR (結論)

KB単位の小ファイルをそのままGlacierに入れると、容量課金が数十倍になることがある
リクエスト料金（移行コスト） だけで、保存料の節約分が吹っ飛ぶ
対策は「ファイルをまとめる」か「ライフサイクルでサイズフィルタをかける」こと

S3 Glacierの「3つの罠」

S3 Glacierなどのアーカイブ系ストレージクラスは、GB単価は激安ですが、独特な課金ルールがあります。特に以下の3点に注意が必要です。

最小課金オブジェクトサイズ（Minimum storage charge per object）
リクエスト料金（Transition requests）
メタデータオーバーヘッド（Metadata overhead）

それぞれ詳しく見ていきましょう。

1. 最小課金オブジェクトサイズ（40KB / 128KBの壁）

これが最大の要因です。Glacier系ストレージには 「実際のファイルサイズに関わらず、最低でもこのサイズ分の料金を請求する」 というルールがあります。

ストレージクラス	最小課金サイズ
S3 Glacier Flexible Retrieval	40 KB
S3 Glacier Deep Archive	40 KB
S3 Glacier Instant Retrieval	128 KB

どういうことか？

例えば、1KB のログファイルを S3 Glacier Flexible Retrieval に保存したとします。
実際の容量は 1KB ですが、AWSからの請求は 40KB 分の料金 として計算されます。

つまり、中身のない「空気」に対して、実データの39倍もの料金を払うことになるのです。

1KBのファイルを100万個保存した場合の衝撃

実容量: 約 1 GB
課金容量: 約 40 GB

これだけで、GB単価の安さが無意味になってしまいます。

2. リクエスト料金（移行コスト）

StandardクラスからGlacierへライフサイクル機能で移動させる際、1ファイルごとに「ライフサイクル移行リクエスト（Lifecycle Transition Request）」の料金がかかります。

この料金は、ファイルサイズに関係なく 「1個あたりいくら」 で決まります。

例（us-east-1）: 1,000リクエストあたり $0.05
1KBのファイルを100万個移動すると... $50（約7,500円）

たった1GB（実容量）のデータを安くするために、7,500円の手数料を払うことになります。1GBをGlacierに置いた時の節約額など微々たるもの（月数円レベル）なので、この移行コストの元を取るのに数十年かかる計算になり、完全な赤字です。

3. メタデータオーバーヘッド

これは意外と知られていない仕様ですが、S3のオブジェクトをGlacierクラスに移行すると、管理用のメタデータ（オーバーヘッド）が追加で発生し、これにも課金されます。

S3 Standard側に残る: 8 KB （オブジェクト名などの管理用）
Glacier側に追加される: 32 KB （インデックスやメタデータ用）

元のファイルが数KBしかない場合、本体よりもこの「管理データ」の方が大きくなってしまい、無駄なコストが増え続けます。

シミュレーション：どのくらい損をするのか？

1KB のファイル 100万個（合計1GB）を S3 Glacier Deep Archive に移行した場合をざっくり計算してみます。

項目	S3 Standardのまま	Deep Archiveへ移行 (罠発動)
課金対象容量	1 GB	40 GB (最小40KBルール適用)
容量単価	高い	安い (Standardの約1/23)
容量料金(月)	~$0.023	~$0.04 (40倍容量のため意外と安くならない)
移行コスト(初回)	$0	~$50.00 (リクエスト料金)
判定	平和	大赤字 (元が取れない)

※リージョンやレートにより変動しますが、傾向としてはこのようになります。

対策：どうすればいいのか？

小さいファイルが大量にある場合、以下のいずれかの対策を行う必要があります。

対策A：ファイルをまとめる（アーカイブ）

Glacierへ送る前に、tar や zip コマンド等で複数のログファイルを1つの大きなファイル（数百MB〜数GB推奨）に固めてからアップロードします。
これが最もコスト効率が良い方法です。

対策B：ライフサイクルルールでサイズフィルタをかける

S3のライフサイクル設定には、ファイルサイズによるフィルタ機能があります。
「128KB未満のファイルは移行しない」という設定を入れることで、事故を防げます。

設定例:

ObjectSizeGreaterThan: 128000 (バイト)
Action: Transition to Glacier Deep Archive

対策C：S3 Intelligent-Tiering を使う

自分で管理するのが面倒な場合は、S3 Intelligent-Tiering がおすすめです。
このクラスは、128KB未満のオブジェクトについては自動的に「高頻度アクセス層（Standard相当）」に留め置き、アーカイブ層へは移動させない仕様になっています（アーカイブインスタントアクセス層を除く）。

つまり、「小さいファイルは安くならないから移動しない」という判断をAWS側が自動でやってくれるため、最小課金サイズの罠を回避できます。

まとめ

S3 Glacier は「大容量の巨大ファイル」を保存するための倉庫です。「大量の小粒ファイル」を入れる場所ではありません。

コスト削減のつもりが「クラウド破産」にならないよう、ライフサイクルを設定する際は 「ファイルサイズ」と「オブジェクト数」 を必ず確認しましょう。

参考文献