お久しぶりです。
最近はQiitaの方に書くことが多かったので、こちらに書くのはだいぶ久々です。
さて、今回のお題はS3のライフサイクルについてです。
AWSを使っている方は恐らく大体の方がS3を使っているとは思いますが、S3上でファイルの自動削除やストレージクラスの変更をしたい場合はS3ライフサイクルを使用することが多いと思います。
例にもれず私も使う機会がやってきたのですが、いざライフサイクルを設定しようとすると以下のライフサイクルルールのアクションのところで？？？となってしまいました。
そのため、今更それ確認するの？っという感はありますが、見ていきたいと思います。
実施作業
S3ライフサイクルとは
S3をよりコスト効率よく使うために、オブジェクト(=ファイル)の移行ルール等を設定し、参照しなくなったオブジェクトをより安いストレージクラスに変更する等を行うための機能です。
S3の料金は大きく分けて6つの種類があります。
S3ライフサイクルはこのうち①に大きく関わります。また、オブジェクトのストレージクラスを変更するにはリクエストが発生するため、②も関係してきます。
一般的に使われそうな設定としては、最初はストレージクラスをデフォルトのS3 Standardで使用し、その後1か月後～数か月後経った頃にIntelligent - Tieringに変更、1年～数年経過した頃に長期保管用のGlacierに変更するといったものがありがちな設定になります。
ライフサイクルルールのアクションから見る
実際のS3ライフサイクルのアクションルールを見ると以下の5つがあります。
これをひとつづつ見ていきます。
- オブジェクトの現行バージョンをストレージクラス間で移行する
- ストレージクラス間でオブジェクトの以前のバージョンを移行する
- オブジェクトの現行バージョンの有効期限が切れる
- オブジェクトの以前のバージョンを完全に削除する
- 期限切れの削除マーカーまたは不完全なマルチパートアップロードを削除する
オブジェクトの現行バージョンをストレージクラス間で移行する
これはオブジェクトのストレージクラスの変更をするためのルールです。
設定の際には「どのストレージクラスに移行するのか」「オブジェクトを作成して何日後に移行するのか」を明示的に指定する必要があります。
一点注意が必要なのは"現行バージョンを"という部分です。
S3ではバージョニング機能が提供されており、デフォルトは無効化されていますが有効化することでアップロードしたオブジェクトのバージョニングがされるようになります。
以下が実際にバージョニングを有効化し、現行バージョンと過去バージョンが発生している状態です。
このルールは「オブジェクトの現行バージョンのストレージクラスで移行する」とあるので、過去バージョンには適用されないため注意が必要です。
ストレージクラス間でオブジェクトの以前のバージョンを移行する
これは現行"以外"のバージョンを対象としたストレージクラスの変更ルールになります。
ストレージクラスを変更するというのは変わらないですが、ルールを設定する際に現行バージョンと若干異なる部分があります。
以下が実際の設定ルールになります。
見てわかる通り、日数のところが現行バージョンの場合は「オブジェクト作成後の日数」となっていましたが、このルールでは「オブジェクトが現行バージョンでなくなってからの日数」となっています。
以下の例ですと、下の過去バージョンの最終更新日時が現行バージョンでなくなった日時になります。
この日時を基準としてライフサイクルルールが適用されます。
オブジェクトの現行バージョンの有効期限が切れる
このルールを設定するとオブジェクトに有効期限を設定することができます。
有効期限後の挙動はバージョニングが有効化されているか否かによって変わり、バージョニングが有効化されていなければオブジェクトが非同期で削除されます。
バージョニングが有効化されている場合は、過去バージョンとして保持されるようになります。
設定ではオブジェクトの現行バージョンの有効期限を日数で設定します。
注意点としては、ストレージクラスによって胃は最低限の料金が発生する期間が決まっており、Glacierであれば最低でも90日間の料金が発生します。
これは90日未満で削除された場合でも変わらないため、削除を設定する場合は日数を意識しましょう。
docs.aws.amazon.com
オブジェクトの以前のバージョンを完全に削除する
このルールでは過去のバージョンの削除期限を設定します。
過去バージョンが発生する条件としては、オブジェクトの再アップロードや現行バージョンの有効期限が切れた場合などで、設定内容としては「オブジェクトが過去バージョンになってからの日数」を指定するようになっています。
期限切れの削除マーカーまたは不完全なマルチパートアップロードを削除する
このルールを理解する前にS3の削除マーカーを知る必要があります。
docs.aws.amazon.com
上記のAWSドキュメントに記載がありますが、バージョニングが有効化されているS3のオブジェクトにDELETEリクエストが送られた場合、S3側ではオブジェクトと同様にキーとバージョンIDが含まれた削除マーカーが作成されます。
その削除マーカーを対象オブジェクトの最新バージョンと位置づけし、それまで現行バージョンだったオブジェクトは過去バージョンとして扱われます。
この最新バージョンに削除マーカーが含まれているオブジェクトに対してGETリクエストを送ると、S3上からは完全削除されていませんが404エラーを表示されるようになっており、見かけ上は存在しないように見えるようです。
尚、完全削除はされていないため、DeleteObject versionId リクエストに削除マーカーのバージョンIDを含めることで、削除したオブジェクトの復元が可能です。
※先ほど削除マーカーにはオブジェクトと同様にキーとバージョンIDが含まれるとありましたが、オブジェクトとは異なる点もあるので、ご注意ください。
- 関連付けられたデータがない。
- アクセスコントロールリスト (ACL) 値に関連付けられていない。
- データがないため、GET リクエストから何も取得しない (エラー 404 を受け取る)。
- 削除マーカーで使用できるオペレーションは、Amazon S3 API DELETE コールだけです。これを行うには、適切な権限を持つ AWS Identity and Access Management (IAM) ユーザーまたはロールを使用して DELETE リクエストを行う必要があります。
上記を踏まえた上でルールを理解します。
docs.aws.amazon.com
docs.aws.amazon.com
まずは「期限切れの削除マーカー」とはなにかというところからですが、端的に言うと過去バージョンが1つもない削除マーカーのことを期限切れオブジェクト削除マーカーと呼びます。
具体的には以下のような削除マーカーが最新バージョンに設定されているオブジェクトに対して、ライフサイクルルール等で過去バージョンの削除を行った場合、最新バージョンに設定されている削除マーカーだけが残っている状態になります。
その場合は過去バージョンを復元することもできず、削除マーカーにGETリクエストしても404エラーを返すのみのため、完全に不要なものになります。
完全に不要になった削除マーカーを自動で削除するための設定がこのルールになります。
※「このアクションは、[オブジェクトの現行バージョンの有効期限が切れる] が選択されている場合は使用できません」とあるので、このルールを設定したい場合は有効期限切れルールとは分けてルールを作成しましょう
尚、不完全なマルチパートアップロードの削除の項目もありますが、これは指定日数で完了しなかったマルチパートアップロードが存在していた場合に自動で削除します。
マルチパートアップロードを使用していなければ設定は特に不要です。
S3の現行バージョンを完全に削除したい場合
以下のAWSドキュメントに記載があります。
aws.amazon.com
ルールは全部で2つ作成する必要があります。
1つ目のルールには現行バージョンの有効期限と過去バージョンの削除、マルチパートアップロードの削除を設定します。
2つ目のルールには前述した期限切れ削除マーカーの削除を設定します。
感想及び所感
削除マーカーの部分が特に理解できていなかったところがあったので、今回調べてみて理解できました。
ライフサイクルルールを設定するときは若干の癖があるので、上記の内容をちゃんと理解した上で設定できるようにしておきましょう。
