Amazon S3には、一定期間が経過したオブジェクトを低コストのストレージクラスへ移行したり、不要になったオブジェクトを自動的に削除したりする"ライフサイクル"という機能があります。
私が参画しているプロジェクトでも、複数のS3バケットに対して数十個以上のライフサイクルルールが設定されています。
設計書には"オブジェクト作成から1年経過後にS3 Glacier Deep Archiveへ移行する"と記載されていました。しかし、実際にバケット内のオブジェクトを確認したところ、2年半ほど前に作成されたオブジェクトが、最近になってようやくDeep Archiveへ移行していることが分かりました。
ライフサイクルルールを設定していても、フィルター条件やオブジェクトサイズ、バージョニングの状態などによって、想定どおりに移行・削除されないことがあります。
そこで今回は、AWS公式ドキュメントを参照しながら、Amazon S3のライフサイクルの基本と、設定を確認する際のポイントを整理します。
S3ライフサイクルとは
S3ライフサイクルは、オブジェクトの利用期間に応じて、ストレージクラスの移行や削除を自動化する機能です。
例えば、次のような運用を実現できます。
- 作成直後はS3 Standardに保存する
- 30日後にS3 Standard-IAへ移行する
- 1年後にS3 Glacier Deep Archiveへ移行する
- 10年後にオブジェクトを削除する
オブジェクトを保存し続けるだけでなく、アクセス頻度や保存期間に応じてストレージクラスを変更することで、ストレージコストを最適化できます。
S3ライフサイクルで設定する主なアクションは、次の2種類です。
●移行アクション(Transition actions)
移行アクションでは、オブジェクトを別のストレージクラスへ移行するタイミングを指定します。
AWS公式ドキュメントでは、移行アクションを"Transition"と表現しています。
例えば、作成から30日後にS3 Standard-IAへ移行したり、作成から1年後にS3 Glacier Flexible Retrievalへ移行したりできます。
●有効期限切れアクション(Expiration actions)
有効期限切れアクションでは、一定期間が経過したオブジェクトを削除するタイミングを指定します。
AWS公式ドキュメントでは、"Expiration"と表現されています。
一時ファイルや処理済みファイルなど、一定期間を過ぎた後に保管する必要がないオブジェクトを自動的に削除できます。
ただし、実際にオブジェクトが完全削除されるかどうかは、バケットのバージョニング状態によって異なります。
■ライフサイクルを使用したストレージクラスの移行
S3に保存するオブジェクトの用途はさまざまです。
頻繁に参照するファイルもあれば、障害や監査に備えて長期間保存するものの、通常はほとんど参照しないファイルもあります。
アクセス頻度が低いオブジェクトを、いつまでもS3 Standardに保存しておく必要はありません。オブジェクトの用途や保存期間に合わせて、より低コストなストレージクラスへ移行することを検討できます。
S3ライフサイクルでは、主に次のストレージクラスへの移行がサポートされています。
- S3 Standard-IA
- S3 Intelligent-Tiering
- S3 One Zone-IA
- S3 Glacier Instant Retrieval
- S3 Glacier Flexible Retrieval
- S3 Glacier Deep Archive
■オブジェクトの有効期限
S3にアップロードしたオブジェクトの中には、一時的な処理のために保存され、処理完了後は不要になるものもあります。
ライフサイクルの有効期限切れアクションを設定すると、一定期間が経過したオブジェクトを自動的に削除できます。
ただし、削除時の挙動は、次のバケットの状態によって異なります。
- バージョニングが設定されていないバケット
- バージョニングが有効なバケット
- バージョニングが停止されているバケット
注意が必要そうなのが、バージョニングが有効になっている場合、もしくはバージョニングが停止されたバケットの場合でしょうか。
削除設定を実施し、削除されたと考えていても、最新バージョンのみ削除されている可能性がありそうです。
その場合、最新以外のバージョンが残り、コストがかかることになりますね。
マネジメントコンソールでは、主に次の項目を設定できます。
- オブジェクトの現行バージョンを有効期限切れにする
- オブジェクトの非現行バージョンを完全に削除する
- 期限切れのオブジェクト削除マーカーを削除する
バージョニングを有効にしていた場合、確実に設定しておきたいですね。
また、ドキュメントの注意文を見ると、以下の記載がありました。
オブジェクトは、1 日あたり 1 つの S3 ライフサイクルアクションのみの対象となります。複数のルールが一致すると、Amazon S3 は最もコストの低いアクションを適用します。
ライフサイクルルールは複雑にしすぎると、コスト効率のいい設定がうまく機能しないかもしれませんね。
まとめ
S3ライフサイクルは、一度設定すれば自動的にストレージコストを最適化してくれる便利な機能です。
一方で、次のような要素によって、設計時の想定と実際の挙動に差が生じることがあります。
- ルールの追加・変更時期
- プレフィックスやタグなどのフィルター条件
- 128KB未満のオブジェクトに対する移行制限
- バケットのバージョニング状態
- 現行バージョンと非現行バージョンの違い
- 複数ルールが一致した場合の優先順位
特にバージョニングが有効なバケットでは、現行バージョンを有効期限切れにするだけでは、非現行バージョンが残り続ける可能性があります。
また、設計書に"1年後にDeep Archiveへ移行する"と記載されていても、ルールのフィルター条件やオブジェクトサイズが適切でなければ、実際には移行されません。
ライフサイクルルールを設計・変更した後は、設定しただけで終わりにせず、一定期間後に対象オブジェクトのストレージクラスやバージョンの状態を確認することが重要です。
今回、実際の設定と設計書の乖離をきっかけに公式ドキュメントを読み直したことで、ライフサイクルルールは"何日後に移行するか"だけでなく、"どのオブジェクトの、どのバージョンを、どの条件で処理するか"まで確認する必要があると改めて分かりました。
参考サイトリンク：AWS公式ドキュメント
↓ほかの協栄情報メンバーもAmazon S3に関する記事を公開しています。ぜひ参考にしてみてください。
■AWS CLI の list-buckets で取得した S3 バケット作成日が一致しない理由と対処方法(小林 剛)
■AMIから複製したインスタンスをALB配下に入れたら S3 が AccessDenied で詰まった話(musaka.k)
■S3 Filesは運用処理を変えるのか？CloudTrailログ読み取りでS3 APIと処理時間を比較してみた(齊藤弘樹)