この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。
コンバンハ、千葉（幸）です。
2021年11月に、Amazon S3 ライフサイクルアクションに新たなオプションが追加されました。バージョニングが有効な S3 バケットにおいて「以前（非現行）のバージョン」のバージョン数を指定できるようになったというものです。
このアップデートを見たときにわたしは、「例えば 3 世代を指定すれば、バージョン数が 4 を超えたときに古いものから削除（あるいは移行）してくれる」という挙動を想像しました。もしかしたら同じような想像をした方がいるかも知れません。
上の表現は、間違いとまではいかないまでも誤解を招きやすい状態です。
実際に試してみて挙動が理解できましたので、記しておきます。
まとめ
- S3 ライフサイクルによるバージョン数の保持は「経過日数」との組み合わせが必須
- 最小の経過日数は以下の通り
- 移行の場合：0 日（ストレージクラスによっては 30 日）
- 削除の場合：1 日
- 移行アクションと組み合わせる場合、その日数より大きい必要がある
- 最小の経過日数は以下の通り
- バージョン数の保持は「世代数を超えたものにアクションを行う」というよりは「指定した世代数だけ日数経過後のアクションの対象外とする」
- 指定できるバージョン数は最大で 100
Amazon S3 ライフサイクルについておさらい
簡単に Amazon S3 ライフサイクルについておさらいをしておきましょう。
詳細は以下のエントリに記載していますので、あわせてご参照ください。
バージョニング
まず、S3 バケットにはバージョニングという考え方があります。バージョニングが有効なバケットのオブジェクトに以下のいずれかが行われると、「以前（非現行）のバージョン」が生成されます。
- 同一名称でのオブジェクトの Put
- 現行のバージョンのオブジェクトの削除
上記の画像の一番左、hoge.jpgを例にとれば「以前のバージョン」が2世代ある状態です。さらに同じ名称でオブジェクトが Put されれば世代数（バージョン数）は増えていきます。「削除マーカー」以外のバージョンは、「以前のバージョン」であってもストレージクラスに応じた保管料金がかかりますので注意してください。
ライフサイクルアクション
S3 ライフサイクルを使用することで、「以前のバージョン」のオブジェクトに以下のいずれかのアクションを実行できます。
- 削除（失効）
- ストレージクラスの移行
ライフサイクルアクションはライフサイクルールによって行われます。ライフサイクルルールでは経過日数の指定が必要です。指定した日数が経過することでアクションの対象となります。
従来は経過日数のみが指定可能でしたが、（「以前のバージョン」を対象にするアクションにおいては）バージョン数も指定できるようになりました。
ライフサイクルアクションの実行のタイミング
指定した日数が経過したタイミングで即時にライフサイクルアクションが実行されるわけではありません。
「日数が経過した翌日の午前 0:00」が実行タイミングです。ここでの午前 0:00 とは UTC での時間を表しますので、日本時間では 9:00 に読み替えが必要です。
さらに、新規ルールの伝播遅延、削除処理の非同期処理による遅延など、実行が遅延する場合もあります。詳細は以下を参照してください。
やってみた
おさらいが終わったところで実際に試してみます。
ライフサイクルルールの設定
今回は以下のようなルールを設定しました。
非現行（以前）のバージョンになってから 1 日が経過したら（次の 0:00(UTC)に）削除する、ただし非現行のバージョンのうち最新の 3 世代はその対象外とする、という設定です。
上記のルールを編集画面で見ると以下になります。
「オブジェクトが現行バージョンでなくなってからの日数」は指定が必須で、最小でも 1 にする必要があります。保持するバージョン数は最大 100 であることも示されています。
上記のルールはバケット全体をスコープとして設定しています。
オブジェクトのバージョニング
同一の名称のオブジェクトを繰り返しアップロードし、バージョニングを行います。
S3 コンソールでは「バージョンの表示」のトグルをオンにすることで各バージョンが確認できます。
一番上に表示されているのが現行バージョンで、それにぶら下がる形で表示されているのが非現行バージョンです。
上に行くほど新しいバージョンであることを表します。今回は最古のバージョンを除きほぼ同じタイミングで Put したため、指定した日数が経過するのもほぼ同じタイミングです。
ライフサイクルルールの実行後
上記の状態から十分な時間を置いたのちに確認すると、非現行のバージョンが 3 世代を残して削除されたことが確認できました。
残っている 3 世代も指定した日数は経過していますが、ライフサイクルルールによる削除アクションの対象外になっている状態です。
おかわりでバージョンを増やす
挙動のイメージはつきましたが、せっかくなので追加でバージョンを増やしてみます。
今回は追加で 2 世代増やしました。
非現行のバージョンの世代数が 5 世代になったので、次の実行タイミングで古い方から 2 世代削除されることを期待します。
ライフサイクルルールの実行後（おかわり）
次のライフサイクルのタイミングで想定通り 3 世代保持されて削除が行われていました。
ちなみに
本エントリの本筋である「バージョン数の保持」とは外れますが、ライフサイクルルールの組み合わせによっては最小日数に注意が必要です。
「ストレージクラス間で移動」と「完全に削除」の両方を使用する場合、後者の方が数字が大きい必要があります。
↑マネジメントコンソール上でその旨メッセージが表示されますし、そのまま保存しようとするエラーになります。
また、「ストレージクラス間で移行」で選択するストレージクラスによっては最小の日数が 30 日となる場合もあります。
↑この時は「完全に削除」で指定する日数は 31 日より大きい必要があります。
ライフサイクルルールを設定する際はこういった考慮事項を押さえておきましょう。
終わりに
Amazon S3 ライフサイクルのバージョン数の保持の挙動を確認してみました。
冒頭で述べた「例えば 3 世代を指定すれば、バージョン数が 4 を超えたときに古いものから削除（あるいは移行）してくれる」という表現の微妙さが理解いただけたでしょうか。
経過日数の指定が必須であること、ライフサイクルアクションの実行が特定のタイミングであることも重要な観点なので、それを読み取れない上記の表現は言葉足らず感があります。
本エントリを通じて正しい仕様の理解につながっていれば幸いです。よいバージョニングライフをお過ごしください。
以上、 チバユキ (@batchicchi) がお送りしました。
1
