「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 は「大容量の巨大ファイル」を保存するための倉庫です。「大量の小粒ファイル」を入れる場所ではありません。
コスト削減のつもりが「クラウド破産」にならないよう、ライフサイクルを設定する際は 「ファイルサイズ」と「オブジェクト数」 を必ず確認しましょう。