概要
S3バケットにアプリケーションログやアクセスログを格納する運用は広く行われていますが、ログが蓄積し続けるとストレージコストが増加します。「一定期間保持した後に自動的に削除したい」という要件は非常に一般的であり、S3にはこの要件を実現するためのライフサイクル設定機能が用意されています。
本記事では、S3のライフサイクル設定ルールを使って、30日経過したオブジェクトを自動削除する方法を解説します。バケットポリシーやIAMポリシーといったアクセス制御機能との違いも整理し、適切な機能の選択ができるようにします。

この記事のメリット
- S3ライフサイクル設定の仕組みと用途を理解できる
- 有効期限アクションと移行アクションの違いを把握できる
- バケットポリシー・IAMポリシー・バージョニングとの違いを明確に区別できる
- コンソールを使ったライフサイクルルールの設定手順を習得できる
- SCS試験で「S3オブジェクトの自動削除」に関する問いに正確に答えられるようになる
技術解説
S3ライフサイクル設定とは
S3ライフサイクル設定は、バケット内のオブジェクトに対して、時間の経過に応じた自動処理を定義する機能です。オブジェクトの作成日を基準に、指定した日数が経過したら自動的に削除したり、より低コストなストレージクラスに移行したりできます。
ライフサイクル設定はバケット単位で構成し、1つのバケットに複数のルールを定義できます。各ルールにはフィルター(対象オブジェクトの絞り込み条件)とアクション(実行する処理)を指定します。
ライフサイクル設定をバケットに追加すると、既存のオブジェクトと今後追加されるオブジェクトの両方にルールが適用されます。例えば、30日後の有効期限ルールを追加した場合、すでに30日以上前に作成されたオブジェクトも削除対象のキューに追加されます。
ライフサイクルルールのアクション
ライフサイクルルールで設定できるアクションは、大きく2種類に分かれます。
| アクション種別 | 説明 | ユースケース |
|---|---|---|
| 有効期限アクション(Expiration) | 指定した日数が経過したオブジェクトを自動削除する | ログの自動削除、一時ファイルのクリーンアップ |
| 移行アクション(Transition) | 指定した日数が経過したオブジェクトを別のストレージクラスに移行する | アクセス頻度の低下に応じたコスト最適化 |
有効期限アクション
オブジェクトの作成日から指定した日数が経過すると、S3が自動的にオブジェクトを削除します。本記事のテーマである「30日後にログを自動削除する」要件には、このアクションを使用します。
有効期限を迎えたオブジェクトに対するストレージ料金は発生しません。ただし、有効期限日と実際の削除日の間には遅延が発生する場合があります。また、S3 Standard-IA(30日)、S3 Glacier Flexible Retrieval(90日)、S3 Glacier Deep Archive(180日)など最低保存期間が設定されているストレージクラスでは、最低保存期間より前にオブジェクトが有効期限切れになった場合でも、最低保存期間分のストレージ料金が発生します。
バージョニングの状態によって有効期限アクションの挙動が異なります。
| バケットの状態 | 有効期限アクションの挙動 |
|---|---|
| バージョニング無効 | オブジェクトが永続的に削除される |
| バージョニング有効 | 削除マーカーが追加され、現行バージョンが非現行バージョンになる(オブジェクト自体は削除されない) |
| バージョニング一時停止 | バージョンID=nullの削除マーカーが作成される |
バージョニングが有効なバケットで非現行バージョンを完全に削除するには、NoncurrentVersionExpirationアクションを別途構成する必要があります。
移行アクション
オブジェクトの作成日から指定した日数が経過すると、S3がオブジェクトを指定したストレージクラスに自動移行します。例えば、作成から90日後にS3 Standard-IAへ、180日後にS3 Glacierへ移行するといった段階的なコスト最適化が可能です。
フィルタリング
ライフサイクルルールは、バケット内のすべてのオブジェクトに適用することも、特定のオブジェクトに絞り込むこともできます。フィルタリングには以下の方法があります。
| フィルター | 説明 | 例 |
|---|---|---|
| プレフィックス | オブジェクトキーの先頭文字列で絞り込む | logs/ で始まるオブジェクトのみ対象 |
| タグ | オブジェクトに付与されたタグで絞り込む | environment: dev タグが付いたオブジェクトのみ対象 |
| オブジェクトサイズ | オブジェクトのサイズで絞り込む | 指定サイズ以上または以下のオブジェクトのみ対象 |
フィルターは組み合わせて使用することもできます。例えば、「logs/ プレフィックスかつ temporary: true タグが付いたオブジェクト」のように条件を組み合わせて対象を絞り込めます。
各選択肢の比較
S3オブジェクトの自動削除を実現する方法として、以下の機能が選択肢として挙がることがあります。それぞれの特徴と自動削除への適性を整理します。
| 機能 | 主な用途 | 自動削除に使えるか | 理由 |
|---|---|---|---|
| ライフサイクル設定 | オブジェクトの自動削除・ストレージクラス移行 | はい | 有効期限アクションで日数指定の自動削除が可能 |
| バケットポリシー | バケットおよびオブジェクトへのアクセス制御 | いいえ | アクセスの許可・拒否を定義するもので、時間経過による自動処理の機能はない |
| IAMポリシー | IAMプリンシパルの権限管理 | いいえ | ユーザーやロールの操作権限を定義するもので、自動処理の機能はない |
| バージョニング | オブジェクトの複数バージョン保持 | いいえ | 上書き・削除時に以前のバージョンを保持する機能であり、自動削除とは無関係 |
バケットポリシーとIAMポリシーはどちらもアクセス制御の仕組みであり、「誰が・どのリソースに・何の操作を行えるか」を定義するものです。時間の経過に基づいてオブジェクトを自動的に処理する機能は備えていません。
なお、バケットポリシーですべてのアクションを拒否するように設定していても、ライフサイクル設定による削除や移行は通常通り実行されます。AWS公式ドキュメントでも「バケットポリシーを使用してS3ライフサイクルルールによる削除や移行を防止することはできない」と明記されています。
バージョニングは、オブジェクトの上書きや削除が行われた際に以前のバージョンを保持する機能です。データの保護には有用ですが、オブジェクトの自動削除を実現する機能ではありません。
実践
ここでは、S3バケットを作成し、30日経過したオブジェクトを自動削除するライフサイクルルールを設定します。
前提条件
- リージョン:
ap-northeast-1(東京) - S3バケットの作成権限を持つIAMユーザーでログインしていること
| リソース種別 | リソース名 | 用途 |
|---|---|---|
| S3バケット | cloud-shikaku-lab-<アカウントID> | ログ格納用バケット 作成できればなんでも大丈夫です |
| ライフサイクルルール | auto-delete-after-30-days | 30日経過したオブジェクトの自動削除 |
S3バケット名はグローバルで一意である必要があります。
<アカウントID>の部分をご自身のAWSアカウントIDに置き換えてください。
手順1: S3バケットの作成
- AWSマネジメントコンソールにログインし、右上のリージョンが「アジアパシフィック(東京) ap-northeast-1」であることを確認します。
- 上部の検索バーに
S3と入力し、表示された「S3」を選択します。 - 「バケットを作成」をクリックします。
- 「一般的な設定」セクションに以下を入力します。
- バケット名:
cloud-shikaku-lab-<アカウントID> - AWSリージョン:
アジアパシフィック(東京)ap-northeast-1が選択されていることを確認します - その他の項目はデフォルトのままにします。
- ページ下部の「バケットを作成」をクリックします。
- バケット一覧画面に戻り、作成したバケットが表示されていることを確認します。

手順2: ライフサイクルルールの設定
- バケット一覧から作成したバケット名(
cloud-shikaku-lab-<アカウントID>)をクリックして、バケットの詳細画面を開きます。 - 「管理」タブを選択します。
- 「ライフサイクルルール」セクションの「ライフサイクルルールを作成する」をクリックします。
- 「ライフサイクルルールの設定」画面で以下を入力します。
- ライフサイクルルール名:
auto-delete-after-30-days - 「ルールスコープを選択」セクションで「バケット内のすべてのオブジェクトに適用」を選択します。
- 確認のチェックボックス「現在のルールがバケット内のすべてのオブジェクトに適用されることを了承します。」にチェックを入れます。
- 「ライフサイクルルールのアクション」セクションで「オブジェクトの現行バージョンを有効期限切れにする」にチェックを入れます。
- 「オブジェクト作成後の日数」に
30と入力します。

- その他の項目はデフォルトのままにします。
- ページ下部の「ルールの作成」をクリックします。
手順3: ライフサイクルルールの確認
設定したライフサイクルルールが正しく作成されたことを確認します。
- バケットの詳細画面で「管理」タブを選択します。
- 「ライフサイクルルール」セクションに
auto-delete-after-30-daysルールが表示されていることを確認します。 - ルール名をクリックして詳細を開き、以下の内容が正しく設定されていることを確認します。
- ステータス: 「有効」
- ルールスコープ: 「バケット内のすべてのオブジェクトに適用」
- ライフサイクルルールのアクション: 「オブジェクトの現行バージョンを有効期限切れにする」(オブジェクト作成後の日数: 30)

ライフサイクルルールは設定後すぐにオブジェクトが削除されるわけではありません。有効期限日と実際の削除日の間には遅延が発生する場合があります。ただし、有効期限を迎えたオブジェクトに対するストレージ料金は発生しません。
まとめ
S3バケットに格納されたログを一定期間後に自動削除するには、ライフサイクル設定ルールの有効期限アクションを使用します。
| 要件 | 適切な機能 |
|---|---|
| 一定日数後にオブジェクトを自動削除したい | ライフサイクル設定(有効期限アクション) |
| 一定日数後に低コストなストレージクラスに移行したい | ライフサイクル設定(移行アクション) |
| 特定のユーザーやロールのアクセスを制御したい | バケットポリシー / IAMポリシー |
| オブジェクトの上書き・削除時に以前のバージョンを保持したい | バージョニング |
バケットポリシーやIAMポリシーはアクセス制御の機能であり、時間経過に基づくオブジェクトの自動処理には使えません。バージョニングはデータ保護のための機能であり、自動削除の仕組みとは異なります。
ライフサイクルルールではフィルター(プレフィックス、タグ、オブジェクトサイズ)を使って対象オブジェクトを絞り込むことも可能です。例えば、logs/ プレフィックスのオブジェクトのみを30日後に削除し、それ以外のオブジェクトは保持するといった運用にも対応できます。
SCS試験では、「S3オブジェクトを一定期間後に自動削除する方法」として、ライフサイクル設定とアクセス制御機能(バケットポリシー・IAMポリシー)を混同させる選択肢が出題されることがあります。各機能の役割を正確に理解しておくことが重要です。
