はじめに
災害対策として、別リージョンにS3のレプリケーションをするケースを考えます。
通常、メインリージョンのデータをバックアップ目的でサブリージョンにコピーすることが目的です。ケースによってはメインリージョンでの削除を反映させたい場合と反映させたくない場合が考えられます。どのようなコントロールができるかを考えていきます。
削除を反映させるケース
アプリケーションが利用しているデータの場合、ほぼリアルタイムに削除を反映したいというケースがあります。削除が反映されない場合、メインリージョンとサブリージョンでデータの不整合が発生してしまい、リカバリ時に削除済みデータが復元されてしまう可能性があります。この場合は削除を反映させたくありません。
削除を反映させないケース
ログや証跡など削除されては困るようなデータのレプリケーションを考えます。この場合、メインリージョンで削除されてしまったとしても、サブリージョンのバックアップには反映されたくありません。メインリージョンでは誤削除や不正の場合が疑われるため、削除を反映させないケースです。削除できないように権限やオブジェクトロックなどをしておくのはもちろんですが、イレギュラーに実施された場合を考え、削除が反映されないようにするのが望ましいでしょう。
コントロール方法
削除マーカーレプリケーションという機能を利用します。
もともと、S3のレプリケーションを有効化する場合、バージョニングの有効化が必須となり、バージョニングが有効化されたバケットにおいて、削除操作をすると対象バージョンで削除マーカーというフラグが付与され、オブジェクトはコンソール上ならびにGETリクエストでは取得できなくなります。削除マーカーを削除することで、復元が可能になるロジックです。ゴミ箱に入れた状態というのが表現上わかりやすいかもしれません。この削除マーカーをレプリケーションすれば、削除した操作がサブリージョンにも反映されるという代物です。
削除を反映させるケース
以下のように削除マーカーレプリケーションを有効化します。この設定により、メインリージョンでの削除がリクエストされると、サブリージョンへ削除マーカーがレプリケーションされ、メインリージョン側と同じような状態となります。
アプリケーション側からみると、GETリクエストではオブジェクトの取得ができなくなるため、サブリージョンのデータを利用したとしても同じ状態にすることが可能です。削除マーカーが付与されたオブジェクトは、S3のライフサイクルルールにより、相互のリージョンで一定期間後削除することが可能です。またデータのライフサイクルポリシーもメインリージョン、サブリージョンそれぞれに設定することでほぼ同じタイミングでデータの削除やストレージクラスの移動が可能です。
削除を反映させないケース
削除マーカレプリケーションをオフにするだけです。
これにより、メインリージョンでの削除操作がサブリージョン側に反映されなくなります。メインリージョン側で不正な操作や誤操作があったとしても、サブリージョン側のデータを参照すれば、削除されていない状態のオブジェクトを取得できます。
まとめ
メインリージョンでのオブジェクトの削除を反映させるかどうかはバックアップの戻し方や、アプリケーション側の仕様、セキュリティポリシーに応じて判断する必要があります。相互のリージョンで整合性を取る必要がある場合は、有効化する必要がありますが、バックアップとして捉えた場合、削除の反映をせず、常にデータを保管しておく、またはセキュリティ上、削除操作を反映されたくない等の場合、無効化するべきです。また、削除マーカーのレプリケーション有無だけではなく、S3のオブジェクトロック、IAMポリシーによる制御、バケットポリシーによるコントロール、MFA削除など、複数の対策をすることが重要です。