AVD 自動調整與自動化主機池：成本模型

我審閱過的每一份 Azure Virtual Desktop 帳單都長得一樣：運算是遙遙領先的最大一項，而其中相當大一部分是在凌晨 2 點為空無一人的環境執行。自動調整正是解決這個問題的功能，而我在 2026 年 6 月 Azure Virtual Desktop 更新彙整中介紹的自動化主機池與動態自動調整讓它變得更好。但美國 IT 團隊問我的問題不是「自動調整能省錢嗎」，而是「對我們來說能省多少，我們需要改什麼」。本指南用一個你可以直接複製到試算表裡的成本模型來回答：成本構成、兩種自動調整方法的差異、附公式的範例、依影響排序的槓桿、防止省錢變成服務台工單的護欄，以及如何在 Azure Cost Management 中衡量結果。每一條功能聲明都經過內文連結並列在「資料來源」中的 Microsoft Learn 頁面核對。單價故意留作預留位置：它們因區域與合約而異，對你來說正確的數字是你登入 Azure 定價計算機後取得的那些。

Azure Virtual Desktop 的錢花在哪裡

Microsoft 的 Azure Virtual Desktop 定價頁面把帳單描述為兩部分：使用者存取權，以及由虛擬機器、OS 映像/資料磁碟/使用者設定檔的儲存體與網路組成的 Azure 基礎結構，按隨用隨付或保留方式計費。實務上我把它拆成七行，因為開啟自動調整後它們的表現各不相同。

模型中有兩個授權要點。第一，對於 Windows 11 企業版多重工作階段的工作階段主機，符合資格的授權包括 Microsoft 365 E3、E5、A3、A5、F3、商務進階版與學生使用權益，Windows 企業版 E3 與 E5，Windows 教育版 A3 與 A5，以及 Windows VDA 每位使用者授權；授權頁面明確指出，每一位存取該服務的使用者都必須配備一份，而多重工作階段 FAQ指出這種每位使用者的 Windows 授權取代了 RDS 用戶端存取授權。第二，Windows Server 工作階段主機需要具備軟體保證的 RDS CAL 或 RDS 使用者訂閱授權，這正是後文 Windows Server 的 Azure Hybrid Benefit 發揮作用的地方。自動調整時這兩條授權行都不會變動，這就是為什麼運算項上的標題百分比總是大於總帳單上的百分比。

電源管理自動調整與動態自動調整

各自做什麼

自動調整詞彙表定義了兩種調整方法。電源管理自動調整「開啟與關閉工作階段主機以調整主機池中的可用容量」，是標準管理主機池的方法。動態自動調整「開啟與關閉工作階段主機，並建立與刪除工作階段主機以調整主機池中的可用容量」，只能用於具備工作階段主機組態的集區式主機池。兩者執行相同的排程：爬升、尖峰、爬降與離峰階段，每個階段都有負載平衡演算法、最低主機百分比與容量閾值。兩者在爬降期間使用完全相同的整併邏輯；Microsoft 的情境逐步解說說「唯一的差別是電源管理解除配置工作階段主機，而動態自動調整可以刪除工作階段主機。」

同一頁面還有兩條可用性說明。電源管理自動調整在 Azure 與 Azure Government 中所有可以建立主機池的區域均可用。動態自動調整僅在 Azure 中可用，不支援 Azure Government，而且在我撰寫本文時 Learn 頁面上仍標示為預覽版。

先決條件

以上全部來自建立並指派調整計畫指南，該指南還警告在低於訂用帳戶的範圍指派這些角色「會導致自動調整無法正常運作」。管理方式本身只能決定一次：主機池管理方式頁面提醒它「在建立主機池時設定，之後無法變更。如果建立主機池時沒有工作階段主機組態，之後也無法再新增。」

各自適用的情境

如果你執行標準主機池，並用自己的 Terraform、Bicep 或管線加註冊權杖來建置主機，那麼電源管理是你唯一的選項，而且它已正式推出。如果你執行工作階段主機組態主機池，動態自動調整是自然的選擇，而自動調整 FAQ說明了如何塑造它：把 Minimum host pool size 設為等於 Maximum host pool size，它的行為就和電源管理一樣；把 Minimum percentage of active hosts (%) 設為 100，它就只建立與刪除。動態自動調整建立的主機使用「預設工作階段主機組態中定義的最新有效/穩定映像版本」，所以你的映像管線直接為自動調整供料。個人主機池使用另一種排程：工作階段中斷連線或登出 0 到 360 分鐘後解除配置、休眠或什麼都不做，並在早上使用「連線時啟動 VM」。FSLogix 與 App Attach 不支援休眠，所以使用這兩者的個人池應該選擇解除配置。

成本模型

變數

下面的模型就是我交給客戶的那個。它刻意保持簡單：小時數是自動調整改變的那一項，所以模型把小時數單獨隔離出來。

公式

P          = U × C                                           peak concurrent sessions
H          = ceil( P / (S × T) )                             hosts running at peak
Hours_on   = N × 730                                         always-on host-hours per month
Hours_as   = D × (R × h_up + H × h_peak + R × h_down + F × h_off) + W × F × 24
Compute    = Hours × p_vm
Disks      = DiskMonths × p_disk                             persistent OS disks
Profiles   = GiB_prov × p_gib + IOPS_prov × p_iops + MiBps_prov × p_tp   (Azure Files provisioned v2)
Egress_GB  = P × h_active × D × kbps × 0.45 / 1000           0.45 MB per kbps-hour
Egress     = max(Egress_GB - 100, 0) × p_egress
Licences   = U × your per-user licence (outside the Azure bill for internal users)

H 的公式是 Microsoft 自己的。自動調整 FAQ寫明「所需主機數 = 工作階段總數 /（最大工作階段限制 x 容量閾值 %）」，無條件進位。它是針對爬降期間的整併而寫的，但同樣的算術決定了自動調整在穩態下保持開啟的主機數，因為只要已用容量超過閾值它就會開啟主機。

範例

代入範例值：

每位使用者 30 GiB 來自大小調整指南的最低設定檔儲存體欄；150 kbps 是 Microsoft RDP 頻寬估算中預設模式下活躍使用 Word 與 Excel 的中間值，在 1080p 下範圍是 100 到 200 kbps。該頁面上影片、PowerPoint 與圖片密集的瀏覽是以 Mbps 計量的，所以如果你的使用者會做這些事情，請另外建模。

自動調整如何改變小時數項

自動調整把運算項從 23,360 降到 8,011 主機小時，即原來的 34%，削減了大約三分之二，而且沒有用到任何折扣、沒有調整大小、使用者白天看到的一切都沒有改變。模型中的其他一切都保持原樣。這就是誠實的標題：自動調整是一個運算槓桿，如果運算佔你帳單的 60%，那麼運算項省三分之二就是總額省 40%。

在調校之前有兩個敏感度值得了解。在 30 台主機上每多一個尖峰小時就每月多 30 × 21 = 630 主機小時，所以為一個 8:30 登入的團隊把爬升設在 6:00 的排程，是在為 1,260 主機小時的空氣付費。夜間底線每多一台主機就每月多 10 × 21 + 24 × 9.4，約 436 主機小時；把底線從兩台提到四台要花 871 主機小時，佔整個自動調整後帳單的 11%。底線是好意葬身之地，所以要依據 Insights 中真實的下班後工作階段資料來決定它，而不是出於恐懼。

動態自動調整不會進一步改變小時數項；一台執行中的主機無論是被開機還是被建立，成本都一樣。它改變的是磁碟項與已停止 VM 的佔用。使用電源管理時，32 顆持續性 OS 磁碟整月計費；使用動態自動調整時只有最小池大小整月存在，而使用暫時性 OS 磁碟時被建立主機的儲存費用完全消失。

依影響排序的槓桿

這是我為典型美國知識工作者主機池給出的排序。如果你已經落實了其中某一項，順序可能會不同。

1. 排程小時數與底線。 如上所示。在第一批真實登入出現時開始爬升，在最後一批真實登出發生時開始爬降，如果你下班後的工作階段確實為零，就把離峰最低主機百分比設為 0%。沒有其他任何一項能與之相比。
2. 密度假設：C 與 S。 我接手的大多數環境都假設 100% 並行與一個保守的工作階段限制。用一個月的 Insights 工作階段計數來測量 C。對於 S，大小調整指南給出的每 vCPU 最大使用者數為輕量 6、中等 4、重度 2、高效能 1，建議 8 vCPU 與 16 GB 作為多重工作階段主機的最低設定，並建議把多重工作階段主機保持在 4 到 24 vCPU 之間，因為「兩台 16 核心 VM 的使用者體驗優於一台 32 核心 VM」。指南還指出，更多的小主機會留下更多沒有使用者的主機可以關閉，而這正是自動調整所需要的。
3. 為 VM 系列選對大小。 同一頁面說 CPU 擴充不是線性的（每翻倍一次係數為 1.5 到 1.9），而且當記憶體是瓶頸時，從 8 GB 增加到 16 GB「可以讓你支援的使用者數增加一倍以上」。在改變大小之前，用 Insights 的主機效能索引標籤看看哪種資源最先飽和。選擇具備本機儲存體的 v5 或 v6 D 系列大小，讓暫時性 OS 磁碟仍是一個選項。
4. 只對基準使用承諾折扣。 Azure 保留在一年或三年期限內相比隨用隨付最高可節省 72%，按小時套用，而且只涵蓋 VM 運算計量：「它不涵蓋額外的軟體、Windows、網路或儲存體費用。」由於未使用的保留小時會作廢，每月執行 h 小時的主機只有在 h ÷ 730 > 1 − 折扣率時才能回收成本。在範例中，兩台底線主機執行 730 小時，是顯而易見的保留候選；30 台尖峰主機在 21 個工作日裡每天執行約 14 小時，即 294 小時或一個月的 40%，只有折扣率超過 60% 時才划算。請在定價計算機中查看你的大小與期限的實際百分比，而不是憑假設。執行個體大小彈性讓保留可以在同一群組內的不同大小之間浮動，這在你日後調整大小時提供保護。對於可變層，Azure 運算節省方案是一項按小時的美元承諾，適用於不同大小、區域與運算服務；它同樣不包括軟體、網路與儲存體，而且購買後不能取消或退款。Microsoft 自己的順序是：先調整大小，交換或折抵未充分使用的保留，然後為穩定用量購買新保留，最後再加入節省方案。對於 Windows Server 工作階段主機，如果你擁有具備軟體保證的核心授權，Azure Hybrid Benefit 可以免除 Windows Server 軟體費用，每台 VM 至少需要 8 個核心授權。Windows 11 多重工作階段主機則透過使用者的授權取得 Windows 權利。
5. 暫時性 OS 磁碟。 暫時性 OS 磁碟頁面明確指出「已停止（已解除配置）」狀態與停止/啟動「不支援」，所以它們不能與會解除配置主機的計畫搭配。它們可以與動態自動調整的建立與刪除行為搭配，而且適合 AVD，因為一旦設定檔存放在 FSLogix 中，主機就是無狀態的。限制：映像必須能放進 VM 的快取、暫存或 NVMe 磁碟（最多 2,040 GiB），而且不支援 VM 映像擷取、磁碟快照、Azure 磁碟加密、Azure 備份、Azure Site Recovery 與 OS 磁碟交換。如果為了更高的 SLA 選擇標準 SSD 或進階 SSD 基底磁碟，你需要支付該基底磁碟費用。
6. 解除配置原則。 處於*已停止（已配置）狀態的 VM 仍按運算計費；只有已停止（已解除配置）*才會停止計費。自動調整執行的是解除配置，這正是你想要的。對於個人池，把中斷連線與登出動作設為解除配置（如果涉及 FSLogix 就不要用休眠），並啟用連線時啟動 VM，讓使用者可以自己喚回桌面。
7. FSLogix 儲存體層級。 FSLogix 儲存體比較為大多數客戶推薦 Azure 檔案儲存體，少於 200 位使用者的輕量工作負載用標準檔案共用，其他一切用進階，並指出 Azure NetApp Files 的效能「是層級乘以容量的函數」，所以在較低層級佈建更多容量可能是達到 IOPS 目標更便宜的方式。Azure 檔案儲存體計費指南建議所有新部署使用佈建 v2 模型，並指出 Azure 檔案儲存體保留最高可為儲存體提供 36% 的折扣。
8. 區域選擇。 VM、磁碟與輸出流量價格因區域而異，輸出費率因洲別而異。調整計畫的設定必須與主機池設定位於同一區域，但工作階段主機可以在任何區域，所以你可以把中繼資料留在原地，把主機放到價格與延遲平衡最好的地方。不要為了更便宜的區域犧牲來回時間；大小調整指南把延遲、封包遺失與抖動列為直接影響使用者體驗的因素。

護欄

爬升與爬降的時間點

自動調整在爬升期間不會關閉主機，所以開始得太早的爬升只是在燒小時數。在第一波登入前 30 到 60 分鐘開始，並設定較高的最低主機百分比，動態自動調整指南建議把它延續到尖峰階段。在爬降中，強制登出只在該階段發生，而且只在你設定的等待時間之後；FAQ 精確給出了失敗模式：「如果爬降階段長 15 分鐘，而登出使用者與關閉 VM 前的等待時間長 20 分鐘，排程就會切換到離峰階段，使用者工作階段不會被強制登出。」讓爬降階段比等待時間更長。如果你的排程只涵蓋週一到週五，週五的離峰設定會延續整個週末直到週一的爬升，這正是底線所需要的。

清空模式與排除標籤

自動調整會覆寫清空模式：「無論是誰把 VM 置於清空模式，自動調整仍會開啟或關閉處於清空模式的 VM。」進行維護時，給主機加上調整計畫的排除標籤（Microsoft 的範例是 excludeFromScaling），自動調整就不會啟動、停止或變更它的清空模式。Learn 頁面有兩條提醒：打了標籤的主機仍計入最低主機百分比；如果你給每台主機都打上標籤並關機，使用者會看到「沒有可用資源」，因為自動調整沒有可以啟動的主機了。

縮減期間的使用者體驗

除非在爬降中啟用了強制登出，自動調整只會關閉沒有工作階段的主機；當它選中一台主機時，會先將其置於清空模式，傳送你設定的通知訊息，等待，然後登出並解除配置。因為主機處於清空模式，重新連線的使用者會落在一台存活的主機上，而不是即將關閉的那台。在爬升與尖峰使用廣度優先負載平衡以確保效能，在爬降與離峰使用深度優先，讓工作階段整併到更少的主機上，這是 FAQ 推薦的模式。再搭配群組原則或 Intune 設定 Set time limit for disconnected sessions（Microsoft 範例中為 15 到 30 分鐘），中斷連線的工作階段就不會整夜佔著主機。

應對登入風暴的容量

連線時啟動 VM 不是登入風暴工具；對於集區式主機池，它每五分鐘最多啟動一台 VM，在這個視窗內到達的使用者會收到「沒有可用資源」。你的防線是具備合理最低主機百分比的爬升階段。如果你所在區域容量緊張，隨選容量保留可以保證你指定的 VM 大小與數量，沒有期限承諾，但無論是否有 VM 在使用，你都要為保留容量支付 VM 費率，而已使用與未使用的保留容量都可以享有保留與節省方案折扣。只保留尖峰那一部分，而不是整個池，而且只在部署失敗確實困擾過你的地方這麼做。

衡量

Azure Cost Management 檢視

成本分析智慧檢視提供 KPI、異常洞察，以及從訂用帳戶到資源群組到資源再到計量的逐級深入；保留檢視顯示過去 30 天的攤銷使用率。在 AVD 資源群組上建立附警示的預算，在訂用帳戶上啟用異常警示，並每週檢查；Microsoft 建議在任何變更後的頭一兩週每天檢查，而這正是新調整計畫上線的時候。

標籤

用工作階段主機資源群組與主機池上的標籤依主機池對成本分組。在 Enterprise Agreement、Microsoft 客戶合約與 Microsoft 合作夥伴合約帳戶上，開啟標籤繼承，資源群組與訂用帳戶標籤就會在大約 24 小時內套用到子資源的使用記錄；之後你就可以依據繼承的標籤建立篩選預算。動態自動調整建立的主機會從工作階段主機組態繼承 VM 標籤，所以請在那裡設定標籤，而不是在個別 VM 上。

Insights 與自動調整活頁簿

Azure Virtual Desktop Insights 需要一個專用的 Log Analytics 工作區、主機池與工作區上的診斷設定，以及工作階段主機上具備資料收集規則的 Azure Monitor 代理程式；位於 aka.ms/avdi 的設定活頁簿會把這些全部設定好。把 Autoscale logs for pooled host pools 類別新增到主機池診斷設定中，Insights 裡就會出現自動調整索引標籤，顯示電源狀態隨時間的變化。底層資料表是 WVDAutoscaleEvaluationPooled，它為每次評估記錄 SessionOccupancyPercent、ActiveSessionHostCount、排程階段與 ScalingReasonMessage。這條查詢能告訴你容量閾值與底線是否合適：

WVDAutoscaleEvaluationPooled
| where ResultType == "Succeeded"
| summarize max(SessionOccupancyPercent), max(SessionCount), max(ActiveSessionHostsPercent), max(ActiveSessionHostCount)
    by _ResourceId, bin(TimeGenerated, 1d), ConfigScheduleName, ConfigSchedulePhase
| order by _ResourceId asc, TimeGenerated asc, ConfigScheduleName, ConfigSchedulePhase asc

失敗的評估透過 CorrelationId 與 WVDErrors 聯結。個人池不能使用 Insights 索引標籤；請把它們的自動調整記錄傳送到儲存體帳戶或事件中樞。

每月要檢視什麼

• 每個主機池的運算主機小時數與模型的比較，以及來自 WVDAutoscaleEvaluationPooled 的依排程階段劃分的小時數。
• 每個階段的 SessionOccupancyPercent 峰值。如果它從未接近閾值，就提高閾值或降低最低主機百分比。
• 離峰的 ActiveSessionHostCount。如果它高於底線，就找出佔著主機的中斷連線工作階段。
• 成本分析中的保留與節省方案使用率；保留上任何低於 100% 的部分都是你預付了卻沒用上的錢。
• 磁碟月數與主機數的比較；使用動態自動調整時兩者應當分離。
• 以 GB 計的 Log Analytics 擷取量，它會隨著你新增計數器而悄然增長。
• 工作階段主機組態中的映像版本，確保自動調整不是在用舊版本建立主機。

該怎麼做

1. 從成本分析中依計量匯出上個月的 AVD 成本，填入七行成本項；記下運算項的百分比。
2. 從 Insights 取得 30 天的工作階段計數，計算你真實的並行比與真實的下班後工作階段數。
3. 確認主機池管理方式。標準意味著電源管理自動調整；工作階段主機組態意味著可以使用動態自動調整。
4. 依據你的工作負載類型與主機大小，按大小調整指南設定自訂 MaxSessionLimit；預設值會阻止自動調整。
5. 在訂用帳戶範圍指派 Desktop Virtualization Power On Off Contributor（動態還需要 Desktop Virtualization Virtual Machine Contributor）。
6. 依據資料建立排程：在首次登入前 30 到 60 分鐘開始爬升，爬降要比強制登出等待時間更長，如果下班後工作階段為零就把離峰最低值設為 0%。
7. 透過 Intune 或群組原則部署 Set time limit for disconnected sessions，讓主機池真正能降到底線。
8. 在調整計畫中定義排除標籤，並把它寫進你的維護執行手冊。
9. 啟用 Insights，新增自動調整記錄類別，兩週後執行佔用率查詢；一次性調整閾值與底線。
10. 到這一步才購買：為高於損益平衡使用率的主機購買保留，為其餘部分購買節省方案，為任何 Windows Server 主機啟用 Azure Hybrid Benefit，為將長期保留的設定檔儲存體購買 Azure 檔案儲存體保留。
11. 如果主機池使用工作階段主機組態，在新映像版本上測試暫時性 OS 磁碟，並讓動態自動調整來建立主機。
12. 在資源群組上設定預算與異常警示，並給工作階段主機組態加上標籤，這樣下一台被建立的主機就已經歸屬到成本中心。

常見問題

Azure Virtual Desktop 自動調整能節省多少錢？ 這取決於你的主機目前有多少小時是在為空無一人的環境執行。自動調整本身不收費；FAQ 對「使用自動調整會額外收費嗎？」的回答是「不會」。在範例中，一個 32 台主機、每天執行 24 小時的池每月消耗 23,360 主機小時，而同一個池採用具備 2 台主機底線的平日排程後約為 8,000，運算項削減了大約三分之二。設定檔儲存體、授權與輸出流量不會改變，所以總帳單的節省比例小於運算項的節省比例。

AVD 中電源管理自動調整與動態自動調整有什麼差別？ 電源管理自動調整開啟與關閉（解除配置）主機，是標準管理主機池的方法。動態自動調整還會建立與刪除主機，而且只適用於具備工作階段主機組態的集區式主機池。兩者使用相同的階段、容量閾值與整併邏輯；差別在於最終動作，是解除配置還是刪除，而這正是改變 OS 磁碟成本的地方。

我應該為自動調整的 AVD 工作階段主機購買 Azure 保留嗎？ 只為每月大部分時間都在執行的主機購買。保留按小時套用，未使用的小時會作廢，所以每月執行 h 小時的主機只有在 h ÷ 730 大於 1 減去折扣率時才能回收成本。為夜間底線與整個工作日都執行的主機購買保留，為可變層考慮節省方案，並記住兩者都不涵蓋 Windows 軟體、儲存體或網路。

我可以在 AVD 自動調整中使用暫時性 OS 磁碟嗎？ 不能與會解除配置的計畫搭配。Learn 頁面把暫時性 OS 磁碟的停止並解除配置與停止/啟動標為不支援。它們適合動態自動調整，後者依據工作階段主機組態建立與刪除主機，並且可以消除無狀態主機的 OS 磁碟儲存費用。你需要具備本機儲存體的 VM 大小，而且這些主機將無法使用 Azure 備份、Site Recovery 與磁碟快照。

為什麼下班後沒人工作，自動調整仍讓工作階段主機保持執行？ 因為中斷連線的工作階段也算。自動調整假定中斷連線的使用者可能會重新連線，並依「所需主機數 = 工作階段總數 ÷（最大工作階段限制 × 容量閾值）」為他們保留執行中的主機。要降到零主機，就必須有零工作階段，包括中斷連線的工作階段：設定 Set time limit for disconnected sessions，讓它們在爬降結束前登出，並把離峰最低主機百分比設為 0%。

如果你在調校之前仍在決定 AVD 是否是某個使用者群的正確平台，Windows 365 與 Azure Virtual Desktop 的比較涵蓋了每位使用者固定價格的情形，而 Azure Virtual Desktop 新功能系列會在 Microsoft 發布自動調整與工作階段主機組態的變化時持續追蹤。

需要多一雙手嗎？Big Hat Group 為美國與加拿大的組織提供 Azure Virtual Desktop 架構與成本檢視服務，從為期兩週的自動調整健康檢查到完整的主機池重新設計。預約一次探索通話，聊聊你的環境。

資料來源

• Autoscale scaling plans and example scenarios in Azure Virtual Desktop
• Create and assign an autoscale scaling plan for Azure Virtual Desktop
• Azure Virtual Desktop autoscale glossary
• Azure Virtual Desktop autoscale FAQ
• Host pool management approaches
• Licensing Azure Virtual Desktop
• Windows Enterprise multi-session FAQ
• Session host virtual machine sizing guidelines
• Remote Desktop Protocol bandwidth requirements
• Storage options for FSLogix profile containers in Azure Virtual Desktop
• Understand Azure Files billing
• Ephemeral OS disks for Azure VMs
• States and billing status of Azure Virtual Machines
• What are Azure Reservations?
• Virtual machine size flexibility with Reserved VM Instances
• What are Azure savings plans?
• Decide between a savings plan and a reservation
• Explore Azure Hybrid Benefit for Windows VMs
• On-demand capacity reservation in Azure
• Drain session hosts for maintenance in Azure Virtual Desktop
• Configure Start VM on Connect for Azure Virtual Desktop
• Enable Insights to monitor Azure Virtual Desktop
• Monitor Autoscale operations with Insights in Azure Virtual Desktop
• Set up diagnostics for Autoscale in Azure Virtual Desktop
• Quickstart: Start using Cost analysis
• Group and allocate costs using tag inheritance
• Azure Virtual Desktop pricing
• Azure Pricing Calculator
• Windows Virtual Machines pricing
• Managed Disks pricing
• Azure Files pricing
• Bandwidth pricing