ひとことで言うと
オブジェクトの経過日数を条件に、ストレージクラスの遷移（transition）と失効・削除（expiration）を自動化するルールです。Intelligent-Tieringのような実アクセス監視ではなく、あくまで日数ベースの機械的な処理です。
要するに、賞味期限シールです。「作ってから30日で低頻度層へ、1年で削除」のように、中身を見ずに経過日数だけで機械的に処理します。RAGの学習ログや推論ログのように「いつまで保持する義務があるか」が規約で決まっているデータには、これが向きます。逆に「どの文書がよく読まれるか」で判断したいなら、賞味期限ではなくIntelligent-Tieringの実アクセス監視の出番です。
何に使うか
| 用途 | 使い方 | 関連ドメイン |
|---|---|---|
| 推論ログ・監視ログの保持期間管理 | CloudWatch Logsからエクスポートしたログや監査証跡を、規定期間後に低頻度層へ遷移・最終的に削除 | D3 3.3 |
| モデルカスタマイズの学習データの後始末 | ファインチューニング完了後、学習用JSONLを一定期間後に削除する運用 | D3 3.2 / D4 4.1 |
| コンプライアンス保持期間の実装 | 「規制上◯年保持が必要」という要件を、遷移＋失効アクションの組み合わせで機械的に満たす | D3 3.3 |
試験でどう問われるか
| 問われ方 | 正解に寄る条件 | 引っかけ |
|---|---|---|
| 「監査ログを一定期間後に自動削除したい」 | 経過日数が既知・固定 → Lifecycle の Expiration アクション | Intelligent-Tieringを使う案（Intelligent-Tieringは階層を下げるだけで、削除はしない） |
| 「バケットポリシーで削除を禁止しているのに、古いオブジェクトが消える」 | バケットポリシーはLifecycleルールの実行を止められない。 汎用バケットではポリシーで拒否していてもLifecycleは通常どおり動く | バケットポリシーの設定ミスだと判断する案 |
| 「バージョニング有効化後にLifecycleの挙動が変わった」 | バージョニングを有効にした後は NonCurrentVersionExpiration / NonCurrentVersionTransition を追加しないと、旧バージョンが永久に残る | Lifecycle設定自体が壊れたと判断する案 |
Lifecycleの遷移アクションには「移行リクエスト」という別料金がかかります。PUT・COPY・遷移で新しいストレージクラスに移す操作には従量課金が発生する一方、遷移そのものにデータ取得料金はかかりません。「頻繁に遷移ルールを跨ぐ小さいオブジェクトを大量に持つ」設計は、遷移コストの方がストレージ節約分を上回ることがあります。
実務でどう使うか
- Lifecycleルールは既存オブジェクトにも新規オブジェクトにも同時に適用されます。 「今日ルールを追加したら、作成30日以上前の既存オブジェクトも即座に失効対象としてキューに入る」——過去データを巻き込む前提でルールを書く必要があります
- Intelligent-Tieringへの遷移だけは課金の切り替えタイミングが違います。 通常の遷移はS3が実際に処理を完了した時点で課金が変わりますが、Intelligent-Tieringへの遷移は「実際に移行が完了するまで」旧クラスの料金のままです
- レプリケーション先バケットのLifecycleルールは、複製が到着した時刻ではなく元オブジェクトの作成時刻を基準に効きます。 「レプリカが届いてから30日」ではなく「元オブジェクトが作られてから30日」で計算される点を、マルチリージョン構成では見落としやすいです
最低保存期間があるストレージクラスでは、早すぎる失効が思わぬ課金を生みます。S3 Glacier系のように最低保存期間が設定されたクラスへ遷移させたオブジェクトを、期間が満ちる前に失効（削除）させると、公式ドキュメントが明記する「最低保存期間の課金」が発生します。保持期間の短い学習ログを安いクラスへ急いで遷移させる設計は、かえって高くつくことがあります。
取り違えやすいもの
| 迷う相手 | 切り分けの一言 |
|---|---|
| S3 Intelligent-Tiering | Lifecycle＝経過日数という機械的なルール。Intelligent-Tiering＝実アクセスの監視による自動判断。「◯日後に削除」という確定要件はLifecycle、「アクセス頻度が読めない」はIntelligent-Tiering |
| S3 Object Lock | Lifecycleは「消す・移す」ためのルール。Object Lockは逆に「一定期間消せなくする」ための保持機能。コンプライアンス要件で「改ざん・削除を防ぐ」ならObject Lock、「一定期間で自動的に片付ける」ならLifecycle |
想起チェック
Q1. バケットポリシーで全アクションを拒否していても、Lifecycleルールによる削除は止まりますか？
止まりません。汎用バケットではバケットポリシーでLifecycleルールによる削除・遷移を防ぐことはできず、ルールは通常どおり実行されます。
Q2. バージョニングを有効化したバケットで、Lifecycle設定に追加を忘れると何が起きますか？
NonCurrentVersionExpiration や NonCurrentVersionTransition を追加しないと、非現行バージョン（上書き・削除前の古いバージョン）がLifecycleの対象にならず、永久にStandard相当の課金のまま残り続けます。