觀點 · 資訊分享
Azure 擴展集「可用區自動平衡」正式上線：VM 擠在同一區，系統會一台一台幫你搬平
Azure 虛擬機器擴展集的可用區自動平衡正式 GA：發現 VM 偏向某個可用區時，會先在 VM 最少的區建新機、確認健康後才刪掉多的那台，一次只搬一台。
- 發布
- 2026-10-16
- 篇幅
- 約 4 分鐘 · 1,932 字
- 結構
- 7 節 + 4 題常見問題
- 標籤
一句話看懂：Azure 虛擬機器擴展集的「可用區自動平衡」正式上線，VM 偏向某個可用區時，系統會先建新機、確認健康再刪舊機，一台一台把數量拉平。
先用白話講：可用區自動平衡是什麼？
想像一家連鎖飲料店在同一個城市開了三家分店，總共排了 9 位店員。理想狀況是每家 3 位，這樣某家店停電，另外兩家還能撐住。可是經過幾次排班調動，變成 A 店 1 位、B 店 4 位、C 店 4 位，萬一 B 店停電，一口氣就少了將近一半人手。
雲端的「可用區」就像這些分店：同一個地區裡，電力和網路各自獨立的幾個機房。可用區自動平衡就是一位會自己看班表的店長，發現人數不平均時，先在人少的店補一位新人，確認他上手了，再從人多的店調走一位。
發生什麼事
Microsoft 在 10 月 15 日的 Azure 更新公告中宣布，虛擬機器擴展集（VMSS）的可用區自動平衡正式上線（GA）。依照官方文件，運作方式是：
- 怎樣算平衡：每個可用區的 VM 數量，跟其他區相差不超過 1 台
- 先建後刪：在 VM 最少的區建新 VM，新 VM 健康之後，才刪掉 VM 最多那區的一台
- 一次一台：每次只搬 1 台，兩次搬移之間還有冷卻時間，避免一次動太多
- 等健康最多 90 分鐘：新 VM 超過 90 分鐘還不健康，就改看舊 VM：舊的健康就刪新的，舊的不健康就刪舊的、留新的
- 不打擾變更：擴展集過去 60 分鐘內有新增、刪除、升級這類操作，就先不搬
開之前要注意的事
| 注意事項 | 說明 |
|---|---|
| 暫時多 1 台 | 先建後刪，搬移期間會多一台 VM，自動調整的上限與訂閱配額要留空間 |
| 跟自動調整的互動 | 搬移中遇到縮減，會等搬完再縮；遇到擴增，這次搬移直接取消 |
| 不保留身分 | 搬移是刪掉重建，VM 的 ID、網路設定、磁碟都不會保留 |
| 規格會變新 | 新 VM 一律用擴展集設定裡最新的規格（SKU） |
| 不是故障備援 | 它不偵測可用區故障，不能拿來當區域停擺的復原機制 |
所以官方建議只用在無狀態的服務，例如網站前台、API 伺服器。資料庫這類會在本機存資料的服務不適合。
給開發者的技術細節
開啟前要先滿足三個條件：至少跨 2 個可用區、所有 VM 都是指定可用區的 zonal 執行個體、啟用應用程式健康監控（Application Health 擴充功能或負載平衡器健康探查，二選一）。Compute API 版本要 2024-07-01 以上。
用 Azure CLI 對既有擴展集開啟：
az vmss update \
--resource-group myResourceGroup \
--name myVMScaleSet \
--enable-automatic-zone-balancing true \
--automatic-zone-balancing-behavior CreateBeforeDelete \
--automatic-zone-balancing-strategy Recreate
- 開啟時會預設一併開啟自動修復（automatic instance repairs）；不想要可以加
--enable-auto-repairs false - 不想被搬的 VM，可以套用執行個體保護原則
- 搬移紀錄可以在活動記錄裡篩選
BalanceVMsAcrossZones查看
我的看法
中小企業的系統大多不會用到擴展集，但只要客戶開始要求「機房出事也不能停」，跨可用區就是第一步。麻煩的是，分散部署之後很少有人會回頭檢查 VM 是不是還分得平均，往往是真的出事了才發現大部分機器都擠在同一區。
這個功能把「定期檢查、手動調整」變成自動的，對人力有限的團隊很實用。不過要記得它是靠刪掉重建來搬，所以前提是你的服務本身就是無狀態的：設定、檔案、工作階段都放在外部的資料庫或儲存服務。如果服務還依賴本機磁碟，先改架構，再開這個功能。
名詞小辭典
- VMSS（虛擬機器擴展集）：一群設定相同的虛擬機器，可以依流量自動增加或減少數量。
- 可用區（Availability Zone）：同一個雲端地區裡，電力、網路、冷卻各自獨立的機房。
- 無狀態（Stateless）：服務本身不在機器上保存資料，任何一台壞掉換新的都能直接接手。
- GA（正式上線）：功能結束預覽，正式提供給所有客戶在正式環境使用。