ひとことで言うと
アクセス頻度を監視して、自動で安いストレージ階層に移してくれる仕組みです。取得（retrieval）に追加料金はかからず、月あたりのオブジェクト監視・自動化の料金だけがかかります。
要するに、自動で棚卸しをしてくれる倉庫です。RAGのコーパスは「どの文書がいつ検索に使われるか」を事前に読めません。ある文書は毎日検索され、別の文書は半年に一度も呼ばれない。人間が使用頻度を予測して階層を決める代わりに、Intelligent-Tieringが実際のアクセスを見て勝手に移動してくれます。
だから試験の分岐は「アクセスパターンが読めるか、読めないか」です。読めるなら安いStandard-IAを直接指定した方が監視料金の分だけ得です。読めないときだけIntelligent-Tieringが正解になります。
何に使うか
| 用途 | 使い方 | 関連ドメイン |
|---|---|---|
| RAGコーパスのコスト最適化 | Knowledge Basesのデータソースとして使うS3バケットに設定し、参照頻度が下がった古い文書のコストを自動で下げる | D4 4.1 |
| 生成AIアプリのログ・出力の保管 | アクセス頻度が読めない推論ログ・生成物を、削除せず安く持ち続ける | D4 4.1 |
| データレイクの新規アプリ | 「アクセスパターンが不明・変化する」データ全般の既定クラス | D4 4.1 |
試験でどう問われるか
| 問われ方 | 正解に寄る条件 | 引っかけ |
|---|---|---|
| 「RAG用の文書コーパスのストレージコストを下げたいが、どの文書がいつ参照されるか予測できない」 | アクセスパターンが不明・変化する → S3 Intelligent-Tiering | S3 Lifecycleで日数ベースの機械的な階層移行を設定する案（アクセスの実態と合わなければ、頻繁に参照される文書まで低頻度層に落としてしまう） |
| 「小さいメタデータファイルが大量にあり、コストを下げたい」 | 128KB未満のオブジェクトは監視・自動階層化の対象外で常にFrequent Access層のまま | Intelligent-Tieringを設定すれば小さいファイルも自動で安くなると考える案 |
| 「非同期でしか使わない生成物をさらに安くしたい」 | Archive Access / Deep Archive Access層を明示的に有効化する（既定では有効にならない） | 何もしなくても90日後・180日後に自動でアーカイブされると考える案（自動で移るのはArchive Instant Access層まで） |
「アクセス」の定義がAPIによって違います。GetObject・PutObject・RestoreObjectは階層を上げる（安い層から高い層へ戻す）操作としてカウントされますが、HeadObject・ListObjectsV2・タグ操作はカウントされません。「オブジェクトの存在確認だけしているのに、なぜか階層が上がらない／下がらない」というシナリオは、この違いを見ています。
実務でどう使うか
- オブジェクトサイズが128KB未満だと監視・自動階層化の対象外。 常にFrequent Access層に留まるため、料金は下がりません。チャンク分割で生成した小さなメタデータJSONやサムネイルには効果がないことを前提に設計します
- Archive Access / Deep Archive Access層は明示的にオプトインしないと有効になりません。 既定の自動階層は「Frequent → Infrequent（30日）→ Archive Instant Access（90日）」までで、この3層はすべて低レイテンシです。「最終的に安くなる」と思って放置しても、Glacier相当の階層までは自動で落ちません
- S3 Replicationと組み合わせると、
CopyObjectやBatch Replicationでのレプリケーションは「アクセス」として扱われ、対象オブジェクトの階層が上がります。 頻繁にレプリケーションを回す構成だと、狙った低頻度層に落ち着かないことがあります
HeadObjectやListObjectsV2は階層を上げも下げもしません。存在確認やタグ操作を繰り返しても「アクセスされた」扱いにならず、逆にオブジェクトが低頻度層に落ちるのを止めることもできません。「監視ジョブが定期的に触っているのに階層が下がっていく」というシナリオは、この非対称を見ています。
取り違えやすいもの
| 迷う相手 | 切り分けの一言 |
|---|---|
| S3 Lifecycleポリシー | Intelligent-Tiering＝実際のアクセスを監視して自動判断。Lifecycle＝経過日数というルールベースの機械的な移行。アクセス頻度が予測できるならLifecycle、できないならIntelligent-Tiering |
| S3標準（Standard） | 標準は常にFrequent Access相当の単一階層。Intelligent-Tieringは複数階層を自動で行き来する点が違う |
想起チェック
Q1. アクセスパターンが読めないRAGコーパスのコストを下げたいとき、Lifecycleではなくこちらを選ぶ理由は？
Lifecycleは経過日数だけを見る機械的なルールで、実際に参照されているかを見ません。アクセス頻度が予測できない・変化するデータには、実アクセスを監視して自動で階層を上下させるIntelligent-Tieringの方が適しています。
Q2. 128KB未満の小さいオブジェクトに対してIntelligent-Tieringはどう振る舞いますか？
監視・自動階層化の対象外で、常にFrequent Access層に留まります。コスト削減効果はありません。