S3の「バージョニング機能」は、誤削除や上書きからデータを守ってくれる心強い味方です。でも、放って置くと古いバージョンがどんどん溜まり、ストレージ料金が膨れ上がってしまう⋯⋯なんて恐ろしいことになりかねません。
私は模擬試験で「古いバージョンを2年間保存しつつ、コストを最小にするには？」という問いに対し、「タグを付けてバッチ処理で消せばいいのかな？」と遠回りな回答を選んでしまいました。
実は、S3には「ライフサイクルポリシーという、設定するだけで自動的にデータを整理してくれる「お掃除ロボット」のような機能があるんです。
データの「鮮度」に合わせて置き場所を変える
S3ライフサイクルポリシーの核となるのが、「移行アクション」と「有効期限切れアクション」の2つです。
今回の「2年間は保持したいが、めったにアクセスしない」という要件には、この組み合わせが最強のソリューションになります。
- S3 Glacier Deep Archiveへ移行
作成から一定期間（今回の場合は旧バージョンになってすぐ）経ったデータを、最も安価な「氷河の底（Deep Archive）」へ自動で移動させます。 - 2年後に失効（削除）
「作成から2年（730日）経過したら削除する」というルールをセットしておけば、管理者が手を下さずとも自動で消えてくれます。
「最新ではないバージョン」への特別ルール
ここが試験のひっかかりポイントです。S3のライフサイクルポリシーでは、「現行バージョン」と「最新ではない（Noncurrent）バージョン」を分けて設定できます。
- 現行バージョン
今まさに使っている最新のファイル。 - 最新ではないバージョン
上書きや削除によって過去のものになったファイル。
今回のケースのように「古いバージョンだけを安く保存したい」なら、「NoncurrentVersionTransition（最新ではないバージョンの移行）」というルールを指定するのが正解です。
【比較表】S3ライフサイクルでできること
| アクション | 内容 | 主な用途 |
| 移行（Transition） | 安いストレージクラスへ移動 | コスト削減（標準 → IA → Glacier） |
| 期限切れ（Expiration） | オブジェクトを完全削除 | 不要なデータの自動クリーンアップ |
| 不完全なアップロードの停止 | 失敗したゴミデータを削除 | 無駄な課金の防止 |
試験で役立つ！キーワード判別法
S3の長期保存とコストの問題で、以下の言葉があればS3ライフサイクルポリシーが正解です！
- 「コスト最適にアーカイブ」
- 「一定期間後に削除（失効）」
- 「最新ではないバージョンの管理」
- 「S3 Glacier Deep Archiveへ移行」
今回の学び：攻略の格言
「過去の自分（バージョン）はアーカイブへ。ライフサイクルを設定して、2年経ったらサヨナラ（失効）しよう！」
あとがき：一歩ずつ、合格へ
最後まで読んでいただき、ありがとうございました！
今回の設定を使えば、「万が一のためにデータは取っておきたい、でもお金はかけたくない」という、一見わがままな願いも叶えられます。
私は「S3 = ただの箱」だと思っていましたが、時間の経過とともに中身を整理してくれるインテリジェンスな機能があるのだと学び、設計の深さを感じました。これで、ストレージ貧乏からは卒業ですね！
それでは、次回の記事でお会いしましょう！
