Microsoft AZ-900: Azure 架構與全球基礎設施 — 學習指南

By Laurynas Brazys · 24 July 2026 · #microsoft #az-900 #certification #exam-prep #study-guide

屬於 Microsoft Azure AZ-900 — 學習指南. 使用經過驗證的解答練習： Microsoft 考試中心, 或參加限時模擬考試： ExamRoll.io.

Azure 的全球架構旨在提供具備彈性、高效能且合規的大規模雲端服務。了解地理位置 (geographies)、區域 (regions) 和可用性區域 (availability zones) 的實體佈局，以及管理群組 (management groups)、訂用帳戶 (subscriptions)、資源群組 (resource groups) 和資源 (resources) 的邏輯階層，是可靠設計與治理的基礎。由 Azure Resource Manager 提供的控制平面 (control plane)，結合宣告式範本 (declarative templates)，能夠實現與組織政策和安全性要求一致且可重複的部署。在此領域的設計決策會直接影響可用性目標、資料落地義務以及全球使用者的體驗。選擇正確的備援模型 (redundancy model)、計算複合式 SLA，以及挑選如 Azure Front Door、Traffic Manager 和 Azure CDN 等全球路由服務，是達成業務連續性、合規性與效能目標的核心。

地理位置、區域、可用性區域與區域配對

Azure 地理位置 (geographies) 是定義好的一組區域，用以維持資料落地 (data residency) 與合規性的邊界。範例包括美國、歐洲、英國、澳洲和加拿大，以及具有獨特合規性與連線模型的「主權雲端」(sovereign clouds)。必須保留在特定管轄範圍內的工作負載，應部署到屬於目標地理位置的區域中，以確保符合法規並滿足資料落地要求。一個區域 (region) 是一組部署在延遲定義範圍 (latency-defined perimeter) 內的資料中心，並透過專用、低延遲的網路相互連接。並非所有服務或功能在每個區域都可用，因此在規劃初期就應驗證容量與功能可用性。支援可用性區域 (Availability Zones) 的區域會提供三個或更多個實體上分離的資料中心區域，各自擁有獨立的電力、冷卻和網路。區域備援服務 (Zone-redundant services, ZRS) 以及跨區域的架構設計，可以在維持區域內低延遲存取的同時，防禦資料中心層級的故障。每個 Azure 區域都會與同一地理位置內的另一個區域配對，形成一個區域配對 (region pair)（例如，North Europe 與 West Europe 配對，East US 與 West US 配對）。區域配對可以在發生大規模中斷時實現優先復原、錯開平台更新時間，並為特定服務提供資料複寫。Azure Storage 的異地備援選項 (geo-redundant options, GRS/GZRS) 會以非同步方式將資料複寫到配對的區域；當需要對次要區域進行讀取存取時，可使用 RA-GRS 或 RA-GZRS，以便在發生中斷或計劃性容錯移轉時，允許從次要端點讀取資料。對於同時需要區域內高可用性與跨區域災難復原的關鍵任務工作負載，應結合區域備援 (zone redundancy) 與區域配對複寫 (region pair replication)。平衡延遲、彈性與合規性後，會形成一種常見模式：將活動中的工作負載部署到主要區域的各個可用性區域，並透過將資料複寫到配對區域及提供容錯移轉路徑，來防禦區域性災難。定期驗證容錯移轉的執行手冊 (runbooks) 以及 DNS 或前端路由的行為，以確保能達成復原目標。

• 地理位置
  • 範圍：跨多個區域的邊界
  • 主要優點：資料落地與合規性
  • 典型用途：符合法規要求（例如：歐盟資料）
• 區域
  • 範圍：單一都會區
  • 主要優點：對服務的低延遲存取
  • 典型用途：主要部署地點
• 可用性區域
  • 範圍：區域內不同的資料中心
  • 主要優點：資料中心層級的故障隔離
  • 典型用途：區域內高可用性
• 區域配對
  • 範圍：同一地理位置中的兩個區域
  • 主要優點：協調的復原與更新
  • 典型用途：跨區域災難復原

資源組織與治理：管理群組、訂用帳戶、資源群組與資源

Azure 的管理階層讓您能大規模地進行原則、存取和成本控制。管理群組位於訂用帳戶之上，讓您能集中套用 Azure Policy 和角色型存取控制 (RBAC)，並將繼承層疊至子管理群組和訂用帳戶。這是依公司部門、環境層級（生產、非生產）或法規邊界進行區隔，同時維持統一防護機制的正確結構。訂用帳戶是管理、計費和配額的邊界。它們非常適合用來隔離事業單位、環境或應用程式的成本和存取權限。使用一致的訂用帳戶設計來區分生產與非生產環境，並強制執行限制和預算。對於擁有多個部門和分散式管理模式的組織，可為每個部門指派一個或多個訂用帳戶，並將它們放在特定部門的管理群組下，以實現乾淨的原則和 RBAC 繼承。資源群組是存放共享相同生命週期之資源的邏輯容器。它們支援不可部分完成的部署 (atomic deployments)、一致的標籤管理，以及刪除或鎖定等生命週期操作。將一起部署、更新和淘汰的資源群組在一起，例如 Web 層及其監控元件。使用標籤來推動跨資源和群組的成本分攤/成本透明化、所有權、環境和合規性屬性。鎖定 (ReadOnly, CanNotDelete) 在資源或群組範圍內增加了防止意外刪除的保護。資源是已部署的服務執行個體（VM、App Service 方案、儲存體帳戶）。RBAC 範圍（管理群組、訂用帳戶、資源群組、資源）讓您能在需要的地方精確地授予最低權限存取。對於多部門部署，除非有強烈的合規性或自主性要求需要多個租用戶，否則請保持單一的 Microsoft Entra ID 租用戶；訂用帳戶和管理群組通常能提供足夠的分隔，且管理上的額外負擔要少得多。

• 管理群組 (Management Group)
  • 主要目的：全組織的治理
  • 套用的控制項：RBAC、原則、藍圖 (透過原則 + 範本)
  • 常見模式：部門/法規區隔
• 訂用帳戶 (Subscription)
  • 主要目的：計費與配額邊界
  • 套用的控制項：預算、RBAC、原則
  • 常見模式：依事業單位或依環境隔離
• 資源群組 (Resource Group)
  • 主要目的：生命週期邊界
  • 套用的控制項：鎖定、標籤、RBAC
  • 常見模式：依應用程式或工作負載單元
• 資源 (Resource)
  • 主要目的：服務執行個體
  • 套用的控制項：執行個體層級的 RBAC、標籤
  • 常見模式：個別的服務元件

Azure Resource Manager 與範本

Azure Resource Manager (ARM) 是透過一致的 API 和角色型模型來部署、更新和刪除 Azure 資源的控制平面。ARM 提供等冪操作 (idempotent operations)、相依性管理、標籤管理，以及在部署時強制執行原則，讓平台治理能夠嵌入到每一次的變更中。宣告式 ARM 範本以 JSON 格式描述您環境的期望狀態，並支援參數、變數、條件和模組化的連結範本。它們讓您能夠在不同環境和訂用帳戶之間進行可重複、版本控制的部署。為了提供更精簡的編寫體驗，Bicep 提供了一種簡潔的語法，它會轉譯為 ARM 範本，同時保留了相同的部署引擎和優點。將範本儲存在原始程式碼控制中，將它們打包成範本規格 (template specs) 以便共用，並將其整合到 CI/CD 管線中，以確保無漂移、可稽核的基礎架構變更。系統管理員密碼或連接字串等敏感值絕不應嵌入範本中。使用帶有 Key Vault 參考的 secureString/secureObject 參數，這樣 ARM 就能在部署時擷取祕密，而不會在日誌中暴露它們。將範本與受控識別結合使用，以消除自動化中的硬式編碼認證。這種方法在降低風險的同時，也為大規模、多訂用帳戶的部署保留了完整的自動化能力。

• 等冪部署 (Idempotent deployments)
  • ARM/範本支援：是
  • 結果：安全、可重複的變更
• 部署時強制執行原則
  • ARM/範本支援：是
  • 結果：將防護機制內建於管線中
• 模組化組合
  • ARM/範本支援：連結模組 / Bicep 模組
  • 結果：可重用性與標準化
• 祕密處理
  • ARM/範本支援：Key Vault 參考
  • 結果：程式碼或日誌中沒有祕密

可用性、SLA、複合式 SLA 與服務生命週期

Azure 為正式發行 (GA) 的服務發布具備財務補償的服務等級協定 (SLA)。對於虛擬機器，可用性取決於部署的拓撲：一台使用 Premium SSD 儲存體的單一 VM 有 99.9% 的 SLA；兩台或多台位於可用性設定組 (availability set) 中的 VM 有 99.95% 的 SLA；而兩台或多台跨可用性區域 (availability zones) 部署的 VM 則可達到 99.99% 的 SLA。平台服務 (例如 Azure SQL Database 或 App Service) 有自己的 SLA，且可能因層級或備援選項而異。請透過選擇適當的備援模型和服務層級，讓架構符合目標 SLA。當一個解決方案依賴多個服務時，如果所有元件都是應用程式運作所必需的，其複合式 SLA 就是個別 SLA 的乘積。例如，如果一個 Web 應用程式 (99.95%) 依賴一個資料庫 (99.99%)，其複合式可用性約為 0.9995 × 0.9999 = 99.94%。在任何層級增加備援——例如跨區域部署、在負載平衡器後方新增多個執行個體，或使用異地備援資料儲存——都能提高有效可用性。反之，增加串列依賴性會降低複合式 SLA，應有明確的功能價值才能證明其合理性。服務的生命週期狀態會影響可靠性保證。公開預覽 (Public preview) 功能是為了收集回饋而提供，可能僅限於特定區域或有功能上的缺口；它們通常不帶有 SLA，不建議用於生產環境的關鍵路徑。GA (正式發行) 功能已準備好用於生產環境，並受 SLA 保障。應追蹤產品藍圖和區域推出時程，以避免在生產設計中無意間依賴預覽功能，尤其是在對合規性敏感的環境中。災難復原目標，如 RPO 和 RTO，是 SLA 的補充，並指導著設計選擇，例如跨區域或跨地區複寫、備份頻率和容錯移轉協調。定期驗證容錯移轉程序，以確保測得的復原效能符合業務目標，並確保 DNS、憑證和身分識別依賴項也能如預期般復原。

• 單一 VM (使用 Premium SSD)
  • 指標性 SLA：99.9%
  • 備註：用於非關鍵性工作負載或具容錯能力的應用程式
• 2+ 台 VM 位於可用性設定組 (Availability Set)
  • 指標性 SLA：99.95%
  • 備註：防護機架/容錯網域層級的故障
• 2+ 台 VM 跨可用性區域 (Availability Zones)
  • 指標性 SLA：99.99%
  • 備註：防護資料中心層級的故障
• 公開預覽 (Public Preview) 功能
  • 指標性 SLA：無財務補償的 SLA
  • 備註：用於評估；避免用於關鍵路徑
• GA 功能 (依服務層級而定)
  • 指標性 SLA：有 SLA 支持
  • 備註：請檢查特定層級和區域的 SLA

全域路由與內容交付：Azure Front Door、Traffic Manager 與 Azure CDN

全域使用者體驗取決於智慧路由、與內容的鄰近性以及快速的容錯移轉。Azure Front Door 是一個全域性的 anycast 第 7 層反向代理，具備 Web 應用程式防火牆 (WAF)、TLS 終止、基於 URL/路徑的路由、工作階段親和性 (session affinity) 以及來自邊緣的健康狀態探查。它透過分割 TCP (split-TCP) 和協定優化來加速動態內容，並在來源伺服器之間提供近乎即時的容錯移轉。Front Door 非常適合主動-主動 (active-active) 或主動-被動 (active-passive) 的多區域 Web 應用程式和 API，當您需要在邊緣同時實現高效能和集中式安全時。Azure Traffic Manager 是一個基於 DNS 的流量分發服務，它使用優先順序、加權、效能 (延遲)、地理位置、子網路或多重值等策略，將用戶端導向至最佳端點。由於它在 DNS 層級運作，因此支援非 HTTP 端點 (例如 TCP 服務) 和混合情境，但容錯移轉速度受 DNS TTL 和用戶端快取的限制。Traffic Manager 不代理流量也不加速內容；它僅僅是回應 DNS 查詢並提供所選的端點。Azure CDN 在邊緣的接入點 (points of presence) 快取靜態內容，以降低延遲並卸載來源伺服器的負擔。它非常適合大型靜態資產，如圖片、影片、腳本和下載檔案。雖然 CDN 為可快取的內容減少了來回傳輸次數，但它並非一個具備健康狀態感知能力的全域負載平衡器來處理動態來源；應將其與 Front Door 或 Traffic Manager 結合使用，以實現多來源容錯移轉或動態路由邏輯。許多架構會將用於靜態資產快取的 CDN 和用於動態流量與安全的 Front Door 部署在同一個應用程式的前端。

• Azure Front Door (Std/Prm)
  • 層級/機制：第 7 層 anycast 代理
  • 主要使用情境：全域負載平衡、邊緣安全、內容加速
  • 路由方法：優先順序、加權；基於路徑/主機的規則
  • 健康狀態探查：由邊緣 POP 探查
  • 容錯移轉速度：數秒 (近乎即時)
  • 動態內容加速：是
  • 靜態內容快取：是 (基於規則)
  • 是否提供 WAF：是 (整合式)
  • 典型模式：將 Front Door 部署在多區域 Web 應用程式/API 前端
• Azure Traffic Manager
  • 層級/機制：基於 DNS 的策略
  • 主要使用情境：跨區域 DNS 路由；非 HTTP 端點
  • 路由方法：優先順序、加權、效能、地理位置、子網路、多重值
  • 健康狀態探查：由全域探查端點
  • 容錯移轉速度：受 TTL 限制 (數十秒到數分鐘)
  • 動態內容加速：否
  • 靜態內容快取：否
  • 是否提供 WAF：不適用
  • 典型模式：為 HTTP 和非 HTTP 服務進行 DNS 導向
• Azure CDN
  • 層級/機制：邊緣快取網路
  • 主要使用情境：卸載靜態內容並降低延遲
  • 路由方法：不適用 (依快取規則)
  • 健康狀態探查：不適用 (可選的來源群組容錯移轉)
  • 容錯移轉速度：不適用 (基於快取)
  • 動態內容加速：否 (快取之外)
  • 靜態內容快取：是
  • 是否提供 WAF：透過 Front Door Premium 或獨立的 WAF
  • 典型模式：CDN 用於資產 + Front Door/Traffic Manager 用於來源伺服器

實務問題：為 IronPeak 製造公司設計一個高可用、合規且具備全球效能的網站平台

情境： IronPeak 製造公司的營運範圍橫跨歐洲與北美，現正將其客戶與合作夥伴入口網站整合至 Azure。此平台必須為 Web 層提供 99.99% 的可用性、將歐盟客戶資料保留在歐盟境內、提供跨區域的快速容錯移轉，並在全球提供快速的頁面載入速度。團隊希望實現全自動化部署，且程式碼或日誌中不得包含任何明文密碼。

挑戰： 在歐盟實現資料落地的前提下，達成區域內高可用性與跨區域災難復原；為動態流量提供全球加速與容錯移轉；並在多個訂用帳戶之間實現可重複且安全的部署。

建議方法：

1. 選擇 Europe 地理區域，並將主要工作負載部署在一個具備 Availability Zones 的區域（例如 West Europe），使用兩個或多個跨區域分佈的 VM scale set 執行個體或 App Service 執行個體。
2. 啟用到配對區域（North Europe）的跨區域災難復原，並使用服務的原生複寫功能：對 Storage 使用 RA-GZRS，對可用的資料庫使用 geo-replication；設定自動化的容錯移轉 runbook。
3. 在應用程式前端使用 Azure Front Door Standard/Premium，以實現全域 HTTPS 終止、WAF、邊緣健康狀態探查、在 West Europe（主要）和 North Europe（次要）之間的基於優先順序的容錯移轉，以及基於路徑的路由規則。
4. 使用與相同來源整合的 Azure CDN 來快取靜態資產（圖片、腳本、下載檔案），以降低延遲並卸載流量；驗證快取規則與 TTL。
5. 為歐盟和北美部門定義 management groups；將生產與非生產訂用帳戶分別置於其下，並套用 Azure Policy 以強制執行資料落地、標籤和允許的位置等規範。
6. 實作儲存在原始碼控制中並發布為 template specs 的 ARM/Bicep 範本；將區域、SKU 和擴展規模參數化；在部署時使用 managed identities 從 Azure Key Vault 參考密碼。
7. 設定 SLA 並測試複合可用性：在 Front Door 後方部署兩個跨區域分佈的執行個體，目標是為應用程式層達到 99.99% 的可用性；每季驗證端到端的容錯移轉演練、DNS、憑證和身分識別相依性。
8. 使用 Application Insights 和 Azure Monitor 來檢測平台；設定 Front Door 健康狀態探查與警示；根據遙測資料調整自動擴展和快取策略。

Azure 基本原理： 此設計將歐盟資料保留在 Europe 地理區域內，同時透過 Availability Zones 提供區域內的容錯隔離，並透過配對區域實現跨區域災難復原。Azure Front Door 為動態流量提供全球加速和可感知健康狀態的容錯移轉，而 Azure CDN 則卸載靜態內容以提升效能。使用 Key Vault 參考的 ARM/Bicep 範本，可在多個訂用帳戶和區域之間提供可重複且安全的部署。所選的拓撲結構符合已發布的 SLA，以滿足 Web 層 99.99% 的目標，而在 management group 和 subscription 層級的 policy 則以最少的維運負擔來強制執行治理。

← 雲端概念 · 所有領域 · 運算與應用程式服務 →

練習這些題目 → · 在 ExamRoll.io 上限時練習 →

瀏覽 Microsoft →