S3 を使い始めると、すぐに2つの不安が出てきます。「間違えて上書き・削除したら戻せるのか」と、「ログやバックアップが溜まり続けて、気づくと料金が増えていないか」です。どちらも、設定を一度決めておけば放っておいても回ります。ここでは、その2つの設定の理由と動きを順に説明します。ストレージクラスの中身は s3-toha で扱った前提で進めます。
この記事の結論
- S3 の運用は「戻せるようにする」（バージョニング）と「溜め続けない」（ライフサイクル）の2本立てです。
- バージョニングを有効にしたバケットでは、削除すると削除マーカーが付くだけで、前のバージョンは残ります。
- 各バージョンは丸ごと1個のオブジェクトとして課金されるので、有効にしたら古いバージョンの失効も決めます。
- ライフサイクルには「移行」と「失効」の2種類があり、すでにあるオブジェクトにも適用されます。
- 現行バージョンと非現行バージョンは別のルールで扱います。ルールは小さい範囲で試してから広げます。
S3 の運用で何を回すのか
S3 は置いて終わりの場所ではありません。運用で回すことは3つあります。
| 回すこと | 目的 | 使う機能 |
|---|---|---|
| 戻す | 上書き・誤削除から復元できる状態にする | バージョニング |
| 溜めない | 古いものを安い置き場へ移し、期限が来たら消す | ライフサイクルルール |
| 見る | ルールが狙いどおり効いているか確かめる | 定期チェック（後述） |
「戻す」だけを入れると、古い版が積み上がって費用が増えます。「溜めない」だけを入れると、消したくないものまで消えるかもしれません。2つを対にして設計するのが、この記事の骨格です。
バージョニングとは何か
バージョニングは、同じキー（名前）のオブジェクトを上書きしても、古い中身を別のバージョンとして残す機能です。バケット単位で設定します。公式ドキュメントでは、バケットの状態は次の3つとされています。
| 状態 | 動き |
|---|---|
| バージョニングなし（未設定） | 上書きすると古い中身は失われる。初期状態 |
| 有効 | 上書きのたびに新しいバージョン ID が付き、古い版が残る |
| 停止 | 新しい書き込みにはバージョン ID が付かない。すでにあるバージョンは残る |
一度有効にすると、未設定の状態には戻せません。戻せるのは「停止」までです。有効にする前に、後述の費用の話を理解しておくのはそのためです。
削除マーカーの動き
有効なバケットで、バージョン ID を指定せずにオブジェクトを削除すると、中身は消えません。代わりに削除マーカーという空の印が新しい現行バージョンとして積まれます。通常の取得ではそのキーが「無い」ように見えますが、前のバージョンは残っています。
VERSIONING上書き・削除・復元
削除しても前のバージョンは残る。マーカーを消せば戻る
-
上書き
古い版は非現行として残る
-
削除
削除マーカーが現行になる
-
復元
マーカーを消すと前の版が現行
一方、バージョン ID を指定して削除すると、そのバージョンは完全に消えます。「キーだけで消す」と「バージョン ID を指定して消す」は別の操作だと覚えておくと、事故の読み解きが楽になります。
CHECK 1ここまでの確認
バージョニングを有効にしたバケットでオブジェクトを削除すると、何が起きる?
答えと解説
答え: 2. 削除マーカーが現行になり、前のバージョンは残る
削除の指示をキーだけで出すと、削除マーカーが新しい現行バージョンとして積まれるだけで、中身のバージョンは残ります。マーカーを消せば前のバージョンが現行に戻ります。「削除マーカーの動き」を読み直してください。
誤上書き・誤削除から戻す流れは？
戻し方は、起きたことで2通りに分かれます。
- 誤って削除した: 現行になっている削除マーカーを、そのバージョン ID を指定して消します。すると1つ前のバージョンが現行に戻ります。
- 誤って上書きした: 上書き前のバージョンが非現行として残っています。その版を取り出して同じキーに置き直せば、新しい現行バージョンになります（古い版を残したまま戻せます）。
どちらも、戻せるのは「バージョニングを有効にしてから」の操作です。有効にする前に起きた上書きや削除は戻せません。事故が起きてから設定しても遅いので、大事なバケットは使い始めに有効にします。
また、バージョニングが守るのは「うっかり」です。保存した原本を、管理者を含めて誰も上書き・削除できないようにする要件は別の話で、Object Lock が担当します。目的が違うので混同しないようにしてください。詳細は別の記事の題材です。
ライフサイクルルールの仕組み
ライフサイクルルールは、オブジェクトの作成からの経過日数などを条件に、S3 が自動で動作を行う設定です。動作は2種類です。
| 動作 | 意味 | 例 |
|---|---|---|
| 移行（Transition） | 別のストレージクラスへ移す | 一定期間たったログを低頻度アクセス向けやアーカイブ向けへ |
| 失効（Expiration） | 期限が来たオブジェクトを消す | 一定期間たったログを削除 |
ルールの対象は、プレフィックス（logs/ のような名前の先頭）やタグで絞れます。ルールを作る前からあるオブジェクトにも適用されます。 広い範囲で作ると、既存のものが一斉に移行・失効の対象になるので、最初は小さい範囲で試します。
LIFECYCLEライフサイクルの例
古くなるほど安い置き場へ下がり、最後は失効する
30日（例）
- 失効（削除）
- アーカイブ向け
- 低頻度アクセス向け
- 標準
90日（例）
- 失効（削除）
- アーカイブ向け
- 低頻度アクセス向け
- 標準
1年（例）
- 失効（削除）
- アーカイブ向け
- 低頻度アクセス向け
- 標準
自分で決める期間S3 が自動で実行
図の日数はあくまで例です。たとえば、最初の30日は障害調査で頻繁に見るログ、その後の1年は監査のためにまれに見るだけで取り出しに数時間かかってもよく、1年を過ぎたら不要、という要件なら、「30日で Glacier 系へ移行、1年で失効」の2つのルールで表せます。期間は用途の要件から逆算して決めるもので、決まった正解はありません。
移行先はアクセスの読みやすさで選ぶ
移行先の選び方は、s3-toha と storage-shurui-shikumi で扱ったストレージクラスの使い分けそのものです。
- 数か月アクセスしないが長期保管が要り、取り出しに時間がかかってもよい: Glacier Deep Archive のような最安のアーカイブ向け
- まれに参照され、数時間待てる: Glacier Flexible Retrieval のようなアーカイブ向け
- いつ・どのデータが参照されるか読めない: Intelligent-Tiering。アクセスの様子に応じて階層を自動で移すので、ルールで日数を決めにくいデータに向く
「読めるなら日数で移行ルール、読めないなら Intelligent-Tiering」という分け方です。料金の単価や最小保存期間などの条件はクラスごとに違い、改定もあるので、数値は料金ページで確認してください。
現行バージョンと非現行バージョンは別に扱う
バージョニングと組み合わせると、ルールは2つの対象に分かれます。現行バージョンに対する移行・失効と、非現行バージョンに対する移行・失効です。次の章で、後者が費用の主役になる理由を見ます。
CHECK 2ここまでの確認
ライフサイクルルールが行う動作の2種類は?
答えと解説
答え: 1. 移行と失効
ライフサイクルは、オブジェクトを別のストレージクラスへ移す「移行」と、期限が来たものを消す「失効」のどちらかです。「ライフサイクルルールの仕組み」を読み直してください。
古いバージョンが費用を増やさないようにするには？
公式ドキュメントでは、バージョニング有効のバケットでは各バージョンが丸ごと1個のオブジェクトとして課金されると説明されています。差分だけが保存されるわけではありません。1 GB のファイルを10回上書きすれば、約10 GB 分が積み上がる計算です。さらに、削除マーカーが残り続けると、一覧の処理が重くなる原因にもなります。
BALANCE安心と費用
戻せる安心と溜まる費用は、非現行の失効で釣り合う
戻せる安心
- 古いバージョンを保持
- 誤削除・誤上書きから復元
溜まる費用
- 各バージョンが丸ごと課金
- 削除マーカーも残り続ける
非現行バージョンの失効ルール
釣り合わせる方法が、非現行バージョンの失効ルールです。「非現行になってから一定日数たった版を消す」「新しい版を数世代だけ残す」といった条件を、公式ドキュメントに沿って設定できます。あわせて、期限切れの削除マーカー（前のバージョンがすべて消えて、マーカーだけが残った状態）の整理もルールの対象にできます。
決めることは3つです。
- 何日、戻せる状態にしておくか。気づくまでの日数（週次の確認なら1週間より長く）から決める
- 何世代残すか。頻繁に上書きするバケットは世代数を絞る
- 古い版を移行するか、消すか。まれにしか戻さないなら安い置き場へ移す手もある
「戻せる期間」は、気づくまでの時間の実態に合わせます。長ければ安心ですが、その分だけ費用が積み上がります。
運用の定期チェック
ルールは作って終わりではなく、効いているかを見ます。
- 効きの確認: ルール追加後、小さいプレフィックスで試し、期待した日数で移行・失効が起きているかを確かめてから、対象を広げます。
- 消してはいけないものの扱い: ライフサイクルによる失効は、公式ドキュメントによればバケットポリシーでは止められません。消されて困るものは、ルールの対象（プレフィックスやタグ）から外す設計にします。保持が法令や契約で決まっているなら、Object Lock のような別の機能を検討します。
- 増え方の確認: ストレージ量が想定より伸びていないかを、運用の監視（kanshi-sekkei）の一部として見ます。
- ルールの棚卸し: 用途が変わると、ルールが現状に合わなくなります。バケットの用途を変えたときにルールも見直します。
Cloudory 執筆者（AWS 認定 全冠）
運用の設計は、「何を戻せるようにするか」と「何を捨ててよいか」を先に言葉にするところから始まります。機能の名前を覚えるより、この2つの問いに答えられることを目標にしてください。
CHECK 3ここまでの確認
バージョニングを有効にしたまま放置すると、何が増えていく?
答えと解説
答え: 1. 非現行バージョンの保存料金
各バージョンは丸ごと1個のオブジェクトとして課金されるため、上書きのたびに古い版が残って料金が積み上がります。非現行バージョンの失効まで決めておくのが運用です。
まとめ
- 運用は「戻す」「溜めない」「見る」の3つ。バージョニングとライフサイクルを対で設計します。
- 削除マーカーは前のバージョンを隠すだけで、消してはいません。マーカーを消せば戻せます。
- ライフサイクルは移行と失効。既存のオブジェクトにも適用されるので、小さい範囲で試します。
- 各バージョンは丸ごと課金されます。有効化と同時に、非現行バージョンの失効を決めます。
- 禁止したいなら Object Lock、止められない失効はルールの対象から外す、と使い分けます。
参照ソース
- Amazon S3 ユーザーガイド「オブジェクトのライフサイクルの管理」 — 移行と失効の2種類の動作、既存オブジェクトへの適用、バケットポリシーで失効を止められないことの根拠に使用
- Amazon S3 ユーザーガイド「S3 バケットでのバージョニングの使用」 — 3つの状態、削除マーカー、各バージョンが丸ごと課金されること、非現行バージョンの失効の根拠に使用
