Azure Blob Storageコスト最適化入門｜アクセス層の自動切替・ライフサイクルポリシー・Reserved Capacityで月額費用を削減する実践ガイド

クラウド移行後、Azure Blob Storageの請求額が予想より大幅に膨らんだという経験はないだろうか。オンプレのNASやストレージアレイと違い、クラウドのオブジェクトストレージはアクセス頻度、操作回数、データ転送量など複数の課金軸が絡み合う。「とりあえずHotで入れておいたら高くなった」というパターンは、Azure移行プロジェクトで頻出の失敗だ。

この記事では、Azure Blob Storageのコスト構造を整理したうえで、アクセス層の自動切替、ライフサイクルポリシーの設計、Reserved Capacityの活用という3つの柱で月額費用を削減する実践的な方法を解説する。AWS S3のコスト最適化手法と比較しながら進めるので、AWSからAzureへ移行中のエンジニアにも参考になるはずだ。

Azure Blob Storageの料金体系を正確に把握する

まず前提として、Azure Blob Storageには複数の課金軸がある。これを混同したまま削減策を考えても、的外れな施策になってしまう。

1. ストレージ料金（保存容量）

保存しているデータ量に対してGB単位で課金される。東日本リージョン（japaneast）でLRS（ローカル冗長）を使った場合の目安（2026年9月時点）は以下のとおりだ。

ストレージ料金だけ見ると、ArchiveはHotの約1/23だ。100TBのデータをHotで保管すると月約$2,300かかるところ、Archiveなら約$99で済む計算になる。

2. 操作料金（リクエスト課金）

オンプレのストレージと大きく異なる点がここだ。ファイルの読み書き・一覧取得といった操作ごとに課金される。アクセス頻度が高いデータをCoolやArchiveに移してしまうと、操作料金が増えてトータルコストが逆に上がることがある。

・Hot 書き込み（PUT/COPY/POST/LIST）: $0.05 / 1万回
・Cool 書き込み: $0.10 / 1万回
・Cold 書き込み: $0.18 / 1万回
・Hot 読み取り（GET等）: $0.004 / 1万回
・Cool 読み取り: $0.01 / 1万回
・Cold 読み取り: $0.10 / 1万回
・Archive 読み取り（リハイドレーション後）: 優先度によって$0.02～$0.065 / 1万回（別途リハイドレーション料金も発生）

3. データ転送料金

同一リージョン内での転送は基本的に無料だが、別リージョンや外部（インターネット）への送信は有料になる。インターネットへのデータ送信（Egress）は最初の5GBが無料で、以降は約$0.082/GB程度かかる（リージョン・量によって異なる）。

4. 早期削除料金

これを見落とすと想定外のコストが発生する。

・Cool層: 最低保存期間30日（30日未満で削除すると不足分を課金）
・Cold層: 最低保存期間90日
・Archive層: 最低保存期間180日

頻繁に更新・削除されるデータをCoolやArchiveに入れると、かえって高くつく。アクセスパターンの把握が最適化の出発点だ。

アクセス層（Hot/Cool/Cold/Archive）の仕組みと使い分け

Azure Blob Storageには現在4つのアクセス層がある。AWSのS3ストレージクラスに慣れている人向けに、対応関係と特徴を整理しておく。

Hotアクセス層 — 頻繁にアクセスするデータ向け

ストレージ料金は最も高いが、操作料金は最も安い。Webアプリのアセット、リアルタイムで読み書きされるデータ、アクティブなログなどに適している。新規ストレージアカウントのデフォルトはHotだ。

Coolアクセス層 — アクセス頻度が低いデータ向け

ストレージ料金はHotの約半分だが、操作料金と読み取り料金が高め。月に1～2回程度しかアクセスしないデータの保管に向いている。バックアップの保管先として使われるケースが多い。注意点は最低30日の保存期間があることだ。

Coldアクセス層 — さらに低頻度なデータ向け

AWSで言えばGlacier Instant Retrievalに近い位置づけ。ストレージ料金はCoolのさらに半分以下だが、読み取り料金はかなり高い。四半期に1度程度のアクセスを想定したデータに最適だ。コンプライアンス目的で長期保管するが年に数回は参照する可能性があるようなデータに向いている。

Archiveアクセス層 — ほぼアクセスしないデータ向け

ストレージ料金は最安だが、読み取りにはリハイドレーション（解凍）が必要で、データが利用可能になるまで数時間から最大15時間かかる。コンプライアンス要件で7年保管が必要な監査ログのような「ほぼ読まない、でも捨てられない」データに最適だ。

アクセス層選択の判断フロー

実務では以下の順で判断するとよい。

・月1回以上アクセスする → Hot
・月1回未満、30日以上保管確定 → Cool
・四半期1回以下、90日以上保管確定 → Cold
・年1回以下、180日以上保管確定、数時間の待機OK → Archive

AWSのS3との大きな違いは、Cool/Cold/Archiveで最低保存期間が設定されている点だ。S3のGlacierにも最低保存期間はあるが、Azure側は層の数が多く条件が細かいため、移行パターンの設計を慎重に行う必要がある。

ライフサイクルポリシーで自動化するコスト削減

アクセス層の使い分けを頭で理解していても、手動で管理するのは現実的でない。ライフサイクルポリシーを使って自動化するのが正解だ。

ライフサイクルポリシーとは

Azure Blob Storageのライフサイクル管理（Lifecycle Management）は、ブロブの最終更新日時や最終アクセス日時を基準に、自動でアクセス層を切り替えたり、ブロブを削除したりするルールを定義できる仕組みだ。AWSのS3ライフサイクルルールに相当する機能で、Azureポータル、Azure CLI、Bicepテンプレートのいずれでも設定できる。

1. ポータルでの設定手順

Azureポータルでの設定は以下の手順で行う。

「ストレージアカウント」→「データ管理」→「ライフサイクル管理」→「ルールの追加」をクリック

条件として設定できる主な項目:
・ブロブの種類（Block blob / Append blob）
・プレフィックス（フォルダパスによるフィルタ）
・最終変更日からの日数
・最終アクセス日からの日数（要: アクセス追跡の有効化）

アクションとして設定できる主な項目:
・アクセス層をCoolに移動
・アクセス層をColdに移動
・アクセス層をArchiveに移動
・ブロブの削除
・スナップショットの削除

2. ライフサイクルポリシーのJSON例

Azure CLIで使うJSON形式のポリシー例を示す。「作成から30日経過したらCool、90日でCold、365日でArchive、2555日（7年）で削除」という典型的なパターンだ。

# lifecycle-policy.json
{
  "rules": [
    {
      "name": "auto-tier-rule",
      "enabled": true,
      "type": "Lifecycle",
      "definition": {
        "filters": {
          "blobTypes": ["blockBlob"],
          "prefixMatch": ["logs/"]
        },
        "actions": {
          "baseBlob": {
            "tierToCool": {
              "daysAfterModificationGreaterThan": 30
            },
            "tierToCold": {
              "daysAfterModificationGreaterThan": 90
            },
            "tierToArchive": {
              "daysAfterModificationGreaterThan": 365
            },
            "delete": {
              "daysAfterModificationGreaterThan": 2555
            }
          }
        }
      }
    }
  ]
}

このポリシーをAzure CLIで適用するコマンド:

# Azure CLI でライフサイクルポリシーを適用する
az storage account management-policy create \
  --account-name <ストレージアカウント名> \
  --resource-group <リソースグループ名> \
  --policy @lifecycle-policy.json

3. 最終アクセス日ベースのポリシー（注意点あり）

最終「変更」日ではなく最終「アクセス」日を基準にしたい場合は、ストレージアカウントの「アクセス追跡」機能を有効にする必要がある。ただしこの機能自体にも追加コストが発生するため、大量の小ファイルを扱う場合は費用対効果を確認してほしい。

【重要】早期削除料金を考慮したポリシー設計

前述のとおり、Cool（30日）・Cold（90日）・Archive（180日）にはそれぞれ最低保存期間がある。ライフサイクルポリシーを設計する際は、各層での滞在期間がこれを下回らないようにすること。例えばCoolへ移動してから30日未満でColdへ移動する設定だと、Cool層の早期削除料金が発生する。

安全な設計の例:
・30日でCoolに移動（Cool最低保存30日をクリア）
・61日でColdに移動（Coolに31日以上滞在、Cold最低保存90日は次で考慮）
・152日でArchiveに移動（Coldに91日以上滞在、Archive最低保存180日は次で）
・333日以降に削除（Archiveに181日以上滞在してからでないと早期削除料金が発生）

Reserved Capacity（予約容量）で割引を受ける

ライフサイクルポリシーでアクセス層を最適化した後に検討したいのが、Reserved Capacity（予約容量）だ。

Reserved Capacityとは

1年または3年間の容量をあらかじめ予約することで、ストレージ料金に割引が適用される仕組みだ。AWSのReserved Instancesと同様の考え方で、「長期間一定量以上のデータを保管する」ことがわかっているなら、前払いで割引を受けるほうが得になる。

割引率の目安（Hot層、LRS、東日本リージョン・2026年9月時点）:
・1年予約: 約18～23%割引
・3年予約: 約36～40%割引

層別・冗長性レベル別に独立して購入できるため、Hot/Cool/Archive各層で使用量に応じた予約が可能だ。

Reserved Capacity購入の判断基準

有効なケース:
・過去12か月のデータ量が安定していて、今後も同水準が見込まれる
・コンプライアンス要件でArchiveデータが確実に増える見通しがある
・毎月数TB以上のデータを安定して保管している

注意が必要なケース:
・データ量が大幅に増減するプロジェクト（予約量が余ると割引分が無駄になる）
・まだライフサイクルポリシーを最適化できていない段階（最適化後の実績値で予約量を決めるべき）
・1年未満のプロジェクト（予約期間が合わない）

Reserved Capacityの購入手順

# Azure Portal での購入手順（概要）
# Azureポータル → 予約 → 「+ 追加」→ 「Azure Blob Storage」を選択
#
# 設定項目:
#   スコープ: サブスクリプション全体 or 特定のリソースグループ
#   リージョン: Japan East 等
#   アクセス層: Hot / Cool / Archive（Cool / Archive が主な対象）
#   冗長性: LRS / ZRS / GRS
#   容量: 100GB単位で指定
#   期間: 1年 or 3年

予約の範囲（スコープ）はサブスクリプション全体または特定のリソースグループに設定できる。複数のストレージアカウントで合算して割引が適用されるため、組織全体の使用量でまとめて予約するとよい。

その他のコスト削減テクニック

1. 冗長性レベルの最適化

冗長性レベルを下げることもコスト削減の有効な手段だ。

本番の重要データはGRS/GZRSが望ましいが、バックアップや開発環境のデータ、再生成が容易なデータはLRSで十分なケースも多い。テスト環境のログをGRSで保管していたというのはよくある無駄遣いだ。

2. 不要なスナップショットとバージョンの削除

BLOBバージョニングや論理削除（Soft delete）を有効にしている場合、古いバージョンやスナップショットが蓄積してストレージ料金が増大することがある。ライフサイクルポリシーでスナップショットの削除ルールも合わせて設定しておくことが重要だ。

# スナップショットと旧バージョンを90日後に削除するポリシー（抜粋）
"actions": {
  "snapshot": {
    "delete": {
      "daysAfterCreationGreaterThan": 90
    }
  },
  "version": {
    "delete": {
      "daysAfterCreationGreaterThan": 90
    }
  }
}

3. Azure Cost Managementでの使用量モニタリング

コスト削減施策を実施するうえで、現状の定期的な把握は欠かせない。Azure Cost Managementのコスト分析を使えば、ストレージアカウント別・操作タイプ別にコストを可視化できる。Blob Storageのコスト内訳（ストレージ料金/操作料金/データ転送料金）を月次で確認する習慣をつけることで、どの施策が効いているかを定量的に判断できる。

よくあるコスト膨張パターンと対策

パターン1: 全データをHotで放置

最も多い失敗パターンだ。「とりあえずHot」で入れておいたデータが何年も蓄積されるケース。対策は、まずAzure Cost Managementでストレージ料金の内訳を確認し、アクセス頻度の低いコンテナを特定してからライフサイクルポリシーを設計することだ。

パターン2: ArchiveへのCOPY後に誤って大量読み取り

ArchiveはHotやCoolからライフサイクルポリシー経由で移動する際は操作料金が安く済むが、ArchiveからHotへの取り出し（リハイドレーション）には時間と費用がかかる。試しにArchiveのデータをGETしようとして大量のリハイドレーション料金が発生するケースがある。Archiveは「ほぼ読まない」という確証があるデータのみに使うこと。

パターン3: 開発環境のデータをGRSで保管

開発・テスト環境のデータはLRSで十分なことが多い。環境ごとにストレージアカウントを分けて冗長性レベルを使い分けるだけで、数十%のコスト削減が見込める。

パターン4: 操作料金を無視したアクセス層選択

ストレージ料金だけを見てCoolやArchiveに移したが、実はアクセス頻度が高く操作料金が激増するケース。ライフサイクルポリシーを適用する前に、Azure Monitorやストレージのメトリクスから実際のアクセスパターンを分析することが重要だ。

パターン5: 早期削除料金を考慮しないポリシー設計

各層の最低保存期間（Cool: 30日、Cold: 90日、Archive: 180日）を考慮せずにポリシーを設定すると、意図せぬ早期削除料金が発生する。特にCoolからColdへの移動タイミングに注意が必要で、ポリシー設計時に各層の滞在日数を必ず計算してから設定すること。

本記事のまとめ

Azure Blob Storageのコスト最適化で押さえるべきポイントを整理する。

オンプレのストレージ管理と根本的に異なるのは、「使っていないデータを最安の場所へ自動で動かせる」点だ。これをライフサイクルポリシーで自動化し、Reserved Capacityで長期割引を取る。この組み合わせが、Azure Blob Storageのコスト最適化の基本形となる。

FinOps全体の取り組みに興味があれば、FinOps実践入門でタグ設計・予算管理・Reserved Instance最適化の全体像も合わせて押さえておくことを勧める。