Amazon S3のバージョニングとライフサイクルルールについて

はじめに

本稿では、Amazon S3（以下S3）のバージョニングとライフサイクルルールについて、

• それぞれどんな機能なのか
• 使ってみるとどのような挙動になるのか

をコンソールを使って実際に見ていく記事になります

ただし、この記事ではコンソールもしくはAWS CLIでの具体的な設定方法は記載しません
あくまで、この設定をしたらこうなる、という挙動を示した記事、ということをご了承ください

目次

1. S3のバージョニングとは何か
2. ライフサイクルルールとは何か
3. バージョニングとライフサイクルルールを組み合わせる
4. 注意点
5. まとめ

1.S3のバージョニングとは何か

それでは早速、S3のバージョニングとは何か、という部分から見ていきます

AWSの公式ドキュメントでは以下のように説明されています

S3 バージョニングを使用すると、オブジェクトの複数のバージョンを 1 つのバケットに保持し、誤って削除または上書きされたオブジェクトを復元できます。
S3 バージョニングの仕組み

イメージとしては本の改訂管理が分かりやすいです
例えば「AWSの全て」という本があった時、この本の改訂版が出版されたとしましょう
バージョニングを設定する、ということは、古い版も改訂版もどちらも本棚に置いておく、ということです
こうすれば、仮に改訂版に間違いがあったり無くしてしまった場合、古い版を参照することができます
しかし、バージョニングが無効な場合は改訂版だけ残して古い版は捨ててしまうため、もし上記のような出来事があれば古い版を古本屋で探してこなければいけません
これがバージョニングの利点です

なお、バージョニングはバケットに対して設定します
バケット内のオブジェクトに個別に設定することはできないことには注意しましょう

1-1.バージョニングを設定した時の挙動

公式ドキュメントでも述べられている通り、バージョニングは主に

• オブジェクトを削除した場合
• オブジェクトを上書きした場合

に有効です

今回は、バージョニングを設定したバケット内のオブジェクトを削除したときにどのような挙動になるか見てみましょう
オブジェクトを削除した場合、S3はそのオブジェクトの「削除マーカー」を作成し、これが最新のオブジェクトバージョンになります
改訂管理で言えば、「この本は捨てました！」と張り紙をしている状態です（本そのものは無くなっていないことに注目してください）

ここでは、バージョニングを設定したバケット内の、”namagaki.jpg”を削除してみました

1-1-1.削除前の確認

バージョンは「現行バージョン」となっています

1-1-2.削除後の様子

「バージョンの表示」ボタンをオンにすると、タイプが「削除マーカー」になった”namagaki.jpg”と元の”namagaki.jpg”が表示されます

1-1-3.元のデータを復元してみる

一度削除した＝削除マーカーがついたデータを復元するには、削除マーカーを削除する必要があります
改訂管理で言えば、「捨てました！」の張り紙を剥がすイメージです

先ほどの削除マーカーを削除すると、削除マーカーのバージョンはなくなり、元のデータが戻ってきました！

誤ってオブジェクトを消してしまっても、これがあれば復活できるので、消えてほしくないオブジェクトが入っているバケットには設定しておきましょう

2.ライフサイクルルールとは何か

では次に、バージョニングとよくセットで使われるライフサイクルルールについて見ていきましょう

AWSの公式ドキュメントでは、ライフサイクルを以下のように説明しています

S3 ライフサイクルは、オブジェクトを低コストのストレージクラスに移行するか、ユーザーに代わって期限切れのオブジェクトを削除することで、ライフサイクル全体でコスト効率の高い方法でオブジェクトを保存するのに役立ちます。オブジェクトのライフサイクルを管理するには、バケットの S3 ライフサイクル設定を作成します。S3 ライフサイクル設定は、Amazon S3 がオブジェクトのグループに適用するアクションを定義するルールのセットです。次の 2 種類のアクションがあります。
オブジェクトのライフサイクルの管理

つまり、ライフサイクルルールとはコストよくストレージ管理をするために設定するルール、ということです

ライフサイクルルールで設定できるルールは以下の5つで、これらを組み合わせて適切なルールを設定していきます

1. 現行バージョンのオブジェクトをストレージクラス間で移行する
2. 非現行バージョンのオブジェクトをストレージクラス間で移行する
3. オブジェクトの現行バージョンを有効期限切れにする
4. オブジェクトの非現行バージョンを完全に削除
5. 有効期限切れのオブジェクト削除マーカーまたは不完全なマルチパートアップロードを削除
   ※「現行バージョン」とはオブジェクトの最新バージョンのこと、「非現行バージョン」は最新ではないオブジェクトのバージョンのことです

また、ライフサイクルルールはオブジェクトごと、もしくはフォルダごとに設定できるので、きめ細かく管理が行えます

ここで、「現行バージョンを有効期限切れにする」、「有効期限切れのオブジェクト削除マーカー」について説明します

2-1.オブジェクトの有効期限とは何か

AWSの公式ドキュメントではこう説明されています

移行アクションを S3 ライフサイクル設定に追加して、有効期間終了時にオブジェクトを削除するように Amazon S3 に指示できます。ライフサイクル設定に基づいて、オブジェクトの存続期間が終了すると、Amazon S3 はバケットの S3 バージョニング状態に応じて Expiration アクションを実行します。
・バージョニングされていないバケット – Amazon S3 はオブジェクトを削除キューに追加して非同期的に削除し、オブジェクトを完全に削除します。
・バージョニングが有効なバケット – 現在のオブジェクトバージョンが削除マーカーではない場合、Amazon S3 は固有のバージョン ID を持つ削除マーカーを追加します。これにより、最新のバージョンが最新以外のバージョンとなり、削除マーカーが最新バージョンになります。
・バージョニングが停止されたバケット — Amazon S3 はバージョン ID として null を使用する削除マーカーを作成します。この削除マーカーは、バージョン階層においてあらゆるオブジェクトバージョンをバージョン ID null に置き換えるため、オブジェクトが効率的に削除されます。
オブジェクトの有効期限

つまり、バージョニングが有効な場合の「オブジェクトの現行バージョンを有効期限切れにする」は現行バージョンが削除され、削除マーカーが追加される設定になります

2-2.有効期限切れのオブジェクト削除マーカーとは何か

AWSの公式ドキュメントではこう説明されています

期限切れのオブジェクト削除マーカーは、すべてのオブジェクトバージョンが削除され、単一の削除マーカーだけが残っている場合のマーカーです。ライフサイクル設定が現行バージョンを削除するように設定されている、または ExpiredObjectDeleteMarker アクションが明示的に設定されている場合、Amazon S3 は期限切れのオブジェクト削除マーカーを削除します。
削除マーカーの管理

つまり、最初にアップロードされたデータをA、Aを削除した時に作成される削除マーカーをBとすると、AとB以外にバージョンがなく、かつAが削除されている状態の時のBが「有効期限切れのオブジェクト削除マーカー」です

3.バージョニングとライフサイクルルールを組み合わせる

ライフサイクルルールとバージョニングの概要が分かったところで、両者を組み合わせた時の挙動を見てみましょう
なお、ライフサイクルルールの設定時はバケット内の全てのオブジェクトをルールの対象にできることに加え、

• プレフィックス
• オブジェクトタグ
• オブジェクトサイズ

でオブジェクトを絞り込んでルールの対象にすることができます

3-1.現行バージョンのオブジェクトをストレージクラス間で移行する

こちらを設定するときは、以下のスクリーンショットのように、

• どのオブジェクトをルールの対象にするか
• オブジェクトがアップロードされてから何日後に移動させるか
• どのストレージクラスに移動させるか

を選びます

ここでは「image:catのタグがついたオブジェクトを1日後にGlacier Flexible Retrieval (旧 Glacier)に移動する」ルールを作りました

ルール作成後、オブジェクトを確認すると、Glacier Flexible Retrieval (旧 Glacier)に移動していました

3-2.非現行バージョンのオブジェクトをストレージクラス間で移行する

こちらを設定する場合は、以下のスクリーンショットのように、

• どのオブジェクトをルールの対象にするか
• オブジェクトが最新バージョンでなくなってから何日後に移動させるか
• どのストレージクラスに移動させるか
• 非現行バージョンをいくつ残すか（オプション）

を選びます

ここでは「image:pinkunokumaのタグがついたオブジェクトが最新バージョンでなくなったあと、1日後にGlacier Flexible Retrieval (旧 Glacier)に移動する。非現行バージョンは残さない」ルールを作りました

ルール作成後、手動でオブジェクトを削除し、削除マーカーを追加したあとで確認すると、オブジェクトはGlacier Flexible Retrieval (旧 Glacier)に移動していました

 

3-3.オブジェクトの現行バージョンを有効期限切れにする

こちらを設定する場合は、以下のスクリーンショットのように、

• どのオブジェクトをルールの対象にするか
• オブジェクトがアップロードされてから何日後に現行バージョンではなくなるか

を選びます

ここでは「プレフィックスがgyoza.jpgのオブジェクトを1日後に有効期限切れにする」ルールを作りました

ルール作成後、オブジェクトを確認すると削除マーカーが追加され、これが現行バージョンになっていました

3-4.オブジェクトの非現行バージョンを完全に削除

こちらを設定する場合は、以下のスクリーンショットのように、

• どのオブジェクトをルールの対象にするか
• オブジェクトが現行バージョンでなくなったあと、何日で削除するか
• 非現行バージョンをいくつ残すか（オプション）

を選びます

ここでは「image:shinjunobutaのタグがついたオブジェクトが非現行バージョンになったあと、1日後に削除する」ルールを作りました

ルール作成後、手動でオブジェクトを削除し、削除マーカーを追加したあとで確認すると、削除マーカーのみが残って、オブジェクトは削除されていました

3-5.有効期限切れのオブジェクト削除マーカーまたは不完全なマルチパートアップロードを削除

ここで、「不完全なマルチパートアップロードを削除」について説明します

3-5-1.不完全なマルチパートアップロードを削除とは何か

この説明のためには、まず「マルチパートアップロード」についてから説明します
AWSの公式ドキュメントではこう説明されています

マルチパートアップロードを使用すると、単一のオブジェクトをパートのセットとして Amazon S3 にアップロードすることができます。各パートは、オブジェクトのデータの連続する部分です。これらのオブジェクトパートは、任意の順序で個別にアップロードできます。
Amazon S3 でのマルチパートアップロードを使用したオブジェクトのアップロードとコピー

読んで字の如く、大きいオブジェクトを小分けにしてアップロードする仕組みのことです
仮にアップロード中にネットワークエラーで失敗しても、アップロードを一からやり直す必要はなく、失敗した部分のアップロードだけやり直せば良いため手間が減ります

ただし、うまくアップロードが完了せず、未完了のままになったマルチアップロードは勝手に消えるわけではなく、S3内に残り続け、コストがかかります
「不完全なマルチパートアップロードを削除」はこれを削除する設定です（不完全なマルチパートアップロードを削除するためのバケットライフサイクル設定の設定）

今回はマルチアップロードは設定しないため、こんな設定もあるんだな、と思っていただければ大丈夫です

3-5-2.有効期限切れのオブジェクト削除マーカーを削除する

それでは、今回はこちらのルールを使って、オブジェクトおよび削除マーカーを完全に削除してみます

この場合、設定は少し複雑になり、ライフサイクルルールを2つ設定する必要があります
それは、オブジェクト制御用のルール、それから削除マーカー削除用のルールです（ライフサイクル設定ルールを使用して Amazon S3 バケットを空にするにはどうすればよいですか?）

具体的には、オブジェクト制御用のルールでは

• オブジェクトの現行バージョンを有効期限切れにする
• オブジェクトの非現行バージョンを完全に削除
• 不完全なマルチパートアップロードを削除（何日後に削除するかを設定）

の3つのルールを設定する必要があります
削除マーカー削除用のルールでは、

• 有効期限切れのオブジェクト削除マーカーまたは不完全なマルチパートアップロードを削除

のルールだけで大丈夫です

1つ目のルールは以下のような設定です

2つ目のルールは以下のような設定です

これらの設定は1つのルールにまとめることはできません
具体的には、

• オブジェクトの現行バージョンを有効期限切れにする
• 期限切れのオブジェクト削除マーカーの削除

を一度に設定しようとしても、エラーが出て設定できません

ルール作成後、オブジェクトを確認すると、
まず削除マーカーが追加され、

しばらくすると削除マーカーも削除されていました

以上で、バージョニングとライフサイクルルールを組み合わせた時のオブジェクト移動・削除の挙動を確認できました！！

注意点

バージョニングやライフサイクルルールは便利ですが、使用にあたっては注意すべき点も存在します

バージョニング＝絶対消えない、ではない

バージョニングの使用の際には以下の注意点があります

• バージョニングを有効にする前にアップロードしたオブジェクトのバージョンIDは”null”になり、そのオブジェクトを削除するとバージョニングが有効にならず、そのまま削除されてしまう可能性がある（S3 バージョニングの仕組み/バージョン ID）
• バージョニングは有効にしても即時で有効化されるとは限らない（バケットでのバージョニングの有効化）

つまり、バージョニングを有効にしたからといって絶対安全ではない、ということは念頭に置きましょう
大事なバケットにはオブジェクトロックをかけたり、アクセスするIAMユーザーの権限を制限するなど、他の方法と組み合わせて使うことで、より安全にS3を利用できます

ライフサイクルルールの適用タイミング

ライフサイクルルールは、毎日午前0時 (UTC) に1回のみ実行されます
つまり、例えば1/1の午後4時(UTC)に「オブジェクトを3日後に有効期限切れにする」ライフサイクルルールを設定した場合、ルールが適用されるのは1/5の午前0時(UTC)になります（Amazon S3 バケットにライフサイクルルールを適用してから 1 日を超えても、ルールが機能していない原因を教えてください。）

また、オブジェクトをアップロードしてからライフサイクルルールを設定した場合、ライフサイクルルールはルール設定後の日数で適用されます

例えばオブジェクトのアップロードが1/1で、「オブジェクトの現行バージョンを1日後に有効期限切れにする」ルールを1/4に設定した場合、オブジェクトが有効期限切れになるのは1/5です
当たり前と言えば当たり前ですが、ルールを設定したからといって既存のオブジェクトに対して即ルールが適用される、ということはありません

加えて、ストレージ移行を行いたい場合、オブジェクトの数でもタイミングがズレる可能性もあります
ただし、タイミングがずれても料金計算は設定したタイミングに合わせて計算を行うため、低コストのストレージに設定通り移行できずに請求が嵩む、ということはありません

そのため、ライフサイクルの設定は適用タイミングも考慮して行うようにしましょう

移行できるオブジェクト、ストレージ

ライフサイクルルールでは、デフォルトでは128KB以下のオブジェクトはどのストレージクラスにも移行されません（移行に関する制約と考慮事項）

また、移行したいストレージによっては、スタンダードストレージに一定期間保存してからでないと移行できないストレージもあるため、それらも考慮してルールを設定するようにしましょう

上記以外にも料金面や移行手順で気をつけるべき点はいくつかあるため、公式ドキュメント等を読んで無駄なく、安全にバージョニング・ライフサイクルを活用しましょう

まとめ

• バージョニングを活用することで、S3バケット内のオブジェクトの誤削除を**ある程度**防止できる
• 適切なライフサイクルルールを設定することで、アクセス頻度や用途に合わせてオブジェクトを削除したりストレージクラスの移行ができる
• バージョニングとライフサイクルルールを組み合わせることで、オブジェクトを可用性とコストを両立しながら管理できる
• ただし、使用にあたっては考慮点もあるため、公式ドキュメント等を参考にしながら設定を行う

以上です