S3のクロスリージョンレプリケーション下でオブジェクトの削除やライフサイクルルールはどうなるの?

本日のお話

S3バケットクロスリージョンで同期している場合、オブジェクトの削除周りについて、各種条件やS3 Replication Time Control(後述)などの制限が少しややこしいので自分用のメモとして残しておきます。

S3バケットクロスリージョンレプリケーション

クロスリージョンレプリケーションを有効化すると、ソースバケットにオブジェクトをPUTすると、非同期でターゲットバケットにオブジェクトが同期されます。

この際、オブジェクトの削除動作を同期するか/同期しないかを要件に合わせて設定する必要があります。

例えば、

  • アプリコンテンツが格納されたS3バケットを東阪で同期。東京リージョン利用不可の際に災害対策(DR)サイトとして大阪リージョンでサービス提供を継続する
    →削除動作を同期する
  • オブジェクトの誤削除/悪意ある削除からデータを復旧できるように別リージョンにオブジェクトを退避しておく
    →削除動作を同期しない

削除動作について、明示的にオブジェクトをDELETEした場合と、ライフサイクルルールによって自動的に削除された場合でも挙動が異なります。

本記事では、オブジェクトの削除に注目して挙動を整理します。

S3におけるオブジェクトの削除

S3レプリケーションの前提条件として、ソースバケットとターゲットバケットの両方でバージョニングを有効にする必要があります。
バージョニングを有効にしたバケットでのオブジェクトの削除は、削除マーカーの挙動を押さえておく必要があります。

バージョニングを有効にしていないバケットでは、同じキーで複数回オブジェクトをPUTすると、そのオブジェクトは上書きされます。オブジェクトを削除すると、そのオブジェクトは完全削除されます。

次の図でバージョニングを有効にしたバケットでの挙動を見ていきます。

f:id:imiky:20220331194359p:plain

①同じキーで複数回オブジェクトをPUTすると、既に存在するオブジェクトは以前のバージョンに繰り下がり、PUTしたオブジェクトは新しいバージョンとして別に保管されます。

②バージョンを指定せずにオブジェクトを削除した場合、既に存在するオブジェクトは以前のバージョンに繰り下がり、削除マーカーという目印が最新バージョンになります。この状態でバージョンを指定せずにオブジェクトをGETするとエラーになります。
※以降、バージョンを指定しないオブジェクトの削除を「論理削除」と呼びます

③バージョンを指定して削除マーカーを削除すると、以前のバージョンが繰り上がり、現行バージョンになります。この状態でバージョンを指定せずにオブジェクトをGETすると現行バージョンのオブジェクトが取得できるようになります。

※以降、バージョンを指定したオブジェクトの削除を「完全削除」と呼びます

このように、バージョニングされたバケットでは削除マーカーの挙動がポイントになります。

ライフサイクルルールによる削除は?

S3ではライフサイクルルールにより、指定期間経過後にオブジェクトを別のストレージクラスに移行したり、オブジェクトを削除することができます。

以下、マネジメントコンソールの画面ですが、上から2つが移行に関する設定、次の2つが削除に関する設定です。一番下は細かい話なので本記事では割愛します。

f:id:imiky:20220331202848p:plain

バージョニングされたバケットでは、現行バージョンと以前のバージョンのそれぞれについて削除動作を設定できます。それぞれの挙動を次の図で見ていきましょう。

f:id:imiky:20220331203302p:plain

指定期間を経て「オブジェクトの現行バージョンの有効期限が切れる」と、自動的に削除マーカーが最新バージョンになります。つまり、ライフサイクルルールは自動的にオブジェクトの論理削除を行います。

指定期間を経て「オブジェクトの以前のバージョンを完全に削除する」と、以前のバージョンがバージョン指定で完全削除され、削除マーカーだけが残ります。すなわち、オブジェクトは復旧不可能な状態になります。

本題のクロスリージョンレプリケーション下で削除マーカーとライフサイクルルールはどうなるのか?

既定では、ソースバケット削除マーカーはターゲットバケットに同期されません
すなわち、要件上、削除を同期したくない場合は既定の設定で問題ありません。

f:id:imiky:20220331204313p:plain

ソースバケットで誤って/悪意を持って、以前のバージョンも含めて完全削除してしまった場合でも、ターゲットバケットからオブジェクトを復旧できます。

ソースバケットとターゲットバケットで削除を同期したい場合、削除マーカーのレプリケーションを有効化できます。が、いくつか条件があります

  1. タグ指定でオブジェクトを限定したレプリケーションルールの場合、削除マーカーはレプリケートされません
  2. ライフサイクルルールによる削除動作はレプリケートされません(というより、ライフサイクルルールによって実行されたアクション全般が同期されません)
  3. 削除マーカーのレプリケーションS3 Replication Time ControlのSLAの対象外になります
  4. ソースバケットに対するオブジェクトの完全削除はターゲットバケットに同期されません

S3 Replication Time Control (S3 RTC) は、DR要件などでRTO (Recovery Time Objective) に関わる設定です。オブジェクトをどれくらいの時間間隔・遅延で同期できるのか?という話です。

クロスリージョンレプリケーションでは、PUTされたオブジェクトは非同期的にターゲットバケットに転送されます。
既定ではこの同期遅延については特に定めがありませんが、データ転送量に対して少しだけ追加料金を払うと、オブジェクトの99.99%を15分以内にレプリケートするというSLAが設定されます。これがS3 RTCです。
SLAなので絶対に同期しますと言っているわけではないです

DR要件などでオブジェクトのレプリケーションを利用する場合、RTOが考慮ポイントに入ってくると思いますが、S3 RTCを使った場合でも、削除動作の同期遅延については特に定めがないという点は認識しておく必要があります。

まとめると、タグ指定でレプリケーション設定を組んでいないという前提で、ライフサイクルルールはソース/ターゲットの両バケットで個別に設定S3 RTCのSLAの対象外になる点を認識し、完全削除まで同期したい場合は明示的にターゲットバケットからも完全削除するのであれば、削除動作を同期することができます。

f:id:imiky:20220331205550p:plain

おわりに

なんだかちょっとややこしい、クロスリージョンレプリケーションと削除マーカーの挙動をまとめました。もし、誰かの役に立てば幸いです。

 

以上