# S3 Lifecycle と Intelligent-Tiering の違いを整理する
S3 のコスト最適化を考えるとき、S3 Lifecycle と S3 Intelligent-Tiering を同じ「安くする機能」として扱ってしまうケースはかなり多いです。
ですが、この 2 つは発想がまったく同じではありません。Lifecycle はあらかじめ決めた日数やルールでオブジェクトを移行する仕組みで、Intelligent-Tiering はアクセス実態に応じて階層を自動で最適化する仕組みです。
ここを雑に理解したまま設計すると、試験では選択肢を外し、実務では「Glacier に落としたのに急に参照が必要になった」「自動で戻ると思っていた」という事故につながります。
この記事では、両者を料金表の比較ではなく、運用判断の軸で整理します。
先に結論
先に結論を言うと、判断は次のように分けるとかなり安定します。
- 古くなるタイミングが読めるデータには S3 Lifecycle
- アクセスパターンが読めないデータには S3 Intelligent-Tiering
特に重要なのは、Lifecycle は一度下げたオブジェクトをアクセス増加に応じて Standard へ自動で戻す仕組みではないという点です。
この前提を取り違えると、コスト最適化のつもりが、取り出し遅延や復元待ちを自分で増やすことになります。
なぜ混同されやすいのか
両方とも S3 の保存コストを下げる文脈で登場するため、見た目だけだと似ています。
ただし、実際の判断基準はかなり違います。
- Lifecycle は 時間ベース
- Intelligent-Tiering は アクセスベース
つまり、Lifecycle は「30 日後に Standard-IA、90 日後に Glacier Flexible Retrieval のように、先にルールを決めておく」設計です。一方で Intelligent-Tiering は、「今どう読まれているか」を見ながら階層を寄せていく考え方です。
この違いを曖昧にしたまま「どちらも自動で安くするやつ」と覚えると、必要なときにすぐ読めないストレージクラスへ落としてしまう、といった実務事故が起きます。
S3 Lifecycle の役割
S3 Lifecycle は、オブジェクトの経過日数などを条件にして、ストレージクラス移行や削除を自動化する仕組みです。
たとえば、次のようなルールを作れます。
- 30 日後に Standard-IA へ移行する
- 90 日後に Glacier Flexible Retrieval へ移行する
- 365 日後に Deep Archive へ移行する
- 730 日後に削除する
このため、Lifecycle は時間とともに確実に冷えていくデータに向いています。
向いている例
- 長期バックアップ
- 一定期間後はほぼ参照しない監査ログ
- 保管年限が決まっているアーカイブ
注意点
- アクセスが増えても自動で Standard に戻るわけではない
- Glacier 系に移した場合は復元操作が必要になることがある
- 取り出し時間と取り出し料金も考慮が必要
Lifecycle は便利ですが、あくまで決めたルールを実行する仕組みです。需要変化を読んで勝手に最適化してくれるわけではありません。
S3 Intelligent-Tiering の役割
S3 Intelligent-Tiering は、オブジェクトのアクセス状況を見ながら、自動で適切なアクセス階層へ最適化する仕組みです。
このため、読まれる時期が読みにくいデータに向いています。
向いている例
- いつ再参照されるか読めないユーザーデータ
- 普段は静かだが障害調査時に急に読むログ
- 案件や季節要因でアクセス量が変動するファイル
注意点
- 自動最適化には管理コストがある
- 長期アーカイブ前提のデータでは Lifecycle の方が素直なことも多い
- 何でも Intelligent-Tiering に入れれば最適という話ではない
要するに Intelligent-Tiering は、読まれ方の不確実性を吸収したいときの選択肢です。
比較表で整理する
| 観点 | S3 Lifecycle | S3 Intelligent-Tiering |
|---|---|---|
| 判断基準 | 経過日数やルール | 実際のアクセス頻度 |
| 主な目的 | 計画的に冷やす | 読まれ方に応じて自動調整する |
| 自動で戻るか | 基本的に戻らない | アクセス階層を自動調整できる |
| 向くデータ | 古くなる時期が読める | アクセス変動が読めない |
| 典型的な失敗 | Glacier に落として即時参照を期待する | 何でも入れて管理コストだけ増やす |
この表で見ると、両者は代替というより、判断軸が違う仕組みだと分かります。
実務での使い分け
実務では、次の 3 点で見ると判断しやすいです。
1. 古くなるタイミングが明確か
バックアップや法令保管データのように、時間経過で価値が下がることが分かっているなら Lifecycle が扱いやすいです。
2. 突然の再参照があり得るか
たとえば、通常は見ないが監査や障害対応で急に必要になるデータは、Lifecycle だけで Glacier に落とすと事故になりやすいです。こういうケースでは Intelligent-Tiering の方が安全です。
3. 取り出し待ちを業務が許容できるか
Glacier Flexible Retrieval や Deep Archive を使うなら、必要時にすぐ読めない可能性を前提にしなければいけません。ここを確認せずに「安いから」で選ぶのは危険です。
ありがちなハマりどころ
たとえば、アクセスパターンが読めないユーザーファイル群に対して、単純な Lifecycle ルールで Glacier へ移行したとします。この場合、利用者が急に古いファイルを開こうとしたとき、即時に返せず、復元待ちや追加料金が発生する可能性があります。
逆に、7 年保管が決まっている監査アーカイブを全部 Intelligent-Tiering に入れると、ルールで十分なものにまで管理コストを払うことになります。
大事なのは、単価の安さだけではなく、再参照の不確実性と取り出し要件を一緒に見ることです。
試験での判断基準
AWS 認定試験でも、この 2 つはよく混同されます。問題文を読むときは、次の切り分けが有効です。
- 経過日数ベースで移行したい → Lifecycle
- アクセスパターンが不明で自動最適化したい → Intelligent-Tiering
- Glacier に移した後もすぐ読める前提がある → その前提を疑う
問われているのは、単なる用語の暗記ではなく、時間で決めるのか、アクセス実態で決めるのかです。
まとめ
S3 Lifecycle と Intelligent-Tiering は、どちらも S3 のコスト最適化に有効ですが、役割は同じではありません。
- Lifecycle は、時間経過を基準に計画的に冷やす仕組み
- Intelligent-Tiering は、アクセス状況を見ながら自動で最適化する仕組み
そのため、
- 古くなる時期が読めるなら Lifecycle
- 読まれ方が読めないなら Intelligent-Tiering
という判断が基本になります。
S3 のコスト設計は、安さだけで決めると後で取り出し要件に刺されます。両者の違いを先に切り分けておくと、設計判断も試験問題もかなり安定します。