Contents
- 1 Azure Storage の基本課金モデル
- 2 2026‑02 時点の主要ストレージ層別単価表
- 3 料金に影響を与えるポイント
- 4 コスト削減に向けた実践的 5 ステップ
- 5 モニタリング・アラート設定例
- 6 よくある落とし穴と対策
- 7 まとめと次のアクション
Azure Storage の基本課金モデル
| 項目 | 説明 |
|---|---|
| 従量課金 | 使用した GB・リクエスト回数・データ転送量に対して課金。保存開始瞬間から容量料金が発生します。 |
| ストレージ層(Tier) | Hot, Cool, Archive の 3 段階。層ごとに単価と最低保存期間が異なります。 |
| アクセス料金 | 読み取り / 書き込みリクエスト、データ復元時の転送費用は別途従量課金です(層により単価が変わります)。 |
| 最小契約容量 | Reserved Capacity を利用する場合は 1 TB〜。通常は最低保存期間のみが制限となります。 |
2026‑02 時点の主要ストレージ層別単価表
※ 本価格は「東日本 (Japan East)」リージョン、USD/JPY = 150 の為替レートで計算した概算です。
正確な数値は Azure 公式料金ページをご確認ください【^1】。
| ストレージ層 | 単価(円 / GB / 月) | 最低保存期間 | アクセス料金の目安 |
|---|---|---|---|
| Hot | 約 2.8 円 | 0 日 | 高め(読み取り/書き込みともに従量課金) |
| Cool | 約 1.4 円 | 30 日 | 中程度(リクエストごとに追加料金) |
| Archive | 約 0.6 円 | 180 日 | 低め(復元時に転送費用が発生) |
出典
- Azure 公式料金ページ – Blob Storage【^1】
- Azure 公式ドキュメント – Reserved Capacity の割引率【^2】
料金に影響を与えるポイント
| 要素 | 具体的な影響例 |
|---|---|
| リージョン | 同一単価でも日本国内と米国西部で約 5‑10% の差が生じることがあります。複数リージョンに跨ってデータを保管する場合は、各リージョンの料金表を個別に確認してください。 |
| 為替レート | Azure は基本価格を米ドルで設定しているため、JPY/USD の変動が直接円建て単価に反映されます。大幅な円安・円高時は見積もりと実際の請求額が乖離する可能性があります。 |
| 最低保存期間 | Cool と Archive はそれぞれ 30 日、180 日 の「最低保存期間」中に削除するとペナルティ(未満分の課金)が発生します。早期削除は割引対象外です。 |
| データ転送 | 同一リージョン内での読み取りは無料ですが、別リージョンへの復元やインターネット経由のダウンロードは転送費用がかかります(Archive の復元は特に高額になることがあります)。 |
対策
- 予算策定時には「為替変動リスク」・「リージョン別価格差」を 5‑10% 程度のバッファとして見込む。
- 最低保存期間を超える前に削除したいデータは、事前に Cool → Hot の一時的な階層変更でペナルティ回避が可能です(ただし追加のストレージ単価が発生します)。
コスト削減に向けた実践的 5 ステップ
Step 1:使用状況の可視化と無駄データ抽出
| 手順 | ポイント |
|---|---|
| 1‑1 Azure Portal → Cost Management + Billing → 「コスト分析」 | リソースタイプで「Storage」を絞り、期間は過去 30 日または 90 日を選択。 |
| 1‑2 「使用量」タブで GB 単位の容量 と コスト をグラフ化 | コンテナ・アカウント別にフィルタリングし、急増傾向がある箇所を特定。 |
| 1‑3 「エクスポート」ボタンで CSV ダウンロード → Excel/Power BI で 利用率 < 10 % の BLOB を抽出 | データドリブンな削減対象リスト化がポイント。 |
前提条件
- アカウントに対して「Cost Management Reader」以上のロールが付与されていること。
- エクスポート先は Azure Storage アカウントか、Power BI のワークスペースへ接続できる環境を用意。
Step 2:アクセス頻度に応じた層(Tier)最適化
| 方法 | 手順概要 |
|---|---|
| 手動で階層変更 (Portal) | 1. 対象コンテナ → 「設定」→「アクセストレアの変更」 2. Hot → Cool または Cool → Archive を選択し、適用開始日を指定 3. 保存すると次回請求サイクルから新単価が反映。 |
| 自動化(ライフサイクル管理ポリシー) | Step 4 で詳述するポリシーに「最終アクセス日 ≥ 30 日 → Cool」「最終アクセス日 ≥ 180 日 → Archive」等の条件を設定。 |
注意点
- Cool→Hot の逆転は、最低保存期間が過ぎていないと割引が無効になるため、必ず「保存開始日+30 日」以降に実行してください。
Step 3:Reserved Capacity(予約容量)で最大 38% 割引を取得
3‑1. Reserved Capacity の概要と最新割引率
| リージョン | 1 年契約割引率 | 3 年契約割引率 |
|---|---|---|
| Japan East | 30 %〜34 % | 35 %〜38 % |
| East US | 28 %〜32 % | 33 %〜36 % |
| West Europe | 29 %〜33 % | 34 %〜37 % |
出典:Azure 公式ドキュメント – Reserved Capacity【^2】
3‑2. 購入前の必須チェックリスト
- 対象サービス:Blob Storage、Data Lake Storage Gen2(どちらも同一プランで適用可)。
- 最低購入単位:1 TB(実務上は 5 TB 以上を推奨)。
- 利用予測:過去 6 ヶ月の平均使用量が予約容量の 80‑90 % 程度であることを確認。過剰購入は無駄になるため、Azure Cost Management の「予約使用率」レポートでシミュレーション。
- リージョン整合性:予約容量は同一リージョン内でのみ有効。マルチリージョン展開の場合は各リージョンごとに別途予約が必要。
3‑3. 購入手順(Portal)
- Azure Portal → 「Reserved Capacity」 → 「新規予約」
- サービス:
Blob StorageまたはData Lake Storage Gen2を選択 - 容量:例)5 TB、期間は 1 年 または 3 年(長期ほど割引率が上昇)
- リージョン:実際に使用しているストレージアカウントと同一を選択
- 「確認」→「購入」 → 完了後、Cost Management > 予約の使用状況で適用状態をモニタリング
3‑4. キャンセル・余剰分の扱い
- キャンセル:原則不可(契約期間中は変更できません)。
- 余剰容量:同一サブスクリプション内で他リージョンへ 移行可能(ただし、移転手続きは Azure サポートに依頼)。
実装上のヒント:Reserved Capacity の利用率が 70 % 未満になる場合は、次回更新時に容量を減らすか、余剰分を他プロジェクトへ割り当てることを検討してください。
Step 4:ライフサイクル管理ポリシーで自動階層化・削除
4‑1. ポリシー定義例(JSON)
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 |
{ "rules": [ { "name": "move-to-cool", "enabled": true, "definition": { "actions": { "baseBlob": { "tierToCool": {} } }, "filters": { "blobTypes": ["blockBlob"], "prefixMatch": [""], "daysSinceModificationGreaterThan": 30 } } }, { "name": "move-to-archive", "enabled": true, "definition": { "actions": { "baseBlob": { "tierToArchive": {} } }, "filters": { "blobTypes": ["blockBlob"], "prefixMatch": [""], "daysSinceModificationGreaterThan": 180 } } }, { "name": "delete-after-retention", "enabled": true, "definition": { "actions": { "baseBlob": { "delete": {} } }, "filters": { "blobTypes": ["blockBlob"], "prefixMatch": [""], "daysSinceModificationGreaterThan": 365 } } } ] } |
4‑2. ポリシー適用手順
| 手順 | 操作 |
|---|---|
| Portal | Storage アカウント → 「データ管理」→「ライフサイクル管理」→「新しいポリシーを追加」→上記 JSON を貼り付けて保存。 |
| CLI | bash az storage account management-policy create --account-name <myAccount> --policy @lifecycle.json(lifecycle.json に上記内容を保存) |
4‑3. 前提条件・注意点
- バージョニングが有効であること(Archive 移行前に必ずバージョン管理設定)。
- ポリシーは 作成後最大 24 時間 で適用開始されるため、即時効果を期待しない。
daysSinceModificationGreaterThanは「最終更新日」基準のため、コピーやメタデータ更新もカウントする点に留意。
Step 5:スナップショット・古いバージョンの一括クリーンアップ
5‑1. 前提条件(スナップショット削除用コンテキスト取得)
|
1 2 3 4 5 |
# Azure PowerShell でストレージアカウントへの認証コンテキストを作成 $accountName = "myStorage" $key = (Get-AzStorageAccountKey -ResourceGroupName rg-demo -Name $accountName)[0].Value $ctx = New-AzStorageContext -StorageAccountName $accountName -StorageAccountKey $key |
必須ロール:
Storage Blob Data Contributor以上が付与されていること。
5‑2. PowerShell によるスナップショット一括削除(30 日超過)
|
1 2 3 4 5 6 7 8 9 10 11 12 |
$container = "logs" $cutoff = (Get-Date).AddDays(-30) # 指定コンテナ内の全 Blob を取得し、30日以上前のスナップショットだけを抽出・削除 Get-AzStorageBlob -Container $container -Context $ctx | Where-Object { $_.SnapshotTime -and $_.SnapshotTime -lt $cutoff } | ForEach-Object { Write-Host "Deleting snapshot: $($_.Name) @ $($_.SnapshotTime)" Remove-AzStorageBlob -Blob $_.Name -Container $container ` -Context $ctx -SnapshotTime $_.SnapshotTime } |
5‑3. Azure CLI による古いバージョン削除(90 日超過)
|
1 2 3 4 5 6 |
# バージョニングが有効なコンテナ「archive」から、最終更新日が90日前より前のオブジェクトを一括削除 az storage blob delete-batch \ --account-name myStorageAccount \ --source archive \ --if-modified-since "$(date -d '90 days ago' +%Y-%m-%dT%H:%M:%SZ)" |
5‑4. 実装上のベストプラクティス
- バックアップ取得:削除前に
az storage blob download-batchで対象をローカルまたは別リージョンへコピー。 - 定期実行:Azure Automation または Azure Functions の Timer Trigger で週次・月次実行するスクリプトを作成し、失敗時はメール/Teams 通知を設定。
モニタリング・アラート設定例
| 項目 | 推奨手段 |
|---|---|
| 総容量増加率 | Cost Management の「予算」機能で月間 5 % 超過時にメール通知。 |
| Cool/Archive への自動移行遅延 | Azure Monitor のカスタムメトリック Microsoft.Storage/storageAccounts/blobServices の BlobTierChangeCount をクエリし、閾値を設定。 |
| スナップショット容量比率 | Log Analytics ワークスペースで以下 KQL クエリを実行し、スナップショットが全体の 20 % 超えたらアラート: StorageBlobInventory | where Type == "Snapshot" | summarize totalSnap = sum(Size) by AccountName | join (StorageBlobInventory | summarize total = sum(Size) by AccountName) on AccountName | extend ratio = todouble(totalSnap)/todouble(total) | where ratio > 0.2 |
よくある落とし穴と対策
| 落とし穴 | 原因 | 対策 |
|---|---|---|
| 割引率が実際より高いと誤認 | Reserved Capacity の割引は「リージョン別」「期間別」で変動するため、全体平均だけを見る。 | 公式ドキュメントのテーブル【^2】を必ず参照し、見積もりツール(Azure Pricing Calculator)でシミュレーション。 |
| 最低保存期間違反によるペナルティ | Cool/Archive のデータを期限前に削除したまま放置。 | 削除スクリプト実行前に daysSinceModificationGreaterThan 条件を満たすか確認、または一時的に Hot に戻す手順を組み込む。 |
| リージョン間のデータ転送コスト見落とし | 同一アカウント内でもリージョン横断レプリケーションが有効化されているケース。 | Azure Monitor の「Network Outbound」メトリックで転送量を監視し、不要な Geo‑Replication をオフにする。 |
| スナップショット削除時のコンテキスト取得漏れ | スクリプト実行環境が Azure AD 認証のみでキー取得を省略した結果、New-AzStorageContext が失敗。 |
Service Principal に Storage Blob Data Contributor ロール付与し、キーまたは SAS トークンで明示的にコンテキスト生成。 |
まとめと次のアクション
- 料金体系を正確に把握
- Hot / Cool / Archive の単価と最低保存期間、リージョン・為替リスクを認識する。
- 可視化 → 最適化 → 自動化 の 3 ステップでコスト削減サイクルを構築
- Step 1 で「どこに無駄があるか」を数値化。
- Step 2・3 で 層最適化 + Reserved Capacity を実行し、最大 38 % の割引を獲得。
- Step 4・5 で ライフサイクル管理ポリシー と スナップショットクリーンアップ を自動化し、ヒューマンエラーを排除。 |
- モニタリングとアラート を設定し、予算超過やポリシー未適用をリアルタイムで検知。 |
- 定期レビュー(四半期ごと)で使用量・割引率の変化を確認し、Reserved Capacity の再調整やリージョン移行の可否を判断。 |
最終的な目標:Azure Blob と Data Lake Storage の総コストを 30 % 以上削減 しつつ、パフォーマンスとデータ保全性は維持することです。まずは「Cost Management + Billing」で現在の使用状況を把握し、本ガイドの Step 1〜5 を順に実装してください。
脚注
[^1]: Azure 公式料金ページ – Blob Storage (2026‑02 更新)
https://learn.microsoft.com/ja-jp/azure/storage/blobs/scalability-targets
[^2]: Reserved Capacity(予約容量)ドキュメント – 割引率と利用条件 (2026‑02)
https://learn.microsoft.com/ja-jp/azure/storage/common/reserved-capacity