はじめに

FusicAdventCalendar2025 12日目です！
株式会社Fusicでエンジニアをしている山本です。

昨日は@Junkinsさんの用語整理に関する個人的なノウハウのまとめでした。

今回の記事では、S3オブジェクトのストレージクラス制御についてご紹介いたします。
S3 には複数のストレージクラスが用意されており、利用頻度に応じて最適なコストで運用できます。
年に 1 回読み出すかどうかといったオブジェクトであれば、最も低コストな Glacier Deep Archive（以下 Glacier）を利用するのが一般的と思います。

ストレージクラスの変更方法として、AWS コンソール操作があり、対象オブジェクトを選択して「ストレージクラスを編集する」を選べば簡単に Glacier 化できます。しかし、これをAWS CLI を用いてプログラムで制御しようとすると、状態によって挙動が異なるため注意が必要です。

この記事では、S3 オブジェクトの Glacier 化・復元処理を自前で実装する際に理解しておきたい状態と API の返却値の関係、そして注意点をまとめます。

前提

今回は次の 2 種類のみを扱います。
・Standard
・Glacier Deep Archive（以下 Glacier）
Standard → Glacier への移行（凍結）
Glacier → Standard のような挙動を可能にする復元（解凍）
を CLI ベースのプログラムで実現することを想定します。
なお、本記事では具体的なソースコードの記載はありません。

オブジェクトの状態と storage_class の関係

プログラムでは一般的に次のことを実行します。
・Standard → Glacier へ変更するコマンドを発火
・Glacier → 復元コマンドを発火
そのためには「いまこのオブジェクトはどのストレージクラスなのか？」を取得する必要があります。
しかし、S3 では変更中や復元中といった中間状態が存在し、APIで取得可能な storage_class が期待どおり変化しないケースがあります。

実際の挙動をまとめると次の通りです。

状態	APIで取得したstorage_class
Standard	Standard
StandardからGlacierに凍結中	Standard
Glacier	Glacier
Glacierから復元中	Glacier
Glacierを復元した※	Glacier
復元したGlacierを再度凍結中	Glacier

特に重要なのは「Glacier を復元した」後も storage_class は Glacier のままという点です。
これにより、単純に storage_class だけを見ると、
・すでに復元済みのオブジェクトを “Standard と同様に扱う” 判定ができない
という問題が発生します。

復元済み Glacier を見分ける方法：RestoreStatus

S3のオブジェクトのプロパティとして RestoreStatus というフィールドを取得できます。
これは「復元されたかどうか」を返すもので、復元が完了した Glacier は RestoreStatus=true になります。
そのため、前述の判定は次のように修正できます。
・Standard
・storage_class = Glacier かつ RestoreStatus=true
上記のどちらかであれば、「Glacier 化（再凍結）対象」として扱うことが可能になります。

状態ごとのリクエスト結果：排他制御の観点から

プログラムで安全に処理するためには、
「どの状態でどのリクエストが成功し、どれがエラーになるか」
を確認しておくことが重要です。
以下は、各状態に対して Glacier 化リクエスト / 復元リクエストを発火した結果です。

状態	Glacier化リクエストを発火	復元リクエストを発火
Standard	受け付ける	エラーとなる Restore is not allowed for the object's current storage class
StandardからGlacierに凍結中	受け付ける	エラーとなる Restore is not allowed for the object's current storage class
Glacier	エラーとなる Unable to perform copy operations on GLACIER objects	受け付ける
Glacierから復元中	エラーとなる Unable to perform copy operations on GLACIER objects	エラーとなる Object restore is already in progres
Glacierを復元した	受け付ける	受け付ける（ただ、何も起きない）
復元したGlacierを再度凍結中	（タイミングが短く実証不可）	（タイミングが短く実証不可）

ポイントは次の 2 つです。

状態と矛盾するリクエストは基本的にエラーになる
状態遷移中のリクエストは受け付けられない
つまり、排他制御や状態管理を丁寧に実装しないと、意図しないエラーが発生しうるということです。

まとめ

S3 のストレージクラスを自前プログラムで制御する場合、
storage_class の文字列だけで判別するのではなく、RestoreStatus を併用するのが理想です。
特に Glacier → 復元済み状態では storage_class が変わらないため、
・Glacier なのにダウンロードできる
・Glacier なのに再度 Glacier 化できる
といった一見矛盾した挙動が起きます。
こうした S3 の仕様を踏まえて判定処理を組むことで、より堅牢なプログラムを実装できます。