企業級雲端的治理骨架：Azure 全球基礎設施與 CAF 落地方法論

多數企業不是敗在選錯服務，而是敗在沒有骨架。訂用帳戶隨手開、權限隨手給，一年後沒有人說得出哪一包資源屬於誰、誰有權改它。

這篇把三件事串成一條線：Azure 的地理層級怎麼決定故障邊界、雲端採用架構 CAF 在 2026 年長什麼樣、管理群組與 Azure Policy 又怎麼把規則變成真的擋得住的護欄。

把治理當成上線前的一次性儀式，它就只是一份沒有人再打開的文件；把它當成骨架，它會決定你三年後還敢不敢動這套系統。

骨架的第一層：先決定東西放在地球上的哪裡

Azure 的 Region 是一組實體設施，包含資料中心與網路基礎設施，通常落在同一個大都會區內。每個 Region 都屬於某一個 geography，而 geography 是固定的資料落地邊界。

順序不能顛倒。有資料落地要求的時候，先選對 geography，再從裡面挑 Region。官方也註明每個 geography 至少會有一個具備可用區的 Region。

可用區的官方定義是「具備獨立電力、冷卻與網路連線的獨立資料中心群」。它們彼此夠近，所以能維持低延遲；又夠遠，所以單一風暴或停電不會讓它們一起倒。

還有一類東西不在這個框架裡：非區域服務。它們不綁單一 Region，規劃營運持續計畫時要另外算進去。

CAF 在 2026 年的樣子：七個階段，七個問題

雲端採用架構（Cloud Adoption Framework，簡稱 CAF）不是一套產品，是一份給決策者的路線圖。官方把它拆成七個階段，每個階段對應一個必須回答的關鍵決策。

前四個是順序走完的基礎階段，後三個是持續運轉的營運階段。它們不是做完就收起來的清單，而是環境一直變、就要一直回訪的三條線。

CAF 另有延伸情境掛在這個基礎上，例如資料平台、AI 採用，以及 2026 年新增的 AI 代理採用指引。

登陸區：Ready 階段真正的產出

CAF 走到 Ready，交出來的東西叫做 Azure 登陸區。官方定義它由兩個部分組成：平台登陸區（通常每個 Microsoft Entra 租戶一個）與應用程式登陸區（每個工作負載一組）。

在動手部署之前，官方要你先走過八個設計領域。前四個決定環境的骨架，後四個決定合規怎麼持續維持。

• 環境設計：計費與 Entra 租戶、身分與存取管理、資源組織、網路拓撲與連線。
• 合規設計：安全、管理、治理、平台自動化與 DevOps。
• 這八個領域官方建議依序評估，已經想清楚的就跳過，重點是每一個都被問過一次，而不是每一個都要重做。

資源階層：管理群組、訂用帳戶、資源群組怎麼切

Azure 用四個層級組織資源：管理群組、訂用帳戶、資源群組、資源。政策與角色指派會沿著這條路徑往下繼承，所以你在哪一層放東西，就決定了它會影響多少人。

管理群組是訂用帳戶之上的治理範圍。官方限制是一個目錄可支援一萬個管理群組、樹最多六層深（不含根層與訂用帳戶層），而且新的訂用帳戶預設會落在租戶根管理群組底下。

Platform 底下放平台團隊的共用訂用帳戶，Landing zones 底下依連線需求分成 Corp（要接公司網路）、Online（直接對外）與 Local（跑在 Azure Local 上的混合工作負載）。

官方的設計建議裡，有幾條是踩過才會痛的。以下五條我認為值得直接貼在團隊的設計文件上。

1. 階層要扁平。官方建議不超過三到四層，不要把組織圖複製成管理群組樹。
2. 不要為正式、測試、開發各建一個管理群組。要區隔就用同一個管理群組底下的不同訂用帳戶。
3. 不要為 Region 建管理群組。多 Region 部署請沿用標準階層，除非你有資料落地或主權的法遵要求。
4. 不要在管理群組層級把權限發給應用團隊。權限應該落在他們真正需要的訂用帳戶或資源群組上。
5. 設一個預設管理群組，讓新的訂用帳戶不會直接落在根，並開啟階層的 RBAC 授權保護，否則預設任何人都能在根底下建管理群組。

訂用帳戶則同時扮演兩個角色：政策與管理的邊界，以及擴充的單位。想清楚這件事，你就不會再問「一個訂用帳戶還是十個」，而會問「哪些東西該共用同一組配額與同一套政策」。

Azure Policy：把「大家記得要」變成擋得住的東西

Azure Policy 用 JSON 描述規則，這份規則叫做原則定義。多條定義可以包成一個計畫（initiative，SDK 裡叫 policySet），再指派到管理群組、訂用帳戶、資源群組或單一資源。

指派會套用到範圍內所有資源，必要時可以排除子範圍。要記得一件反直覺的事：Policy 是明確拒絕系統，上層擋掉的東西，沒辦法靠下層再指派一條寬鬆政策放行，只能用排除。

評估的時機有四種：資源建立或更新、範圍收到新指派、既有指派被更新，以及每二十四小時一次的標準合規評估週期。所以政策改完不會立刻讓整個環境的合規數字跳動，那是正常的。

• 先稽核再強制。官方建議先用 audit 或 auditIfNotExists 觀察影響，再換成 deny、modify、deployIfNotExists。
• 定義放高一層，指派放低一層。在管理群組建定義，指派到底下的訂用帳戶或資源群組。
• 就算只有一條也建計畫。之後要加規則時直接加進計畫，不必新增一份要維護的指派。
• 根管理群組的指派要克制。根層指派會套到租戶內所有資源，官方建議只放「非有不可」的項目。
• 把政策當程式管。定義、計畫、指派的變更都走版本控制與人工審查。

還有一個 2026 年值得知道的能力：政策條件現在能看請求的身分脈絡。官方文件示範的用法包括擋掉未啟用多重要素驗證的使用者所發出的建立、更新與刪除請求，或禁止使用者手動刪除關鍵資源。

一份可以照著走的順序

1. 先確認 geography 與可用區。有資料落地要求的話，這一步錯了後面全部要重來。
2. 把 CAF 的七個問題各寫一段答案。寫不出來的那一段，就是你現在最該處理的地方。
3. 設計管理群組階層，控制在三到四層，並先建好沙箱與預設管理群組。
4. 決定訂用帳戶的切法，用「同一組配額、同一套政策」當判準，不要用部門當判準。
5. 政策從 audit 起步，跑滿一次二十四小時的評估週期，看清楚影響再換成強制。
6. 把上面每一項的負責人與複查日期寫進行事曆。沒有負責人的治理項目，等於沒有這個項目。

治理骨架的價值不在於做得多漂亮，而在於它讓後面每一個決定都變便宜。骨架搭好之後，新開一個工作負載只是套用既有模式，不必每次重吵一輪。