S3ライフサイクルポリシー「Expiration: 1日」で、ファイルは本当にいつ消えるのか
はじめに
S3のライフサイクルポリシーで Expiration: 1 Days を設定した場合、ファイルはアップロードからきっちり24時間後に消えるのでしょうか？
それとも別のタイミングで消えるのでしょうか？
AWSドキュメントには「オブジェクトの有効期限はUTC午前0時に評価される」との記載がありますが、実際の削除がいつ実行されるかは明確に記載されていません。
そこで、実際にS3バケットの状態を1時間おきに記録し続ける実験を行い、ライフサイクルによる削除の正確なタイミングを確認しました。
実験概要
実験環境
| 項目 | 内容 |
|---|---|
| リージョン | ap-northeast-1（東京） |
| 試験期間 | 2026/08/15 ～ 2026/08/19（5日間） |
ライフサイクル設定
- ルール名: lifecysle-test
- 有効期限: 1日（オブジェクト作成から1日後に期限切れ）
- フィルター: なし（バケット内の全オブジェクトに適用）
実験方法
EC2（Windows）のタスクスケジューラに、1時間おきに対象S3バケットの aws s3api list-objects-v2 結果を取得し、同じS3バケットにTXTファイルとして出力する処理を登録しました。
- ファイル名形式:
YYYYMMDDHHmmss.TXT（JST基準） - 出力内容: その時点でのS3バケット内の全オブジェクト一覧
- 取得間隔: 1時間ごと
これにより、「あるファイルが前回のリストには存在していたが、次のリストでは消えている」というタイミングを1時間の精度で特定できます。
実験結果
各ファイルの作成・削除タイムライン
各記録ファイルの中身を比較することで、以下のタイムラインが判明しました。
8/15（UTC日付）に作成されたファイル群の追跡
| 確認タイミング（JST） | 確認タイミング（UTC） | 8/15作成ファイルの状態 |
|---|---|---|
| 8/15 09:00 ～ 8/17 21:00 | 8/15 00:00 ～ 8/17 12:00 | ✅ 存在（毎時の記録に含まれている） |
| 8/17 21:00 → 8/17 22:00 の間 | 8/17 12:00 → 8/17 13:00 の間 | 🗑️ 削除実行 |
| 8/17 22:00 以降 | 8/17 13:00 以降 | ❌ 存在しない |
Expiration: 1 Days であるにもかかわらず、8/17のUTC 12:00～13:00（JST 21:00～22:00）に初めて削除されました。作成から約2日＋12時間後です。8/16（UTC日付）に作成されたファイル群の追跡
| 確認タイミング（JST） | 確認タイミング（UTC） | 8/16作成ファイルの状態 |
|---|---|---|
| 8/16 09:00 ～ 8/18 22:00 | 8/16 00:00 ～ 8/18 13:00 | ✅ 存在（毎時の記録に含まれている） |
| 8/18 22:00 → 8/18 23:00 の間 | 8/18 13:00 → 8/18 14:00 の間 | 🗑️ 削除実行 |
| 8/18 23:00 以降 | 8/18 14:00 以降 | ❌ 存在しない |
8/17（UTC日付）に作成されたファイル群の追跡
現時点（8/19 14:00 JST = 8/19 05:00 UTC）のバケット内最古ファイルが 20260817090002.TXT（8/17 00:00 UTC作成）であることから、8/17作成分はまだ削除されていません。過去のパターンから、8/19 UTC 12:00～14:00頃に削除されると予測されます。
削除パターンの全体像
| ファイル作成日 （UTC日付） |
最後に存在確認 （JST / UTC） |
削除確認 （JST / UTC） |
作成から削除まで |
|---|---|---|---|
| 8/15 | 8/17 21:00 JST (8/17 12:00 UTC) |
8/17 22:00 JST (8/17 13:00 UTC) |
約36～60時間 |
| 8/16 | 8/18 22:00 JST (8/18 13:00 UTC) |
8/18 23:00 JST (8/18 14:00 UTC) |
約38～62時間 |
| 8/17 | 8/19 14:00 JST時点で存在 | （未削除・予測: 8/19 21:00～23:00 JST） | – |
削除の仕組み（3段階プロセス）
今回の実験から、S3ライフサイクルの削除は以下の3段階で処理されることがわかりました。
Expiration: 1 Days は「作成から24時間後に消える」という意味ではありません。実際の削除は作成から最短36時間、最長62時間後に行われました。ファイル作成タイミングと実際の保持時間
削除はUTC日付単位で行われるため、同じ日に作成されたファイルでも、作成時刻によって保持時間が異なります。
| 作成タイミング | 具体例 | 削除されるタイミング | 実際の保持時間 |
|---|---|---|---|
| UTC 0:00 直後に作成 | 8/15 00:00 UTC に作成 | 8/17 12:00～13:00 UTC | 約60～61時間 |
| UTC 12:00 に作成 | 8/15 12:00 UTC に作成 | 8/17 12:00～13:00 UTC | 約48～49時間 |
| UTC 23:59 直前に作成 | 8/15 23:59 UTC に作成 | 8/17 12:00～13:00 UTC | 約36～37時間 |
タイムライン図
実務への影響と注意点
1. 「N日で消える」は文字通りではない
Expiration: N Days の実際の動作は：
- 期限切れ判定 = 作成日 + N日目の UTC 0:00
- 実際の削除 = 期限切れ判定の翌日 UTC 12:00～14:00頃
- つまり実質 N + 1.5～2.5 日間 存在し続ける
2. コスト計算への影響
ストレージコスト見積もり時は、設定日数 + 1～2日分のバッファを見込む必要があります。大量のオブジェクトを短期間で処理する場合、この差は無視できません。
3. コンプライアンス要件への対応
「N日以内にデータを必ず削除する」という要件がある場合、ライフサイクルポリシーだけでは保証できません。厳密な削除タイミングが求められる場合は、Lambda + EventBridge 等を使った能動的な削除処理を検討してください。
4. 削除バッチの実行時間帯にはばらつきがある
| 削除対象日（UTC） | 削除実行時間帯（UTC） | 削除実行時間帯（JST） |
|---|---|---|
| 8/15作成分 | 8/17 12:00～13:00 | 8/17 21:00～22:00 |
| 8/16作成分 | 8/18 13:00～14:00 | 8/18 22:00～23:00 |
日によって1時間程度のずれがあり、削除バッチの実行タイミングは完全に固定されているわけではないことがわかります。
📋 まとめ
| 項目 | 結果 |
|---|---|
| ライフサイクル設定 | Expiration: 1 Days |
| 期限切れ判定 | 作成日の翌日 UTC 0:00 |
| 実際の削除実行 | 期限切れ判定のさらに翌日 UTC 12:00～14:00 |
| 削除バッチ頻度 | 1日1回 |
| 最短保持時間 | 約36時間（UTC 23:59直前に作成した場合） |
| 最長保持時間 | 約61時間（UTC 0:00直後に作成した場合） |
| 削除の単位 | UTC日付単位（同日作成分を一括削除） |
結論
S3ライフサイクルポリシーの Expiration は、即座にオブジェクトを削除するものではなく、AWSの内部バッチ処理スケジュールに依存します。
設計時には「設定日数 + 最大2日」のバッファを考慮してください。
