Azure Files の課金モデルについて

  • [アーティクル]

Azure Files では、ストレージのメディア レベルとして SSD と HDD の 2 つがサポートされているため、実際のシナリオのパフォーマンスと価格の要件に合わせてファイル共有を調整できます。

  • SSD (プレミアム): ソリッドステート ドライブ (SSD) 上でホストされるファイル共有です。一貫したハイ パフォーマンスと低待機時間が特長であり、ほとんどの IO 操作を 1 桁ミリ秒以内で実行できます。
  • HDD (標準): ハード ディスク ドライブ (HDD) 上でホストされるファイル共有です。汎用目的のためのコスト効果の高いストレージです。

Azure Files には複数の価格モデルの選択肢があり、その代表がプロビジョニング済みと従量課金制です。

  • プロビジョニング済み課金モデル: プロビジョニング済み課金モデルでは、ファイル共有の主コストはファイル共有を作成または更新するときにユーザーがプロビジョニングするストレージの量、IOPS (1 秒あたりの入出力操作数)、およびスループットに基づいており、ユーザーが使用する量とは無関係です。 Azure Files のプロビジョニング済みモデルは、"プロビジョニング済み v2" と "プロビジョニング済み v1" の 2 つがあります。

    • プロビジョニング済み v2: プロビジョニング済み v2 モデルでは、ストレージ、IOPS、スループットをユーザーが個別にプロビジョニングできますが、初回プロビジョニングに役立つ推奨値が提示されます。
    • プロビジョニング済み v1: プロビジョニング済み v1 モデルでは、共有に必要なストレージの量をユーザーがプロビジョニングし、IOPS とスループットはユーザーがプロビジョニングするストレージの量に基づいて決定されます。 Azure Files のプロビジョニング済み v1 モデルを利用できるのは SSD ファイル共有のみです。

  • 従量課金制課金モデル: 従量課金制モデルでは、ファイル共有のコストはその共有をユーザーがどれだけ使用するかに基づいており、これは使用したストレージ、トランザクション、データ転送のコストとして計算されます。 Azure Files の従量課金制モデルを利用できるのは HDD ファイル共有のみです。 新しい HDD ファイル共有のデプロイには、プロビジョニング済み v2 モデルを使用することをお勧めします。

この記事では、Azure Files の課金モデルのしくみを説明します。毎月の Azure Files の請求書を理解するのにお役立てください。 Azure Files の価格については、「Azure Files の料金」ページを参照してください。

適用対象

管理モデル 課金モデル メディア レベル 冗長性 SMB NFS
Microsoft.Storage プロビジョニング済み v2 HDD (標準) ローカル (LRS) はい いいえ
Microsoft.Storage プロビジョニング済み v2 HDD (標準) ゾーン (ZRS) はい いいえ
Microsoft.Storage プロビジョニング済み v2 HDD (標準) geo (GRS) はい いいえ
Microsoft.Storage プロビジョニング済み v2 HDD (標準) geo ゾーン (GZRS) はい いいえ
Microsoft.Storage プロビジョニング済み v1 SSD (プレミアム) ローカル (LRS) はい はい
Microsoft.Storage プロビジョニング済み v1 SSD (プレミアム) ゾーン (ZRS) はい はい
Microsoft.Storage 従量課金制 HDD (標準) ローカル (LRS) はい いいえ
Microsoft.Storage 従量課金制 HDD (標準) ゾーン (ZRS) はい いいえ
Microsoft.Storage 従量課金制 HDD (標準) geo (GRS) はい いいえ
Microsoft.Storage 従量課金制 HDD (標準) geo ゾーン (GZRS) はい いいえ

ストレージ ユニット

Azure Files では、ストレージ容量を表すために基数 2 の測定単位が使用されます。KiB、MiB、GiB、TiB です。

頭字語 定義 ユニット
KiB 1,024 バイト キビバイト
MiB 1,024 KiB (1,048,576 バイト) メビバイト
GiB 1024 MiB (1,073,741,824 バイト) ギビバイト
TiB 1024 GiB (1,099,511,627,776 バイト) テビバイト

base-2 (基数 2、2 進数) の測定単位は、ストレージ容量を計測するために、ほとんどのオペレーティング システムおよびツールで一般的に使用されていますが、これらは base-10 (基数 10、10 進数) の単位 (よく使用される KB、MB、GB、TB など) として誤ってラベル付けされることが頻繁にあります。 誤ってラベル付けされる理由はさまざまですが、Windows などのオペレーティング システムでストレージ ユニットのラベルが誤っている一般的な理由は、多くのオペレーティング システムでこのような頭字語が使用され始めたときはまだ、IEC (国際電気標準会議)、BIPM (国際度量衡局)、NIST (米国国立標準技術研究所) によって標準化されていなかったことです。

次の表に、一般的なオペレーティング システムがストレージを測定し、ラベルを付ける方法を示します。

オペレーティング システム 測定システム ラベル付け
Windows Base-2 一貫して base-10 と間違ったラベルを付けています。
Linux ディストリビューション 一般的に base-2 ですが、一部のソフトウェアでは base-10 を使用しています 一貫性のないラベリング、測定とラベル付けの配置は、ソフトウェアパッケージによって異なります。
macOS、iOS、iPad OS Base-10 一貫して base-10 としてラベルを付けます。

ご使用のオペレーティング システムがリストにない場合は、オペレーティング システムの製造元にご確認ください。

ファイル共有の総所有コストのチェックリスト

オンプレミスから Azure Files に移行する場合、または他のクラウド ストレージ ソリューションと Azure Files を比較する場合は、次の要素を考慮して、同一条件で公平に比較する必要があります:

  • ストレージ、IOPS、帯域幅に対する課金方法 ほどんどのクラウド ソリューションは、ストレージのプロビジョニング (価格決定方式、シンプル) と従量課金制ストレージ (実際の使用量に応じて課金されるため、コストを最適化できる) のどちらかを前提としたモデルを採用しています。 プロビジョニングの課金モデルで重要なのは、プロビジョニングする共有の最小サイズ、プロビジョニングの単位、プロビジョニングの増減機能です。

  • ストレージ コストを最適化する方法はありますか? Azure Files 予約を使用して、ストレージに対して最大 36% の割引を受けることができます。 他のソリューションでは、重複除去や圧縮などの戦略を採用している場合があり、必要に応じてストレージ効率を最適化できます。 ただし、これらのストレージ最適化戦略では、パフォーマンスの低下など、多くの場合、非金銭的なコストが発生します。 Azure Files 予約では、パフォーマンスへの副作用はありません。

  • ストレージの回復性と冗長性の実現方法 Azure Files では、ストレージの回復性と冗長性が製品オファリングに組み込まれています。 すべてのレベルと冗長性レベルで、データを常時利用できることを重視しており、同一のデータについて少なくとも 3 つの複製にアクセスできます。 他のファイル ストレージ サービスの使用を検討するときは、ストレージの回復性と冗長性が組み込まれているか、それとも自分でその仕組みを構築する必要があるかを考慮してください。

  • 管理が必要なもの Azure Files の管理の基本単位はストレージ アカウントです。 他のソリューションでは、その他の管理、たとえばオペレーティング システムの更新や仮想リソースの管理 (VM、ディスク、ネットワーク IP アドレスなど) が必要な場合があります。

  • 付加価値のある製品のコストとは何ですか? Azure Files では、複数のファースト パーティおよびサード パーティの付加価値サービスとの統合がサポートされています。 Azure Backup、Azure File Sync、Microsoft Defender for Storage などの付加価値サービスにより、Azure Files に対してバックアップ、レプリケーション、キャッシュ、セキュリティ機能が提供されます。 付加価値ソリューションには、オンプレミスかクラウドかにかかわらず、独自のライセンス コストと製品コストがあり、通常、ファイル ストレージの総所有コストの一部として考慮されます。

プロビジョニング済み v2 モデル

Azure Files のプロビジョニング済み v2 モデルは、総保有コストの予測可能性と柔軟性を兼ね備えているため、ユーザーが望むとおりのストレージとパフォーマンスの要件を満たすファイル共有を作成できます。 新しいプロビジョニング済み v2 ファイル共有を作成するときに、ユーザーはファイル共有にどれだけのストレージ、IOPS、スループットが必要かを指定します。 ユーザーがプロビジョニングする、このそれぞれの数量によって、合計請求額が決まります。

ユーザーがプロビジョニングするストレージ、IOPS、スループットの量は、そのファイル共有での使用が保証される上限です。 たとえば、2 TiB の共有をプロビジョニングして、その共有に 2 TiB のデータをアップロードすると、共有の容量がいっぱいになるため、さらにデータを追加するには共有のサイズを増やすか、データの一部を削除することが必要になります。 クレジットベースの IOPS バーストを利用すると、使用に関する柔軟性がベストエフォート ベースで向上しますが、クレジットは残ります。

プロビジョニングするストレージ、IOPS、スループットの量は、ニーズの変化に応じて動的にスケールアップまたはスケールダウンできますが、プロビジョニング済みの数量を減らすことができるのは、前回の数量の増加から 24 時間が経過した後のみです。 ストレージ、IOPS、スループットの変更は、プロビジョニングの変更後、数分以内に有効になります。

既定では、プロビジョニング済み v2 モデルを使用して新しいファイル共有を作成するときに、ユーザーが指定したプロビジョニング ストレージの量に基づいて、どれだけの IOPS とスループットが必要になるかについての推奨事項が提示されます。 これらの推奨事項は、Azure Files でそのメディア レベルに対してその量のストレージをプロビジョニングしているお客様の典型的な使用状況に基づいていますが、実際のワークロードに必要な IOPS とスループットは、その "典型的なファイル共有" を上回る、または下回ることもあるため、ユーザーは必要に応じて、プロビジョニングする IOPS とスループットの量を個々のファイル共有の要件に合わせて増減できます。

プロビジョニング済み v2 の提供状況

プロビジョニング済み v2 モデルは、ストレージ アカウントの種類が FileStorage であるストレージ アカウント内のファイル共有に対して提供されます。 現時点では、ストレージ アカウント SKU のうち、次のものが提供されています。

ストレージ アカウントの種類 ストレージ アカウント SKU 使用可能なファイル共有の種類
FileStorage StandardV2_LRS HDD でプロビジョニングされる v2 ファイル共有、ローカル (LRS) 冗長性を指定。
FileStorage StandardV2_ZRS HDD でプロビジョニングされる v2 ファイル共有、ゾーン (ZRS) 冗長性を指定。
FileStorage StandardV2_GRS HDD でプロビジョニングされる v2 ファイル共有、geo (GRS) 冗長性を指定。
FileStorage StandardV2_GZRS HDD でプロビジョニングされる v2 ファイル共有、geo ゾーン (GZRS) 冗長性を指定。

現時点では、これらの SKU は次の限定的なリージョンで一般提供されています。

  • フランス中部
  • フランス南部
  • オーストラリア東部
  • オーストラリア南東部
  • 東アジア
  • 東南アジア
  • 米国西部 2
  • 米国中西部
  • 西ヨーロッパ
  • 北ヨーロッパ

プロビジョニング済み v2 のプロビジョニングの詳細

プロビジョニング済み v2 ファイル共有を作成するときは、ファイル共有のためにプロビジョニングする容量を、ストレージ、IOPS、スループットとして指定します。 ファイル共有に関する制限は、次の属性に基づいて定められます。

項目 HDD の値
ストレージ プロビジョニング ユニット 1 GiB
IOPS プロビジョニング ユニット 1 IO/秒
スループット プロビジョニング ユニット 1 MiB/秒
ファイル共有あたりのプロビジョニング済みストレージの最小量 32 GiB
ファイル共有あたりのプロビジョニング済み IOPS の最小量 500 IOPS
ファイル共有あたりのプロビジョニング済みスループットの最小量 60 MiB/秒
ファイル共有あたりのプロビジョニング済みストレージの最大量 256 TiB (262,144 GiB)
ファイル共有あたりのプロビジョニング済み IOPS の最大量 50,000 IOPS
ファイル共有あたりのプロビジョニング済みスループットの最大量 5,120 MiB/秒
ストレージ アカウントあたりのプロビジョニング済みストレージの最大量 4 PiB (4,194,304 GiB)
ストレージ アカウントあたりのプロビジョニング済み IOPS の最大量 50,000 IOPS
ストレージ アカウントあたりのプロビジョニング済みスループットの最大量 5,120 MiB/秒
ストレージ アカウントあたりのファイル共有の最大数 50 ファイル共有

既定では、ユーザーが指定したストレージのプロビジョニング量に基づいて、推奨される IOPS とスループットのプロビジョニング量が提示されます。 これらの推奨値の数式は、Azure Files でそのメディア レベルに対してその量のストレージをプロビジョニングしているお客様の典型的な使用状況に基づいています。

数式の名前 HDD の数式
IOPS 推奨値 MIN(MAX(1000 + CEILING(0.2 * ProvisionedStorageGiB), 500), 50000)
スループット推奨値 MIN(MAX(60 + CEILING(0.02 * ProvisionedStorageGiB), 60), 5120)

個々のファイル共有の要件によっては、必要になる IOPS やスループットが提示された推奨値を上回る、または下回ることもあるため、必要に応じてこれらの推奨値を上書きして実際に必要な値を指定できます。

プロビジョニング済み v2 のバースト

クレジットベースの IOPS バーストを利用すると、IOPS の使用に関する柔軟性が向上します。 この柔軟性は、予期しない IO スパイクに対するバッファーとして使用するのに適しています。 IO パターンが確立している場合は、IO ピークに合わせたプロビジョニングをお勧めします。

バースト IOPS クレジットは、ファイル共有のトラフィックがプロビジョニング済み (ベースライン) IOPS を下回るたびに蓄積されます。 ファイル共有に使用される IOPS がプロビジョニング済み IOPS を超えているときに、バースト IOPS クレジットがある場合は、そのファイル共有は許容されるバースト IOPS の上限までバーストできます。 ファイル共有のバーストは、クレジットが残っている限り継続できますが、これは累積バースト クレジットの数に基づきます。 プロビジョニング済み IOPS を超える IO が発生するたびに、1 クレジットが消費されます。 すべてのクレジットが消費されると、共有はプロビジョニング済み IOPS に戻ります。 バーストを使用するために、ファイル共有に対する IOPS について特別な操作を行う必要はありません。 バーストはベスト エフォート ベースで動作します。

共有のクレジットには次の 3 つの状態があります。

  • 蓄積中: ファイル共有が使用している量がプロビジョニング済み IOPS を下回っているとき。
  • 減少中: ファイル共有が使用している量がプロビジョニング済み IOPS を上回り、バースト モードであるとき。
  • 一定: ファイル共有が使用している量がプロビジョニング済み IOPS とまったく同じであり、クレジットの蓄積も使用もされていないとき。

新しいファイル共有は、そのバースト バケットに全数のクレジットが含まれると開始されます。 共有の IOPS がプロビジョニング済み制限を下回る理由がサーバーによるスロットリングの場合は、バースト クレジットは蓄積しません。 バースト IOPS の上限と、1 つのファイル共有が持てるクレジットの数の特定には、次の数式が使用されます。

項目 HDD の数式
バースト IOPS 上限 MIN(MAX(3 * ProvisionedIOPS, 5000), 50000)
バースト IOPS クレジット (BurstLimit - ProvisionedIOPS) * 3600

次の表は、さまざまなプロビジョニング済み IOPS の量に対するこれらの数式の例をまとめたものです。

プロビジョニングされた IOPS HDD のバースト IOPS 上限 HDD のバースト クレジット
500 最大 5,000 16,200,000
1,000 最大 5,000 14,400,000
3,000 最大 9,000 21,600,000
5,000 最大 15,000 36,000,000
10,000 最大 30,000 72,000,000
25,000 最大 50,000 90,000,000
50,000 最大 50,000 0

プロビジョニング済み v2 のスナップショット

Azure Files では、Windows ファイル サーバー上のボリューム シャドウ コピー (VSS) に似たスナップショットがサポートされています。 共有スナップショットの詳細については、「Azure Files のスナップショットの概要」を参照してください。

スナップショットは常にライブ共有との、および他のスナップショットとの差分です。 プロビジョニング済み v2 課金モデルでは、すべてのスナップショットの差分サイズ合計が、そのファイル共有の追加プロビジョニング済みストレージ スペースに収まる場合は、スナップショット ストレージの追加コストは発生しません。 ライブ共有データに差分スナップショット データを加えたサイズが、その共有のプロビジョニング済みストレージを上回る場合は、スナップショットの超過使用容量がオーバーフロー スナップショット使用メーターに基づいて課金されます。 オーバーフローの量を決定する数式は次のとおりです: MAX((LiveShareUsedGiB + SnapshotDifferentialUsedGiB) - ProvisionedStorageGiB, 0)

Azure Files の一部の付加価値サービスでは、価値提案の一部としてスナップショットを使用します。 詳細については、「Azure Files の付加価値サービス」を参照してください。

プロビジョニング済み v2 の論理的削除

論理的削除が有効になっているストレージ アカウント内の削除済みファイル共有については、論理的削除期間の間、その削除済み共有に使用されたストレージ容量に基づいて課金されます。 削除済みファイル共有を常に復元可能にするために、その共有のプロビジョニング済みのストレージ、IOPS、およびスループットは、ファイル共有が消去されるまでストレージ アカウントの制限に対してカウントされますが、課金はされません。 論理的削除の詳細については、「Azure ファイル共有で論理的な削除を有効にする方法」を参照してください。

プロビジョニング済み v2 の課金メーター

プロビジョニング済み v2 課金モデルを使用してプロビジョニングされたファイル共有は、次の 5 つの課金メーターに基づいて課金されます。

  • プロビジョニング済みストレージ: プロビジョニングされたストレージの量 (GiB)。
  • プロビジョニング済み IOPS: プロビジョニングされた IOPS (IO/秒) の量。
  • プロビジョニング済みスループット MiBPS: プロビジョニングされたスループットの量 (MiB/秒)。
  • オーバーフロー スナップショット使用量: プロビジョニング済みのストレージ容量内に収まらない、差分スナップショット使用量 (GiB)。 詳細については、「プロビジョニング済み v2 のスナップショット」を参照してください。
  • 論理的な削除の使用量: 論理的に削除されたファイル共有に使用されているストレージ容量 (GiB)。 詳細については、「プロビジョニング済み v2 の論理的削除」を参照してください。

プロビジョニング済み v2 課金メーターで測定される消費は、時間あたりユニット数として 1 時間ごとに報告されます。 たとえば、1024 GiB がプロビジョニングされた共有の場合は、次のようになります。

  • プロビジョニング済みストレージ メーターの、ある 1 時間の測定量は 1,024 ユニット。
  • プロビジョニング済みストレージ メーターの、ある 1 日の測定量を集計した場合は 24,576 ユニット。
  • ある月について集計した場合は、ユニット数は次のようにその月の日数に応じて変化します。
    • 28 日の月 (うるう年ではない 2 月): プロビジョニング済みストレージ メーターに基づく値は 688,128 ユニット。
    • 29 日の月 (うるう年の 2 月): プロビジョニング済みストレージ メーターに基づく値は 712,704 ユニット。
    • 30 日の月: プロビジョニング済みストレージ メーターに基づく値は 737,280 ユニット。
    • 31 日の月: プロビジョニング済みストレージ メーターに基づく値は 761,856 ユニット。

プロビジョニング済み v1 モデル

プロビジョニング済み v1 方式では、ストレージ、IOPS、スループットの互いの比率が固定されています。これは、ストレージをオンプレミスのストレージ ソリューションとして購入する場合と同様です。 新しいプロビジョニング済み v1 ファイル共有を作成するときに、ユーザーはファイル共有にどれだけのストレージが必要かを指定し、IOPS とスループットの値は計算されます。 Azure Files のプロビジョニング済み v1 モデルを利用できるのは SSD ファイル共有のみです。

ユーザーがプロビジョニングするストレージの量によって、そのファイル共有での使用が保証されるストレージ、IOPS、スループットの上限が決まります。 たとえば、2 TiB の共有をプロビジョニングして、その共有に 2 TiB のデータをアップロードすると、共有の容量がいっぱいになるため、さらにデータを追加するには共有のサイズを増やすか、データの一部を削除することが必要になります。 クレジットベースの IOPS バーストを利用すると、使用に関する柔軟性がベストエフォート ベースで向上しますが、クレジットは残ります。

オンプレミスのストレージを購入する場合とは異なり、プロビジョニング済み v1 ファイル共有はニーズの変化に応じて動的にスケールアップまたはスケールダウンできますが、プロビジョニング済みのストレージを減らすことができるのは、前回のストレージ増加から 24 時間が経過した後のみです。 ストレージ、IOPS、スループットの変更は、プロビジョニングの変更後、数分以内に有効になります。

プロビジョニングされた共有のサイズを、使用されている GiB 未満に減少できます。 これを行った場合、データは失われませんが、使用されているサイズに対して引き続き課金され、使用されているサイズではなく、プロビジョニングされた共有のパフォーマンスを受け取ります。

プロビジョニング済み v1 の提供状況

プロビジョニング済み v1 モデルは、ストレージ アカウントの種類が FileStorage であるストレージ アカウント内の SSD ファイル共有に対して提供されます。

ストレージ アカウントの種類 ストレージ アカウント SKU 使用可能なファイル共有の種類
FileStorage Premium_LRS SSD でプロビジョニングされる v1 ファイル共有、ローカル (LRS) 冗長性を指定。
FileStorage Premium_ZRS SSD でプロビジョニングされる v1 ファイル共有、ゾーン (ZRS) 冗長性を指定。

プロビジョニング済み v1 モデルを使用する SSD ファイル共有は、ほとんどの Azure リージョンで一般提供されています。 詳細については、「リージョン別の Azure 製品」を参照してください。

プロビジョニング済み v1 のプロビジョニングの詳細

プロビジョニング済み v1 ファイル共有を作成するときは、その共有に必要なストレージの量をユーザーが指定します。 プロビジョニングする量 (GiB) が大きいほど、使用できる IOPS とスループットが固定比率で増加します。 ファイル共有に関する制限は、次の属性に基づいて定められます。

Item Value
ストレージ プロビジョニング ユニット 1 GiB
ファイル共有あたりのプロビジョニング済みストレージの最小量 100 GiB
ファイル共有あたりのプロビジョニング済みストレージの最大量 100 TiB (102,400 GiB)
ストレージ アカウントあたりのプロビジョニング済みストレージの最大量 100 TiB (102,400 GiB)

共有に対してプロビジョニングされる IOPS とスループットの量は、次の数式によって決まります。

項目 式
計算されたプロビジョニング済み (ベースライン) IOPS MIN(3000 + 1 * ProvisionedStorageGiB, 102400)
計算されたプロビジョニング済みスループット (MiB/秒) 100 + CEILING(0.04 * ProvisionedStorageGiB) + CEILING(0.06 * ProvisionedStorageGiB)

個々のファイル共有の要件によっては、プロビジョニングの数式で計算された値よりも多くの IOPS またはスループットが必要になる場合があります。 この場合は、必要な IOPS またはスループットを得るために、より多くのストレージをプロビジョニングする必要があります。

プロビジョニング済み v1 のバースト

クレジットベースの IOPS バーストを利用すると、IOPS の使用に関する柔軟性が向上します。 この柔軟性は、予期しない IO スパイクに対するバッファーとして使用するのに適しています。 IO パターンが確立している場合は、IO ピークに合わせたプロビジョニングをお勧めします。

バースト IOPS クレジットは、ファイル共有のトラフィックがプロビジョニング済み (ベースライン) IOPS を下回るたびに蓄積されます。 ファイル共有に使用される IOPS がプロビジョニング済み IOPS を超えているときに、バースト IOPS クレジットがある場合は、そのファイル共有は許容されるバースト IOPS の上限までバーストできます。 ファイル共有のバーストは、クレジットが残っている限り継続できますが、これは累積バースト クレジットの数に基づきます。 プロビジョニング済み IOPS を超える IO が発生するたびに、1 クレジットが消費されます。 すべてのクレジットが消費されると、共有はプロビジョニング済み IOPS に戻ります。 バーストを使用するために、ファイル共有に対する IOPS について特別な操作を行う必要はありません。 バーストはベスト エフォート ベースで動作します。

共有のクレジットには次の 3 つの状態があります。

  • 蓄積中: ファイル共有が使用している量がプロビジョニング済み IOPS を下回っているとき。
  • 減少中: ファイル共有が使用している量がプロビジョニング済み IOPS を上回り、バースト モードであるとき。
  • 一定: ファイル共有が使用している量がプロビジョニング済み IOPS とまったく同じであり、クレジットの蓄積も使用もされていないとき。

新しいファイル共有は、そのバースト バケットに全数のクレジットが含まれると開始されます。 共有の IOPS がプロビジョニング済み制限を下回る理由がサーバーによるスロットリングの場合は、バースト クレジットは蓄積しません。 バースト IOPS の上限と、1 つのファイル共有が持てるクレジットの数の特定には、次の数式が使用されます。

項目 式
バースト限度 MIN(MAX(3 * ProvisionedStorageGiB, 10000), 102400)
バースト クレジット (BurstLimit - BaselineIOPS) * 3600

次の表は、プロビジョニングされる共有サイズに対するこれらの数式の例をまとめたものです。

容量 (GiB) ベースライン IOPS バースト IOPS バースト クレジット スループット (イングレス + エグレス) (MiB/秒)
100 3,100 最大 10,000 24,840,000 110
500 3,500 最大 10,000 23,400,000 150
1,024 4,024 最大 10,000 21,513,600 203
5,120 8,120 最大 15,360 26,064,000 613
10,240 13,240 最大 30,720 62,928,000 1,125
33,792 36,792 最大 102,400 227,548,800 3,480
51,200 54,200 最大 102,400 164,880,000 5,220
102,400 102,400 最大 102,400 0 10,340

ファイル共有の実効パフォーマンスは、他の多くの要因の中でも特にマシン ネットワークの制限、使用可能なネットワーク帯域幅、IO サイズ、並列処理の影響を受けます。 並列処理の利点を最大限に活用するために、SSD ファイル共有に対して SMB マルチチャネルを有効にすることをお勧めします。 よくあるパフォーマンスの問題と回避策については、SMB パフォーマンスとパフォーマンスのトラブルシューティング ガイドに関するページを参考にしてください。

プロビジョニング済み v1 のスナップショット

Azure Files では、Windows ファイル サーバー上のボリューム シャドウ コピー (VSS) に似たスナップショットがサポートされています。 共有スナップショットの詳細については、「Azure Files のスナップショットの概要」を参照してください。

スナップショットは常にライブ共有との、および他のスナップショットとの差分です。 プロビジョニング済み v1 課金モデルでは、使用量メーターで測定された差分サイズ合計に対して課金されます。これは、プロビジョニング済みストレージのうち、どれだけが未使用かには関係ありません。 使用済みスナップショット ストレージ メーターの価格は、プロビジョニング済みストレージの価格よりも低く設定されています。

プロビジョニング済み v1 の論理的削除

論理的削除が有効になっているストレージ アカウント内の削除済みファイル共有については、論理的削除期間の間、その削除済み共有に使用されたストレージ容量に基づいて課金されます。 論理的に削除された使用済みストレージ容量は、使用済みスナップショット ストレージ メーターで測定されて報告されます。 論理的削除の詳細については、「Azure ファイル共有で論理的な削除を有効にする方法」を参照してください。

プロビジョニング済み v1 の課金メーター

プロビジョニング済み v1 課金モデルを使用してプロビジョニングされたファイル共有は、次の 2 つのメーターに基づいて課金されます。

  • Premium プロビジョニング済み: プロビジョニングされたストレージの量 (GiB)。
  • Premium スナップショット: 使用されたスナップショットの量と使用された論理的削除済み容量。

プロビジョニング済み v1 課金メーターで測定される消費は、月間ユニット数として 1 時間ごとに報告されます。 たとえば、1024 GiB がプロビジョニングされた共有の場合は、次のようになります。

  • ある 1 時間のユニット数は、次のようにその月の日数に応じて変化します。
    • 28 日の月 (うるう年ではない 2 月): Premium プロビジョニング済みメーターに基づく値は 1.5238 ユニット。
    • 29 日の月 (うるう年の 2 月): Premium プロビジョニング済みメーターに基づく値は 1.4713 ユニット。
    • 30 日の月: Premium プロビジョニング済みメーターに基づく値は 1.4222 ユニット。
    • 31 日の月: Premium プロビジョニング済みメーターに基づく値は 1.3763 ユニット。
  • ある 1 日について集計した場合は、ユニット数は次のようにその月の日数に応じて変化します。
    • 28 日の月 (うるう年ではない 2 月): Premium プロビジョニング済みメーターに基づく値は 36.5714 ユニット。
    • 29 日の月 (うるう年の 2 月): Premium プロビジョニング済みメーターに基づく値は 35.3103 ユニット。
    • 30 日の月: Premium プロビジョニング済みメーターに基づく値は 34.1333 ユニット。
    • 31 日の月: Premium プロビジョニング済みメーターに基づく値は 33.0323 ユニット。
  • Premium プロビジョニング済みメーターの、ある月の測定量を集計した場合は 1024 ユニット。

従量課金制モデル

従量課金制モデルでは、ユーザーが支払う金額はプロビジョニング済みの量ではなくユーザーが使用する量によって決まります。 大まかに言えば、格納されている論理データの量に対するコストを支払い、そのデータの使用状況に基づくトランザクションに対しても課金されます。 従量課金制の課金モデルの場合は、予算を立てるのが難しいこともあります。このモデルでの料金は、エンドユーザーの使用量によって決まるからです。 したがって、新しいファイル共有のデプロイにはプロビジョニング済み v2 モデルを使用することをお勧めします。 従量課金制モデルを利用できるのは HDD ファイル共有のみです。

従量課金制の提供状況

従量課金制モデルは、ストレージ アカウントの種類が StorageV2 または Storage であるストレージ アカウント内の HDD ファイル共有に対して提供されます。

ストレージ アカウントの種類 ストレージ アカウント SKU 使用可能なファイル共有の種類
StorageV2 または Storage Standard_LRS HDD 従量課金制ファイル共有、ローカル (LRS) 冗長性を指定。
StorageV2 または Storage Standard_ZRS HDD 従量課金制ファイル共有、ゾーン (ZRS) 冗長性を指定。
StorageV2 または Storage Standard_GRS HDD 従量課金制ファイル共有、geo (GRS) 冗長性を指定。
StorageV2 または Storage Standard_GZRS HDD 従量課金制ファイル共有、geo ゾーン (GZRS) 冗長性を指定。

従量課金制モデルを使用する HDD ファイル共有は、すべての Azure リージョンで一般提供されています。

アクセス層の違い

HDD ファイル共有を作成するときに、ユーザーはトランザクション最適化、ホット、クールのいずれかのアクセス層を選択します。 3 つのアクセス層はどれも、まったく同じストレージ ハードウェアに格納されます。 この 3 つのアクセス層の主な違いは、保存データのストレージ価格 (クール層に向かうほど低くなる) とトランザクション価格 (クール層に向かうほど高くなる) です。 これは、以下のようなことを意味します。

  • トランザクション最適化は、その名前が示すとおり、高 IOPS (トランザクション) ワークロードの価格を最適化するものです。 トランザクション最適化では、保存データのストレージ料金が最も高くなりますが、トランザクション料金は最も低くなります。
  • ホットでは、多数のトランザクションを含まないアクティブなワークロードを対象としてしています。 トランザクション最適化と比べて、保存データのストレージ料金は若干低くなりますが、トランザクション料金が若干高くなります。 これは、トランザクション最適化層とクール層の間の中間点と考えてください。
  • クールでは、アクティビティが多くないワークロードの料金を最適化し、これにより、保存データのストレージ料金は最も低くなりますが、トランザクション料金は最も高くなります。

アクセス頻度の低いワークロードをトランザクション最適化アクセス層に置くと、共有に対して実行されるトランザクションが月に数回ならば、支払う金額は 0 に近くなります。 ただし、データ ストレージのコストに対して高い金額を支払います。 この同じ共有をクール アクセス層に移動した場合も、トランザクション コストの支払いは 0 に近くなります。これは単に、このワークロードに対してトランザクションを実行する頻度が低いためです。 ただし、クール アクセス層ではデータ ストレージ価格が大幅に安くなります。 ユース ケースに適したアクセス層を選択すると、コストを大幅に縮小できます。

同様に、アクセスの多いワークロードをクール アクセス層に置くと、トランザクション コストの支払い額は大幅に増加しますが、データ ストレージ コストは少なくなります。 これにより、トランザクション料金の上昇によるコストの増加が、データ ストレージ料金の低下による節約額を上回り、トランザクション最適化よりもクールの方がコストがかかる可能性があります。 使用量によっては、ホット アクセス層の場合にコスト効率が最も高くなり、クール アクセス層の場合にコストがトランザクション最適化よりも高くなることもあります。

従量課金制ファイル共有に対して、どのアクセス層が最もコスト効率が高くなるかは、実際のワークロードとアクティビティ レベルによって決まります。 実際のところ、最もコスト効率の高いアクセス層を選択する最善の方法は、共有の実際のリソース消費量 (格納データ、書き込みトランザクションなど) を調べることです。 従量課金制ファイル共有の場合は、最初にトランザクション最適化層を選択して Azure Files への初期移行を行い、移行が完了した後の使用状況に基づいて適切なアクセス層を選択することをお勧めします。 移行中のトランザクションの使用量は、通常、通常のトランザクション使用量を示すものではありません。

トランザクションとは

SMB を使用してコンピューターに Azure ファイル共有をマウントすると、Azure ファイル共有はローカル ストレージであるかのようにコンピューター上に公開されます。 つまり、コンピューター上にあるアプリケーション、スクリプト、およびその他のプログラムは、Azure に保存されていることを知らなくても、Azure ファイル共有上のファイルとフォルダーにアクセスできます。

ファイルの読み取りまたは書き込みを行う場合、使用しているアプリケーションでは、オペレーティング システムによって提供されるファイル システム API に対して一連の API 呼び出しを実行します。 これらの呼び出しは、オペレーティング システムによって解釈されて SMB プロトコル トランザクションになり、ネットワーク経由で送信され、Azure Files で満たされます。 エンド ユーザーが最初から最後までファイルを読み取るなどの 1 つの操作として認識されるタスクは、Azure Files によって提供される複数の SMB トランザクションに変換される場合があります。

原則として、標準ファイル共有で使用される従量課金制課金モデルは、使用量に基づいて課金されます。 アプリケーションとスクリプトによって行われた SMB および FileREST トランザクションは、ファイル共有の使用状況を表し、請求書の一部として表示されます。 Azure File Sync や Azure Backup など、共有に追加できる付加価値クラウド サービスにも同じ概念が適用されます。 トランザクションは、Azure ファイル共有への影響に基づいて価格が異なる 5 つの異なるトランザクション カテゴリにグループ化されます。 これらのカテゴリは、書き込み、一覧表示、読み取り、その他、削除です。

次の表は、各トランザクションの分類を示しています。

トランザクション バケット 管理操作 データ操作
書き込みトランザクション
  • CreateShare
  • SetFileServiceProperties
  • SetShareMetadata
  • SetShareProperties
  • SetShareAcl
  • SnapshotShare
  • RestoreShare
  • CopyFile
  • Create
  • CreateDirectory
  • CreateFile
  • PutRange
  • PutRangeFromURL
  • SetDirectoryMetadata
  • SetFileMetadata
  • SetFileProperties
  • SetInfo
  • Write
  • PutFilePermission
  • Flush
  • SetDirectoryProperties
一覧表示トランザクション
  • ListShares
  • ListFileRanges
  • ListFiles
  • ListHandles
読み取りトランザクション
  • GetFileServiceProperties
  • GetShareAcl
  • GetShareMetadata
  • GetShareProperties
  • GetShareStats
  • FilePreflightRequest
  • GetDirectoryMetadata
  • GetDirectoryProperties
  • GetFile
  • GetFileCopyInformation
  • GetFileMetadata
  • GetFileProperties
  • QueryDirectory
  • QueryInfo
  • Read
  • GetFilePermission
その他/プロトコル トランザクション
  • AcquireShareLease
  • BreakShareLease
  • ReleaseShareLease
  • RenewShareLease
  • ChangeShareLease
  • AbortCopyFile
  • Cancel
  • ChangeNotify
  • Close
  • Echo
  • Ioctl
  • Lock
  • Logoff
  • Negotiate
  • OplockBreak
  • SessionSetup
  • TreeConnect
  • TreeDisconnect
  • CloseHandles
  • AcquireFileLease
  • BreakFileLease
  • ChangeFileLease
  • ReleaseFileLease
削除トランザクション
  • DeleteShare
  • ClearRange
  • DeleteDirectory
  • DeleteFile

Note

NFS 4.1 は、プロビジョニング済み課金モデルを使用する SSD ファイル共有でのみ使用できます。 トランザクション バケットは、プロビジョニング済みファイル共有の課金には影響しません。

アクセス層の切り替え

従量課金制ファイル共有のアクセス層を 3 つの間で変更することはできますが、初期移行後にコストを最適化するためのベスト プラクティスは、コスト面で最善のアクセス層を選択して、アクセス パターンが変化しない限りそのままにすることです。 この理由は、標準ファイル共有のアクセス層を変更すると、次のような追加コストが発生するためです。

  • トランザクション: 共有のアクセス層をホット側からクール側に移動すると、クール側のアクセス層の書き込みトランザクション料金が共有内の各ファイルに対して発生します。 ファイル共有のアクセス層をクール側からホット側に移動すると、クール側のアクセス層の読み込みトランザクション料金が共有内の各ファイルに対して発生します。

  • データ取得: クール アクセス層からホットまたはトランザクション最適化に移動する場合は、移動されたデータのサイズに基づいてデータ取得料金が発生します。 データ取得料金が適用されるのはクール アクセス層のみです。

次の表は、アクセス層移動のコストの内訳をまとめたものです。

アクセス層 トランザクション最適化 (移動先) ホット (移動先) クール (移動先)
トランザクション最適化 (移動元) --
  • ファイルあたり 1 つのホット書き込みトランザクション。
  • ファイルあたり 1 つのクール書き込みトランザクション。
ホット (移動元)
  • ファイルあたり 1 つのホット読み取りトランザクション。
    		 --
    • ファイルあたり 1 つのクール書き込みトランザクション。
    クール (移動元)
    • ファイルあたり 1 つのクール読み取りトランザクション。
    • 使用済み GiB の合計あたりのデータ取得。
    • ファイルあたり 1 つのクール読み取りトランザクション。
    • 使用済み GiB の合計あたりのデータ取得。
    		 --

    ファイル共有のアクセス層を変更できる頻度について、公式には制限はありませんが、共有内のデータ量に基づいて、共有の移行に時間がかかります。 ファイル共有のアクセス層間での移行が進行中の間は、その共有のアクセス層を変更することはできません。 ファイル共有のアクセス層を変更しても、ファイル共有への通常のアクセスには影響しません。

    アクセス層の選択

    既存のデータを Azure Files に移行する方法にかかわらず、最初にファイル共有を作成するときはトランザクション最適化アクセス層にすることをお勧めします。その理由は、移行中に発生するトランザクション数の多さです。 移行が完了して、通常の使用状況での運用を数日または数週間続けた後に、実際のトランザクション数を料金計算ツールに入力すると、どのアクセス層が実際のワークロードに最も適しているかを特定できます。

    従量課金制ファイル共有では、トランザクション情報が示されるのはストレージ アカウント レベルのみであるため、ファイル共有レベルでのコストが低くなるのはどのアクセス層かを特定するのにストレージのメトリックを使用するのは、科学的とはいえません。 可能であれば、各ストレージ アカウントに 1 つのファイル共有のみをデプロイして、課金を完全に可視化することをお勧めします。

    以前のトランザクションを表示するには、次のようにします。

    1. Azure Portal のストレージ アカウントに移動します。
    2. サービス メニューの [監視] の下の [メトリック] を選択します。
    3. ストレージ アカウント名として [スコープ] を、"ファイル" として [メトリック名前空間] を、"トランザクション" として、 [メトリック] を、"合計" として [集計] を選択します。
    4. [Apply Splitting]\(分割の適用) をクリックします。
    5. "API 名" として [値] を選択します。 任意の [制限] と [並べ替え] を選択します。
    6. 任意の期間を選択します。

    Note

    トランザクションの平均数をよりよく理解するには、一定期間のトランザクションを表示してください。 選択した期間が初期プロビジョニングと重複しないようにします。 この期間中のトランザクションの平均数を乗算して、1 か月全体の推定トランザクションを取得します。

    従量課金制のスナップショット

    Azure Files では、Windows ファイル サーバー上のボリューム シャドウ コピー (VSS) に似たスナップショットがサポートされています。 共有スナップショットの詳細については、「Azure Files のスナップショットの概要」を参照してください。

    スナップショットは常にライブ共有との、および他のスナップショットとの差分です。 従量課金制課金モデルでは、通常使用ストレージ メーターに従って差分サイズの合計について課金されます。 つまり、従量課金制ストレージ アカウントのスナップショットを表す独立した明細行が請求書に表示されることはありません。 これは、差分スナップショットの使用量が、従量課金制ファイル共有用に購入された予約に対してカウントされることも意味します。

    従量課金制の論理的削除

    論理的削除が有効になっているストレージ アカウント内の削除済みファイル共有については、論理的削除期間の間、その削除済みファイル共有に使用されたストレージ容量に基づいて課金されます。 論理的に削除された使用済みストレージ容量は、通常使用ストレージ メーターで測定されて報告されます。 つまり、従量課金制ストレージ アカウントの論理的削除済みファイル共有を表す独立した明細行が請求書に表示されることはありません。 これは、論理的削除済みファイル共有の使用量が、従量課金制ファイル共有用に購入された予約に対してカウントされることも意味します。

    従量課金制の課金メーター

    従量課金制課金モデルを使用して作成されたファイル共有は、次のメーターに従って課金されます。

    • 格納データ: 使用されているストレージ (GiB)。これにはライブ共有、差分スナップショット、論理的削除済みファイル共有が含まれます。
    • メタデータ: ファイルとディレクトリに関連付けられたファイル システム メタデータ、たとえばアクセス制御リスト (ACL) やその他のプロパティのサイズ (GiB)。 この課金メーターは、ホットまたはクール アクセス層のファイル共有のみに使用されます。
    • 書き込み操作: 書き込みトランザクション バケットの数 (1 バケット = 10,000 トランザクション)。
    • リスト操作: リスト トランザクション バケットの数 (1 バケット = 10,000 トランザクション)。
    • 読み取り操作: 読み取りトランザクション バケットの数 (1 バケット = 10,000 トランザクション)。
    • その他の操作 / プロトコル操作: その他トランザクション バケットの数 (1 バケット = 10,000 トランザクション)。
    • データ取得: ファイル共有から読み取られたデータの量 (GiB)。 このメーターは、クール アクセス層のファイル共有のみに使用されます。
    • geo レプリケーション データ転送: ファイル共有の冗長性が geo または geo ゾーンの場合に、ファイル共有に書き込まれてセカンダリ リージョンにレプリケートされたデータの量 (GiB)。

    格納データとメタデータの課金メーターで測定される消費は、月間ユニット数として 1 時間ごとに報告されます。 たとえば、1024 GiB が使用済みの共有の場合は、次のようになります。

    • ある 1 時間のユニット数は、次のようにその月の日数に応じて変化します。
      • 28 日の月 (うるう年ではない 2 月): 格納データ メーターに基づく値は 1.5238 ユニット。
      • 29 日の月 (うるう年の 2 月): 格納データ メーターに基づく値は 1.4713 ユニット。
      • 30 日の月: 格納データ メーターに基づく値は 1.4222 ユニット。
      • 31 日の月: 格納データ メーターに基づく値は 1.3763 ユニット。
    • ある 1 日について集計した場合は、ユニット数は次のようにその月の日数に応じて変化します。
      • 28 日の月 (うるう年ではない 2 月): 格納データ メーターに基づく値は 36.5714 ユニット。
      • 29 日の月 (うるう年の 2 月): 格納データ メーターに基づく値は 35.3103 ユニット。
      • 30 日の月: 格納データ メーターに基づく値は 34.1333 ユニット。
      • 31 日の月: 格納データ メーターに基づく値は 33.0323 ユニット。
    • 格納データ メーターの、ある月の測定量を集計した場合は 1024 ユニット。

    他のメーターで測定される消費 (たとえば書き込み操作やデータ取得) は 1 時間ごとに報告されますが、時間枠として報告されるものではないため、注意すべき特別な単位変換はありません。

    プロビジョニング/クォータ、論理サイズ、物理サイズ

    Azure Files は、共有容量に関して 3 つの異なる容量を追跡します。

    • プロビジョニング済みサイズまたはクォータ: プロビジョニング済みと従量課金制のどちらのファイル共有の場合も、そのファイル共有の拡張を許可する最大サイズをユーザーが指定します。 プロビジョニング済みファイル共有では、この値がプロビジョニング済みサイズと呼ばれます。 実際に使用する金額に関係なく、プロビジョニングした量に応じて料金が発生します。 従量課金制ファイル共有では、この値はクォータと呼ばれ、ユーザーへの請求書に直接影響することはありません。 プロビジョニング済みサイズは、プロビジョニング済みファイル共有の必須フィールドです。 従量課金制ファイル共有については、プロビジョニング済みサイズが直接指定されていない場合に、ストレージ アカウントでサポートされる最大値 (100 TiB) がその共有の既定の最大値となります。

    • 論理サイズ: ファイル共有またはファイルの論理サイズは、それがどれだけ大きいかに関連しますが、これには実際にどのように格納されているか (ストレージ最適化が適用されることもあります) は考慮されません。 ファイルの論理サイズは、別の場所にコピーした場合にネットワーク経由で転送される KiB/MiB/GiB の数です。 プロビジョニング済みと従量課金制のどちらのファイル共有でも、プロビジョニング済みサイズ/クォータの適用にはファイル共有の合計論理サイズが使用されます。 従量課金制ファイル共有では、論理サイズの数値が保存データ用使用量の課金に使用されます。 論理サイズは、ファイル/フォルダーの Windows プロパティ ダイアログでは 「サイズ」と呼ばれ、Azure Files メトリックでは 「コンテンツの長さ」 と呼ばれます。

    • 物理サイズ: ファイルの物理サイズは、ディスク上にエンコードされたファイルのサイズに対応します。 これは、ファイルの論理サイズに合わせて調整することも、オペレーティング システムによるファイルの書き込み方法に応じて小さくなる場合があります。 論理サイズと物理サイズが異なる一般的な理由は、スパース ファイルの使用によって異なります。 共有内のファイルの物理サイズはスナップショットの課金に使用されますが、割り当てられた範囲が変更されていない場合はスナップショット間で共有されます (差分ストレージ)。

    付加価値サービス

    多くのオンプレミス ストレージ ソリューションと同様に、Azure Files は、ファースト パーティ製品とサード パーティ製品が顧客所有のファイル共有と統合するための統合ポイントを提供します。 これらのソリューションは Azure Files にかなりの付加価値をもたらす可能性がありますが、これらのサービスが Azure Files ソリューションの総コストに追加する追加コストを考慮する必要があります。

    コストは、次の 3 つのバケットに分割されます。

    • 付加価値サービスのライセンス コスト。 これらは、顧客、エンドユーザー （「ヘッド コスト」と呼ばれることもある）、Azure のファイル共有やストレージ アカウントごとの固定費という形で提供されることがあります。 また、ファイル共有内のデータの 500 GiB チャンクごとの固定費など、ストレージ使用率の単位に基づく場合もあります。

    • 付加価値サービスのトランザクション コスト。 付加価値サービスの中には、選択された Azure Files 課金モデルに加えて独自のトランザクションの概念を持つものがあります。 これらのトランザクションは、付加価値サービス料金の下で請求書に表示されます。ただし、これらは、ファイル共有で付加価値サービスを使用する方法に直接関連します。

    • Azure Files では、付加価値サービスを使用するためのコストがかかります。 Azure Files では、付加価値サービスを追加するためのコストはお客様に直接課金されませんが、Azure ファイル共有に価値を追加する一環として、付加価値サービスによって Azure ファイル共有に表示されるコストが増加する可能性があります。 これは、従量課金制ファイル共有の場合はトランザクション料金が請求されるため、簡単にわかります。 付加価値サービスがユーザーに代わってファイル共有に対してトランザクションを実行する場合、ユーザーが自分で直接トランザクションを実行していない場合でも、Azure Files トランザクション請求書に表示されます。 これはプロビジョニング済みファイル共有にも当てはまりますが、わかりにくいこともあります。 プロビジョニング済みファイル共有に対する、付加価値サービスからのトランザクションはプロビジョニング済み IOPS の数値に対してカウントされます。つまり、十分な IOPS またはスループットをワークロードに利用できるようにするには、その付加価値サービスのための追加のストレージのプロビジョニングが必要になる場合があります。

    ファイル共有の総所有権コストを計算するときは、Azure Files のコストと、Azure Filesで使用するすべての付加価値サービスのコストを考慮する必要があります。

    付加価値の高いファースト パーティサービスとサード パーティ サービスが複数あります。 このドキュメントでは、お客様が Azure ファイル共有で使用する一般的なファーストパーティ サービスのサブセットについて説明します。 ここに記載されていないサービスの詳細については、そのサービスの価格ページを参照してください。

    Azure File Sync

    Azure File Sync は、1 つ以上のオンプレミスの Windows ファイル共有を Azure ファイル共有と同期する、Azure Files 用の付加価値サービスです。 クラウドの Azure ファイル共有には、オンプレミスで使用可能な同期ファイル共有にデータの完全なコピーがあるため、オンプレミスの Windows ファイル サーバーを Azure ファイル共有のキャッシュに変換して、オンプレミスのフットプリントを削減できます。 詳細については、「Azure File Sync の概要」を参照してください。

    Azure File Sync を使用してデプロイされたソリューションの総所有コストを考慮する場合は、次のコスト面を考慮する必要があります。

    • 1 つ以上のサーバー エンドポイントを持つ Windows ファイル サーバーの資本コストと運用コスト。 レプリケーション ソリューションとしての Azure File Sync は、Azure Files と同期される Windows ファイル サーバーの場所に依存しません。オンプレミス、Azure VM、さらには別のクラウドのどこでもホストできます。 Azure VM でホストされている Windows ファイル サーバーで Azure File Sync を使用している場合を除き、資本コスト (ソリューションの初期ハードウェア コスト) と運用コスト (人件費、電力など) は Azure の請求書には含まれませんが、総保有コストの非常に大きな部分であることに変わりはありません。 オンプレミスでキャッシュする必要があるデータの量、Windows ファイル サーバーで Azure File Sync のワークロードをホストするために必要な CPU の数とメモリの量 (詳しくは推奨されるシステム リソースを参照)、その他の組織固有のコストを考慮する必要があります。

    • Azure File Sync に登録されているサーバーのサーバーごとのライセンス コスト。特定の Windows ファイル サーバーで Azure File Sync を使うには、まず、Azure File Sync の Azure リソースであるストレージ同期サービスにそれを登録する必要があります。 最初のサーバーの後に登録する各サーバーについては、月額料金が一律です。 この料金は非常に小さなものですが、請求書の考慮すべき 1 つの要素です。 目的のリージョンのサーバー登録料金の現在の価格を確認するには、Azure Files の価格ページの File Sync のセクションを参照してください。

    • Azure Files のコスト。 Azure File Sync は Azure Files の同期ソリューションであるため、Azure Files リソースを使うことになります。 これらのリソースは、ストレージの消費量のように、比較的明白なものもあれば、トランザクションやスナップショットの利用のように、そうでないものもあります。 ほとんどのお客様には、Azure File Sync で Standard ファイル共有を使うことをお勧めしますが、必要であれば、Azure File Sync は Premium ファイル共有でも完全にサポートされています。

      • ストレージの使用。 Azure File Sync は、サーバー エンドポイントで指定されている Windows ファイル サーバー上のパスに対して行われた変更を Azure ファイル共有にレプリケートするため、ストレージが消費されます。 Standard ファイル共有では、これは、サーバー エンドポイント上の既存のファイルの数やサイズが増えると、変更がレプリケートされるため、ストレージ コストが増加することを意味します。 Premium ファイル共有では、変更があるとプロビジョニング済みの領域が消費されます。お客様は、ファイル共有の拡大に対応し、必要に応じて、プロビジョニングを定期的に増やす必要があります。

      • スナップショットの使用。 Azure File Sync は、通常の使用の一環として、共有とファイル レベルのスナップショットを取得します。 スナップショットの使用は常に差分ですが、Azure Files の合計請求額に顕著な影響を与える可能性があります。

      • チャーンからのトランザクション。 サーバー エンドポイントでファイルが変更されると、変更がクラウド共有にアップロードされ、トランザクションが生成されます。 クラウドを使った階層化を有効にすると、エグレス コストに加え、階層化されたファイルで発生する I/O など、階層化されたファイルを管理するための追加のトランザクションが生成されます。 チャーンのレートとキャッシュの効率のため、トランザクションの量と種類を予測するのは困難ですが、将来の使用状況が現在の使用状況と似ていると思われる場合は、以前のトランザクション パターンを使用して、将来のコストを見積もることができます。

      • クラウド列挙からのトランザクション。 Azure File Sync はクラウド内の Azure ファイル共有を 1 日に 1 回列挙して、サーバー エンドポイントと同期できるよう、共有に直接加えた変更を検出します。 このスキャンでは、1 日に 1 ディレクトリあたり 1 回の ListFiles トランザクションの割合で、ストレージ アカウントに請求されるトランザクションが生成されます。 この数値を料金計算ツールに入力して、スキャン コストを見積もることができます。

      ヒント

      フォルダーの数が不明な場合は、JAM Software GmbH の TreeSize ツールをぜひご利用ください。

    Azure Backup

    Azure Backup は、ファイル共有や Azure File Sync などの他の付加価値サービスとシームレスに統合される Azure Files 用のサーバーレス バックアップ ソリューションを提供します。Azure Files の Azure Backup はスナップショット ベースのバックアップ ソリューションで、Azure Backup は、管理者が定義したスケジュールに基づいてスナップショットを自動的に作成するためのスケジュール メカニズムを提供します。 また、削除されたファイルやフォルダー、または共有全体を特定の時点に復元するためのユーザーにわかりやすいインターフェイスも提供します。 詳細については、「Azure ファイル共有のバックアップについて」を参照してください。

    Azure Backup を使用するコストを検討する場合は、次の点を考慮する必要があります。

    • Azure ファイル共有データの保護されたインスタンスのライセンス コスト。 Azure Backup では、バックアップされた Azure ファイル共有を含むストレージ アカウントごとに、保護されたインスタンスのライセンス コストが課金されます。 保護されたインスタンスは、250 GiB の Azure ファイル共有ストレージとして定義されます。 250 GiB 未満を含むストレージ アカウントには、わずかな保護されたインスタンスのコストが適用されます。 詳細については、「Azure Backup の価格」をご覧ください。 Azure Backup が保護できるサービスのリストから Azure Files を選択する必要があります。

    • Azure Files のコスト。 Azure Backup では、次のように Azure Files のコストが増加します。

      • Azure ファイル共有スナップショットからの差額コスト。 Azure Backup は、管理者が定義したスケジュールで Azure ファイル共有スナップショットの作成を自動化します。 スナップショットは常に差分ですが、どれだけのコストが追加されるかは、スナップショットが保持される時間の長さと、その時間におけるファイル共有でのチャーンの量によって決まります。 このことは、スナップショットがライブ ファイル共有と比較してどれだけ異なるか、したがってどれだけの追加データが Azure Files によって保存されるかを左右します。

      • 復元操作によるトランザクション コスト。 スナップショットからライブ共有に復元する操作では、トランザクションが発生します。 標準ファイル共有の場合は、スナップショットからの読み取り/リストアからの書き込みは、通常のファイル共有トランザクションとして課金されます。 プロビジョニング済みファイル共有の場合は、これらの操作は、そのファイル共有のプロビジョニング済み IOPS に対してカウントされます。

    Microsoft Defender for Storage

    Microsoft Defender は、Microsoft Defender for Storage 製品の一部として Azure Files のサポートをサポートしています。 Microsoft Defender for Storage は、SMB または FileREST 経由で Azure ファイル共有にアクセスしたり、悪用したりしようとする、異常で潜在的に有害な試みを検出します。 Microsoft Defender for Storage は、そのサブスクリプション内のストレージ アカウント内のすべてのファイル共有のサブスクリプション レベルで有効になります。

    Microsoft Defender for Storage は、Azure ファイル共有のウイルス対策機能をサポートしていません。

    Microsoft Defender for Storage からの主なコストは、Azure ファイル共有に対して実行されるトランザクションに加えてこの製品から課金される一連の追加トランザクション コストです。 これらのコストは Azure Files で発生したトランザクションに基づいていますが、Azure Files の課金の一部ではなく、むしろMicrosoft Defender の価格の一部です。 Microsoft Defender for Storage のトランザクション料金は、プロビジョニング済みファイル共有 (Azure Files の IOPS プロビジョニングの一部としてトランザクションが含まれています) の場合も課金されます。 現在のトランザクション レートは、Microsoft Defender for Cloud の価格ページの Microsoft Defender for Storage テーブル行で確認できます。

    トランザクションの負荷の高いファイル共有では、Microsoft Defender for Storage を使用すると、大きなコストが発生します。 これらのコストに基づいて、特定のストレージ アカウントの Microsoft Defender for Storage をオプトアウトすることができます。 詳細については、「ストレージ保護のために Microsoft Defender からストレージ アカウントを除外する」を参照してくださ。

    Reservations

    Azure Files では、予約 ("予約インスタンス" とも呼ばれます) がプロビジョニング済み v1 モデルと従量課金制モデルでサポートされます。 予約を利用すると、ストレージ利用を事前に確約することによってストレージ料金の割引が受けられます。 一定して負荷がかかる業務用のワークロードや開発/テスト用ワークロードでは、予約インスタンスの購入をご検討ください。 予約を購入するときは、次のディメンションを指定する必要があります。

    • 容量のサイズ: 予約できるサイズは 10 TiB か 100 TiB です。容量予約が大きい方が大きな割引を受けられます。 複数の予約容量を購入することもできます。その場合、ワークロードの条件に合わせて、サイズの異なる容量を組み合わせられます。 たとえば、製品のデプロイに 120 TiB のファイル共有を使用する場合、100 TiB 1 つと 10 TiB 2 つを予約すれば、必要なストレージ容量をカバーできます。
    • 期間: 1 年または 3 年の期間で予約を購入できます。予約期間が長い方が大きな割引を受けられます。
    • レベル: 予約ができる Azure Files のレベル。 予約を利用できる層は、現時点ではプレミアム (SSD)、ホット (HDD)、クール (HDD) です。
    • 場所: 予約ができる Azure リージョン。 予約は、一部の Azure リージョンでご利用いただけます。
    • 冗長性: 予約ができるストレージの冗長性。 容量予約は、LRS、ZRS、GRS、GZRS など、Azure Files でサポートしているすべての冗長性に対応しています。
    • 請求頻度: アカウントが予約に対して課金される頻度を示します。 オプションには [月 1 回] または [前払い] があります。

    購入した予約は、既存のストレージを使うことで自動的に使用されます。 予約した以上のストレージを使用した場合、予約でカバーされていない分は定価で請求されます。 トランザクション、帯域幅、データ転送、およびメタデータ ストレージの料金は予約に含まれていません。

    Azure ファイル共有スナップショットに関する予約の動作は、従量課金制ファイル共有とプロビジョニング済み v1 ファイル共有とで異なります。 従量課金制ファイル共有のスナップショットを取る場合は、スナップショット差分が予約に対してカウントされ、通常使用ストレージ メーターの一部として課金されます。 しかし、プロビジョニング済み v1 ファイル共有のスナップショットを取る場合は、スナップショットの課金に別のメーターが使用されます。また、予約に対してカウントされることはありません。

    予約購入の詳しい方法は、「予約を使用して Azure Files のコストを最適化する」を参照してください。

    関連項目