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

Azure Files では、SSD と HDD の 2 つの異なるメディア層がサポートされています。 これにより、シナリオのパフォーマンスと価格の要件に合わせてファイル共有を調整できます。

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

Azure Files には、プロビジョン済みオプションや従量課金制オプションを含む、複数の価格モデルがあります。

• プロビジョニング済み課金モデル: プロビジョニングされた課金モデルでは、ファイル共有の主なコストは、ストレージの量、IOPS (1 秒あたりの入力操作と出力操作)、およびファイル共有の作成時または更新時にプロビジョニングするスループットに基づきます。 実際に使用する金額に関係なく、プロビジョニングした内容に基づいて支払います。 Azure Files には、 プロビジョニングされた v2 とプロビジョニングされた v1 という 2 つの異なる プロビジョニング済みモデルがあります。

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

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

この記事では、Azure Files の課金モデルがどのように機能するかについて説明します。これにより、毎月の Azure Files の課金内容を理解しやすくなります。 Azure Files の価格については、「Azure Files の料金」ページを参照してください。

適用対象

管理モデル	課金モデル	メディア階層	冗長性	中小企業	ネットワークファイルシステム（NFS）
Microsoft.Storage	プロビジョニング済み v2	HDD (標準)	ローカル (LRS)
Microsoft.Storage	プロビジョニング済み v2	HDD (標準)	ゾーン (ZRS)
Microsoft.Storage	プロビジョニング済み v2	HDD (標準)	geo (GRS)
Microsoft.Storage	プロビジョニング済み v2	HDD (標準)	ジオゾーン (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 (標準)	ジオゾーン (GZRS)

ストレージ ユニット

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

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

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

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

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

オンプレミスから 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 の数と必要なスループットに関する推奨事項が提供されます。 これは、指定したプロビジョニング済みストレージの量に基づいて計算されます。 これらの推奨事項は、選択したメディア層のプロビジョニング済みストレージの量に対する一般的な顧客の使用状況に基づいています。 ただし、ワークロードで "一般的なファイル共有" よりも多かれ少なかれ IOPS とスループットが必要である場合があります。この場合、必要に応じて、個々のファイル共有の要件に応じて、多かれ少なかれ IOPS とスループットをプロビジョニングできます。

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

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

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

• すべての Azure パブリック クラウド リージョン。
• すべての Azure US Government クラウド リージョン。

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

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

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

個々のファイル共有の要件によっては、推奨事項よりも多かれ少なかれ 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 つのファイル共有が持てるクレジットの数の特定には、次の数式が使用されます。

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

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

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

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

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

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

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

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

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

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

プロビジョニングされた v2 課金メーターに対する消費単位は、1 時間ごとに出力されます。 たとえば、1,024 GiB がプロビジョニングされた共有の場合、次の内容が表示されます。

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

プロビジョニング済み v2 への移行

SMB Azure ファイル共有を従量課金制モデルからプロビジョニング済み v2 課金モデルに移行するプロセスは、Azure File Sync を使用しているかどうかによって異なります。

• Azure File Sync を使用せずに Azure Files をしている場合は、「ある SMB Azureファイル共有から別のファイル共有にファイルを移行する」を参照してください。
• Azure File Sync を使用している場合は、「Azure File Sync を使用するときに、ある Azure ファイル共有から別の Azure ファイル共有にファイルを移行する」を参照してください。

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

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

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

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

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

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

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

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

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

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

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

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

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

プロビジョニングされた v1 モデルでは、クレジット ベースのバースト (プロビジョニングの一部として無料で含まれる) と 有料バーストの 2 種類がサポートされています。これは、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 つのファイル共有が持てるクレジットの数の特定には、次の数式が使用されます。

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

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

有料バーストは、調整されたくないお客様をサポートするように設計された、プロビジョニング済み v1 モデルの高度な機能です。 有料バーストでは、プロビジョニングされたストレージを超える任意の量の IOPS またはスループットに対して、使用量ベースの課金が追加されます。 これは、プロビジョニング済みストレージの一部として無料で提供されるクレジットベースのバーストとは異なります。 有料バーストを使用すると、ファイル共有をプロビジョニングする方法に強力な柔軟性が追加されますが、誤って使用した場合に予期しない課金が発生する可能性もあります。

クレジット ベースのバーストと同様に、有料バーストは、適切な量の IOPS とスループットをプロビジョニングするための代替ではありません。 むしろ、予期せぬ需要が発生した場合にスロットリングに対する保護を強化するものです。 一貫したレベルの IOPS またはスループットの使用量がある場合は、有料バーストに依存する代わりに、需要をカバーするのに十分な IOPS とスループットを (ストレージ プロビジョニングを通じて) プロビジョニングする方が安価です。

有料バーストは既定では無効になっていますが、 プロビジョニングされた v1 ファイル共有のコストとパフォーマンスの特性を変更 する手順に従って有効にすることができます (PowerShell と CLI のみ)。 有料バーストが有効になっている場合は、Azure Monitor で使用可能な次のメトリックを使用して、IOPS とスループットの使用状況を慎重に監視することをお勧めします。

• ファイル共有のプロビジョニングされた IOPS
• ファイル共有のプロビジョニング済み帯域幅 MiB/秒 (スループット)
• Max IOPS によるトランザクション
• MiB/秒（スループット）での最大帯域幅
• IOPS のバースト クレジット (クレジットベースのバースト)
• 有料バースト IOS (IO)
• 有料バースト帯域幅

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

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

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

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

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

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

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

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

プロビジョニングされた v1 課金メーターで測定される消費データは、月単位として1時間ごとに送信されます。 たとえば、1,024 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 プロビジョニング済みメーターの、ある月の測定量を集計した場合は 1,024 ユニット。

従量課金制モデル

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

従量課金制の提供状況

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

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

アクセス層の違い

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

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

ユース ケースに適したアクセス層を選択すると、コストを大幅に縮小できます。 アクセス頻度の低いワークロードをトランザクション最適化アクセス層に配置すると、共有に対して取引を行うのが月に数回しかないため、その費用はごくわずかです。 ただし、データ ストレージのコストに対して高い金額を支払います。 この同じ共有をクール アクセス層に移動した場合も、トランザクション コストの支払いは 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 つの異なるトランザクション カテゴリにグループ化されます。 これらのカテゴリは、書き込み、一覧表示、読み取り、その他、削除です。

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

アクセス層の切り替え

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

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

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

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

ファイル共有のアクセス層は、30 日以内に最大 5 回変更できます。 30 日間のウィンドウの最初の日は、最初のレベルの変更が発生したときに開始されます。 アクセス層間の変更はすぐに行われますが、共有のアクセス層を変更すると、過去 30 日以内にアクセス層プロパティを 5 回未満に変更した場合でも、24 時間以内に再度変更することはできません。

アクセス層の選択

既存のデータを Azure Files に移行する方法に関係なく、最初にトランザクション最適化アクセス層でファイル共有を作成することをお勧めします。 これは、移行中に発生するトランザクションの数が多いためです。 移行が完了し、定期的な使用で数日間または数週間運用した後、トランザクション数を 料金計算ツール に接続して、ワークロードに最適なアクセス層を判断できます。

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

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

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

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

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 時間ごとに出力されます。 たとえば、1,024 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 ユニット。
• 格納データ メーターの、ある月の測定量を集計した場合は 1,024 ユニット。

他のメーターで測定される消費 (たとえば書き込み操作やデータ取得) は 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 バックアップ

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 からストレージ アカウントを除外する」を参照してくださ。

予約

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

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

予約を購入すると、既存のストレージ使用率によって自動的に消費されます。 予約済みよりも多くのストレージを使用する場合は、予約の対象ではない残高の定価を支払います。 トランザクション、帯域幅、データ転送、およびメタデータ ストレージの料金は予約に含まれていません。

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

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

関連項目

• Azure Files の価格
• 「Azure Files のデプロイの計画」と「Azure File Sync のデプロイの計画」。
• 「ファイル共有を作成する」と「Azure File Sync のデプロイ」。