Azure Files の請求でまず押さえるべき結論は、新規の Azure Files デプロイでは、原則として Provisioned v2 を起点に検討することです。従来のように「保存容量が何TBだからいくら」と見るだけでは不十分で、ストレージ容量、IOPS、スループット、冗長性、スナップショット、ソフト削除、Azure File Sync などの周辺サービスまで含めて判断する必要があります。
Microsoft Learn の「Understand Azure Files Billing」は、Azure Storage の中でも Azure Files の課金モデルを読み解くための公式情報です。さらに、2026年5月20日更新の Microsoft.FileShares 作成手順では、ストレージアカウントを作らずにファイル共有をデプロイする新しい管理モデルも説明されています。この記事では、管理者・開発者・FinOps 担当者が確認すべき変更点、影響範囲、移行・展開時の注意点を実務目線で整理します。(Microsoft Learn)
Azure Storageの「Understand Azure Files Billing」で押さえるべき変更点
Azure Files Billing の重要な変化は、料金判断の軸が「使用容量だけ」から「課金モデル、メディア層、冗長性、リソースモデルの組み合わせ」へ明確に広がっている点です。Azure Files のコストは、主に次の4要素で決まります。(Microsoft Learn)
| 判断軸 | 確認すべき内容 | コストへの影響 |
|---|---|---|
| 課金モデル | Provisioned v2、Provisioned v1、Pay-as-you-go | 課金対象が「確保した性能」か「実際の使用量」か変わる |
| メディア層 | SSD、HDD | 性能、レイテンシ、単価が変わる |
| 冗長性 | LRS、ZRS、GRS、GZRS | 可用性・耐障害性が上がるほどコストも上がりやすい |
| リソースモデル | Microsoft.Storage、Microsoft.FileShares | 請求の見え方、上限、プロトコル、運用設計が変わる |
特に重要なのは、Provisioned v2 が新規 Azure Files デプロイの推奨モデルとして位置づけられていることです。Provisioned v2 では、ストレージ容量、IOPS、スループットを個別に指定でき、実際にどれだけ使ったかではなく、プロビジョニングした量に基づいて課金されます。(Microsoft Azure)
これは単なる料金表の更新ではありません。ファイル共有の設計段階で「何TiB必要か」だけでなく、「ピーク時に何IOPS必要か」「業務時間帯にどの程度のスループットが必要か」「バーストで吸収できるのか」を決める必要がある、という設計思想の変更です。
影響を受ける対象者
Azure Files Billing の見直しは、インフラ担当者だけの作業ではありません。アプリケーション開発、運用監視、コスト管理、バックアップ設計にも影響します。
| 対象者 | 主な影響 | すぐ確認すべきこと |
|---|---|---|
| Azure 管理者 | ストレージアカウント、ファイル共有、冗長性、SKU の設計が変わる | 既存共有の課金モデル、メディア層、冗長性、プロトコル |
| 開発者・SRE | アプリの I/O パターンによってコストと性能が変わる | ピーク IOPS、平均 IOPS、スループット、SMB/NFS の要件 |
| 情シス・ファイルサーバー担当 | オンプレミス移行や Azure File Sync の費用見積もりが変わる | 同期対象データ量、変更頻度、スナップショット、バックアップ |
| FinOps・経理担当 | 予約、タグ、請求粒度の設計が重要になる | プロジェクト別・部門別に費用を追跡できる構成か |
| セキュリティ担当 | Defender、バックアップ、ソフト削除が追加コストに関係する | Defender for Storage、Azure Backup、保持期間の設定 |
注意したいのは、既存の Azure Files が自動的に Provisioned v2 に切り替わる、という意味ではない点です。Pay-as-you-go から Provisioned v2 へ移行する場合は、Azure File Sync を使っているかどうかで移行手順が変わります。(Microsoft Learn)
3つの課金モデルの違い
Azure Files には、主に3つの課金モデルがあります。名前だけで判断すると誤りやすいため、どのようなワークロードに向くかをセットで理解することが重要です。
| 課金モデル | 課金の考え方 | 向いているケース | 注意点 |
|---|---|---|---|
| Provisioned v2 | ストレージ、IOPS、スループットを個別に確保し、確保量に対して課金 | 新規構築、性能要件が明確な業務システム、予算を読みたい環境 | 使っていない分も課金対象。減少変更には制約がある |
| Provisioned v1 | ストレージ容量を指定し、IOPS とスループットは容量に応じて決まる | 既存の SSD ファイル共有を継続利用する場合 | 性能を上げるために不要な容量を増やすことがある |
| Pay-as-you-go | 使用済みストレージ、トランザクション、データ転送などに応じて課金 | HDD で、利用量が読みづらい既存ワークロード | トランザクションが多いと予算化しにくい |
公式情報では、Provisioned v2 は新規デプロイ向けに推奨されています。一方、Pay-as-you-go は HDD のクラシックファイル共有で利用されるモデルで、使用量ベースのため一見安く見えますが、SMB や FileREST のトランザクションが多い場合はコストが読みにくくなります。(Microsoft Learn)
Provisioned v2は「容量」と「性能」を分けて考える
Provisioned v2 の最大の特徴は、ストレージ容量、IOPS、スループットを個別に設計できることです。たとえば、容量は小さいが大量のランダム I/O が発生するアプリケーションでは、従来のように性能を得るためだけに容量を大きくする必要が減ります。
Provisioned v2 の主な上限・下限は次のとおりです。(Microsoft Learn)
| 項目 | SSD | HDD |
|---|---|---|
| 最小プロビジョニング容量 | 32 GiB | 32 GiB |
| 最小 IOPS | 3,000 IOPS | 500 IOPS |
| 最小スループット | 100 MiB/秒 | 60 MiB/秒 |
| 最大容量 | 256 TiB | 256 TiB |
| 最大 IOPS | 102,400 IOPS | 50,000 IOPS |
| 最大スループット | 10,340 MiB/秒 | 5,120 MiB/秒 |
実務では、最初から最大値を狙うのではなく、次の順で考えると失敗しにくくなります。
- まず、実データ量ではなく「将来増加を含めた必要容量」を決める
- 次に、通常時とピーク時の IOPS を分けて見積もる
- 大容量ファイル転送、バックアップ、同期処理を考慮してスループットを決める
- 数週間運用して Azure Monitor や Cost Management で実績を確認する
- 過剰な IOPS やスループットを下げる。ただし、直近の増加後すぐには減らせない制約に注意する
Provisioned v2 では、プロビジョニングした量を増減できますが、前回の増加から24時間が経過するまで減少できません。変更自体は通常、数分以内に有効になると説明されています。短時間の検証で大きく増やし、その日のうちに戻すような運用は避けるべきです。(Microsoft Learn)
IOPSとスループットにはガードレールがある
Provisioned v2 では、不要な過剰プロビジョニングを防ぐために、IOPS とスループットのガードレールが設けられています。各ディメンションは、プロビジョニング容量に対する推奨値の最大5倍までに制限されます。(Microsoft Learn)
たとえば、32 GiB の SSD 共有では推奨 IOPS が 3,032 となり、最大でプロビジョニングできる IOPS は 15,160 です。これ以上の IOPS が必要な場合は、単に IOPS だけを上げるのではなく、プロビジョニング容量を増やして上限を引き上げる必要があります。
この仕様は、アプリケーション担当者にも共有しておくべきです。「容量は少ないが極端に高い IOPS が必要」という設計では、容量側のプロビジョニングも増やす必要が出る可能性があります。
Pay-as-you-goを選ぶ場合の判断基準
Pay-as-you-go は、使った分だけ支払うモデルです。HDD のクラシックファイル共有で利用でき、使用済みストレージ、トランザクション、データ転送などが主な課金対象になります。(Microsoft Learn)
一見すると柔軟ですが、Azure Files の Pay-as-you-go では、エンドユーザーが「1回ファイルを開いた」と感じる操作でも、実際には複数の SMB トランザクションに分解されることがあります。ファイル一覧の取得、読み取り、書き込み、メタデータ操作が多いアプリでは、容量よりもトランザクション料金が問題になる場合があります。
| アクセス層 | 特徴 | 向いているケース | 失敗しやすい例 |
|---|---|---|---|
| Transaction optimized | トランザクション単価を重視 | 移行直後、I/O が多いワークロード | 容量単価だけ見て Hot/Cool を選び、結果的に高くなる |
| Hot | 容量とトランザクションのバランス型 | 日常的にアクセスされる共有 | 実測せずに長期保存用途へ使い続ける |
| Cool | 保存コストを重視 | アクセス頻度が低いデータ | 頻繁に読み書きする共有を置き、取引コストが膨らむ |
移行時は、Transaction optimized から始め、移行が落ち着いてから実際のトランザクション量を見て Hot や Cool を検討するのが安全です。移行期間中は大量の読み書きが発生するため、その期間のメトリックだけで通常運用時のアクセス層を決めると、誤った判断につながります。
Microsoft.FileSharesで変わる展開設計
2026年5月20日更新の公式手順では、Microsoft.FileShares リソースプロバイダーを使って、ストレージアカウントを作成せずに Azure ファイル共有をデプロイする方法が説明されています。これにより、ファイル共有をより直接的な Azure リソースとして扱えるようになります。(Microsoft Learn)
ただし、現時点で Microsoft.FileShares がすべての Azure Files 用途を置き換えるわけではありません。公式手順では、Microsoft.FileShares は NFS ファイル共有向けで、SSD、Provisioned v2、LRS または ZRS が前提とされています。SMB が必要な場合、HDD を使いたい場合、Azure Files の機能を幅広く使いたい場合は、従来どおりストレージアカウント内のクラシックファイル共有を選ぶ必要があります。(Microsoft Learn)
| リソースモデル | 特徴 | 選ぶべきケース |
|---|---|---|
Microsoft.Storage | ストレージアカウント配下にクラシックファイル共有を作成 | SMB、HDD、既存運用、複数サービスとの共存が必要 |
Microsoft.FileShares | ファイル共有をトップレベルリソースとして作成 | NFS、SSD、Provisioned v2、共有単位の管理を重視 |
管理者が見落としやすいのは、請求の見え方です。クラシックファイル共有を同じストレージアカウントに複数配置すると、請求の最小粒度は基本的にストレージアカウントになります。部門別・顧客別にコストを正確に追跡したい場合は、ストレージアカウントの分け方やタグ設計を先に決める必要があります。Microsoft.FileShares ではファイル共有をトップレベルリソースとして扱えるため、共有単位でのコスト把握がしやすくなります。(Microsoft Learn)
バーストクレジットは「保険」であり、常用性能ではない
Azure Files Billing を理解するうえで、burst credits の扱いは重要です。Provisioned v2 では、IOPS 使用量がプロビジョニング済み IOPS を下回っている間にバーストクレジットが蓄積され、突発的に IOPS が上がったときに、そのクレジットを使って一時的にバーストできます。(Microsoft Learn)
ただし、バーストはベストエフォートです。継続的に高い IOPS が必要なワークロードでは、バーストに頼るのではなく、ピークに合わせて IOPS をプロビジョニングする必要があります。
たとえば、SSD で 3,000 IOPS をプロビジョニングしている場合、公式例では最大 10,000 IOPS までバーストでき、バーストクレジットは 25,200,000 です。10,000 IOPS で走り続けると、3,000 IOPS を超える 7,000 IOPS 分が毎秒クレジットを消費します。単純計算では約1時間でクレジットを使い切るため、毎日数時間続くピークをバーストで吸収する設計は危険です。(Microsoft Learn)
スナップショットとソフト削除の課金に注意
Azure Files のコスト超過で見落とされやすいのが、スナップショットとソフト削除です。
Provisioned v2 では、ライブデータとスナップショット差分の合計がプロビジョニング済み容量内に収まる場合、スナップショット用の追加ストレージ料金は発生しません。しかし、合計がプロビジョニング済み容量を超えると、超過分が Overflow Snapshot Usage として課金されます。(Microsoft Learn)
ソフト削除が有効な場合、削除されたファイル共有は保持期間中、使用済み容量に基づいて課金されます。Provisioned v2 では、削除された共有のプロビジョニング済みストレージ、IOPS、スループットはストレージアカウントの制限には引き続きカウントされますが、課金対象としては使用済み容量が中心になります。(Microsoft Learn)
実務では、次の設定を定期的に確認してください。
| 確認項目 | 推奨アクション |
|---|---|
| スナップショット保持期間 | バックアップ要件と復旧要件に合わせ、不要に長くしない |
| データ変更量 | 差分スナップショットの増加要因になるため、更新頻度の高い共有を把握する |
| ソフト削除保持期間 | 誤削除対策とコストのバランスを取る |
| 削除済み共有 | 保持期間中もコストや制限に影響するため、不要なら適切に削除・整理する |
| Azure Backup | スナップショット作成頻度と保持世代を確認する |
予約は有効だが、対象モデルを間違えない
Azure Files では、予約を使うことでストレージコストを削減できる場合があります。公式情報では、予約は Provisioned v1 と Pay-as-you-go モデルでサポートされ、10 TiB または 100 TiB、1年または3年といった単位で購入する形が説明されています。(Microsoft Learn)
ここで重要なのは、予約はすべての課金要素を割り引くものではないという点です。予約の対象外になり得るものとして、トランザクション、帯域幅、データ転送、メタデータストレージなどがあります。Pay-as-you-go でトランザクションが多いワークロードでは、予約で保存容量のコストを下げても、全体の請求額が期待ほど下がらないことがあります。(Microsoft Learn)
予約を検討する場合は、次の条件を満たすか確認しましょう。
| 条件 | 判断基準 |
|---|---|
| 使用量が安定している | 1年または3年で大きく減る予定がない |
| 対象モデルに合っている | Provisioned v1 または Pay-as-you-go の対象範囲か確認する |
| リージョンが決まっている | 予約はリージョン指定のため、移転予定がある場合は慎重に判断する |
| 冗長性が決まっている | LRS、ZRS、GRS、GZRS の選択が変わると試算が崩れる |
| トランザクション比率が低い | 容量コストの比率が高いほど効果を見込みやすい |
新規構築で Provisioned v2 を選ぶ場合は、予約割引だけで判断せず、プロビジョニング量を適正化するほうがコスト最適化につながる可能性があります。
Azure File Sync、Backup、DefenderもTCOに入れる
Azure Files の総保有コストを考えるときは、Azure Files 単体の料金だけでは足りません。Azure File Sync、Azure Backup、Microsoft Defender for Storage などの付加価値サービスが、トランザクション、スナップショット、IOPS、スループット、別サービス側の料金に影響します。(Microsoft Learn)
特に Azure File Sync は、オンプレミスの Windows ファイルサーバーをキャッシュとして使える便利な構成ですが、同期処理そのものがファイル操作を発生させます。従量課金制ではトランザクションコストとして見えやすく、Provisioned モデルでは IOPS やスループットの消費として影響する場合があります。
Azure Backup はスナップショットを使うため、保持期間とデータ変更量がコストに直結します。Microsoft Defender for Storage はセキュリティ上有効な選択肢ですが、トランザクションの多いファイル共有では追加コストが目立つ場合があります。
TCO を試算する際は、少なくとも次の項目を含めてください。
| 区分 | 含めるべき費用 |
|---|---|
| Azure Files 本体 | ストレージ、IOPS、スループット、トランザクション、データ転送 |
| 保護機能 | スナップショット、ソフト削除、Azure Backup |
| 同期・キャッシュ | Azure File Sync、サーバー台数、変更頻度、送信データ転送 |
| セキュリティ | Microsoft Defender for Storage の追加コスト |
| 運用 | 監視、タグ管理、移行作業、オンプレミス機器の残存コスト |
管理者が確認すべき設定チェックリスト
Azure Files Billing を見直すときは、請求画面だけを見るのではなく、構成と利用実績をセットで確認します。
| チェック項目 | 確認方法の例 | 判断ポイント |
|---|---|---|
| 現在の課金モデル | Azure Portal、CLI、Cost Management | Provisioned v2 へ移行検討すべきか |
| メディア層 | SSD / HDD | 性能要件に対して過不足がないか |
| プロトコル | SMB / NFS | Microsoft.FileShares を使えるか、クラシック共有が必要か |
| リソースモデル | Microsoft.Storage / Microsoft.FileShares | 請求粒度、上限、運用方法に合うか |
| 冗長性 | LRS / ZRS / GRS / GZRS | 可用性要件とコストが合っているか |
| IOPS | Azure Monitor | 通常時とピーク時の差が大きいか |
| スループット | Azure Monitor | バックアップ・同期・大容量転送で詰まっていないか |
| スナップショット | スナップショット数、保持期間 | 差分容量が増えすぎていないか |
| ソフト削除 | 保持期間、削除済み共有 | 保持中のデータが無駄なコストになっていないか |
| タグ | Cost Management、Azure Policy | 部門別・プロジェクト別に追跡できるか |
ストレージアカウント内に複数のクラシックファイル共有を置く場合は、容量、IOPS、スループットの上限を共有する点にも注意が必要です。既存共有が成長したときに拡張できなくなるリスクがあるため、3〜5年程度の成長を見込んで余裕を持たせる設計が推奨されています。(Microsoft Learn)
移行・展開時の失敗しやすいポイント
容量だけでProvisioned v2を設計する
Provisioned v2 では、容量が足りていても IOPS やスループットが不足すると性能問題になります。逆に、ピークに合わせすぎて IOPS を過剰に確保すると、使っていない性能にも課金されます。
移行前に、少なくとも1〜2週間分の通常業務データを取り、平均値とピーク値を分けて見ることが重要です。月末処理、バックアップ、ウイルススキャン、ファイル同期など、特定時間帯にだけ負荷が上がる処理も確認してください。
移行中のトランザクションを通常運用と誤認する
Pay-as-you-go のアクセス層を選ぶとき、移行中のトランザクション量をそのまま通常運用の基準にすると判断を誤ります。移行時は大量の読み書き、一覧取得、メタデータ操作が発生します。
移行完了後、通常利用に戻った期間のメトリックを使ってアクセス層を見直すのが安全です。
SMBが必要なのにMicrosoft.FileSharesを選ぶ
Microsoft.FileShares はストレージアカウントを作らずにファイル共有を作成できる新しい管理モデルですが、公式手順では NFS、SSD、Provisioned v2、LRS/ZRS が前提です。SMB が必要な Windows ファイル共有、HDD のコスト重視構成、既存の Azure Files 機能を幅広く使う構成では、クラシックファイル共有を選ぶ必要があります。(Microsoft Learn)
バーストを前提に恒常的な性能を見積もる
バーストクレジットは、突発的な I/O スパイクを吸収するための仕組みです。毎日決まった時間に高負荷が続く処理は、バーストではなくプロビジョニング済み IOPS とスループットで設計してください。
予約で全コストが下がると思い込む
予約はストレージ利用に対する割引であり、トランザクション、データ転送、メタデータ、帯域幅などは対象外です。予約購入前に、請求の内訳でストレージ費用の割合が十分大きいか確認しましょう。
実務でのおすすめ判断フロー
新規構築、既存環境の見直し、オンプレミス移行では、次の順で判断すると整理しやすくなります。
| ステップ | 判断内容 | 推奨アクション |
|---|---|---|
| 1 | SMB か NFS か | SMB はクラシック共有、NFS かつ SSD 前提なら Microsoft.FileShares も検討 |
| 2 | SSD か HDD か | 低レイテンシ・高性能なら SSD、汎用・コスト重視なら HDD |
| 3 | 新規か既存か | 新規は Provisioned v2 を第一候補にする |
| 4 | 性能要件は明確か | IOPS・スループットの実測値を取る |
| 5 | コスト予測を重視するか | 予算化しやすい Provisioned v2 を優先 |
| 6 | 使用量が安定しているか | Provisioned v1 / Pay-as-you-go では予約も検討 |
| 7 | 同期・バックアップがあるか | Azure File Sync、Azure Backup、Defender の影響を加算 |
| 8 | 部門別請求が必要か | タグ、リソース分割、ストレージアカウント設計を見直す |
判断に迷う場合は、まず Provisioned v2 で小さく構成し、Azure Monitor と Cost Management で実績を見ながら調整するのが現実的です。最初から過大に確保するより、実測に基づいて IOPS とスループットを調整するほうが、性能とコストのバランスを取りやすくなります。
まずやるべきこと
Azure Files Billing の見直しで最初にやるべきことは、料金表を眺めることではなく、現在のファイル共有を棚卸しすることです。
次の5項目を一覧化してください。
| 棚卸し項目 | 記録する内容 |
|---|---|
| ファイル共有 | 名前、用途、部門、環境、本番/検証 |
| 構成 | 課金モデル、SSD/HDD、冗長性、SMB/NFS |
| 使用状況 | 容量、IOPS、スループット、トランザクション |
| 保護設定 | スナップショット、ソフト削除、Azure Backup |
| 関連サービス | Azure File Sync、Defender、監視、タグ |
そのうえで、新規構築は Provisioned v2 を基準に、既存の Pay-as-you-go や Provisioned v1 は実測値をもとに移行可否を判断します。Microsoft.FileShares は有力な選択肢ですが、現時点では NFS・SSD・Provisioned v2 前提であり、SMB や HDD が必要な環境ではクラシックファイル共有を使うべきです。
Azure Files のコスト最適化は、単価を下げる作業ではなく、ワークロードに合った課金モデルとリソースモデルを選ぶ作業です。容量、IOPS、スループット、スナップショット、同期、バックアップを一体で確認し、実測に基づいて段階的に調整していきましょう。
コメント