Amazon S3 ライフサイクルルール入門｜ストレージクラス自動移行と期限削除でクラウドコストを削減する実践ガイド

Amazon S3のストレージ料金が、毎月じわじわ増え続けていませんか？EC2やRDSと違い、S3は「放置しても動き続ける」ストレージです。バケットに溜め込んだオブジェクトが積み上がる一方で、気づいたらAWSの月次請求が想定の2倍・3倍に跳ね上がっていた、という経験をしたエンジニアは少なくありません。

オンプレのファイルサーバーなら「不要ファイルの削除は誰かが手動でやる」で済んでいたかもしれませんが、クラウドでは自動化が標準です。S3にはライフサイクルルールという仕組みがあり、オブジェクトの経過日数に応じてストレージクラスを自動で移行したり、不要になったオブジェクトを自動削除したりできます。

この記事では、S3ライフサイクルルールの仕組みを基礎から解説し、AWS CLIを使った設定手順・料金シミュレーション・実務でよく使うパターンまで、現場でそのまま使える知識を網羅します。

なぜS3ライフサイクルルールが必要なのか？

オンプレのテープバックアップや階層型ストレージ（HSM）を運用してきたエンジニアなら、「アクセス頻度の低いデータを安い媒体に移す」という発想は馴染みがあるはずです。S3のライフサイクルルールは、まさにその自動化をクラウド上で実現する仕組みです。

S3のストレージクラスはアクセス頻度と料金のトレードオフで設計されています。よくアクセスされるデータには高性能・高コストの「S3 Standard」を使い、数か月後にほとんど参照されなくなるデータは「S3 Standard-IA（低頻度アクセス）」や「S3 Glacier」などの安価なクラスに移すことでコストを大幅に下げられます。

問題は「手動でやり続けるのは現実的ではない」という点です。大量のオブジェクトが毎日生成されるシステムでは、人手による管理は不可能です。ライフサイクルルールを設定すれば、ルールに合致したオブジェクトを自動で移行・削除できます。

オンプレとの最大の違いは、クラウドのストレージは「使った分だけ課金される」ということです。オンプレのNASやテープなら、容量が余っていても固定費しかかかりません。しかしS3は保存しているGBの量に比例して毎月課金されるため、「使っていないけど放置しているデータ」がそのままコストになります。ライフサイクルルールはこの問題を解決する最も確実な手段です。

S3ライフサイクルルールの基本的な仕組み

ライフサイクルルールは、S3バケット単位またはプレフィックス（フォルダパス）・タグ単位で設定します。ルールには2種類のアクションがあります。

1. ストレージクラス移行（Transition）

オブジェクトの作成日から指定した日数が経過したら、自動的に別のストレージクラスへ移行します。移行できるのは「より低コストのクラスへの一方向」のみで、逆方向（GlacierからStandardへ）の自動移行はできません。

主な移行先の選択肢は以下のとおりです。

・S3 Standard-IA: 低頻度アクセス向け。Standard比で保管料金は約55%安くなりますが、取り出しごとに料金が発生します。
・S3 One Zone-IA: 1つのAZのみに保存。Standard-IAよりさらに約20%安いですが、AZ障害時にデータ損失のリスクがあります。再現可能なデータ（サムネイル等）向け。
・S3 Glacier Instant Retrieval: アーカイブデータの中では取り出しが最速（ミリ秒）。保管料金はStandardの約68%安。
・S3 Glacier Flexible Retrieval: 取り出しに数分～数時間かかります。保管料金はStandardの約83%安。旧称「S3 Glacier」。
・S3 Glacier Deep Archive: 最安クラス。Standardの約95%安ですが、取り出しに12時間以上かかります。長期保管の法的要件対応などに最適です。

2. オブジェクト削除（Expiration）

作成日から指定した日数が経過したら、オブジェクトを自動削除します。ログファイルやバックアップファイルなど、一定期間後に不要になるデータの管理に使います。

バージョニングを有効にしたバケットでは「現行バージョン」と「非現行バージョン（古いバージョン）」を別々に管理できます。通常の削除では削除マーカーが付くだけでデータは残りますが、ライフサイクルルールで非現行バージョンの保存日数を指定すれば、古いバージョンを自動で完全削除できます。

ストレージクラス別の料金と移行タイミングの目安（2026年時点）

東京リージョン（ap-northeast-1）における保管料金の比較です（2026年6月時点の参考値、USD）。

移行タイミングの目安として現場でよく使われる設計は以下のとおりです。

・30日移行: アクセスログ・システムログなどの直近1か月は参照頻度が高く、それ以降はほぼ参照しないデータに適用。Standardから30日後にStandard-IAへ。
・90日移行: バックアップデータや月次レポートなど、四半期程度は時々参照する可能性があるデータ。90日後にGlacier Instantへ。
・365日移行: 法定保存義務がある書類や監査ログなど、年に1度も参照しないが保存必須のデータ。1年後にGlacier Deep Archiveへ移行し、7年後に削除。

【重要】最小保存期間の落とし穴: Standard-IAには「30日の最小保存期間」があります。オブジェクトを移行後30日未満で削除すると、30日分の料金が発生します。作成から数日で削除されることが多いオブジェクト（小さなキャッシュファイル等）をStandard-IAに移行すると、却ってコストが上がることがあります。

ライフサイクルルールの設定手順

1. AWSマネジメントコンソールで設定する

コンソール操作でライフサイクルルールを設定する手順です。スクリーンショットなしでも再現できるよう、クリック先を明記します。

まず、S3バケットを開き「管理」タブを選択します。「ライフサイクルルール」セクションで「ライフサイクルルールを作成」をクリックします。

設定項目の流れは以下のとおりです。

・ルール名: わかりやすい名前をつけます（例: logs-to-glacier-180days）
・ルールスコープ: バケット全体に適用するか、特定プレフィックス（logs/ など）やタグでフィルタするかを選択
・ライフサイクルルールのアクション: 「ストレージクラスを移行」または「期限切れオブジェクトを削除」にチェックを入れる
・移行先とタイミング: 移行先クラスと「作成から〇日後」を指定

設定を保存すると、翌日以降の夜間バッチで条件を満たしたオブジェクトが移行されます。移行は即時ではなく、処理が実行されるまで最大で24時間程度かかります。

2. AWS CLIで設定する

CLI（コマンドラインインターフェース）での設定は、IaCによる管理やスクリプト自動化に向いています。まずルールをJSON形式のファイルに記述し、それをバケットに適用します。

lifecycle-policy.json の記述例（logs/ プレフィックスに適用し、30日後にStandard-IA移行、90日後にGlacier移行、365日後に削除）:

{
  "Rules": [
    {
      "ID": "logs-archive-and-delete",
      "Status": "Enabled",
      "Filter": {
        "Prefix": "logs/"
      },
      "Transitions": [
        {
          "Days": 30,
          "StorageClass": "STANDARD_IA"
        },
        {
          "Days": 90,
          "StorageClass": "GLACIER_IR"
        }
      ],
      "Expiration": {
        "Days": 365
      }
    }
  ]
}

# AWS CLI でバケットにルールを適用する
aws s3api put-bucket-lifecycle-configuration \
  --bucket your-bucket-name \
  --lifecycle-configuration file://lifecycle-policy.json

# 設定確認
aws s3api get-bucket-lifecycle-configuration \
  --bucket your-bucket-name

バージョニング有効バケットで非現行バージョンも管理する場合:

バージョニングを有効にしたバケットでは、NoncurrentVersionTransitions と NoncurrentVersionExpiration を追加します。また AbortIncompleteMultipartUpload も同時に設定しておくと、途中で失敗したアップロードの残骸が溜まるのを防げます。

{
  "Rules": [
    {
      "ID": "noncurrent-version-management",
      "Status": "Enabled",
      "Filter": {},
      "NoncurrentVersionTransitions": [
        {
          "NoncurrentDays": 90,
          "StorageClass": "GLACIER_IR"
        }
      ],
      "NoncurrentVersionExpiration": {
        "NoncurrentDays": 365
      },
      "AbortIncompleteMultipartUpload": {
        "DaysAfterInitiation": 7
      }
    }
  ]
}

aws s3api put-bucket-lifecycle-configuration \
  --bucket your-versioned-bucket \
  --lifecycle-configuration file://lifecycle-versioned.json

AbortIncompleteMultipartUpload は、途中で失敗したマルチパートアップロードの不完全な部分を自動削除する設定です。これを設定しておかないと、大量の中途半端なデータが残り、気づかぬうちにストレージ料金が発生します。

料金シミュレーション：ライフサイクルルールあり vs なし

具体的にどのくらいコストが変わるか、試算してみます。

シナリオ: アプリケーションログを毎月100GB生成する環境。保存期間の要件は2年（730日）。

ライフサイクルルールなし（全期間Standard）の場合、2年累計の平均保存量は約1,200GBになります。

適切なライフサイクルルールを設定することで、保管コストを大きく削減できるケースも少なくありません。実際の数値はオブジェクトサイズや取り出し頻度によって変わるため、AWS料金計算ツール（AWS Pricing Calculator）で自社の条件を入れて試算することを推奨します。

実務でよく使うライフサイクルルールのパターン

現場で繰り返し使われる定番パターンを紹介します。

パターン1：アプリケーションログの階層管理

ログは作成直後の1か月は障害調査でよく参照しますが、それ以降は急速にアクセス頻度が下がります。

・0日～30日: S3 Standard（デフォルト）
・30日～90日: S3 Standard-IA
・90日～365日: S3 Glacier Instant Retrieval
・365日以降: 削除（法定保存義務がなければ）

パターン2：データベースバックアップの長期保管

バックアップは直近1週間だけ即時復旧が必要で、それ以降は数時間かけて復旧できれば十分なケースが多いです。

・0日～7日: S3 Standard（直近バックアップは高速アクセス）
・7日～90日: S3 Standard-IA（週次バックアップの保持）
・90日以降: S3 Glacier Flexible Retrieval（取り出し最大12時間で許容）
・2,555日（7年）以降: 削除（会計帳票の7年保存要件を満たした後）

パターン3：画像・動画のサムネイル管理

ユーザーが投稿した画像のサムネイルは、投稿直後は頻繁に参照されますが、古い投稿のサムネイルはほぼ参照されません。また再生成可能なデータなので、冗長性の低いOne Zone-IAが適しています。

・0日～60日: S3 Standard
・60日以降: S3 One Zone-IA（再生成可能なため単一AZで十分）

パターン4：不完全マルチパートアップロードの自動クリア

大容量ファイルのアップロード失敗が多い環境では、不完全なパーツが蓄積します。これは独立したルールとして設定しておくことを推奨します。

・AbortIncompleteMultipartUpload: アップロード開始から7日後に中断・削除

よくあるトラブルと対処法

トラブル1：ルールを設定したのにオブジェクトが移行されない

ライフサイクルルールの処理は夜間バッチで実行されます。設定直後にオブジェクトが移行されないのは正常です。条件を満たしたオブジェクトが処理されるまで、最大24時間待ちましょう。

また「ルールのスコープ」が意図通りか確認してください。プレフィックスが logs/ のつもりで logs（末尾スラッシュなし）と設定すると、logs-archive/ や logs_backup/ も対象に含まれます。

トラブル2：移行後にコストが増えた

Standard-IAやGlacierクラスには最小保存期間（Standard-IAは30日、Glacierは90日）があります。移行先のクラスでの保存日数が最小期間に満たない状態でオブジェクトが削除された場合、残り日数分の料金が請求されます。頻繁に作成・削除されるオブジェクトへの移行ルール適用には注意が必要です。

また、Standard-IAへの移行には「GB単位の移行リクエスト料金」も発生します。小さなファイル（数KB程度）が大量にある場合、リクエスト料金が保管料金の削減分を上回ることがあります。最小オブジェクトサイズを考慮した設計が重要です。

トラブル3：バージョニング有効バケットで削除マーカーが大量に残る

バージョニング有効バケットでは、通常の削除操作でオブジェクトは「削除マーカー」が付いた状態で保持されます。ライフサイクルルールで Expiration を設定しても、バージョニング有効バケットでは削除マーカーが残ることがあります。

削除マーカーを自動クリアするには、ライフサイクルルールに ExpiredObjectDeleteMarker: true を追加するか、CloudWatch Logsで削除マーカーの数をモニタリングし、適宜手動クリアするワークフローを組み込みましょう。

トラブル4：Glacier移行後に取り出しコストが想定外に高くなった

Glacier Flexible RetrievalとGlacier Deep Archiveは取り出しに時間とコストがかかります。特に大容量データをまとめて取り出すと料金が跳ね上がります。災害復旧テストやデータ移行作業の前に、必ずAWS料金計算ツールで取り出しコストを試算してください。

本記事のまとめ

S3ライフサイクルルールは、設定するだけでストレージコストを自動最適化できる強力な機能です。要点を整理します。

・2種類のアクション: ストレージクラス移行（Transition）とオブジェクト削除（Expiration）
・コスト削減効果: 適切な設計で保管コストを大きく削減できるケースも
・最小保存期間の罠: Standard-IA（30日）・Glacier（90日）の最小保存期間に注意
・CLI設定: JSON形式のポリシーファイルを aws s3api put-bucket-lifecycle-configuration で適用
・AbortIncompleteMultipartUpload: 忘れやすいが必ず設定すべき隠れコスト対策
・バージョニング有効バケット: 非現行バージョンと削除マーカーの管理もルールに含める

S3のコストが気になっているなら、まず既存バケットのAWS Cost Explorerでストレージクラス別のコストを確認し、どのバケット・プレフィックスにライフサイクルルールを適用すべきか優先順位をつけるところから始めましょう。Linuxサーバーの基礎については、姉妹サイトLinuxMaster.JPでも詳しく解説しています。