Azure Files の課金について

  • [アーティクル]

Azure Files には、プロビジョニングと従量課金制という 2 つの異なる課金モデルが用意されています。 プロビジョニング モデルは Premium ファイル共有でのみ使用できます。これは、FileStorage ストレージ アカウントの種類でデプロイされたファイル共有です。 従量課金制モデルは Standard ファイル共有でのみ使用できます。Standard ファイル共有は、汎用バージョン 2 (GPv2) ストレージ アカウントの種類でデプロイされたファイル共有です。 この記事では、Azure Files の毎月の請求書を理解できるように、両方のモデルがどのように機能するかについて説明します。

このビデオは、Azure Files 課金モデルの基本について説明するインタビューです。 ここでは、Azure ファイル共有のコストを最適化する方法と、オンプレミスおよびクラウドの他のファイル ストレージ オファリングと Azure Files を比較する方法を説明しています。

Azure Files の価格については、「Azure Files の料金」ページを参照してください。

適用対象

ファイル共有の種類 SMB NFS
Standard ファイル共有 (GPv2)、LRS/ZRS はい いいえ
Standard ファイル共有 (GPv2)、GRS/GZRS はい いいえ
Premium ファイル共有 (FileStorage)、LRS/ZRS はい はい

ストレージ ユニット

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 では、プレミアム か スタンダード のファイル共有を展開するかどうかにより異なる課金モデルを使用します。 ほどんどのクラウド ソリューションは、ストレージのプロビジョニング (価格決定方式、シンプル) と従量課金制ストレージ (実際の使用量に応じて課金されるため、コストを最適化できる) のどちらかを前提としたモデルを採用しています。 プロビジョニングの課金モデルで重要なのは、プロビジョニングする共有の最小サイズ、プロビジョニングの単位、プロビジョニングの増減機能です。

  • ストレージ コストを最適化する方法はありますか? 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 に対してバックアップ、レプリケーション、キャッシュ、セキュリティ機能が提供されます。 付加価値ソリューションには、オンプレミスかクラウドかにかかわらず、独自のライセンス コストと製品コストがあり、通常、ファイル ストレージの総所有コストの一部として考慮されます。

Reservations

Azure Files では予約 (予約インスタンスとも呼ばれます) の利用がサポートされており、ストレージ利用の契約を事前に行うことで割引が受けられます。 一定して負荷がかかる業務用のワークロードや開発/テスト用ワークロードでは、予約インスタンスの購入をご検討ください。 予約を購入するときは、次のディメンションを指定する必要があります。

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

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

Standard ファイル共有と Premium ファイル共有の Azure ファイル共有スナップショットでは、予約のしくみに違いがあります。 Standard ファイル共有のスナップショットを取得する場合、スナップショットの差分は予約に対してカウントされ、通常の使用済みストレージ メーターの一部として課金されます。 しかし、Premium ファイル共有のスナップショットを取得する場合、スナップショットは別のメーターを使用して課金され、予約に対してカウントされません。 詳細については、「スナップショット」を参照してください。

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

プロビジョニング モデル

Azure Files では、Premium ファイル共有にプロビジョニング モデルが使用されます。 プロビジョニング課金モデルでは、使用量に基づいて請求されるのではなく、ストレージ要件を事前に指定します。 ストレージのプロビジョニング モデルは、オンプレミス ストレージ ソリューションを購入するのに似ています。これは、一定のストレージ容量がある Azure ファイル共有をプロビジョニングした場合に、そのストレージ容量を使用するかどうかに関係なく、そのストレージ容量に対して支払いを行うためです。 オンプレミスの物理メディアを購入する場合とは異なり、プロビジョニング ファイル共有は、ストレージと IO のパフォーマンス特性に応じて動的にスケールアップまたはスケールダウンすることができます。

プロビジョニングされたファイル共有のサイズはいつでも引き上げることができますが、引き下げは、最後の引き上げから 24 時間が経過した場合にのみ行うことができます。 クォータの拡大なしで 24 時間経過した後は、再び拡大するまで、共有クォータを何回でも縮小できます。 IOPS/スループットのスケールの変更は、プロビジョニングされたサイズの変更後、数分以内に有効になります。

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

プロビジョニング方法

Premium ファイル共有をプロビジョニングするときは、ワークロードに必要な GiB 数を指定します。 プロビジョニングする GiB ごとに、固定比率で追加の IOPS とスループットを使用できるようになります。 保証されているベースライン IOPS に加えて、各 Premium ファイル共有はベスト エフォート ベースでバーストをサポートしています。 IOPS とスループットの数式は次のとおりです。

Item 値
ファイル共有の最小サイズ 100 GiB
プロビジョニングの単位 1 GiB
ベースライン IOPS 式 MIN(3000 + 1 * ProvisionedStorageGiB, 102400)
バースト限度 MIN(MAX(10000, 3 * ProvisionedStorageGiB), 102400)
バースト クレジット (BurstLimit - BaselineIOPS) * 3600
スループット レート (イングレス + エグレス) (MiB/秒) 100 + CEILING(0.04 * ProvisionedStorageGiB) + CEILING(0.06 * ProvisionedStorageGiB)

次の表は、プロビジョニングされた共有サイズについてのこれらの式の例をいくつか示しています。

容量 (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 サイズ、並列処理の影響を受けます。 並列処理の利点を最大限に活用するために、Premium ファイル共有で SMB マルチチャネルを有効にすることをお勧めします。 よくあるパフォーマンスの問題と回避策については、SMB パフォーマンスとパフォーマンスのトラブルシューティング ガイドに関するページを参考にしてください。

バースト

ピーク時の需要に対応するためにワークロードで追加のパフォーマンスが必要な場合、バースト クレジットを使用してファイル共有のベースライン IOPS の限度を超えることができます。 バーストは自動化され、クレジット システムに基づいて動作します。 バーストはベスト エフォート型のサービスであり、最大値の実現を保証していません。

クレジットは、ファイル共有のトラフィックがベースライン IOPS を下回るたびに、バースト バケットに蓄積されます。 獲得クレジットは、操作がベースライン IOPS を超えたときにバーストを有効にするために後で使用されます。

共有は、ベースライン IOPS を超えてバースト バケット内にクレジットが発生するたびに、許可される最大ピーク バースト率までバーストします。 共有では、クレジットが残っている限りバーストを継続でき、ここでいうクレジットは累積バースト クレジットを指します。 ベースライン IOPS を超えた IO のそれぞれが 1 つのクレジットを消費します。 すべてのクレジットが消費されると、共有はベースライン IOPS に戻ります。

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

  • 蓄積中 (ファイル共有が使用している量がベースライン IOPS より少ない場合)。
  • 減少中 (ファイル共有がベースライン IOPS より多く使用しており、バースト モードである場合)。
  • 一定 (ファイル共有がちょうどベースライン IOPS を使用していて、クレジットが発生したり、使用されたりしていない場合)。

新しいファイル共有は、そのバースト バケットに全数のクレジットが含まれると開始されます。 サーバーによる調整のために共有 IOPS がベースラインを下回った場合、バースト クレジットは発生しません。

従量課金制モデル

Azure Files には、Standard ファイル共有に従量課金制課金モデルが使用されます。 このモデルの場合、支払う金額は、プロビジョニングされた量ではなく、実際に使用する量によって決まります。 大まかに言えば、格納されている論理データの量に対するコストを支払い、そのデータの使用状況に基づくトランザクションに対しても課金されます。 従量課金制モデルの方がコスト効率が良くなる可能性があります。なぜなら、将来の成長、パフォーマンスの要件、パフォーマンス要件を考慮して、過剰なプロビジョニングを行う必要がないためです。 また、ワークロードとデータ フットプリントが時間の経過と同時に変化する場合でも、プロビジョニングを解除する必要はありません。 一方、従量課金制の課金モデルはエンドユーザーの使用量によって決まるため、予算編成プロセスの一環として従量課金制モデルを計画することが困難な場合があります。

Standard レベルの相違点

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

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

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

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

ワークロードとアクティビティ レベルによって、標準ファイル共有の最もコスト効率の高い層が決まります。 実際のところ、最もコスト効率の高い層を選択する最善の方法は、共有の実際のリソース消費量 (格納データ、トランザクションの書き込みなど) を調べることです。 Standard ファイル共有の場合は、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 は、プロビジョニングされた課金モデルを使用するPremium ファイル共有でのみ使用できます。 トランザクションは、Premium ファイル共有の課金には影響しません。

Standard レベル間の切り替え

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

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

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

次の表は、層の移動のコストの内訳を示しています。

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

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

    Premium ファイル共有と Standard ファイル共有は異なるストレージ アカウントの種類に含まれているため、その間を移動する直接のメカニズムはありませんが、robocopy などのコピー ツールを使用して、Premium ファイル共有と Standard ファイル共有の間を移動できます。

    レベルの選択

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

    Standard フファイル共有ではストレージ アカウント レベルでのみトランザクション情報が表示されるため、ストレージ メトリックを使用して、ファイル共有レベルで、どのレベルが安いかを推定するのは科学的に不十分です。 可能であれば、各ストレージ アカウントに 1 つのファイル共有のみをデプロイして、課金を完全に可視化することをお勧めします。

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

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

    Note

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

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

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

    • プロビジョニングされたサイズまたはクォータ: Premium ファイル共有と標準ファイル共有の両方で、ファイル共有の拡張を許可する最大サイズを指定します。 Premium ファイル共有では、この値はプロビジョニングされたサイズと呼ばれます。 実際に使用する金額に関係なく、プロビジョニングした量に応じて料金が発生します。 Standard ファイル共有では、この値はクォータと呼ばれ、請求書に直接影響しません。 プロビジョニングされたサイズは、Premium ファイル共有の必須フィールドです。 標準ファイル共有の場合、プロビジョニングされたサイズが直接指定されていない場合、共有はデフォルトでストレージ アカウントでサポートされる最大値になります。

    • 論理サイズ: ファイル共有またはファイルの論理サイズは、実際にどのように保存されているかを考慮せずに、そのサイズに対応し、追加の最適化が適用される場合があります。 ファイルの論理サイズは、別の場所にコピーした場合にネットワーク経由で転送される KiB/MiB/GiB の数です。 Premium ファイル共有と Standard ファイル共有の両方で、プロビジョニングされたサイズ/クォータに対する適用に使用されるのが、ファイル共有の合計論理サイズです。 Standard ファイル共有では、論理サイズは、保存データ使用量の課金に使用される数量です。 論理サイズは、ファイル/フォルダーの Windows プロパティ ダイアログでは 「サイズ」と呼ばれ、Azure Files メトリックでは 「コンテンツの長さ」 と呼ばれます。

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

    スナップショット

    Azure Files では、Windows ファイル サーバー上のボリューム シャドウ コピー (VSS) に似たスナップショットがサポートされています。 スナップショットは常にライブ共有と相互に区別されます。つまり、各スナップショットの違いに対してのみいつも料金が発生します。 共有スナップショットの詳細については、「Azure Files のスナップショットの概要」を参照してください。

    スナップショットはファイル共有サイズの制限にはカウントされませんが、スナップショットの数は特定の数に制限されます。 現在のスナップショットの制限を確認するには、「Azure ファイル共有スケール ターゲット」を参照してください。

    スナップショットは常に各スナップショットの差分ストレージ使用率に基づいて課金されます。 ただし、Premium ファイル共有と Standard ファイル共有で若干異なります。

    • Premium ファイル共有では、スナップショットは独自のスナップショット メーターに対して課金され、プロビジョニングされたストレージ価格よりも価格が引き下げられます。 つまり、請求書には、各 FileStorage ストレージ アカウントのPremium ファイル 共有のスナップショットを表す個別の行項目が表示されます。

    • Standard ファイル共有では、スナップショットは通常使用されるストレージ 測定の一部として課金されますが、スナップショットの差分コストに対してのみ課金されます。 つまり、Azure ファイル共有を含む各標準ストレージ アカウントのスナップショットを表す個別の行項目が請求書に表示されません。 これは、スナップショットの差分使用量が、Standard ファイル共有用に購入された予約に対してカウントされることも意味します。

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

    付加価値サービス

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

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

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

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

    • Azure Files では、付加価値サービスを使用するためのコストがかかります。 Azure Files では、付加価値サービスを追加するためのコストはお客様に直接課金されませんが、Azure ファイル共有に価値を追加する一環として、付加価値サービスによって Azure ファイル共有に表示されるコストが増加する可能性があります。 これは、標準ファイル共有にはトランザクション料金を含む従量課金制モデルがあるため、標準のファイル共有では簡単に確認できます。 付加価値サービスがユーザーに代わってファイル共有に対してトランザクションを実行する場合、ユーザーが自分で直接トランザクションを実行していない場合でも、Azure Files トランザクション請求書に表示されます。 これは Premium ファイル共有にも当てはまりますが、目立たない場合があります。 付加価値サービスからの Premium ファイル共有に対する追加のトランザクションは、プロビジョニングされた 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 File Sync を使用して Azure Files のコストを最適化するには、ファイル共有のレベルを考慮する必要があります。 各ファイル共有のレベルを選択する方法の詳細については、「ファイル共有レベルの選択」を参照してください。

    StorSimple から Azure File Sync に移行する場合は、「StorSimple と Azure File Sync のコストの比較」を参照してください。

    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 によって保存される追加データの量が決まります。

      • 復元操作によるトランザクション コスト。 スナップショットからライブ共有に復元する操作では、トランザクションが発生します。 標準ファイル共有の場合、スナップショットからの読み取り/リストアからの書き込みは、通常のファイル共有トランザクションとして課金されます。 Premium ファイル共有の場合、これらの操作は、ファイル共有のプロビジョニングされた 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 からストレージ アカウントを除外する」を参照してくださ。

    関連項目