ホットデータ・ウォームデータ・コールドデータの違いとは？AWSとAzureのストレージ階層設計と料金最適化ガイド

ホットデータ、ウォームデータ、コールドデータという言葉は聞いたことがあっても、クラウドの実際のサービスにどう対応させるか迷うエンジニアは少なくありません。「とりあえず全部S3に入れておけばいい」という判断で運用を続けた結果、月末の請求書を見て青ざめる——そんな経験をしたことはないでしょうか。

データの「温度」は、アクセス頻度とコストのトレードオフを整理するための概念です。この考え方をクラウドのストレージサービスに正しく当てはめることができれば、パフォーマンスを落とさずに保管コストを大幅に削減できます。

この記事では、ホット・ウォーム・コールドデータの定義と違いを整理したうえで、AWSとAzureそれぞれのストレージ階層サービスがどう対応するかを比較します。実務でよく出てくる設計ケースも交えながら、判断基準を体系的に解説します。

データの「温度」とは何か

「データ温度」とはアクセス頻度を温度で表現したメタファーです。よく使うデータは熱く（ホット）、めったに触らないデータは冷たい（コールド）という感覚です。オンプレ時代でも、高速な SAS ディスクに最近のログを置き、低速な SATA ディスクや NAS に古いアーカイブを移すという運用は自然に行われていました。クラウドではこの考え方が体系的なサービスとして提供されています。

ここで重要なのは「温度は固定ではない」という点です。本番DBの3か月前のスナップショットは今日はコールドでも、監査対応が発生した途端にウォームへ引き上げる必要が生じることがあります。この動的な変化をどう自動化するかが、設計の核心になります。

AWSにおけるストレージ階層の実装

AWSでは、ストレージ種別ごとに温度対応の選択肢が異なります。それぞれの用途と階層化の考え方を整理します。

1. Amazon S3：階層化の主戦場

オブジェクトストレージである Amazon S3 は、ストレージクラスという仕組みで温度管理を行います。データ本体は同じ S3 バケットに入ったまま、クラスを切り替えるだけでコストが大きく変わります。

S3ストレージクラスの料金比較でも詳しく解説していますが、温度との対応は概ね以下のとおりです（2026年3月時点）。

Standard-IA には「最低保存期間 30 日」「最低保存サイズ 128KB」というルールがあります。頻繁に削除・更新される小さなファイルを Standard-IA に移すと、かえって高くつくケースがあるので注意してください。

ライフサイクルルールを使えば、オブジェクトの作成からの経過日数を条件にしてクラスを自動移行できます。詳しくはAmazon S3 ライフサイクルルール入門を参照してください。

また、アクセスパターンが読めない場合は S3 Intelligent-Tiering を使うと、自動でホット・ウォームを行き来させることができます。ただし、管理料($0.0025/1,000オブジェクト/月)がかかるため、小さなファイルが大量にある場合はコスト計算が必要です。

2. Amazon EBS：ホットデータ専用の高速ブロックストレージ

Amazon EBS は EC2 にアタッチするブロックストレージです。DB や OS ファイルシステムなど、低レイテンシが必要なホットデータの置き場所です。ウォームやコールドのデータを EBS に置き続けることは設計ミスです。EC2 が停止中もコストが発生し続けるためです。

使い終わったスナップショットは S3 へ移動し、EBS に残すのは「今まさに参照・更新が必要なデータ」に限定するのが基本です。ボリュームタイプの詳細はAmazon EBS入門を参照してください。

3. Amazon EFS / FSx：共有ファイルの温度管理

複数の EC2 から共有するファイルシステムには Amazon EFS（NFS）や Amazon FSx（Windows/Lustre）を使います。EFS には「標準」と「低頻度アクセス（IA）」の2つのストレージクラスがあり、30 日間アクセスのなかったファイルを自動で IA 層に移行できます（ライフサイクル管理機能）。IA 層の保管料は標準の約 1/10 ですが、取り出し時に追加料金が発生します。

# EFS のライフサイクルポリシーを設定する（AWS CLI）
aws efs put-lifecycle-configuration \
  --file-system-id fs-xxxxxxxx \
  --lifecycle-policies \
    TransitionToIA=AFTER_30_DAYS,TransitionToPrimaryStorageClass=AFTER_1_ACCESS

`TransitionToPrimaryStorageClass=AFTER_1_ACCESS` を指定すると、IA 層のファイルにアクセスが発生した瞬間に標準層へ戻る設定になります。頻度は低いが一度アクセスしたらしばらく使い続けるパターン（例: 障害調査時の古いログ参照）に適しています。

Azureにおけるストレージ階層の実装

Azure のストレージ階層化は、Azure Blob Storage のアクセス層が中心になります。考え方は S3 と共通ですが、名称と特性に違いがあります。

1. Azure Blob Storage：4つのアクセス層

Azure Blob Storage は Hot・Cool・Cold・Archive の4層構造になっています（2026年3月時点）。

Azure の Archive 層は AWS の Glacier Deep Archive に相当します。Archive に格納されたデータは「リハイドレーション（Rehydration）」という復元プロセスが必要で、High Priority（1時間以内）と Standard（最大15時間）の2段階があります。緊急の監査対応で Archive を選ぶのは危険です。

Azure のライフサイクル管理ポリシーを使えば、S3 と同様に作成日や最終アクセス日を基準にしてアクセス層を自動移行できます。

2. Azure Managed Disks：ホットデータの基盤

VM に接続するブロックストレージです。Premium SSD（低レイテンシ・高 IOPS）と Standard HDD（低コスト・低速）があり、ホットデータには Premium SSD、バックアップ・チェックポイント用には Standard HDD という使い分けが基本になります。

AWS vs Azure ストレージ階層サービス対比表

ケース別：温度設計の判断フロー

ケース1：Webサービスのログ管理

Webサーバーのアクセスログを例にすると、温度移行の設計は以下のようになります。

・0～7日: ホット（S3 Standard / Blob Hot）— デバッグやリアルタイム分析で毎日参照する
・8～90日: ウォーム（S3 Standard-IA / Blob Cool）— 週1程度の障害追跡で参照
・91日～: コールド（S3 Glacier Flexible / Blob Archive）— 法令上の保存義務（3～7年）のみ

コスト試算の例として、月間 100GB のログが発生するサービスで、7日をホット・3か月をウォーム・残りをコールドで管理する設計にすると、全期間 Standard のままにする場合と比べ、1年間で約 60～70% のストレージコスト削減が見込めます（取り出し料金は別途）。

ケース2：データベースのバックアップ

・直近7日間: ホット（EBS スナップショット・高速リストア前提）
・8～30日: ウォーム（S3 Standard-IA に移動）
・31日～1年: コールド（S3 Glacier Flexible）
・1年超: 超コールド（S3 Glacier Deep Archive）

AWS Backup を使うと、バックアップポリシー上でこのライフサイクルを定義できます。詳しくはAWS Backup入門を参照してください。

ケース3：動画・画像コンテンツのアーカイブ

メディア企業の場合、旧コンテンツは数百 TB 規模になることがあります。「もう再配信する予定はないが、権利上5年保存が必要」というデータは Glacier Deep Archive や Blob Archive が最適です。取り出しリードタイムを許容できるなら、保管コストは Standard の 1/10 以下になります。

ただし取り出し料金（$0.01～0.02/GB）は保管料より高くなることもあるため、「年に1回しか触らないが、触るときは一気に 10TB 取り出す」という使い方では注意が必要です。

よくある設計ミスと対処法

ミス1：全データをホットに置き続ける
最も多いミスです。「面倒だからとりあえず Standard」という運用をしていると、データが増えるにつれてストレージ料金が線形に増加します。まず S3 Cost Explorer や Azure Cost Management でストレージの内訳を確認し、最終アクセス日が90日以上前のオブジェクトを洗い出すところから始めましょう。

ミス2：コールドデータの取り出しコストを無視する
Glacier Deep Archive は保管コストが安い反面、取り出しに$0.02/GBかかります。10TB を取り出すと取り出し料金だけで$200です。「いざとなれば取り出せる」という前提で設計する場合は、取り出し頻度の最悪ケースも試算に含めてください。

ミス3：最低保存期間の罠
Standard-IA、Glacier 系はいずれも最低保存期間があります（30～180日）。この期間内に削除すると、残りの期間分の保管料が請求されます。バッチ処理の中間ファイルや短命なオブジェクトを誤って IA に入れると、かえって高くつきます。

ミス4：温度変化のトリガーをアクセス日で判断しない
「30日間アクセスがなければコールドへ」というルールは一見シンプルですが、月次バッチで必ず参照するデータの場合、31日目に IA に落としてすぐ取り出すというサイクルが発生して取り出し料金が積み上がります。S3 Intelligent-Tiering や Azure のライフサイクルポリシーは「最終アクセス日」を基準にできるため、実際のアクセスパターンと設計が合致しているか確認が必要です。

本記事のまとめ

・ホット・ウォーム・コールドはアクセス頻度とコストのトレードオフを整理するための概念。固定ではなく、データのライフサイクルに合わせて動的に変化する
・AWS では S3 ストレージクラスが中心。ライフサイクルルールで自動移行、パターン不明なら Intelligent-Tiering が有効
・Azure では Blob Storage の Hot/Cool/Cold/Archive が対応。ライフサイクルポリシーで自動移行できる
・設計判断の出発点はアクセスパターンの可視化。S3 Analytics や Azure Storage Insights を使って実際のアクセス頻度を把握してから移行計画を立てる
・取り出し料金・最低保存期間のコストも必ず試算に含める。保管料だけ見て選ぶとかえって高くなる場合がある

温度設計はクラウドストレージのコスト最適化において最も効果が大きい施策の一つです。まずは既存バケットの「最終アクセス日が90日以上前のオブジェクト」を調べることから着手してみてください。