← AWSサービスの内部原理 コース
32. ストレージクラスの正体 — 安さは取り出しの遅さと引き換えの記憶階層
S3のストレージクラスは複雑な料金表に見えて、実は「速い記憶は高い・遅い記憶は安い・層を移すにはコストがかかる」という記憶階層の物理法則がそのまま数字になったものです。
① S3クラス=記憶階層のクラウド写し — 下るほど「安いが遠い」
S3 Standardミリ秒アクセス・最上位層
≒ キャッシュ/DRAMさらに下る
Standard-IAミリ秒/取り出しGB課金・最低30日
≒ SSDここから復元が必要
Glacier Instant Retrievalミリ秒のまま・最低90日
≒ HDDGlacier Flexible Retrieval復元に数分〜数時間
Glacier Deep Archive復元に数時間・最低180日
- 耐久性はどのクラスも11ナイン(99.999999999%)で共通
- 変わるのは可用性・アクセス速度・単価:可用性は Standard 99.99% / Standard-IA 99.9% / One Zone-IA 99.5%
CPUキャッシュ→DRAM→SSD→HDD→テープと下るほど1バイト単価が下がり読み出しが遅くなる階層を、S3はそのままクラウドに写し取っています。
② 最低保存期間と取り出し料金は「層の物理コスト」の反映
安い層の前提滅多にアクセスされないデータを安い装置に長期間寝かせる
最低保存期間30日未満で消しても30日分請求(IA)
最小サイズ課金128KB未満でも128KB分として課金(IA)
取り出し課金GBあたりの取り出し料金
- Standard-IA / One Zone-IA に共通するルール
- 値付けの都合ではなく、層の物理的なコスト構造がそのまま料金に現れたもの
安い層は「滅多に読まないデータを長く寝かせる」前提の設計。頻繁に出し入れする回転コストは安い層では割に合わず、それがそのまま課金ルールになっています。
③ Glacierの復元 — テープからディスクへの「巻き戻し」
アーカイブ済みオブジェクトFlexible / Deep Archive
そのままではGET不可復元完了後にはじめて
一時コピー取り出しやすい層に作られる
≒ テープ→ディスクへ巻き戻しGET できる
- Flexible Retrieval の復元速度:Expedited(数分)/ Standard / Bulk
- 急ぐほど高い=遠い層から近い層へ運ぶ物理的な手間が料金に反映されている
Flexible Retrieval と Deep Archive のオブジェクトは「アーカイブ済み」でそのままGETできず、先に復元して取り出しやすい層に一時コピーを作る必要があります。
④ Intelligent-Tiering — LRUの発想を自動化した層
Frequent Accessミリ秒アクセス
90日間アクセスなし
Infrequent Accessミリ秒アクセス維持
オプション有効時のみ(90日 / 180日)
Archive Instant Accessミリ秒アクセス維持
Archive Access90日〜・非同期アクセス
Deep Archive Access180日〜・非同期アクセス
- 取り出し料金なし。代わりにオブジェクト単位の監視・自動化の少額月額手数料
- 「どの層に置くべきか人間が予測できない・変化するアクセスパターン」向きの設計
キャッシュのLRU(使われないものを追い出す)と同じ発想で、アクセスのないオブジェクトを自動で安い層へ沈めていくストレージクラスです。
⑤ 128KB未満の例外 — 移動コスト > 節約額なら動かさない
128KB未満のオブジェクト監視の対象外
損得勘定の結果
監視・移動のオーバーヘッド
こちらが大きい移動して節約できる額
常に Frequent Access に常駐
- キャッシュで管理コストの高いエントリを追い出し対象から外すのと同じ判断
- 層を移す操作自体にコストがあり、節約効果が上回るときだけ移動する原則が一貫している
小さすぎるオブジェクトは監視・移動のオーバーヘッドが節約額を上回るため、Intelligent-Tieringは階層化せずFrequent Accessに置いたままにします。
⑥ DynamoDBとの対比 — 空間の最適化 vs 時間の最適化
DynamoDB パーティショニングどのノードに分散配置するか=空間の問題
S3 ストレージクラスどの速さの層へ移すか=時間の問題
有限資源の配分最適化速い記憶・特定パーティションをどう配ればコストと性能が釣り合うか
- 速い記憶は高い/遅い記憶は安い/層を移すにはコストがかかる — 料金表の裏にある物理法則
- ストレージクラス選び=アクセス頻度をもとに、データを記憶階層のどの高さに置くか決める行為
DynamoDBは「どのノードに置くか(空間)」、S3ストレージクラスは「時間とともにどの速さの層へ移すか(時間)」。根っこはどちらも有限資源の配分最適化です。
サンプルコード(フレームワーク環境が必要なため表示のみ)
# Glacier Flexible / Deep Archive のオブジェクトは直接GETできない。
# まず RestoreObject で「取り出しやすい層」へ一時復元してから読む。
# Flexible Retrieval を Expedited(数分)で1日だけ復元
aws s3api restore-object \
--bucket my-archive-bucket \
--key logs/2025/app.log.gz \
--restore-request Days=1,GlacierJobParameters={Tier=Expedited}
# アップロード時にストレージクラスを直接指定する例
aws s3 cp report.csv s3://my-bucket/report.csv \
--storage-class STANDARD_IA # 他: GLACIER_IR / GLACIER / DEEP_ARCHIVE / INTELLIGENT_TIERING