Amazon S3 バージョニングとライフサイクルルールの「削除」を正しく理解する

AWS 公式ドキュメントでは、S3 バージョニングについて以下のように説明されています。

「S3 バージョニングを使用すると、オブジェクトの複数のバージョンを 1 つのバケットに保持し、誤って削除または上書きされたオブジェクトを復元できます。」
https://docs.aws.amazon.com/ja_jp/AmazonS3/latest/userguide/versioning-workflows.html

つまり、S3バージョニングとはS3バケット内のオブジェクトに対して変更履歴を保持する機能です。
この機能により、オブジェクトを誤って削除したり上書きしてしまった場合でも、過去の状態に戻すことが可能になります。
ここでは、バージョニングの有無によって、オブジェクトを上書きした際にどのような違いがあるのかを見ていきます。

バージョニング無効時の挙動

バージョニングが「無効」の場合、オブジェクトを上書きすると、上書き前のデータは完全に削除されます。
そのため、元のオブジェクトを復元することはできません。

バージョニング有効時の挙動

一方、バージョニングが「有効」な場合は挙動が異なります。

• 上書き前の現行バージョンは削除されるのではなく、非現行バージョンとして保持される
• 上書き後のオブジェクトが新たな現行バージョンになる

このように、上書き操作を行っても過去のバージョンが保持されます。
上書き後のオブジェクトのIDを指定して削除することで(ID:102)、必要に応じて以前の状態に戻すことも可能です。

実際に、コンソールでは以下のように表示されます。

削除マーカーとは

AWS公式ドキュメントでは、削除マーカーについて以下のように説明されています。

「Amazon S3 の削除マーカーは、単純な DELETEリクエストで指定された、バージョニングされたオブジェクトのプレースホルダー (またはマーカー) です。」
削除マーカーの使用 – Amazon Simple Storage Service

ここでいう単純な DELETE リクエストとは、バージョン ID を指定しないリクエストです。
つまり、削除マーカーとは「オブジェクトが削除されたことを示すための、実体を持たないバージョン」という位置づけになります。

削除マーカーの特徴と注意点

削除マーカーには、以下のような特徴があります。

• フラグ用のオブジェクトであり、GETリクエストで取得しようとしても中身は返ってこない
• 実体データは持たないが、オブジェクト名分のメタデータ容量が発生するため、最小オブジェクトコスト分の料金がかかる（STANDARD の場合：USD 0.025$）
• 明示的な削除やライフサイクルルールを設定しない限り、自動では削除されない

そのため、削除マーカーに気づかないまま放置すると、少額ながら継続的にコストを支払い続けてしまう可能性があります。
さらに、削除マーカーに気づかず、非現行バージョンのオブジェクトが残っている場合、その分のストレージコストも引き続き発生します。
このような理由から、AWS公式では不要になった削除マーカーは自動で削除する運用が推奨されています。

実際の削除挙動について

それでは、バージョニングを有効化したオブジェクトを削除した場合の具体的な挙動についてコンソール上で確認しながら、説明します。

1. オブジェクトのバージョンを表示しない画面にする。

S3のライフサイクルルールでは、オブジェクトに対して大きく分けて2種類のアクションを定義できます。

• ストレージクラスの移行（Transition）
• 有効期限による削除（Expiration）

前者は、一定期間が経過したデータをStandard-IAやGlacierなどの安価なストレージクラスへ自動的に移行する設定です。
後者は、データを削除する設定になります。
本記事では主に削除に関するライフサイクルルールにフォーカスしますが、全体像を把握するため、代表的な設定を以下に整理します。

ライフサイクルルールの主な種類

移行ルールと削除ルールの位置づけ

上記のうち、最初の2つ（ストレージクラスへの移行）は主にコスト最適化を目的としたルールです。
AWS 認定試験でも頻出で、実際に設定したことがなくても知識として知っている方は多いのではないでしょうか。

一方で、

• 現行バージョンの有効期限切れ
• 非現行バージョンの削除
• 削除マーカーの削除

といった 削除関連のルールは、データの寿命管理やバージョニング有効時の削除運用に直結します。特に本記事のテーマである「バージョニングの削除」を正しく理解するためには、これらの削除ルールの挙動を押さえておくことが重要です。
次節では、これらのルールが削除マーカーや非現行バージョンに対してどのように作用するのかを、具体的な例を交えて詳しく解説していきます。

ここまで、バージョニングによる削除の仕組み（削除マーカー）と、ライフサイクルルールの種類について説明してきました。
ここからはいよいよ核心である、「バージョニング有効バケットの削除を、ライフサイクルルールでどう管理するか」
について解説します。
バージョニングが有効なバケットでは、前述のとおり、オブジェクトを削除してもデータ自体は残るため、
何も考えずに運用するとストレージが際限なく蓄積していきます。
一方で、古いバージョンを無計画に手動削除してしまうと、せっかくの 「誤削除から復元できる」というメリットを失ってしまいます。
そこで重要になるのが、ライフサイクルルールを使った計画的な削除運用です。

現行バージョンを有効期限切れにする

このルールを設定すると、対象オブジェクトは指定日数経過後に削除マーカーが自動で付与されます。
つまり、ユーザーが削除操作をしなくても、自動的に「削除された状態」になるという挙動です。
下図では、現行バージョンを有効切れにすることで、現行バージョンが非現行バージョンに移行しています。（下図 ①）
そして、削除マーカーが現行バージョンとして生成されます。（下図 ②）

非現行バージョンを完全に削除

こちらは、すでに履歴となった古いバージョンを物理削除するルールです。
この設定は バージョニング有効時のみ意味を持つ もので、

• 「非現行になってから 30 日後に削除」
• 「最新の 5 バージョンは残す」

といった指定が可能です。
ユーザーによる手動削除や、新しいバージョンのアップロードによって非現行化したファイルが、一定期間後に自動でクリーンアップされます。
下図では、非現行バージョンを完全に削除し、test.txtが物理削除されています。（下図 ③）

以下のライフサイクルルールを設定した場合の挙動を例に説明します。

• 現行バージョン：1 日後に有効期限切れ
• 非現行バージョン：1 日後に削除
• 期限切れ削除マーカー：有効

ライフサイクルルールの設定時の時系列

• 1 日目
  test.txt を作成（現行バージョン）
• 2 日目 
  現行バージョンが有効期限切れとなり、非現行バージョンに移行
  → 削除マーカーが現行バージョンとして作成される
• 3 日目 
  非現行バージョンが削除され、データ本体が消える
• 同日または次回実行時
  期限切れ削除マーカーが削除され、バケット内からオブジェクトが完全に消える

このように、設定してから完全削除までには数日かかる点が重要です。

ライフサイクルルールによる自動削除の検証

上記の設定で実際にコンソールで設定してデモを行ってみます。
今回の検証では、以下の2つの S3 バケットを用意しました。
基本的なライフサイクル設定は同一とし、「期限切れ削除マーカーの削除」設定だけを変えています。

検証前の想定

検証前は、以下のように予想していました。

• test-1-oy
  削除マーカー削除を有効にしているため、最終的にはオブジェクトが完全に削除される。
• test-2-oy
  削除マーカー削除を無効にしているため、削除マーカーだけはバケットに残り続ける。

この予想が正しいかどうかを、実際に確認していきます。

検証ログ

まず、両バケットに test.txt をアップロードしました。
この時点では、どちらのバケットにも現行バージョンのオブジェクトが1つ存在する状態です。

「現行バージョンの有効期限」を1日に設定していたため、そろそろ削除マーカーが付くはず、と思って確認しましたが、
特に変化はありませんでした。

ここで分かったのは、以下の点です。

ライフサイクルルールは、設定した日数どおりにきっちり動くわけではない

評価や実行は非同期で行われるため、多少のズレが発生するようです。

夜に確認したところ、ようやく変化がありました。

• test-2-oyバケットのみで 削除マーカーが生成（test-1-oyバケットは2/19 朝に削除マーカー生成を確認）
• 元の test.txt は 非現行バージョン へ移行

このタイミングで、現行バージョンの有効期限切れが実行されたと考えられます。
また、2つのバケットで削除マーカーが生成されるタイミングが異なるということは、
ライフサイクルルールが必ずしも設定日数きっちりに動作するわけではないことを裏付ける結果となっております。

次は「非現行バージョンを1日で削除」の設定です。
こちらもすぐに消えるかと思いきや、

• 2/20 夕方時点でも、非現行バージョンは残ったまま

という状態でした。
設定上は「1日」ですが、実際の削除までには2日以上かかることもあるようです。

夜になってようやく、非現行バージョンが削除され、バケット内には 削除マーカーのみ が残る状態になりました。

最終的な状態を確認したところ、結果は以下の通りでした。

• test-1-oy：オブジェクトなし（想定どおり）
• test-2-oy：オブジェクトなし（想定外）

削除マーカー削除を 無効 にしていた test-2-oy でも、削除マーカーが消えていました。

検証して分かったこと

ライフサイクルは「条件成立」と「実行」が別物

今回の検証を時系列で整理すると、以下のような流れで処理が進んだと考えられます。

• 現行バージョンの有効期限切れが実行される
• 非現行になってから一定時間経過と判定される
• 削除処理がキューに入り、後から実行される

つまり、設定した日数＋AWS 側の処理タイミングという考え方をしておかないと、「まだ消えないの？」と不安になりがちです。

削除マーカーはのみになると消えることがある

test-2-oy の結果から分かったのは、削除マーカーが

• 期限切れ
• かつ、バケット内で唯一のバージョン

という状態になると、個別に削除マーカー削除を有効にしていなくても、S3 側のクリーンアップ処理で削除される場合があるという点です。

本記事では、S3 バージョニング有効時におけるオブジェクト削除の挙動と、ライフサイクルルールによる削除管理について整理しました。