S3ライフサイクルルール — 移行・有効期限・バージョン管理の設計パターン

ライフサイクルルールの2つの機能

S3ライフサイクルルールは「自動でストレージクラスを変更する」と「自動でオブジェクトを削除する」の2つの機能を持つ。

Transition（移行）:   指定日数後に別のストレージクラスへ移動
Expiration（期限）:   指定日数後にオブジェクトを削除（または削除マーカー作成）

ストレージクラスの移行方向（制約あり）

移行は**「低コスト方向のみ」**が原則だ。逆方向（GlacierからStandardへ）の自動移行はできない。

Standard
  ↓
Standard-IA / One Zone-IA / Intelligent-Tiering
  ↓
Glacier Instant Retrieval
  ↓
Glacier Flexible Retrieval
  ↓
Glacier Deep Archive

⚠️ 同じ階層間の移行も制約がある
   Standard-IA → One Zone-IA: 不可
   Intelligent-Tiering → Standard-IA: 不可

移行の最小日数制約

Standard → Standard-IA: 30日以上経過してから
Standard → Intelligent-Tiering: 0日（即時）
Standard → Glacier: 0日（即時）
Standard-IA → Glacier: 0日（移行後）

Small object penalty: Standard-IAやGlacierには最小オブジェクトサイズがある。128KB未満のオブジェクルはIAに移行すると逆に高くなる場合がある（最小128KB分の課金）。

ライフサイクルルールの設定例

{
  "Rules": [
    {
      "ID": "log-archive-policy",
      "Status": "Enabled",
      "Filter": {
        "Prefix": "logs/"
      },
      "Transitions": [
        {
          "Days": 30,
          "StorageClass": "STANDARD_IA"
        },
        {
          "Days": 90,
          "StorageClass": "GLACIER_IR"
        },
        {
          "Days": 365,
          "StorageClass": "DEEP_ARCHIVE"
        }
      ],
      "Expiration": {
        "Days": 2555
      }
    },
    {
      "ID": "temp-files-cleanup",
      "Status": "Enabled",
      "Filter": {
        "Prefix": "temp/"
      },
      "Expiration": {
        "Days": 7
      }
    }
  ]
}

マルチパートアップロードの未完了部分を削除

マルチパートアップロードが途中で中断されると、アップロード済みのパートがS3に残り課金される。ライフサイクルルールで自動クリーンアップできる。

{
  "Rules": [{
    "ID": "cleanup-incomplete-multipart",
    "Status": "Enabled",
    "Filter": {},
    "AbortIncompleteMultipartUpload": {
      "DaysAfterInitiation": 7
    }
  }]
}

バージョニング有効時のライフサイクル

バージョニング有効時は「現在のバージョン」と「古いバージョン（Noncurrent）」を別々に管理できる。

{
  "Rules": [{
    "ID": "versioned-lifecycle",
    "Status": "Enabled",
    "Filter": {},
    "Transitions": [
      {
        "Days": 90,
        "StorageClass": "STANDARD_IA"
      }
    ],
    "NoncurrentVersionTransitions": [
      {
        "NoncurrentDays": 30,
        "StorageClass": "STANDARD_IA"
      },
      {
        "NoncurrentDays": 90,
        "StorageClass": "GLACIER"
      }
    ],
    "NoncurrentVersionExpiration": {
      "NoncurrentDays": 365,
      "NewerNoncurrentVersions": 5
    },
    "ExpiredObjectDeleteMarkerExpiration": {
      "ExpiredObjectDeleteMarker": true
    }
  }]
}

フィルターの種類

// プレフィックスでフィルタ
"Filter": { "Prefix": "images/" }

// タグでフィルタ
"Filter": {
  "Tag": { "Key": "Environment", "Value": "dev" }
}

// プレフィックスとタグの組み合わせ（AND条件）
"Filter": {
  "And": {
    "Prefix": "data/",
    "Tags": [
      { "Key": "Type", "Value": "logs" }
    ]
  }
}

// バケット全体（フィルタなし）
"Filter": {}

コスト最適化の実践パターン

シナリオ: CloudFrontアクセスログの管理

CloudFront → S3（Standardに書き込み）
  ↓ 30日後
Standard-IA
  ↓ 90日後
Glacier Flexible（監査用、取り出し不要）
  ↓ 1年後
削除（法定保存期間満了）

→ ライフサイクルルールで完全自動化

試験頻出ポイント

シナリオ	設定
作成から30日はStandard、その後低頻度	30日後にStandard-IAへ移行
マルチパート中断による課金を防ぐ	AbortIncompleteMultipartUpload設定
最新5バージョンだけ保持	NoncurrentVersionExpiration + NewerNoncurrentVersions
削除マーカーだけ残るゾンビを削除	ExpiredObjectDeleteMarker: true
GlacierからStandardへの自動移行	不可（手動でRestoreが必要）

まとめ

ライフサイクルルールはS3のコスト最適化とデータ管理の自動化に不可欠だ。移行方向の制約（低コスト方向のみ）とマルチパートの未完了部分クリーンアップを忘れずに設定することが運用上重要になる。

S	公式ソース確認済み
A	成功実績多数・失敗例少数
B	賛否両論
C	動作未確認・セキュリティリスク高
Z	個人所感