Azure 架構
打破雲地邊界：Azure Arc 混合雲與多雲管理實踐
打破雲地邊界：Azure Arc 混合雲與多雲管理實踐
多數企業的現實不是「上雲」，是「一半在雲、一半在機房、還有一塊在別家雲」。每一塊都有自己的管理工具、自己的權限系統、自己的稽核報表。
Azure Arc 想解的就是這件事。它不搬你的機器，它把 Azure 的控制平面伸出去，讓那些機器變成 Azure 管得到的資源。這篇談它怎麼做到，以及什麼情況你其實不需要它。
你將學到什麼
延伸的是控制平面
把非 Azure 資源投影進 Azure Resource Manager，運算與資料仍留在原地。
收得進來的東西
伺服器與虛擬機、Kubernetes 叢集、SQL Server，以及跑在任意 Kubernetes 上的資料服務。
多雲現況
多雲連接器支援 AWS，Google Cloud 為預覽，可做清查與自動上線。
什麼時候別用
只想要一面儀表板、沒打算把治理一起搬過去的話，Arc 幫不上忙。
Arc 不是「把地端變成雲」，是「把管雲的方式借給地端」。這兩句聽起來很像，但決定了你導入之後會不會失望。
它延伸的是控制平面，不是運算
官方對 Azure Arc 的定位是提供一致的多雲與地端管理平台。實際做法只有一句話：把既有的非 Azure 與地端資源投影進 Azure Resource Manager。
投影完成之後，那台在你機房裡的伺服器，在 Azure 裡就有一個代表它的資源物件。你可以對它下標籤、指派 RBAC 角色、套用 Azure Policy、用 Resource Graph 查詢它。
這件事的價值要放在治理的脈絡裡才看得出來。Azure Policy 的官方文件直接寫著，有了 Azure Arc，你可以把以政策為基礎的治理延伸到不同的雲端供應商，甚至自家資料中心。
收得進來的東西有哪些
官方列出目前可以透過 Arc 管理的 Azure 外部資源類型，共四類。每一類進來的方式與拿到的能力都不太一樣。
| 資源類型 | 進得來的東西 | 拿到什麼 |
|---|---|---|
| 伺服器與虛擬機 | Azure 之外的 Windows 與 Linux 實體機、虛擬機 | 與原生 Azure VM 類似的營運操作，可裝 VM 擴充 |
| Kubernetes 叢集 | 跑在任何地方的叢集，支援多種散發版 | 大規模治理，GitOps 佈署設定，Policy 零接觸合規 |
| Azure 資料服務 | 在你選的 Kubernetes 與基礎設施上跑 SQL 受控執行個體 | 升級、更新、安全與監控，可彈性擴充 |
| SQL Server | 託管在 Azure 之外的 SQL Server 執行個體 | 把 Azure 服務延伸到這些執行個體上 |
共通的那一層是 Azure 的管理服務：Defender for Cloud、Microsoft Sentinel、Azure Automation、Update Manager、變更追蹤與清查、Azure Monitor，以及 Windows Server 與 SQL Server 的延伸安全性更新。
有一個常被忽略的能力叫自訂位置。它建在 Arc 啟用的 Kubernetes 叢集之上，當成部署目標，於是 Arc 版資料服務、Container Apps on Arc、Event Grid on Kubernetes 都能落到你自己的叢集上。
多雲：2026 年的連接器現況
把地端收進來只是一半。另一半是別家公有雲，這件事現在由「多雲連接器」負責。官方目前列出支援的來源雲是 Amazon Web Services，以及處於預覽階段的 Google Cloud Platform。
- 清查：把來源雲的資源在 Azure 裡呈現成最新檢視，可用 Azure Resource Graph 查詢，也能套上 Azure 標籤與 Azure 政策。連接器會定期掃描來源雲保持同步。
- 伺服器自動上線：自動探索 AWS 的 EC2 執行個體與 GCP 的虛擬機，並安裝 Azure Connected Machine 代理程式，讓它們直接進入 Arc。
- EKS 叢集自動上線（預覽）：自動探索 AWS 的 Amazon EKS 叢集並安裝 Arc 版 Kubernetes 代理程式。
- 儲存體資料管理：讀取 AWS 環境中的 Amazon S3，用於設定雲對雲遷移的資料連線。
多雲連接器也可以跟 Defender for Cloud 既有的 AWS、GCP 連接器並存。兩者目的不同，一個管清查與上線，一個管安全態勢，官方明確說可以一起用。
什麼情況才真的需要 Arc
我看過最多的失望，都來自把 Arc 當成「統一戰情室」在買。它確實會給你一個統一視圖，但那是副產品，不是主菜。以下這些情境才是它真正發揮價值的地方。
- 你要把同一套政策與安全基準套到 Azure 之外的機器上，而不是各環境各自維護一份。
- 你要在非 Azure 的機器上用 Defender for Cloud、Sentinel、Update Manager 這些 Azure 服務，而不想再導入第三套工具。
- 你要為其他公有雲或 vCenter 環境裡的 Windows Server 與 SQL Server 大規模採購延伸安全性更新。
- 你要讓應用團隊用 Azure RBAC 自助開關虛擬機。這需要 Arc-enabled VMware vSphere 或 Azure Local，單純的 Arc-enabled servers 沒有這個能力。
- 你有很多 Kubernetes 叢集散在各處，想用 GitOps 從 Git 倉庫統一佈署設定，並用 Azure Policy 做零接觸合規。
反過來，這幾種情況我會建議先不要動：機器數量少而且地端工具已經很成熟；只想要看板不打算搬治理；資源落在多雲連接器不支援的雲或 Region；以及期待 Arc 幫你增加運算容量的。
那斷線環境呢？間接連線模式已經沒了
舊資料裡常見的「間接連線模式」已於 2025 年 9 月退場，規劃架構時不要再照那個假設走。需要在斷線情境下運作的話，官方的路線是 Azure Local，它支援連線與離線兩種部署，並以 Azure Arc 作為統一的控制平面。
導入之前先確認的五件事
- 先確定治理骨架已經在了。管理群組階層與政策沒有先想清楚，Arc 收進來的資源只會讓混亂變大。
- 選對 Arc 服務。官方建議依機器所在位置決定，不確定就從 Arc-enabled servers 起步，之後再加資源橋接。
- 對照 Region 支援。各 Arc 服務的 Region 可用性不同，偏好的 Region 沒有專門版本時，就用 Arc-enabled servers。
- 先跑一個範圍很小的試點。挑十台左右、屬性一致的機器，把政策指派完整跑過一輪，包含合規報表長什麼樣。
- 把混合工作負載放進登陸區階層。官方登陸區參考架構已經有一個專屬的 Local 管理群組，收 Azure Local 叢集與跑在上面的工作負載。
Arc 屬於微軟稱為「調適雲」的整體路線，核心主張是把雲的管理方式帶到你所在的地方。這個說法聽起來像行銷語言，但落到工程上其實很具體：控制平面統一，執行位置自由。
所以評估 Arc 的問題從來不是「它能不能管我的機器」，而是「我有沒有一套值得套到所有機器上的規則」。有的話它很值得；沒有的話，先把那套規則寫出來比較要緊。
