S3 ライフサイクル

S3 ライフサイクルとは

S3 ライフサイクルは、オブジェクトの経過日数に応じてストレージクラスを自動的に移行し、不要になったオブジェクトを自動削除する機能である。アクセス頻度が下がるデータを安価なクラスへ寝かせることで保管料を下げられる。

ただし保管単価の下げ幅がそのまま請求の下げ幅になるわけではない。移行そのものがオブジェクト 1 個ごとのリクエスト課金であり、移行先には最低課金期間があるため、短命なデータや小さなオブジェクトでは移行費が節約額を食い潰す。効くのは「長く置くが、ほとんど読まない」データである。

ストレージクラスとコスト

移行先の選択は、保管単価と取り出しコストの綱引きで決まる。東京リージョンの代表的なクラスを、2026 年 8 月時点の公表料金で並べる。

クラス	用途	料金 (東京、GB/月)	取り出し
Standard	頻繁にアクセス	$0.025	無料
Standard-IA	月 1 回程度のアクセス	$0.0138	$0.01/GB
Glacier Instant	四半期に 1 回程度	$0.005	$0.03/GB
Glacier Flexible	年 1〜2 回	$0.0045	数分〜12 時間
Glacier Deep Archive	ほぼアクセスしない	$0.002	12〜48 時間

段階移行の典型は、次の刻みになる (削減率はいずれも Standard の保管単価との比較)。

• 30 日後: Standard → Standard-IA (約 45 % 削減)
• 90 日後: Standard-IA → Glacier Instant (約 80 % 削減)
• 365 日後: Glacier Instant → Deep Archive (約 92 % 削減)
• 730 日後: 自動削除

最初の刻みが 30 日なのは任意の設計ではない。Standard-IA と One Zone-IA へは、オブジェクト作成から 30 日経つまで移行できない仕様のため、これが最短になる。移行の向きも一方通行で、Standard から下位クラスへ下ることしかできない。Glacier Instant Retrieval に落としたものを Standard へ戻すのはライフサイクルの仕事ではなく、復元してからコピーし直す操作になる。

さらに移行先ごとに最低課金期間がある。Standard-IA と One Zone-IA が 30 日、Glacier Instant Retrieval と Glacier Flexible Retrieval が 90 日、Deep Archive が 180 日で、この期間内に削除・上書き・次のクラスへの移行を行うと、残り日数分の保管料が日割りで請求される。制約は設定時にも効き、単一のルールに最低課金期間より短い間隔の移行を並べることはできない。7 日目に Glacier Instant Retrieval へ移すルールなら、次の Deep Archive への移行は 97 日目以降でなければ受け付けられない。

小さいオブジェクトはそもそも移行されない。2024 年 9 月以降に作成・編集したライフサイクル設定では、128 KB 未満のオブジェクトをどのクラスへも移行しないのが既定の挙動で、移行させたい場合は ObjectSizeGreaterThan などのサイズ条件を明示する必要がある (2026 年 8 月時点)。既定がこうなっているのは、移行費がオブジェクト単位で発生し、小さいオブジェクトでは節約額を上回るためである。Glacier Flexible Retrieval と Deep Archive ではさらに 1 オブジェクトあたり 40 KB のメタデータ (8 KB は Standard 料金、32 KB は移行先の料金) が加算される。小さなファイルが数百万個あるバケットでは、移行より先にまとめて大きなオブジェクトへ束ねる方が効く。

実務での活用パターン

ログファイル

0〜30日: Standard (直近のログは頻繁に参照)
30〜90日: Standard-IA (たまに参照)
90〜365日: Glacier Instant (インシデント調査時のみ)
365日〜: 自動削除 (コンプライアンス要件に応じて延長)

バックアップ

0〜7日: Standard (直近のバックアップは即座にリストア)
7〜97日: Glacier Instant Retrieval (ミリ秒で取り出せる)
97日〜: Deep Archive (標準の取り出しで 12 時間、最安)

刻みが 97 日なのは前節の制約による。7 日目に Glacier Instant Retrieval へ移す設計では、次の移行を 90 日目には置けない (最低課金期間 90 日を満たさないルールは作成が拒否される)。97 日目までずらすか、中間クラスを挟まず 7 日目に Deep Archive へ直接移すかの二択になる。

不完全なマルチパートアップロードの削除

- Id: CleanupIncompleteUploads
  Status: Enabled
  AbortIncompleteMultipartUpload:
    DaysAfterInitiation: 7

中断されたマルチパートアップロードの残骸を 7 日後に自動削除する。これを設定しないと、不完全なパーツがストレージ料金を消費し続ける。未完了のパーツは通常のオブジェクト一覧に現れないため、請求だけが増えて原因が見えにくい。

S3 Intelligent-Tiering

アクセスパターンが予測できない場合は、階層の移動そのものを S3 Intelligent-Tiering に任せる選択もある。30 日連続でアクセスがなければ Infrequent Access 階層へ、90 日連続でアクセスがなければ Archive Instant Access 階層へ自動で移り、どちらもミリ秒で読めるまま単価が下がる。読まれた時点で Frequent Access 階層へ自動で戻り、取り出し料金もかからない (2026 年 8 月時点)。

さらに安い Archive Access 階層 (90 日以降) と Deep Archive Access 階層 (180 日以降) は任意設定で、有効にすると取り出しが非同期になり、読む前に復元操作が必要になる。自動階層化の対価としてオブジェクト単位の監視・自動化料金がかかるため、小さなオブジェクトが大量にあるバケットでは監視料が節約額を上回ることがある (128 KB 未満のオブジェクトは監視・階層移動の対象外で、常に Frequent Access 階層の単価で課金される)。

ライフサイクルの効果は、設定した瞬間ではなく請求が動いたかどうかで判定する。ストレージクラス別の使用量で移行が進んでいるかを確認し、想定より請求が下がらないときは、128 KB 未満で移行対象外になっている、移行リクエスト課金が節約額を食っている、バージョニング有効なバケットで非現行バージョンが Standard に残っている、のいずれかを先に疑うとよい。非現行バージョンには現行版とは別のルール (NoncurrentVersionTransition・NoncurrentVersionExpiration) が必要で、これを書き忘れると「削除したのに請求が減らない」状態になる。