了解 Azure 檔案儲存體的計費方式

本文將幫助你了解 Azure 檔案儲存體 的不同計費模式，讓你能管理成本並確定總擁有成本。 價格資訊請參見 Azure 檔案儲存體 pricing。

確定 Azure 檔案儲存體 部署的成本

決定 Azure 檔案儲存體 部署成本的四大關鍵因素：計費模式、媒體層級、冗餘選項與資源模型。

計費模型

Azure 檔案儲存體 支援三種不同的計費模式：預備 v2、provisioned v1 以及按使用量付費。

  • 配置 v2：一種配置式計費模式，您可以分別配置儲存、IOPS 和吞吐量。 無論您實際使用多少，您都會根據佈建的內容支付費用。 所有新的 Azure 檔案儲存體 部署都使用預設化的 v2 模型。
  • 佈建 v1：佈建計費模型，您可以在其中佈建所需的儲存量，而 IOPS 和輸送量則取決於您佈建的儲存量。 除非你有特別理由使用已配置的 v1 模型，否則建議使用已配置的 v2 模型。
  • 隨用隨付：基於使用量的計費模型，費用將根據您使用檔案共用的程度來決定，包含已使用儲存體、交易及資料傳輸成本等形式。 除非你有明確理由使用隨用隨付模型，否則請使用已佈建的 v2 模型。

此影片提供各種 Azure 檔案儲存體計費模型之間差異的完整概觀，包括隨用隨付、佈建的 v1 和佈建的 v2。

這段影片深入探討 Azure 檔案服務布建 v2 計費模型，並提供設定指示和建議，以降低總擁有成本。

媒體分層

Azure 檔案儲存體 支援兩種不同的媒體儲存層級：固態硬碟（SSD）與硬碟硬碟（HDD）。 這項支援讓您能根據情境的效能與價格需求，調整檔案共享。

  • SSD（高級）：以 SSD 為主機的檔案分享提供穩定的高效能與低延遲，大多數 IO 操作延遲僅為個位數毫秒。
  • HDD（標準）：存放於 HDD 上的檔案共享，提供具成本效益的一般用途儲存空間。

備援選項

Azure 檔案儲存體 支援四種不同的冗餘選項，你可以用來控制資料的備份數量，以及這些備份在 Azure 基礎設施中的位置。 更耐用的選項提供更高的耐用性與可用性，但代價較高：

  • 本地冗餘儲存（LRS）會在 同一區域的單一資料中心內保存三份資料副本。
  • 區域冗餘儲存（ZRS）會在 一個區域內的獨立資料中心（可用性區域）中儲存三份資料副本。
  • 地理冗餘儲存（GRS） 在主要區域儲存三份資料，並以非同步方式複製至配對區域，總共六份。 僅適用於 HDD 儲存設備。
  • 地理區域冗餘儲存（GZRS）結合 了主區域的區域冗餘與非同步複製至次要區域。 僅適用於 HDD 儲存設備。

資源模型

Azure 檔案儲存體 支援兩種不同的頂層資源類型，這些都是你在 Azure 訂閱和資源群組中建立和管理的項目。 每個資源類型都支援略有不同的計費模型選項，這反過來又會影響成本和成本結構：

  • 儲存體帳戶 代表儲存體、IOPS 和輸送量的共用集區，您可以在其中部署 傳統檔案共用 或其他儲存體資源，視儲存體帳戶類型而定。 儲存體帳戶支援所有計費模型、媒體層和備援選項。 你部署到儲存帳號的所有儲存資源，都會共享該儲存帳號的限制。 傳統檔案共用同時支援 SMB 和 NFS 通訊協定、但 NFS 僅支援 SSD 儲存設備。 Microsoft.Storage 資源提供者提供儲存帳號，你可以在這些儲存帳號內建立經典檔案分享。

  • 檔案共享是一種新的頂層資源類型，透過消除建立儲存帳號，簡化了Azure檔案共享的部署。 檔案共用僅支援建議的佈建v2模型、且僅支援具有NFS檔案系統通訊協定的SSD媒體層。 Microsoft.FileShares 資源提供者提供檔案分享作為頂層資源。

Azure 檔案儲存體 儲存單位

Azure 檔案儲存體使用二進位的測量單位來代表儲存容量：KiB、MiB、GiB 和 TiB。

縮略字 Definition 單位
KiB 1,024 個位元組 kibibyte
MiB 1,024 KiB (1,048,576 個位元組) mebibyte
GiB 1,024 MiB (1,073,741,824 個位元組) gibibyte
TiB 1,024 GiB (1,099,511,627,776 個位元組) tebibyte

大多數作業系統和工具使用以2進位為單位來衡量儲存量。 不過，他們經常把這些單位誤標為你比較熟悉的十進制單位：KB、MB、GB 和 TB。 許多作業系統錯誤標示儲存單元，因為他們在國際電工委員會（IEC）、國際度量衡局（BIPM）及美國國家標準技術研究院（NIST）標準化之前就已開始使用這些縮寫。

下表顯示常見的作業系統如何測量和標記儲存體：

操作系統 測量系統 標籤化
窗戶 2 進位 一致錯誤標記為 10 進位。
Linux 發行版 通常使用二進位，有些軟體使用十進位。 標籤不一致，測量和標籤的對齊方式取決於軟體套件。
macOS、iOS 和 iPad OS 10 進位 以一致方式標示為 10 進位。

如果你的作業系統沒在清單上，請向你的作業系統供應商確認。

檔案共用擁有權總成本的檢查清單

如果您是從本地遷移到 Azure 檔案儲存體，或是將 Azure 檔案儲存體 與其他雲端儲存方案比較，請考慮以下因素以確保公平且直接的比較：

  • 您為儲存體、IOPS 和頻寬支付了多少費用？ 大部分的雲端解決方案都有符合布建 記憶體原則的模型，例如價格決定性和簡單性，或隨用隨 付記憶體，其只需為您實際使用的內容收費，即可將成本優化。 佈建的計費模型可能因最小的佈建共用大小、佈建單位，以及增加和減少佈建的能力而有所不同。

  • 是否有任何方法可將儲存體成本最佳化呢？ 您可以使用Azure 檔案儲存體 保留來獲得儲存空間高達 36% 的折扣。 其他解決方案可能會採用重複數據刪除或壓縮等策略，選擇性地將儲存效率優化。 不過，這些儲存體優化策略通常會有非貨幣成本，例如降低效能。 Azure 檔案預留對效能沒有副作用。

  • 如何實現儲存體復原和備援？ 透過 Azure 檔案儲存體，產品中提供的功能包含儲存復原能力和冗餘。 所有層級和備援層級都可確保資料具有高可用性，而且至少有三份資料複本可供存取。 考慮其他檔案儲存選項時，請思考是否內建儲存的復原能力和備援性，還是需要您自行組裝。

  • 您需要管理什麼？ Azure 檔案服務是完全受控的解決方案。 其他解決方案可能需要作系統更新或管理虛擬資源，例如 VM、磁碟和網路 IP 位址。

  • 增值產品的成本為何？ Azure 檔案服務支援與多個第一方和第三方 增值服務的整合。 Azure 備份、Azure 檔案同步 和 Microsoft Defender for Storage 等增值服務提供備份、復寫和快取，以及 Azure 檔案儲存體 的安全性功能。 無論是內部部署或雲端中的加值解決方案，均具備自己的授權和產品成本，但經常視為檔案儲存體擁有權總成本的一部分。

已佈建的 v2 模型

Azure 檔案服務布建的 v2 模型結合總持有成本的可預見性與彈性，讓您能建立符合您確切儲存和效能需求的檔案共用。 當您建立新的佈建 v2 檔案共享時，您可以指定檔案共用所需的記憶體、IOPS 和輸送量。 您提供的每個數量都會影響您的總帳單金額。

您布建的記憶體、IOPS 和輸送量是檔案共用使用量的保證限制。 舉例來說，如果你配置了一個 2 TiB 的共享，並上傳了 2 TiB 的資料到你的共享資料夾，你的共享就是滿的。 除非你擴大份額或刪除部分資料，否則無法新增更多資料。 額度型 IOPS 高載會儘可能增加使用量的彈性，同時額度維持不變。

你可以根據需求變化動態擴充或縮小配置的儲存空間、IOPS 和吞吐量。 然而，您只能在自上次增加數量起超過24小時後減少配置的數量。 布建變更后的幾分鐘內，記憶體、IOPS 和輸送量變更就會生效。

預設情況下，當你使用已配置的 v2 模型建立新的檔案分享時，系統會建議你需要多少 IOPS 和多少吞吐量。 此建議是根據您指定的配置儲存量計算。 這些建議是以您所選擇的媒體層布建記憶體數量的典型客戶使用量為基礎。 不過，您可能會發現工作負載需要比「一般檔案共用」更多的或更少 IOPS 和輸送量。在此情況下，視個別檔案共用需求而定，您可以選擇性地布建或減少 IOPS 和輸送量。

已佈建的 v2 可用性

佈建的 v2 模型適用於下列媒體層、備援和檔案共用通訊協定的組合：

媒體分層 冗餘性 檔案共用協定 傳統檔案共用 （Microsoft.Storage） 檔案共用 （Microsoft.FileShares）
SSD Local SMB 是的 不
SSD 區域 SMB 是的 不
SSD Local NFS 是的 是的
SSD 區域 NFS 是的 是的
HDD Local SMB 是的 不
HDD 區域 SMB 是的 不
HDD 地理 SMB 是的 不
HDD 地理區域 SMB 是的 不
HDD Local NFS 不 不
HDD 區域 NFS 不 不
HDD 地理 NFS 不 不
HDD 地理區域 NFS 不 不

配置型 v2 模型通常可在所有 Azure 公共雲區域及所有 Azure 美國政府雲區域使用。 並非所有地區都支援所有媒體等級和冗餘選項。

佈建的 v2 佈建

當你建立已配置的 v2 檔案分享時，請指定該檔案共享的儲存容量、IOPS 和吞吐量。 檔案分享的限制基於以下屬性：

Item SSD 值 HDD 值
儲存體佈建單位 1 GiB 1 GiB
IOPS 佈建單位 1 IO / 秒 1 IO / 秒
輸送量佈建單位 1 MiB / 秒 1 MiB / 秒
佈建儲存體下限 32 GiB 32 GiB
佈建的最小 IOPS 3,000 IOPS 500 IOPS
最低佈建輸送量 100 MiB / 秒 60 MiB / 秒
佈建儲存體上限 256 TiB （262,144 GiB） 256 TiB （262,144 GiB）
佈建的 IOPS 上限 102,400 IOPS 50,000 IOPS
佈建的輸送量上限 10,340 MiB / 秒 5,120 MiB / 秒

預設情況下，Azure 檔案儲存體 會根據你指定的配置儲存空間，提供 IOPS 和吞吐量配置的建議。 這些建議公式是以該媒體層在 Azure 檔案儲存體中已佈建儲存體數量的一般客戶使用量為基礎：

公式名稱 SSD 公式 HDD 公式
IOPS 建議 MIN(MAX(3000 + CEILING(1 * ProvisionedStorageGiB), 3000), 102400) MIN(MAX(1000 + CEILING(0.2 * ProvisionedStorageGiB), 500), 50000)
輸送量建議 MIN(MAX(100 + CEILING(0.1 * ProvisionedStorageGiB), 100), 10340) MIN(MAX(60 + CEILING(0.02 * ProvisionedStorageGiB), 60), 5120)

根據你個人的檔案分享需求，你可能需要比建議更多的 IOPS 或更少的吞吐量。 您可以選擇用自己的值來覆寫這些建議。

預設 v2 IOPS 和吞吐量限制（守護措施）

配置 保護欄 有助於防止不必要的成本，因為它讓 IOPS 和吞吐量與已配置的儲存成正比，同時保留覆蓋預設 IOPS 和吞吐量建議的能力。 每個維度上限為 5 ×是你 配置的儲存空間建議值，你可以將它降低到媒體層級允許的最低值。 系統會根據各自的建議公式獨立評估 IOPS 與吞吐量護欄。 如果配置請求超過了保護範圍，你可以增加配置儲存空間，提高上限並解鎖更高的 IOPS 或吞吐量。

舉例來說，一個 32 GiB SSD 的 IOPS 建議值是 3,032，所以你能在該共享上配置的最大 IOPS 是 5 × 3,032 = 15,160。 增加已配置的儲存空間會提高建議的IOPS和吞吐量，進而提高護欄上限，這代表你可以配置更多IOPS或吞吐量。 護欄同時適用於 SSD 和 HDD。

下表顯示了各種配置儲存容量下，您可配置的最大IOPS與吞吐量：

配置的儲存空間 SSD 最大 IOPS SSD 最大吞吐量（MiB/sec） 硬碟最大IOPS 硬碟最大吞吐量（MiB/sec）
32 GiB 15,160 520 5,035 305
64 GiB 15,320 535 5,065 310
128 GiB 15,640 565 5,130 315
256 GiB 16,280 630 5,260 330
512 GiB 17,560 760 5,515 355
1,024 GiB 20,120 1,015 6,025 405
2,048 GiB 25,240 1,525 7,050 505
4,096 GiB 35,480 2,550 9,100 710
8,192 GiB 55,960 4,600 13,195 1,120
16,384 GiB 96,920 8,695 21,385 1,940
32,768 GiB 102,400 10,340 37,770 3,580
65,536 GiB 102,400 10,340 50,000 5,120
131,072 GiB 102,400 10,340 50,000 5,120
262,144 GiB 102,400 10,340 50,000 5,120

在引入護欄之前已配置且超過 5× 限制的共用項目，仍可正常運作。 當你更改該共享中任何已配置的數量時，配置的 IOPS 或吞吐量與其建議值的比率可以維持不變或下降，但不能增加。 舉例來說，如果某個共享資源目前的 IOPS 設定是建議值的 7 倍，你可以把它降到 6 倍，但不能提升到 7.1 倍。 當股價跌破或降至5×時，標準的護欄即適用。

已佈建的 v2 高載

以信用為基礎的 IOPS 突增功能為 IOPS 使用量提供更多的彈性。 利用這種彈性作為防範意外 IO 激增的緩衝。 對於已建立的 IO 模式，應預留 IO 峰值。

當檔案共享的流量低於佈建的 (基準) IOPS 時，突發 IOPS 點數會累積。 每當檔案共用的 IOPS 使用量超過所配置的 IOPS，且有可用的突增 IOPS 點數時，檔案共用可以突增至允許的最大突增 IOPS 限制。 只要額度有剩餘，檔案共用就可以持續高載，這是以累積的高載額度數量為基礎。 超過布建 IOPS 的每個 IO 都會耗用一個點數。 所有點數耗盡後，該檔案共用會恢復至已佈建的 IOPS。 針對檔案共用的 IOPS 不需要執行任何特殊動作，即可使用高載。 高載會盡力運作。

共用額度有三種狀態：

  • 累積，表示檔案共用使用小於已佈建 IOPS。
  • 減少，表示檔案共用使用超過已佈建 IOPS，且處於高載模式。
  • 固定，當檔案共用恰好使用已佈建的 IOPS，且未累積或使用任何點數時。

新的檔案共用最初會具有其高載貯體中的完整額度。 如果共用 IOPS 因伺服器節流而低於佈建的限制，高載額度將不會累積。 下列公式是用來決定檔案共用的高載 IOPS 限制和可能的額度數量：

Item SSD 公式 HDD 公式
高載 IOPS 限制 MIN(MAX(3 * ProvisionedIOPS, 10000), 102400) MIN(MAX(3 * ProvisionedIOPS, 5000), 50000)
高載 IOPS 額度 (BurstLimit - ProvisionedIOPS) * 3600 (BurstLimit - ProvisionedIOPS) * 3600

下表說明這些公式的幾個範例，適用於各種布建的 IOPS 數量：

已佈建 IOPS SSD 高載 IOPS 限制 SSD 高載額度 HDD 高載 IOPS 限制 HDD 高載額度
500 -- -- 最高 5,000 16,200,000
1,000 -- -- 最高 5,000 14,400,000
3,000 最高 10,000 25,200,000 最高 9,000 21,600,000
5,000 最高 15,000 36,000,000 最高 15,000 36,000,000
一萬 最高 30,000 72,000,000 最高 30,000 72,000,000
25,000 最高 75,000 180,000,000 最高 50,000 90,000,000
50,000 最高 102,400 188,640,000 最高 50,000 0
75,000 最高 102,400 98,640,000 -- --
102,400 最高 102,400 0 -- --

配置的 v2 資源模型

布建的 v2 計費模型適用於 Azure 檔案儲存體所使用的兩種資源類型。 你可以建立已配置的 v2 檔案共享，在儲存帳號內建立經典檔案共享 (Microsoft.Storage)，或直接建立頂層檔案共享 (Microsoft.FileShares)。

已佈建 v2 傳統檔案共用 (Microsoft.Storage)

若要使用佈建的 v2 模型建立傳統檔案共用，您的儲存體帳戶必須使用下列其中一個設定組合：

儲存體帳戶種類 儲存帳戶 SKU 可用的傳統檔案共用類型
文件儲存 PremiumV2_LRS SSD 已佈建 v2 傳統檔案共用，已指定本機備援。
文件儲存 PremiumV2_ZRS SSD 已佈建 v2 傳統檔案共用，已指定區域備援。
文件儲存 StandardV2_LRS HDD 已佈建 v2 傳統檔案共用，已指定本機備援。
文件儲存 StandardV2_ZRS HDD 已佈建 v2 傳統檔案共用，已指定區域備援。
文件儲存 StandardV2_GRS HDD 已佈建 v2 傳統檔案共用，已指定異地備援。
文件儲存 StandardV2_GZRS HDD 已佈建 v2 傳統檔案共用，已指定異地備援。

如需如何使用佈建的 v2 模型建立傳統檔案共用的詳細資訊，請參閱 建立傳統檔案共用。

在相同儲存體帳戶中建立的傳統檔案共用會共用該儲存體帳戶的儲存體、IOPS 和輸送量限制：

Attribute SSD 值 HDD 值 執法策略
每個記憶體帳戶布建的記憶體上限 256 TiB （262,144 GiB） 4 PiB（4,194,304 GiB） 在佈建時。
每個儲存體帳戶佈建的最大 IOPS 102,400 IOPS 50,000 IOPS 在佈建時。
每個儲存體帳戶佈建的輸送量上限 10,340 MiB / 秒 5,120 MiB / 秒 在佈建時。
每個儲存體帳戶的傳統檔案共用數上限 50 個經典檔案共用 50 個經典檔案共用 在佈建時。

要在經典檔案共享上部署具備配置 v2 帳單模型的 Azure 檔案儲存體，您需要考慮以下容量規劃的面向：

  • 每個傳統檔案共用需要多少佈建儲存體、IOPS 和輸送量？ 這些要求如何隨時間變化？
    由於儲存體帳戶具有共用限制，因此當您將傳統檔案共用配置給儲存體帳戶時，您必須考慮每個傳統檔案共用現在和一段時間的需求。 佈建 v2 模型的佈建邏輯可防止您佈建超過儲存體帳戶支援的儲存體、IOPS 或輸送量。 如果在單一儲存帳戶中放置足夠多的經典檔案共享，導致其中一個維度達到上限，現有的經典檔案共享就無法成長，除非先遷移到另一個儲存帳戶。 若要降低此風險，請在每個儲存體帳戶中規劃足夠的餘裕，以便至少在未來 3 到 5 年，您可以維持傳統檔案共用與儲存體帳戶的對應。

  • 您是否對將每個傳統檔案共用的帳單與個別專案、部門或客戶關聯起來有特殊需求？
    在 Azure 中，你能看到的最低細度帳單是 資源，這表示如果你把兩個經典檔案共享放在同一個儲存帳號，就無法輕易追蹤它們的成本回到個別專案、部門或客戶。 為了解決此問題，您應根據從計費觀點追蹤的需求，將傳統檔案共用分組到不同的儲存體帳戶中。

  • 目標區域的訂用帳戶中有多少個可用的儲存體帳戶？
    另一個複雜的因素是每個區域每個訂用帳戶可以擁有的儲存體帳戶數目。 如需詳細資訊，請參閱Microsoft.Storage控制平面限制。 根據你需要多少儲存帳號，可能需要額外訂閱才能建立更多儲存帳號。

設定的 v2 檔案共用（Microsoft.FileShares）

使用管理模型建立 Microsoft.FileShares 檔案共用，可讓部署 Azure 檔案儲存體變得相當容易：

  • 你不需要考慮每個檔案分享目前和未來的需求來決定該檔案分享的部署位置。
    每個檔案共用的佈建都獨立於每個其他檔案共用的佈建。 檔案共用成長的唯一考量是檔案共用的限制，詳細說明於佈建的 v2 佈建。

  • 每個檔案共用的帳單均獨立追蹤。
    由於使用 Microsoft.FileShares 資源提供者建立的檔案共用是最上層資源，您可以針對每個檔案共用個別追蹤帳單，而不受其他檔案共用影響。 您也可以使用標籤，輕鬆地將資源分組在一起，以追蹤專案、部門或客戶的成本。

  • 雖然檔案共用仍具有每個區域每個訂用帳戶的限制，但檔案共用的限制遠高於儲存體帳戶的限制。
    如需詳細資訊，請參閱 Microsoft.FileShares 控制平面限制。

已佈建 v2 快照集

Azure 檔案儲存體支援快照集，類似於 Windows 檔案伺服器上的磁碟區陰影複製 (VSS) 功能。 如需共用快照的詳細資訊，請參閱 Azure 檔案的快照概觀。

快照集總是與即時共用及彼此不同。 在已佈建的 v2 計費模型中，如果所有快照的總大小差異在檔案共用的過剩佈建儲存空間內，則快照儲存體不會產生額外費用。 如果即時共享資料的大小加上差異化快照資料大於所配置的共享存儲容量，則快照的超出容量部分將根據溢位快照使用量計費。 判斷溢位量的公式為： MAX((LiveShareUsedGiB + SnapshotDifferentialUsedGiB) - ProvisionedStorageGiB, 0)

Azure 檔案儲存體 的一些增值服務會使用快照集作為其價值主張的一部分。 如需詳細資訊，請參閱 Azure 檔案記憶體的增值服務。

已佈建 v2 虛刪除

啟用軟刪除時，系統會根據保存期間已使用的儲存容量來計費。 已刪除共用的已佈建儲存體、IOPS 和輸送量會持續計入儲存體帳戶的限制中，直到該共用已清除為止，以確保可以還原它。 然而，系統並未對這些資源進行計費。 如需啟用虛刪除的詳細資訊，請參閱 如何在 Azure 檔案共用上啟用虛刪除。

已佈建 v2 計費計量

使用已佈建 v2 計費模型佈建的檔案共用會根據下列計費計量收費：

  • 已布建的記憶體：GiB 中布建的記憶體數量。
  • 已布建的 IOPS：布建的 IOPS 數量（IO/秒）。
  • 布建的輸送量MiBPS：以MiB / 秒布建的輸送量數量。
  • 溢位快照使用量：任何超出配置的儲存容量的差異快照使用量，以GiB計。 如需詳細資訊，請參閱佈建的 v2 快照集。
  • Soft-Deleted 使用量：以 GiB 計算的軟刪除檔案分享的已用儲存容量。 如需詳細資訊，請參閱佈建的 v2 虛刪除。

系統每小時會針對已佈建的 v2 計費量測器產生用量單位。 例如，對於已佈建 1,024 GiB 的共用，您會看到：

  • 1,024 單位，根據單一小時的已佈建儲存體計量。
  • 24,576 單位，根據彙總一天的已佈建儲存體計量。
  • 根據月份中的天數，彙總一個月的可變單位數：
    • 一個月 28 天 (正常的 2 月)：688,128 單位，根據已佈建儲存體計量。
    • 一個月 29 天 (閏年的 2 月)：712,704 單位，根據已佈建儲存體計量。
    • 一個月 30 天：737,280 單位，根據已佈建儲存體計量。
    • 一個月 31 天：761,856 單位，根據已佈建儲存體計量。

已佈建 v2 移轉

將您的 SMB Azure 檔案共用的遷移過程從隨需即用模式轉換至布建 v2 計費模式取決於您是否使用 Azure 檔案同步，因此流程會因而有所不同。

已佈建 v1 模型

布建的 v1 方法會以固定比例提供記憶體、IOPS 和輸送量，類似於在內部部署記憶體解決方案中購買記憶體的方式。 當您建立新的佈建 v1 傳統檔案共用時，您可以指定共用所需的儲存空間量，而 IOPS 和輸送量是計算值。 Azure 檔案儲存體的布建 v1 模型僅適用於 SSD 媒體層。

您配置的儲存空間數量會決定您的傳統檔案共享的保證儲存空間、IOPS 和頻寬限制。 例如，如果您佈建了一個 2 TiB 的共用，並將 2 TiB 的資料上傳到您的傳統檔案共用，其容量就會用滿。 除非你擴大經典檔案分享的大小或刪除部分資料，否則無法新增更多資料。 額度型 IOPS 高載會儘可能增加使用量的彈性，同時額度維持不變。

與在本地購買儲存不同，你可以根據需求變化動態擴充或縮小已配置的 v1 經典檔案分享。 不過，在上次增加記憶體之後，您只能在經過 24 小時之後減少布建的記憶體。 儲存、IOPS 和吞吐量的變更會在配置變更後幾分鐘內生效。

您可以將已佈建的共用縮小到低於您的已使用 GiB 的大小。 即使這麼做，資料不會遺失，但還是會依據使用的容量計費。 你會看到配置的份額的績效，而不是所使用的容量。

已佈建 v1 可用性

佈建的 v1 模型適用於下列媒體層、備援和檔案共用通訊協定的組合：

媒體分層 冗餘性 檔案共用協定 傳統檔案共用 （Microsoft.Storage） 檔案共用 （Microsoft.FileShares）
SSD Local SMB 是的 不
SSD 區域 SMB 是的 不
SSD Local NFS 是的 不
SSD 區域 NFS 是的 不
HDD Local SMB 不 不
HDD 區域 SMB 不 不
HDD 地理 SMB 不 不
HDD 地理區域 SMB 不 不
HDD Local NFS 不 不
HDD 區域 NFS 不 不
HDD 地理 NFS 不 不
HDD 地理區域 NFS 不 不

使用佈建的 v1 模型的 SSD 傳統檔案共用已在大部分的 Azure 區域中正式推出。 如需詳細資訊，請參閱不同區域的 Azure 產品。

已佈建 v1 佈建詳細資料

當您建立佈建的 v1 傳統檔案共用時，您可以指定共用所需的儲存空間量。 您布建的每個 GiB 都可讓您以固定比例獲得更多 IOPS 和輸送量。 佈建的 v1 傳統檔案共用會根據下列屬性進行限制：

Item 價值觀
儲存體佈建單位 1 GiB
佈建儲存體下限 100 GiB
佈建的最小 IOPS （計算） 3,100 IOPS
最低佈建輸送量 （計算） 110 MiB/秒
佈建儲存體上限 100 TiB （102,400 GiB）
佈建IOPS上限（計算） 102,400 IOPS
佈建輸送量上限 （計算） 10,340 MiB / 秒

下列公式決定在共用上佈建的 IOPS 和輸送量：

Item Formula
計算已佈建 (基準) IOPS MIN(3000 + 1 * ProvisionedStorageGiB, 102400)
計算布建輸送量 （MiB / 秒） 100 + CEILING(0.04 * ProvisionedStorageGiB) + CEILING(0.06 * ProvisionedStorageGiB)

根據你個人對經典檔案分享的需求，你可能會發現所需的 IOPS 或吞吐量比配置公式提供的還要高。 在此情況下，您必須佈建更多儲存體，以取得所需的 IOPS 或輸送量。

已佈建 v1 高載

配置型 v1 支援兩種突發方式： 基於信用的突發，作為配置的一部分免費提供;以及 付費突發，這是進階功能，當 IOPS 和吞吐量超過設定時，你可以選擇性啟用，以支援基於使用量的計費。

已佈建 v1 額度型高載

以信用為基礎的 IOPS 突增功能為 IOPS 使用量提供更多的彈性。 利用這種彈性作為防範意外 IO 激增的緩衝。 對於已建立的 IO 模式，應預留 IO 峰值。

當傳統檔案共用的流量低於已佈建 (基準) IOPS 時，將會累積高載 IOPS 額度。 每當傳統檔案共用的 IOPS 使用量超過佈建的 IOPS 且有可用的高載 IOPS 點數時，傳統檔案共用可能會高載至允許的最高高載 IOPS 限制。 只要額度有剩餘，傳統檔案共用就可以持續高載，這是以累積的高載額度數量為基礎。 超過布建 IOPS 的每個 IO 都會耗用一個點數。 當所有點數都用盡後，經典檔案共用會恢復為已佈建的 IOPS。 針對傳統傳統檔案共用的 IOPS 不需要執行任何特殊動作即可使用突增。 高載會盡力運作。

共用額度有三種狀態：

  • 累積，表示傳統檔案共用使用小於已佈建 IOPS。
  • 減少，表示傳統檔案共用使用超過已佈建 IOPS，且處於高載模式。
  • 持平，表示傳統檔案共用使用所有已佈建 IOPS，沒有任何累積或使用的額度。

新的傳統檔案共用最初會具有其高載貯體中的完整額度。 如果共用 IOPS 因伺服器節流而低於佈建的限制，高載額度將不會累積。 下列公式是用來決定傳統檔案共用的高載 IOPS 限制和可能的額度數量：

Item Formula
高載限制 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

已佈建 v1 付費高載

付費高載是已佈建 v1 模型的進階功能，其設計目的是支援從未想要節流的客戶。 付費高載會針對佈建儲存體上方的任何 IOPS 或輸送量，增加額外的使用量型計費。 此功能有別於以點數為基礎的高載，後者是作為已佈建儲存體的一部分免費提供。 雖然付費高載可以增加您佈建傳統檔案共享的強大彈性，但如果使用不正確，也可能會導致非預期的計費。

與額度型高載一樣，付費高載並不是用來佈建正確 IOPS 和輸送量的替代方式。 相反地，如果您遇到非預期的需求，它會提供進一步保護來防止節流 如果你有穩定的 IOPS 或吞吐量使用率，透過儲存配置配置足夠的 IOPS 和吞吐量來滿足需求，比起依賴付費突發來得便宜。

付費的高載預設為停用，但您可以依照變更已佈建 v1 傳統檔案共用的成本與效能特性的指示來啟用它 (僅限 PowerShell 和 CLI)。 如果您啟用已付費的高載，請使用 Azure 監視器中提供的下列計量指標來監視 IOPS 和輸送量使用情況：

  • 檔案共用佈建的 IOPS
  • 檔案共用布建頻寬 MiB/秒 （輸送量）
  • 根據最大 IOPS 的交易
  • 最大 MiB/秒的頻寬 (輸送量)
  • IOPS 高載額度 (額度型高載)
  • 付費高載 IOS (IO)
  • 付費高載頻寬

配置的 v1 資源模型

您只能將已佈建的 v1 檔案共用建立為儲存體帳戶 (Microsoft.Storage) 內的傳統檔案共用。

已佈建 v1 傳統檔案共用 (Microsoft.Storage)

若要使用佈建的 v1 模型建立傳統檔案共用，您的儲存體帳戶必須使用下列其中一種設定組合：

儲存體帳戶種類 儲存帳戶 SKU 可用的檔案共用類型
文件儲存 Premium_LRS SSD 已佈建 v1 檔案共用，已指定本地 (LRS) 備援。
文件儲存 Premium_ZRS SSD 已佈建 v1 檔案共用，已指定區域 (ZRS) 備援。

欲了解更多如何利用 provisioned v1 模型建立經典檔案分享的資訊，請參見 建立經典檔案分享。

在相同儲存體帳戶中建立的傳統檔案共用會共用該儲存體帳戶的儲存體、IOPS 和輸送量限制：

Attribute SSD 值 執法策略
每個記憶體帳戶布建的記憶體上限 100 TiB （102,400 GiB） 在佈建時
每個儲存體帳戶的已用 IOPS 上限 102,400 IOPS 你可以配置超過 102,400 IOPS，但超過這個限制的使用會被限速。
每個儲存帳戶的最大使用吞吐量 10,340 MiB / 秒 你可以配置超過 10,340 MiB / sec，但超過這個限制的使用會被限速。
每個儲存體帳戶的傳統檔案共用數上限 1,024 個傳統檔案共用 儲存體帳戶的最大配置儲存上限隱含地強制執行此限制。

若要在傳統檔案共用上以已佈建 v1 計費模型正確部署 Azure 檔案儲存體，請考量以下幾個容量規劃面向：

  • 每個傳統檔案共用需要多少佈建儲存體、IOPS 和輸送量？ 這些要求如何隨時間變化？
    由於共享儲存帳號的限制，當你將經典檔案分享分配給儲存帳號時，請考慮每個經典檔案共享現在及未來的需求。 佈建的 v1 模型的預配置邏輯可防止您配置超過儲存帳戶支援的儲存空間。 雖然你可以配置比儲存帳號提供的更多的 IOPS 和吞吐量，但你不能用超過 儲存帳號的 IOPS 和吞吐量上限。 若要避免非預期的節流，請勿佈建超過儲存體帳戶支援的 IOPS 或輸送量。

    此外，在儲存體帳戶中放置太多傳統檔案共用可能會限制未來的成長。 儲存體帳戶已滿之後，除非先將某些儲存體帳戶移轉至另一個儲存體帳戶，否則就無法擴充現有的傳統檔案共用。 為了降低此風險，請預留足夠的儲存帳戶餘裕，使經典檔案共享與儲存帳戶的對應至少維持三到五年。

  • 您是否對將每個傳統檔案共用的帳單與個別專案、部門或客戶關聯起來有特殊需求？
    在 Azure 中，你能看到的最低細度帳單是 資源，這表示如果你把兩個經典檔案共享放在同一個儲存帳號，就無法輕易追蹤它們的成本回到個別專案、部門或客戶。 為了解決此問題，請根據傳統檔案共用在計費方面需要如何追蹤，將其分類到儲存體帳戶中。

  • 目標區域的訂用帳戶中有多少個可用的儲存體帳戶？
    另一個複雜的因素是每個區域每個訂用帳戶可以擁有的儲存體帳戶數目。 如需詳細資訊，請參閱Microsoft.Storage控制平面限制。 根據你需要多少儲存帳號，可能需要額外訂閱才能建立更多儲存帳號。

已佈建 v1 快照集

Azure 檔案儲存體支援快照集，類似於 Windows 檔案伺服器上的磁碟區陰影複製 (VSS) 功能。 如需共用快照的詳細資訊，請參閱 Azure 檔案的快照概觀。

快照集總是與即時共用及彼此不同。 在布建的 v1 計費模型中，不論未使用多少布建記憶體，總差異大小都會根據使用量計量計費。 已使用快照集儲存體計費的價格比已佈建儲存體價格更低。

已佈建 v1 虛刪除

在已啟用虛刪除的儲存體帳戶中，已刪除的傳統檔案共用會根據定義的保留期間內已刪除共用的已使用儲存體容量進行計費。 虛刪除使用量儲存體容量會針對使用的快照集儲存體計量發出。 如需虛刪除的詳細資訊，請參閱 如何在 Azure 檔案共享上啟用虛刪除。

已佈建 v1 計費計量

使用已佈建 v1 計費模型佈建的傳統檔案共用會根據下列計量進行收費：

  • 進階布建：GiB 中布建的記憶體數量。
  • 高級快照：已使用的快照數量和已使用的軟刪除容量。

針對已佈建 v1 計費計量的使用量，會以每月單位每小時發出。 例如，對於已佈建 1,024 GiB 的共用，您會看到：

  • 個別小時的可變單位數，視月份的天數而定：
    • 一個月 28 天 (正常的 2 月)：1.5238 單位，根據進階已佈建計量。
    • 一個月 29 天 (閏年的 2 月)：1.4713 單位，根據進階已佈建計量。
    • 一個月 30 天：1.4222 單位，根據進階已佈建計量。
    • 一個月 31 天：1.3763 單位，根據進階已佈建計量。
  • 根據每月天數，彙總一天的可變單位數目：
    • 一個月 28 天 (正常的 2 月)：36.5714 單位，根據進階已佈建計量。
    • 一個月 29 天 (閏年的 2 月)：35.3103 單位，根據進階已佈建計量。
    • 一個月 30 天：34.1333 單位，根據進階已佈建計量。
    • 一個月 31 天：33.0323 單位，根據進階已佈建計量。
  • 1,024 個單位，根據彙總一個月的進階已佈建計量。

隨用隨付模型

在隨用付費模式中，你的帳單是根據你使用的儲存空間，而不是你配置的多少。 概括而言，您會為儲存的邏輯數據量支付費用，而且您也會根據該數據的使用量支付交易費用。 隨用隨付計費可能難以在預算程式中進行規劃，因為您會根據使用者耗用量付費。 使用 已佈建 v2 模型 來部署新的傳統檔案共用。 隨用隨付模式僅適用於 HDD 存儲。

隨用即付可用性

隨用隨付模型適用於下列媒體層、備援和檔案共用通訊協定的組合：

媒體分層 冗餘性 檔案共用協定 傳統檔案共用 （Microsoft.Storage） 檔案共用 （Microsoft.FileShares）
SSD Local SMB 不 不
SSD 區域 SMB 不 不
SSD Local NFS 不 不
SSD 區域 NFS 不 不
HDD Local SMB 是的 不
HDD 區域 SMB 是的 不
HDD 地理 SMB 是的 不
HDD 地理區域 SMB 是的 不
HDD Local NFS 不 不
HDD 區域 NFS 不 不
HDD 地理 NFS 不 不
HDD 地理區域 NFS 不 不

使用隨用量付費模式的 HDD 經典檔案分享通常在所有 Azure 區域都能取得。

存取層的差異

當您在隨用隨付儲存體帳戶中建立經典檔案共用時，請從以下存取層中選擇：交易最佳化、經常性存取和非經常性存取。 這三個存取層級都使用相同的儲存硬體。 這些存取層級的主要差異在於它們的資料靜態儲存價格，在較低層級較低，而交易價格則在較低層級較高。 此定價架構意味著：

  • 交易優化，如名稱所示，將高 IOPS（交易）工作負載的價格優化。 交易最佳化具有最高的待用資料儲存體價格，但交易價格最低。
  • 經常性存取層適用於未涉及大量交易的作用中工作負載。 相較於交易最佳化，其待用資料儲存體價格略低，但交易價格略高。 您可以將其視為介於交易最佳化和非經常性存取層之間的中間方案。
  • Cool 優化沒有高活動量的工作負載的價格，提供最低的靜態數據儲存成本，但交易價格較高。

為您的使用情境選擇合適的存取層級，能大幅降低成本。 如果您將不常存取的工作負載放在交易最佳化存取層中，則您幾乎不需要支付一個月內針對傳統檔案共用進行交易的幾次費用。 不過，您會為數據儲存成本支付大量費用。 如果您把同一的共用移到非經常性存取層，那麼您幾乎不用支付交易費用，因為您不常對這個工作負載進行交易。 不過，冷存取層具有更便宜的數據儲存成本。

同樣地，如果您在冷存取層中放置高頻率存取的工作負載，則會支付較高的交易成本，但數據儲存成本較低。 這種定價結構可能會導致交易費用增加的幅度，超過因資料儲存價格下降而節省的費用，因此您使用 cool 所支付的費用，可能會比使用 transaction optimized 時更高。 在某些使用層級，熱存取層可能成本效益最高，而冷存取層比交易優化後更昂貴。

您的工作負載和活動層級會為隨用隨付傳統檔案共用決定最具成本效益的存取層。 實務上，選擇最具成本效益的存取層級最佳方式是查看該共享的實際資源消耗（儲存資料、寫入交易等）。 對於隨用隨付的傳統檔案共用，在初始移轉至 Azure 檔案儲存體 期間，請先使用交易最佳化層級，待移轉完成後，再根據使用情況選擇正確的存取層級。 移轉期間的交易使用量通常不表示一般交易使用量。

什麼是交易？

當你掛載使用隨用付費模式的 SMB 經典檔案分享時，你會在電腦上看到經典檔案分享，就像它是本地儲存一樣。 這表示您電腦上的應用程式、腳本和其他程式可以存取傳統檔案共用上的檔案和資料夾，而不需要知道它們儲存在 Azure 中。

當您讀取或寫入檔案時，您使用的應用程式會對作系統所提供的檔案系統 API 執行一系列 API 呼叫。 接著，您的作系統會將這些呼叫解譯成SMB通訊協定交易，這些交易會透過網路傳送至 Azure 檔案儲存體來完成。 最終使用者視為單一操作的簡單工作，例如從頭到尾讀取檔案，實際上可能涉及 Azure 檔案服務提供的多個 SMB 交易。

經典的檔案分享是使用按使用量付費的模式。 應用程式和腳本所進行的 SMB 和 FileREST 交易代表傳統檔案共用的使用量，而且它們會顯示為帳單的一部分。 相同的概念適用於您可能新增至共用的加值雲端服務，例如 Azure 檔案同步或 Azure 備份。

交易被分成五個不同的交易類別，根據對經典檔案共享的影響，價格各異。 這些類別包括：寫入、列出、讀取、其他和刪除。

下表顯示每個交易的分類：

交易池 管理作業 資料作業
寫入交易
  • 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

附註

NFSv4.1 僅適用於使用 provisioned v2 或 provisioned v1 計費模型的 SSD 檔案分享。 交易區塊不會影響已佈建檔案共用的計費。

在存取層之間切換

雖然你可以更改使用隨用付費模式的經典檔案分享的存取層級，但優化初期遷移後成本的最佳方式是選擇最經濟化的存取層級，除非你的存取模式改變，否則保持該層級。 更改經典檔案分享的存取層級會產生額外費用，如下：

  • 交易：將傳統檔案共用從經常性儲存層移至非經常性儲存層時，會針對共用中的每個檔案產生非經常性儲存層的寫入交易費用。 將傳統檔案共用從冷存取層移至熱存取層，將對冷存取層中的每個檔案產生讀取交易費用。

  • 資料擷取：如果你從冷存取層級轉為熱存取或交易優化層級，會根據移動的資料大小產生資料檢索費用。 只有非經常性存取層會收取資料擷取費用。

下表說明移動存取層的成本明細：

存取層 交易最佳化 （目的地） 熱門（目的地） 酷炫的目的地
交易優化 （來源） --
  • 每個檔案有一個經常性寫入交易。
  • 每個檔案有一個非經常性寫入交易。
經常性 (來源)
  • 每個檔案有一個經常性讀取交易。
    		 --
    • 每個檔案有一個非經常性寫入交易。
    非經常性 (來源)
    • 每個檔案有一個非經常性讀取交易。
    • 每個已使用 GiB 總計的資料擷取。
    • 每個檔案有一個非經常性讀取交易。
    • 每個已使用 GiB 總計的資料擷取。
    		 --

    您可以在 30 天的期間內變更傳統檔案共用的存取層最多五次。 當第一層變更發生時，30 天視窗的第一天就會開始。 存取等級之間的變動是即時發生的。 然而，一旦你更改了某份額的存取等級，即使你在過去 30 天內更改存取等級屬性少於五次，也不能在 24 小時內再次更改。

    選擇存取層

    無論你如何將現有資料遷移到 Azure 檔案儲存體，你都應該先在交易最佳存取層建立經典檔案分享。 遷移會產生大量交易。 遷移完成後，請先在正常使用情況下運作幾天或幾週，再將交易數量輸入價格計算器，以判斷哪一種存取層級最適合您的工作負載。

    由於隨用隨付儲存體帳戶只會在儲存體帳戶層級顯示交易資訊，因此使用儲存體計量來估計傳統檔案共用層級哪個存取層更便宜是一門不完美的科學。 如果可能，每個儲存帳號只部署一個經典檔案共享，以確保對帳單的完整可視性。

    若要查看先前的交易：

    1. 請進入 Azure portal 的 storage 帳號。
    2. 在服務功能表中的 [ 監視] 底下，選取 [ 計量]。
    3. 選取 [範圍] 作為您的儲存體帳戶名稱、選取 [命名空間] 作為「檔案」、選取 [計量] 作為「交易」，然後選取 [彙總] 作為「總和」。
    4. 選取 [套用分割]。
    5. 選取 [值] 作為「API 名稱」。 選取所需的 [限制] 和 [排序]。
    6. 選取所需的時段。

    附註

    務必在夠長的一段時間內觀察交易情況，才能對平均交易筆數有較切實的概念。 確定所選的時間週期不會與初始布建重疊。 乘以在此時段內的平均交易數目，得出整個月份的預估交易。

    隨用隨付資源模型

    您只能將隨用隨付的檔案共用建立為儲存體帳戶 (Microsoft.Storage) 內的傳統檔案共用。

    隨用隨付傳統檔案共用服務（Microsoft.Storage）

    若要使用隨用隨付模型建立傳統檔案共用，您的儲存體帳戶必須使用下列其中一個設定組合：

    儲存體帳戶種類 儲存帳戶 SKU 可用的檔案共用類型
    StorageV2 Standard_LRS HDD 隨用隨付檔案共用，已指定 Local (LRS) 備援。
    StorageV2 Standard_ZRS HDD 隨用隨付檔案共用，已指定 Zone (ZRS) 備援。
    StorageV2 Standard_GRS HDD 隨用隨付檔案共用，已指定 Geo (GRS) 備援。
    StorageV2 Standard_GZRS HDD 隨用隨付檔案共用，已指定 GeoZone (GZRS) 備援。
    StorageV2 Standard_RAGRS HDD 隨用隨付檔案共用，已指定 Geo (GRS) 備援。
    StorageV2 Standard_RAGZRS HDD 隨用隨付檔案共用，已指定 GeoZone (GZRS) 備援。

    在相同儲存體帳戶中建立的傳統檔案共用會共用該儲存體帳戶的儲存體、IOPS 和輸送量限制：

    Attribute HDD 值 執法策略
    每個儲存體帳戶的已用儲存體上限 5 PiB（5,242,880 GiB） 使用量有上限。
    每個儲存體帳戶的已用 IOPS 上限
    • 選取區域：40,000 IOPS
    • 預設值：20,000 IOPS
    		 超過限制的使用量會受到流量限制。
    每個儲存帳戶的最大使用吞吐量
    • 選取區域：
      • 輸入：7,680 MiB / 秒
      • 輸出：25,600 MiB / 秒
    • 預設：
      • 輸入：3,200 MiB / 秒
      • 輸出：6,400 MiB / 秒
    		 超過限制的使用量會受到流量限制。
    每個儲存體帳戶的傳統檔案共用數上限 無限制 儲存體、IOPS 和輸送量限制是傳統檔案共用數量的實際限制。

    欲了解更多細節，包括哪些區域支援提升 IOPS 與吞吐量限制，請參閱 儲存帳號資料平面限制。

    若要在傳統檔案共用上以隨用隨付計費模式正確部署 Azure 檔案儲存體，請考慮容量規劃的下列層面：

    • 需要多少已使用的儲存空間、IOPS 和吞吐量來支援每個傳統檔案共用？ 這些要求如何隨時間變化？
      由於共享儲存帳號的限制，當你將經典檔案分享分配給儲存帳號時，請考慮每個經典檔案共享現在及未來的需求。 不同於已佈建的 v2 和 v1 模型，隨用隨付模型提供的保護措施較少，較難以協助您在同一儲存體帳戶內的傳統檔案共用之間共用儲存體帳戶的限制。 隨用隨付儲存體帳戶中的每個傳統檔案，其大小可達傳統檔案共用設定的上限，同時其 IOPS 與輸送量亦可達該儲存體帳戶的設定上限。 將兩個傳統檔案共用放在相同的隨用隨付儲存體帳戶中，可能會導致 IOPS 或輸送量爭用。 若要避免非預期的節流，請限制您放置在隨用隨付儲存體帳戶中的傳統檔案共用數目。

    • 您是否對將每個傳統檔案共用的帳單與個別專案、部門或客戶關聯起來有特殊需求？
      在 Azure 中，你能看到的最低細度帳單是 資源，這表示如果你把兩個經典檔案共享放在同一個儲存帳號，就無法輕易追蹤它們的成本回到個別專案、部門或客戶。 為了解決此問題，請根據傳統檔案共用在計費方面需要如何追蹤，將其分類到儲存體帳戶中。

    • 目標區域的訂用帳戶中有多少個可用的儲存體帳戶？
      另一個複雜的因素是每個區域每個訂用帳戶可以擁有的儲存體帳戶數目。 如需詳細資訊，請參閱Microsoft.Storage控制平面限制。 根據你需要多少儲存帳號，可能需要額外訂閱才能建立更多儲存帳號。

    隨用隨付快照集

    Azure 檔案儲存體支援快照集，類似於 Windows 檔案伺服器上的磁碟區陰影複製 (VSS) 功能。 如需共用快照的詳細資訊，請參閱 Azure 檔案的快照概觀。

    快照集總是與即時共用及彼此不同。 在隨用隨付的計費模式中，總差額大小會計入一般已使用的儲存體計量中。 這代表在您的隨用隨付儲存體帳戶帳單上，您不會看到用來表示快照的單獨明細項目。 這種差異快照使用情況，也會計入您為隨用隨付的傳統檔案共用所購買的預留容量。

    隨用隨付虛刪除

    在已啟用虛刪除的儲存體帳戶中，已刪除的傳統檔案共用會根據所定義保留期間內的已使用儲存體容量進行計費。 虛刪除的已使用儲存體容量會計入一般已使用的儲存體計量中。 這表示在您的隨用隨付儲存體帳戶帳單上，您不會看到一筆對應已虛刪除之傳統檔案共用的單獨明細項目。 此已虛刪除的傳統檔案共用使用量，也會計入您為隨用隨付傳統檔案共用所購買的預留容量。

    隨用隨付計費計量

    使用隨用隨付計費模型建立的傳統檔案共享會根據下列計價表計費：

    • 已儲存的資料：已使用的儲存體，包括即時共用、差異化快照及虛刪除的傳統檔案共用，以 Gibibytes (GiB) 為單位。
    • 元資料：與檔案和目錄相關的檔案系統元資料大小，例如存取控制清單（ACL）及其他屬性，在 GiB 中。 此計費計量僅適用於經常性存取或非經常性存取層中的傳統檔案共用。
    • 寫入作業：寫入存儲桶的數量（一個存儲桶 = 10,000 筆交易）。
    • 清單作業：清單交易桶的數量（一個桶 = 10,000 筆交易）。
    • 讀取作業：讀取交易桶的數目（一個桶 = 10,000 筆交易）。
    • 其他作業 / 通訊協議作業：其他交易貯體的數目（一個貯體 = 10,000 筆交易）。
    • 資料擷取：從傳統檔案共用讀取的資料量（以 GiB 為單位）。 此計量僅適用於非經常性存取層的傳統檔案共用。
    • 異地複寫資料傳輸：如果傳統檔案共用具有異地複寫或異地區域備援，則寫入傳統檔案共用的資料量會複寫到次要區域 (以 GiB 為單位)。

    已儲存的資料和中繼資料計費計量將每月的使用量單位轉換為小時單位來表示。 例如，對於已使用 1,024 GiB 的共用，您會看到：

    • 個別小時的可變單位數，視月份的天數而定：
      • 一個月 28 天 (正常的 2 月)：1.5238 單位，根據已儲存的資料計量。
      • 一個月 29 天 (閏年的 2 月)：1.4713 單位，根據已儲存的資料計量。
      • 一個月 30 天：1.4222 單位，根據已儲存的資料計量。
      • 一個月 31 天：1.3763 單位，根據已儲存的資料計量。
    • 根據每月天數，彙總一天的可變單位數目：
      • 一個月 28 天 (正常的 2 月)：36.5714 單位，根據已儲存的資料計量。
      • 一個月 29 天 (閏年的 2 月)：35.3103 單位，根據已儲存的資料計量。
      • 一個月 30 天：34.1333 單位，根據已儲存的資料計量。
      • 一個月 31 天：33.0323 單位，根據已儲存的資料計量。
    • 1024 單位，根據彙總一個月的已儲存的資料計量。

    其他計量（例如 寫入作業 或 資料擷取）會每小時產生一次用量資料。 因為這些電錶沒有特定的時間框架，所以不需要特殊的單位變換。

    Azure 檔案儲存體共用大小概念：佈建大小或配額、邏輯大小和實體大小

    Azure 檔案儲存體追蹤與共用容量相關的三個相異數量：

    • 佈建大小或配額：無論是佈建型還是隨用隨付的檔案共用，您都可以指定檔案共用可成長到的最大大小。 在預設的檔案共用中，此值稱為預設大小。 你支付的費用是依據已佈建容量計算，無論你實際使用多少。 在隨用隨付制的檔案共用中，此值稱為配額，且不會直接影響帳單。 佈建的大小是佈建檔案共用的必要欄位。 對於隨用付費的檔案共享，如果你沒有指定配置大小，該共享會預設為儲存帳戶所支援的最大值（100 TiB）。

    • 邏輯大小：檔案共享或檔案的邏輯大小與它的大小有關，而不考慮實際儲存的方式，而不需要任何記憶體優化。 檔案的邏輯大小是如果你把檔案複製到另一個位置，會透過有線傳輸多少 KiB、MiB 或 GiB。 無論是配置式檔案共享或隨用即付檔案共享，檔案共享的總邏輯大小都用於執行配置大小或配額。 在隨用隨付檔案共用中，邏輯大小為用於待用資料使用量計費的數量。 Windows 檔案或資料夾的屬性對話框將邏輯大小稱為「大小」，而 Azure 檔案儲存體 的指標則將其稱為「內容長度」。

    • 實體大小：檔案的實體大小與磁碟上編碼的檔案大小有關。 實體大小可能與檔案的邏輯大小相符，也可能較小，視作業系統如何寫入該檔案而定。 邏輯大小和實體大小不同的常見原因是使用 疏鬆檔案。 共用中的檔案實體大小會用於快照集計費，但如果快照集未變更 (差異儲存體)，則會將配置的範圍共用在快照集間。

    Azure 檔案儲存體 的加值服務

    與許多內部部署儲存體解決方案一樣，Azure 檔案儲存體提供第一方和第三方產品的整合點，以便與客戶擁有的檔案共用整合。 雖然這些解決方案能為 Azure 檔案儲存體 帶來相當多的額外價值，但請考慮這些服務對 Azure 檔案儲存體 解決方案總成本的額外影響。

    成本分成三個類別：

    • 加值服務的授權成本。 授權成本可能以每個客戶、終端使用者 （有時稱為「人頭成本」） 、檔案共用或儲存體帳戶的固定成本的形式出現。 它們也可能以記憶體使用率單位為基礎，例如檔案共用中每 500 GiB 區塊數據的固定成本。

    • 加值服務的交易成本。 某些增值服務在選取的 Azure 檔案儲存體 計費模型之上有自己的交易概念。 這些交易會在你的帳單上以增值服務的費用計算。 不過，這些問題直接關乎你如何利用檔案分享的增值服務。

    • 使用 Azure 檔案儲存體 的加值服務成本。 Azure 檔案儲存體 不會直接向客戶收取增值服務費用。 然而，作為為 Azure 檔案分享增值的一部分，增值服務可能會增加你在 Azure 檔案分享中看到的成本。 這種增加很容易在隨用隨付的檔案共用中看出來，因為會有交易費用。 如果加值服務代表您對檔案共享執行交易，它們會顯示在 Azure 檔案服務交易帳單中，即使您自己沒有直接執行這些交易也一樣。 這種交易模式同樣適用於已配置的檔案共享，雖然可能不那麼明顯。 加值服務中根據已佈建檔案共用的交易會計入您已佈建 IOPS 號碼，表示加值服務可能需要佈建額外儲存體，才有足夠的 IOPS 或輸送量可供您的工作負載使用。

    在計算檔案分享的總擁有成本時，請考慮 Azure 檔案儲存體 以及你想搭配 Azure 檔案儲存體 使用的所有增值服務的成本。

    有許多增值的第一方及第三方服務存在。 本文件涵蓋客戶在 Azure 檔案儲存體 檔案分享中常用的第一方服務的部分。 想了解更多未在此列出的服務，請參閱該服務的價格頁面。

    Azure 檔案同步

    Azure 檔案同步是 Azure 檔案儲存服務的一項增值服務，它可同步處理一個或多個內部部署的 Windows 檔案共用與 Azure 檔案共用。 由於雲端的 Azure 檔案共用有同步檔案共用中可供內部部署使用的完整資料副本，因此您可以將內部部署的 Windows 檔案伺服器轉換為 Azure 檔案共用的快取，來降低內部部署使用量。 欲了解更多，請參閱Azure 檔案同步導論。

    在考慮使用 Azure 檔案同步 部署解決方案的總擁有成本時，請考慮以下成本面向：

    • 具有一或多個伺服器端點 Windows 檔案伺服器的資本和營運成本。 Azure 檔案同步為複寫解決方案，與 Azure 檔案儲存體同步處理 Windows 檔案伺服器無關；這些伺服器可以裝載在內部部署、Azure 虛擬機器，甚至是另一個雲端。 裝載於內部部署或其他雲端提供者的同步處理伺服器成本包括資本和營運成本，這些費用雖未計入您的 Azure 帳單，但仍屬於解決方案擁有權總成本的組成部分。 資本支出是解決方案的前期硬體成本。 營運支出是指勞動力、電力等持續性成本。您應該考慮快取內部部署所需的資料量、Windows 檔案伺服器裝載 Azure 檔案同步工作負載所需的 CPU 數目和記憶體數量，以及您可能擁有的其他組織特定成本。 如需詳細資訊，請參閱建議的系統資源 (部分內容可能是機器或 AI 翻譯)。

    • 向 Azure 檔案同步註冊伺服器的每部伺服器授權成本。若要搭配特定 Windows 檔案伺服器使用 Azure 檔案同步，您必須先向 Azure 檔案同步的 Azure 資源 (儲存體同步服務) 註冊。 您在第一部伺服器之後註冊的每個伺服器都有一般每月費用。 雖然此費用很小，但這是帳單需要考慮的一個部分。 若要查看所需區域的伺服器註冊費用目前價格，請參閱 Azure 檔案服務定價頁面上的檔案同步一節。

      • 折扣。 自 2026 年 1 月起，擁有 軟體保證（SA） 及 Azure Arc 啟用伺服器的組織，若使用 Azure 檔案同步 代理 22 版或更新版本，將享有每台伺服器 Azure 檔案同步 全額折扣，降低營運成本。 使用版本 22 之前的 Azure 檔案同步 代理的客戶將無法享有折扣。

    • Azure 檔案儲存成本。 Azure 檔案同步會取用 Azure 檔案共用中的資源。 其中一些資源相當明顯 (例如儲存體使用量)，而其他資源可能不是 (例如交易和快照集使用率)。 對於大多數客戶，我們建議使用 HDD 佈建的 v2 檔案共用搭配 Azure 檔案同步，儘管 Azure 檔案同步在所有 Azure 檔案儲存體計費模式下均獲得完整支援 (包括 SSD 佈建的 v2、SSD 佈建的 v1 或 HDD 隨用隨付)。

      • 儲存體使用率。 Azure 檔案同步會將您對伺服器端點所做的任何變更複寫到 Azure 檔案共用，導致儲存體耗用。 在已佈建的檔案共用上，變更會取用已佈建的空間 - 您必須負責定期增加佈建，依需求考慮檔案共用成長。 在隨用隨付的檔案共用上，在伺服器端點上新增或增加現有檔案的大小會導致已使用的儲存體成本增加，因為會複寫變更。

      • 快照使用率。 Azure 檔案同步以共用和檔案層級快照集作為一般使用方式的一部分。 雖然快照使用率一律有差異，但這可能會對整體 Azure 檔案總帳單造成顯著的影響。

      • IOPS / 輸送量使用率：Azure 檔案同步會驅動 IOPS 和輸送量使用率，以將變更從伺服器端點傳輸至 Azure 檔案共用。 如果您使用佈建的檔案共用，則應監視檔案共用使用量，以確保佈建了足夠的 IOPS 和輸送量，避免發生節流。 如果您使用隨用隨付的檔案共用，則會以交易的形式向您收取 IOPS 使用率的費用。 一般來說，有兩種類型的交易需要考慮：

        • 流失的交易。 當伺服器端點上的檔案變更時，系統會將變更上傳至雲端共用，因而產生交易。 啟用雲端階層處理時，將會產生額外的交易來管理階層式檔案，包括階層式檔案上發生的 I/O，以及輸出成本。 雖然由於流失率和快取效率而難以預測交易的數量和類型，但如果您認為未來使用量與目前的使用量類似，您可以使用先前的交易模式來估算未來的成本。

        • 雲端列舉的交易。 Azure 檔案同步每天會掃描雲端中的 Azure 檔案共用，以識別直接對共用進行的變更，並將這些變更同步至伺服器端點。 這項掃描會產生交易，這些交易會依每個目錄每天一次 ListFiles 交易的費率，向儲存體帳戶收取費用。 您可以將此數位放入 定價計算機 中，以估計掃描成本。

        提示

        如果您不知道有多少個資料夾，請參考 JAM Software GmbH 的 TreeSize 工具。

    Azure 備份

    Azure 備份為 Azure 檔案儲存體提供無伺服器備份解決方案，可順暢地與您的檔案共用、Azure 檔案同步等其他增值服務進行整合。適用於 Azure 檔案儲存體的 Azure 備份，是以快照集為基礎的備份解決方案，可提供排程機制，以在系統管理員定義的排程上自動建立快照集。 它也提供使用者友善的介面，讓使用者能將已刪除的檔案、資料夾或整個分享資料還原到特定時間點。 若要深入瞭解，請參閱 關於 Azure 檔案共用備份。

    考慮使用 Azure 備份的成本時，請考慮下列因素：

    • Azure 檔案共用資料的受保護執行個體授權成本。 Azure 備份會針對包含已備份 Azure 檔案共用的每個儲存體帳戶收取受保護的執行個體授權成本。 受保護的執行個體定義為 Azure 檔案共用儲存體的 250 GiB。 包含小於 250 GiB 的儲存帳戶將承擔部分受保護實例的成本。 如需詳細資訊，請參閱 Azure 備份定價。 您必須從 Azure 備份可以保護的服務清單中選取 Azure 檔案 服務。

    • Azure 檔案儲存成本。 Azure 備份會以下列方式增加 Azure 檔案儲存體的成本：

      • Azure 檔案共用快照集的差異成本。 Azure 備份在系統管理員定義的排程上自動擷取 Azure 檔案共用快照集。 快照一律為差異型；不過，新增成本取決於快照保留時間的長短，以及這段期間檔案共用中的變動量。 這些因素會影響快照與即時檔案共用之間的差異，因此 Azure 檔案儲存體 會儲存額外的數據量。

      • 還原作業的交易成本。 將作業從快照集還原到即時共享會產生交易成本。 對於隨用隨付的檔案共用，從快照讀取和從還原寫入會視為一般檔案共用交易計費。 對於已佈建檔案共用，這些作業會計入檔案共用的已佈建 IOPS。

    微軟儲存體防護裝置

    Microsoft Defender 支援 Azure 檔案儲存體 作為其 Microsoft Defender for Storage 產品的一部分。 適用於儲存體的 Microsoft Defender 會透過 SMB 或 FileREST 偵測到針對您的 Azure 檔案共用存取或惡意探索的異常和潛在有害嘗試。 適用於儲存體的 Microsoft Defender 會在該訂用帳戶儲存體帳戶中所有檔案共用的訂用帳戶層級上啟用。

    Microsoft Defender for Storage 不支援 Azure 檔案共用的防毒功能。

    適用於儲存體的 Microsoft Defender 主要成本是一組額外的交易成本，是在針對 Azure 檔案共用執行交易上收取的產品稅。 雖然上述成本是基於發生在 Azure 檔案儲存體上的交易，但此類成本並非 Azure 檔案儲存體帳單的一部分，而是屬於 Microsoft Defender 定價的一部分。 適用於儲存體的 Microsoft Defender 即使在已佈建檔案共用上也會收取交易費率，其中 Azure 檔案儲存體會包含交易作為 IOPS 佈建過程的一部分。 在 適用於雲端的 Microsoft Defender 定價頁面上 ，可以在 適用於記憶體的 Microsoft Defender 數據表數據列底下找到目前的交易費率。

    使用適用於儲存體的 Microsoft Defender 時，交易大量檔案共用會產生大量成本。 根據這些成本，您可能會想要針對某些儲存體帳戶停用 Microsoft Defender for Storage。 如需詳細資訊，請參閱 從 Microsoft Defender for Storage 保護中排除儲存體帳戶。

    Reservations

    Azure 檔案儲存體支援已佈建 v1 和隨用隨付模型的保留 (也稱為保留執行個體)。 預約讓你透過預先承諾儲存使用率，獲得儲存費折扣。 建議針對任何正式執行工作負載，或使用模式保持不變的開發/測試工作負載，考慮購買保留執行個體。 購買訂房時，請指定以下尺寸：

    • 容量大小：預約可選擇 10 TiB 或 100 TiB，購買容量較高的預訂則有較大折扣。 您可以購買多個保留，包括不同容量大小的保留以符合您的工作負載需求。 例如，如果您的生產部署有 120 TiB 的傳統檔案共用，您可以購買一個 100 TiB 預留容量和兩個 10 TiB 預留容量，以符合總儲存容量需求。
    • 期限：您可以購買一年期或三年期的預留，而購買較長期限的預留可享有更高的折扣。
    • 階層：保留的 Azure 檔案儲存體階層。 目前已佈建 SSD v1 (進階版) 和 HDD 隨用隨付 (僅限經常性存取層和非經常性存取層) 計費模型可以使用保留。
    • 位置：保留的 Azure 區域。 保留可在 Azure 區域的子集中使用。
    • 冗餘：儲存空間的預留冗餘。 Azure 檔案儲存體支援的所有備援，包括 LRS、ZRS、GRS 和 GZRS，都支援保留。
    • 計費頻率：指出帳戶對保留計費的頻率。 選項包括 每月 或 預付。

    當您購買保留時，現有的儲存體利用率會自動使用它。 如果您使用的儲存空間超過預留容量，則需按牌價支付超出預留涵蓋範圍的部分。 交易費、頻寬費、資料傳輸費和元資料儲存費不包含在預約內。

    對於隨用隨付和已佈建的 v1 檔案共用，使用共用快照的保留運作方式有所不同。 如果您對隨用隨付的傳統檔案共用建立快照，快照差異會計入保留，並視為一般已使用儲存體計量的一部分計費。 不過，如果您對已佈建的 v1 傳統檔案建立快照，這些快照會用獨立的計量計費，且不會計入保留。

    如需有關如何購買保留的詳細資訊，請參閱使用保留最佳化 Azure 檔案儲存體成本。

    另請參閱

    • Last updated on