【AWS】S3のライフサイクルポリシー設定ガイド｜ストレージクラス移行・自動削除の実践

2026-06-12

はじめに

S3 バケットにログやバックアップ、一時ファイルを置き続けると、オブジェクト数と容量が増え、ストレージ料金が積み上がります。手動で古いファイルを削除したり、ストレージクラスを変更したりする運用は、バケットが増えるほど負担になりやすいです。

次のような要件は、S3 の ライフサイクルポリシー（Lifecycle configuration）で自動化できます。

一定期間アクセスされないデータを安価なクラスへ移す
保持期限を過ぎたオブジェクトを自動削除する

この記事では、ストレージクラスへの移行と有効期限による削除を中心に、ライフサイクルポリシーの設定方法と実務で押さえる注意点を整理します。設定例は AWS CLI の JSON を主に扱い、よくある失敗例もあわせて紹介します。

前提: S3 バケットへのオブジェクト配置は経験があるが、ライフサイクルポリシーは初めて、という読者を想定しています。

背景：ライフサイクルポリシーとは

ライフサイクルポリシーは、バケット単位で定義するルールの集合です。各ルールは フィルター（プレフィックス、タグなど）と アクション（移行・削除など）で構成されます。

S3 は日次でルールを評価し、条件を満たしたオブジェクトにアクションを適用します。評価タイミングは UTC の深夜帯であり、ルールを保存した直後に即時反映されるわけではありません（ライフサイクルの動作）。

移行日数（Days）はオブジェクトの作成日から数えます。 最終アクセス日ではない点に注意してください。

主なアクションは次のとおりです。

アクション	概要	典型的な用途
`Transition`	指定した日数後に別ストレージクラスへ移行	古いログを Standard-IA や Glacier へ
`Expiration`	指定した日数後にオブジェクトを削除	一時ファイルの自動削除
`NoncurrentVersionTransition`	非現行バージョンを別クラスへ移行	バージョニング有効バケットの旧版
`NoncurrentVersionExpiration`	非現行バージョンを削除	旧版の保持日数管理
`AbortIncompleteMultipartUpload`	未完了のマルチパートアップロードを中止	分割アップロードの中断残骸を掃除

ライフサイクルは バケット全体、プレフィックス単位、タグ単位 でルールを分けられます。用途の違うデータを 1 バケットに混在させる場合は、プレフィックスやタグでルールを分けると運用しやすくなります。

移行（Transition）を使う前に知っておくこと

ストレージクラスは、保存コストと取得速度のトレードオフです。Standard は即時アクセス向け、Standard-IA や Glacier 系はアクセス頻度が低いデータ向けに料金を抑えられます。ログやバックアップのように「しばらく読まれなくなるデータ」を安価なクラスへ移すのが、Transition の典型的な使い方です。

移行先を決める前に、各クラスの 最小保存期間 と 最小オブジェクトサイズ を確認しておきます。最小保存期間を満たさない削除・移行では、残り期間分の追加料金が請求されます（ストレージクラスの比較）。

ストレージクラス	最小保存期間	主な用途
S3 Standard	なし	頻繁にアクセスするデータ
S3 Standard-IA	30 日	月 1 回程度のアクセス
S3 One Zone-IA	30 日	再作成可能な低頻度データ
S3 Glacier Instant Retrieval	90 日	四半期に 1 回程度のアクセス
S3 Glacier Flexible Retrieval	90 日	半年に 1 回程度のアーカイブ
S3 Glacier Deep Archive	180 日	年 1 回程度の長期保管

2024 年 9 月以降、128 KB 未満のオブジェクトは、デフォルトではどのストレージクラスへも移行されません（移行に関する一般事項）。

小さなファイルが多いバケットでは、移行ルールを設定してもストレージクラスは変わらないことがあります。S3 Storage Lens などで分布を確認してください。

Standard から Standard-IA への移行は、作成から 30 日未満のオブジェクトには適用できません。

段階移行する場合は、各クラスの最小保存期間を合算した日数が必要です。たとえば Instant Retrieval（90 日）のあと Deep Archive（180 日）へ移すなら、2 段目の Days は 270 以上（作成日からの累計）にします。

"Transitions": [
  { "Days": 90, "StorageClass": "GLACIER_IR" },
  { "Days": 270, "StorageClass": "DEEP_ARCHIVE" }
]

実装と検証

前提を押さえたうえで、コンソールと AWS CLI による設定例に進みます。

1. コンソールでの設定（概要）

S3 コンソールで対象バケットを開く
管理タブ → ライフサイクルルール → ルールの作成
ルール名、適用範囲（バケット全体 / プレフィックス / タグ）を指定
ライフサイクルルールのアクション で「オブジェクトをストレージクラスに移行」「オブジェクトの有効期限」を選択
日数と移行先クラス（Standard-IA、Glacier など）を入力して保存

検証用バケットで試すときは、テスト用プレフィックス（例: logs/test/）に限定すると、本番データへの影響を避けやすくなります。

2. AWS CLI で JSON を設定する

ログバケットを想定した例です。30 日経過で Standard-IA へ移行し、365 日で削除します。7 日以上放置された未完了マルチパートアップロードも掃除します。

{
  "Rules": [
    {
      "ID": "archive-and-expire-logs",
      "Status": "Enabled",
      "Filter": {
        "Prefix": "logs/"
      },
      "Transitions": [
        {
          "Days": 30,
          "StorageClass": "STANDARD_IA"
        }
      ],
      "Expiration": {
        "Days": 365
      },
      "AbortIncompleteMultipartUpload": {
        "DaysAfterInitiation": 7
      }
    }
  ]
}

lifecycle.json として保存し、次のコマンドで適用します。

aws s3api put-bucket-lifecycle-configuration \
  --bucket my-app-logs-bucket \
  --lifecycle-configuration file://lifecycle.json

設定内容の確認は次のとおりです。

aws s3api get-bucket-lifecycle-configuration \
  --bucket my-app-logs-bucket

実装時の注意点:

ルール ID はバケット内で一意にする
Status は Enabled または Disabled。検証中は Disabled で保存し、問題なければ Enabled に変更して再適用する
移行日数（Days）はオブジェクトの 作成日 から数える。最終アクセス日ではない
ライフサイクルルールは 最大 1,000 件 まで（制限事項）

3. バージョニング有効バケットの例

S3 バージョニングを有効にしているバケットでは、上書きや削除をしても旧版が残ります。ライフサイクルでは 現行バージョン と 非現行バージョン を別ルールで扱います。バージョニングが無効なバケットでは、この節の設定は不要です。

バージョン状態は次のコマンドで確認します。

aws s3api get-bucket-versioning --bucket my-app-logs-bucket

{
  "Rules": [
    {
      "ID": "versioned-backup-lifecycle",
      "Status": "Enabled",
      "Filter": {
        "Prefix": "backups/"
      },
      "NoncurrentVersionTransitions": [
        {
          "NoncurrentDays": 30,
          "StorageClass": "STANDARD_IA"
        },
        {
          "NoncurrentDays": 90,
          "StorageClass": "GLACIER"
        }
      ],
      "NoncurrentVersionExpiration": {
        "NoncurrentDays": 365
      }
    }
  ]
}

NoncurrentDays は、そのバージョンが 非現行になってから 経過した日数です。上書きや削除で現行でなくなった版に対してアクションが走ります。

4. 動作確認の手順

ライフサイクルは日次評価のため、即時確認は難しいです。次の手順で段階的に検証します。

テスト用プレフィックス にオブジェクトをアップロードする
get-bucket-lifecycle-configuration でルールが意図どおり保存されているか確認する（成功基準: JSON がそのまま返る）
S3 コンソール → バケット → メトリクス または Storage Lens で、ストレージクラス分布の変化を数日〜数週間観察する
本番適用前に、移行先クラスからの 取得料金 と 最小保存期間 が要件に合うか見積もる

削除だけを短日数で試す場合は、Standard-IA や Glacier 系は最小保存期間の制約があります。Standard クラスのまま Expiration のみ で削除テストする方法が安全です。

よくある失敗例：移行日数が最小保存期間より短い

Standard-IA へ 7 日後 に移行するルールを設定した例です。

{
  "Rules": [
    {
      "ID": "too-early-transition",
      "Status": "Enabled",
      "Filter": { "Prefix": "data/" },
      "Transitions": [
        {
          "Days": 7,
          "StorageClass": "STANDARD_IA"
        }
      ]
    }
  ]
}

Standard-IA の最小保存期間は 30 日です。7 日後への移行を指定したルールは、保存時にバリデーションエラーとなる場合があります。Standard から IA 系へ移す場合は、30 日以上 を指定してください。

対処: 移行先クラスの最小保存期間を公式ドキュメントで確認し、段階移行する場合は各段の合計日数も検証する。アクセス頻度が読めないデータは S3 Intelligent-Tiering の利用も検討できます（本記事の範囲外ですが、移行ルールの代替になり得ます）。

まとめ

ライフサイクルポリシーで、ストレージクラス移行と期限切れ削除をバケット単位で自動化できる
移行日数は作成日基準であり、Standard-IA（30 日）や Glacier 系（90〜180 日）には最小保存期間がある
本番適用前にテスト用プレフィックスでルールを検証し、128 KB 未満のオブジェクトや取得料金の影響も確認する

次に試すこと

上記「AWS CLI で JSON を設定する」の例で Prefix とバケット名を自分の環境に置き換え、put-bucket-lifecycle-configuration で適用する
get-bucket-lifecycle-configuration でルールが返ることを確認し、テスト用プレフィックスにオブジェクトを 1 件アップロードする
バージョニング有効バケット（get-bucket-versioning で確認）であれば、非現行版の移行・削除ルールを追加する
削除だけを試す場合は Standard + Expiration の短日数ルールで検証する（IA / Glacier 系は最小期間の制約あり）
コスト見積もりが必要なら、S3 料金と AWS Pricing Calculator で移行先クラスと GET 回数を入力して確認する

Source

AWSAWS,S3

Posted by 千原耕司