S3 バケット内のオブジェクトをライフサイクルで削除する方法

2026.05.01
 困っていた内容ライフサイクルルールによる S3 バケットのオブジェクト削除の挙動を確認したい
私自身も、上記を理解するのに少し時間がかかりました。

そのため本記事では、S3 バケットのバージョニングとライフサイクルによるオブジェクト削除の流れをできるだけ分かりやすく書いていこうと思います。

長くなりますが、ぜひ最後までご覧いただけると幸いです。
 いきなりまとめライフサイクルルールによるオブジェクト削除を理解するためには以下を把握する必要があります。
S3 バケットのバージョニング
削除マーカーの仕様
ライフサイクルルール適用タイミングは毎日 9:00 (UTC+9)
ライフサイクルアクションは遅延することがある
検証をしてみましたので、1つずつ見ていきましょう。
 バージョニングと削除マーカーライフサイクルでのオブジェクト削除を理解するためには、まず S3 バケットのバージョニングと削除マーカーの仕様の理解が不可欠です。
 バージョニングS3 バケットのバージョニングを有効化することで、同名のファイルをアップロードし上書きしてしまっても以前のバージョンを復元させることができます。
有効化手順は簡単です。

設定する S3 バケットの「プロパティ」からバケットのバージョニングを有効にして保存します。

では、実際に挙動を確認してみましょう。
まずはテスト用のファイルを用意します。今回は test1 という内容の test.txt　を用意し、S3 バケットにアップロードします。



続いて、test.txt の中身を以下のように書き換え、再度アップロードします。

検索バーの右にある「バージョンの表示」をオンにすると、同名ファイルの 2 つのバージョンが確認できます。

古い方のバージョンを選択し、「ダウンロード」または「開く」で中身を確認します。

上書きされる前の内容であることが確認できました。

 削除マーカーでは続いて、アップロードした test.txt を削除してみます。

※「バージョンの表示」はあえてオフしています。

一見、削除されたように見えます。

しかし、「バージョンの表示」をオンにしてみると、アップロードした test.txt の 2 つのバージョンは残っており、現行バージョンとして削除マーカーが追加されています。

続いて、削除マーカーを選択し削除してみます。



削除マーカーを削除した状態で「バージョンの表示」をオフにすると、削除したように見えたオブジェクトが表示されました。

では、次は削除マーカーが付いている状態で 2 つのバージョンを削除し、最後に削除マーカーを削除します。

「バージョンの表示」をオンにしてもオフにしても、オブジェクトが綺麗に削除されました。



つまり、削除マーカーのみ残っている状態で削除マーカーを削除することでオブジェクトが綺麗に削除されます。

言い換えれば、オブジェクトのバージョンも削除マーカーも、このように削除しない限りバケットに残り続けるというわけです。
ちなみに削除マーカーも料金が発生します。

削除マーカーの使用 - Amazon Simple Storage Service
削除マーカーにより、Amazon S3 内のストレージに対して最低料金が発生します。
とはいえ、毎回手作業で削除するのは大変です。そこで使用するのがライフサイクルです。

この削除の工程を踏まえ、次は実際にライフサイクルを使用してオブジェクトを削除してみましょう。
 ライフサイクルによるオブジェクト削除 ライフサイクルルール適用とライフサイクルアクションのタイミングライフサイクルの理解を進めるために、ライフサイクルが動くタイミングに注意する必要があります。
Amazon S3 ライフサイクル問題のトラブルシューティング - Amazon Simple Storage Service
Amazon S3 は、オブジェクトの移行日または有効期限を翌日の午前 0 時 (UTC) に丸めます。
バケットに S3 ライフサイクル設定を設定する - Amazon Simple Storage Service
移行または有効期限の遅延

ライフサイクルルールが満たされてから、ルールのアクションが完了するまでに遅延が生じる場合があります。例えば、ライフサイクルルールによって一連のオブジェクトの有効期限が 1 月 1 日に切れるとします。有効期限ルールは 1 月 1 日に満たされますが、Amazon S3 は数日後または数週間後までこれらのオブジェクトを実際に削除しない場合があります。この遅延は、S3 ライフサイクルがオブジェクトを移行または有効期限のためのキューに非同期的に入れるために発生します。請求の変更は、通常、アクションが完了していなくても、ライフサイクルルールが満たされた際に適用されます。
簡潔に言えば、

「ライフサイクルルールの適用は毎日 9:00 (UTC+9)に実行されるが、実際のアクションには多少の遅延が生じる場合があり、遅延した分の料金はかからない」ということです。
 ライフサイクルルールの設定今回設定するルールは以下のとおりです。
オブジェクトの現行バージョンを有効期限切れにする（1 日後）
オブジェクトの非現行バージョンを完全に削除（1 日後）
有効期限切れのオブジェクト削除マーカーを削除
1 と 3 は 同じルールの中で同時に選択できないため、ルールを 2 つに分けて設定します。

ルール 1



ルール 2

テスト用のファイルをアップロードして準備は完了です。今回は test-lifecycle.txt を 3 バージョン作成しました。

ライフサイクルルールとアクションのタイミングを踏まえると、想定される動作は以下のとおりです。
4/20 8:20 頃 オブジェクトをアップロード。
4/20 9:00 ライフサイクルルールのカウント開始。画面上では 1. と同じ。
4/21 9:00 非現行バージョン（古いバージョン 2 つ）が削除される。 また、現行バージョンが有効期限切れになり、削除マーカーが付与される。
4/22 9:00 有効期限切れとなった 3 つ目のバージョンも削除され、削除マーカーのみ残る。
4/23 9:00 削除マーカーが削除され、クリーンアップ。
 動作確認実際の動作は次のとおりです。
4/20 9:00 ライフサイクルのカウント開始。

→ 確認した日時：4/20 10:13

→ ライフサイクルのカウントが開始されただけなので、アップロード時と特に変化はありません。（想定通り）

4/21 9:00 非現行バージョン（古いバージョン 2 つ）が削除される。 また、現行バージョンが有効期限切れになり、削除マーカーが付与される。

→ 確認した日時：4/22 8:19

→ 非現行バージョン 2　つが削除されています。また、現行バージョンだったものが非現行バージョン（有効期限切れ）になり、現行バージョンとして削除マーカーが付与されました。（想定通り）

4/22 9:00 有効期限切れとなった 3 つ目のバージョンも削除され、削除マーカーのみ残る。

→ 確認した日時：4/24 8:23

→ 動作自体は想定通りで削除マーカーのみ残りました。そのため、ライフサイクルの適用は正常に実施されています。しかし、処理の遅延が発生しました。（具体的にいつ消えたかは確認できません）

4/23 9:00 削除マーカーが削除され、クリーンアップ。

→ 確認した日時：4/27 8:07

→ 週明けの確認でしたが、オブジェクトは何も残っておらずクリーンアップされていることが確認できました。

ライフサイクルアクションの遅延はありましたが、最終的には設定したライフサイクルルール通りにオブジェクトが削除されました。
 まとめS3 バケットのバージョニングと削除マーカーの仕様、そしてライフサイクルによるオブジェクトの削除を確認しました。

はじめは、ライフサイクルルール適用やライフサイクルアクションのタイミングが少し複雑に感じると思います。

しかし、ルール適用のタイミング、アクションの遅延があること等の注意点を考慮して一度検証してみると、かなり理解が進む機能だとも思います。

今回はオブジェクトの削除に焦点を当てましたが、ライフサイクルではストレージクラスの移行や長期的な日数の設定もできます。その際も今回確認した注意点は共通しているため、この記事が皆さんのご理解の助けになれば幸いです。