Microsoft AZ-900: 雲端概念 — 學習指南

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

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

雲端運算透過網際網路交付按用量計費的 IT 資源，具備快速佈建、全球觸及範圍和內建的韌性。從地端基礎設施遷移到 Azure，會同時改變技術選擇和維運模型：容量規劃被彈性擴展所取代，資本支出轉變為維運支出，而硬體維護則成為平台的責任。理解這些概念對於選擇合適的服務、設計高可用性架構以及控制成本至關重要。

核心雲端特性：可擴展性、彈性、敏捷性與韌性

可擴展性是指工作負載透過增加資源來處理增長需求的能力。在 Azure 中，這有兩種形式：透過選擇更大的 VM 大小或更高的 App Service 方案來進行垂直擴展 (scale up)，以及透過 Virtual Machine Scale Sets (VMSS)、Azure Kubernetes Service (AKS) 節點集區或 App Service 自動擴展來增加更多執行個體，以進行水平擴展 (scale out)。反向擴展則是在需求下降時減少容量和成本。設計無狀態層並將狀態外部化 (例如，存放到 Azure Cache for Redis 或 Azure SQL Database) 可使水平擴展變得可預測且快速。彈性是自動化、由政策驅動的擴展，能持續地使容量與負載保持一致。Azure Monitor 自動擴展規則、AKS 叢集自動擴展器，以及如 Azure Functions 或耗用量/彈性進階方案等無伺服器選項，都能近乎即時地擴展和縮減資源。彈性架構能將閒置容量降至最低，非常適合尖峰或季節性工作負載，讓支出能精確地隨用量變化。敏捷性是團隊交付變更的速度。透過 Bicep 或 ARM 範本、GitHub Actions 或 Azure DevOps 管線進行 Azure 資源部署，以及如 App Service 或 AKS 等資源抽象化，都能實現頻繁、低風險的發行。透過 RBAC 和政策護欄實現的自助式佈建，在維持治理的同時減少了等待時間。敏捷性是平台與組織實踐的共同產物；平台抽象化的無差異化繁重工作越多，團隊的行動速度就越快。容錯和災難復原處理不同範圍的故障。容錯是透過使用可用性設定組 (將 VM 分散到不同的容錯/更新網域)、可用性區域 (在一個區域內實體上分離的資料中心)、負載平衡器和備援資料路徑，來緩解一個區域內的元件和資料中心故障。災難復原則是透過跨區域複寫 (GRS/RA‑GRS 儲存體、Azure SQL 主動式異地複寫、Cosmos DB 多區域寫入) 和如 Azure Site Recovery 等復原工具，為區域層級的中斷做好準備。定義明確的 RTO/RPO 目標並測試容錯移轉，以確保設計符合業務連續性目標。

服務模型與共同責任

雲端服務模型決定了您管理什麼以及 Azure 管理什麼。基礎設施即服務 (IaaS) 提供原始的運算、儲存和網路建構區塊。您控制客體作業系統、執行階段和應用程式——這在您需要自訂映像檔、特殊中介軟體或完全控制權時最為理想。平台即服務 (PaaS) 抽象化了作業系統和大部分的中介軟體，提供受控的執行階段、資料庫和整合服務，讓團隊可以專注於程式碼和資料。軟體即服務 (SaaS) 交付完整的應用程式，可透過瀏覽器或 API 使用，只需最少的設定，且沒有應用程式託管的義務。共同責任模型闡明了維運的邊界。在 IaaS 中，Azure 管理實體資料中心、主機和虛擬化管理程式；您則負責作業系統修補、強化、應用程式更新、身分識別與存取以及資料治理。在 PaaS 中，Azure 還會管理作業系統和平台中介軟體；您則管理應用程式程式碼、設定和資料。在 SaaS 中，Azure (或 SaaS 供應商) 維運整個堆疊；您則管理使用者、存取權、資料分類和使用設定。在所有模型中，客戶都需為身分識別、權限、端點安全性和資料保護政策負責。選擇正確的模型會影響可用性目標和成本。部署 Azure 虛擬機器是 IaaS 的任務；Azure App Service 上的 Web API 或 AKS 上的容器則體現了 PaaS；Microsoft 365 和 Dynamics 365 則是 SaaS。盡可能優先選擇 PaaS 和 SaaS 以加速交付並減少維運負擔，僅在工作負載需要作業系統層級的控制或有舊有相依性時才保留使用 IaaS。

• IaaS
  • 典型的 Azure 服務：Azure Virtual Machines、VM Scale Sets、Azure Disks、Virtual Network
  • 您管理的項目：客體作業系統、修補程式、執行階段、應用程式、資料、備份、防毒/EDR
  • 選擇時機：需要完整的作業系統控制權、自訂中介軟體、直接遷移 (lift‑and‑shift)
• PaaS
  • 典型的 Azure 服務：Azure App Service、Azure SQL Database/Managed Instance、AKS、Azure Functions、Azure Integration Services
  • 您管理的項目：程式碼/設定、結構描述、資料、身分識別與存取
  • 選擇時機：更快的交付速度、內建的擴展/高可用性、減少維運工作
• SaaS
  • 典型的 Azure 服務：Microsoft 365、Dynamics 365、Power BI、Azure DevOps Services
  • 您管理的項目：使用者、角色、資料使用/設定
  • 選擇時機：只需最少管理即可使用的完整應用程式

部署模型與擴展範疇

公有雲將工作負載部署在 Microsoft 所擁有的資料中心，並透過邏輯隔離在多個租戶之間共享。它提供最廣泛的服務目錄、全球性的觸及範圍、快速的佈建能力，以及純粹的即付即用模型。私有雲則將基礎設施專門提供給單一組織使用，這通常是出於法規或資料主權的考量，並且可以在 Azure 驗證過的堆疊上運行，例如 Azure Stack Hub 或 Azure Stack HCI。混合雲透過一致的身分識別、原則與網路，將地端環境與 Azure 連接起來，從而實現分階段遷移和資料局部性，同時在適當之處利用雲端的彈性。全域擴展與本地擴展關乎可用性與效能改善的範疇。本地擴展將流量保持在一個區域內，使用 Availability Zones、VM Scale Sets、Application Gateway 和 Azure Load Balancer 來增加執行個體並隔離資料中心的故障。全域擴展則使用 Azure Front Door (現代化的 anycast 第 7 層全域負載平衡，內建 WAF)、Azure Traffic Manager (以 DNS 為基礎的負載平衡)，以及地理複寫的資料服務 (如 Azure SQL 地理複寫或 Cosmos DB 多區域分佈) 來將流量分散到多個區域。多區域主動/主動設計能改善延遲和韌性，但需要謹慎規劃資料一致性與成本。選擇部署模型時，通常會先從合規性與連線能力的限制開始，然後隨著應用程式生命週期演進。全新開發的 Web 應用程式經常為了速度和擴展性而選擇公有雲的 PaaS。而具有相依性的複雜企業營運系統，則可能從混合雲開始——將某些服務保留在地端，同時將前端與無狀態層移至 Azure——然後在相依性完成現代化後，再完成整個轉移過程。

• 公有雲 (Public)
  • 所有權/位置：Microsoft 擁有的區域
  • 典型存取方式：網際網路/VPN/ExpressRoute
  • 使用案例：彈性擴展、全球觸及、快速創新
  • Azure 範例：大多數 Azure 服務、Azure Front Door、Azure App Service
• 私有雲 (Private)
  • 所有權/位置：客戶專用基礎設施 (地端或託管)
  • 典型存取方式：私有網路
  • 使用案例：主權、隔離的工作負載、嚴格合規
  • Azure 範例：Azure Stack Hub、Azure Stack HCI、AKS on HCI
• 混合雲 (Hybrid)
  • 所有權/位置：地端與 Azure 的混合
  • 典型存取方式：站對站 VPN 或 ExpressRoute
  • 使用案例：分階段遷移、資料局部性、舊有系統整合
  • Azure 範例：Azure VPN Gateway、ExpressRoute、Azure Arc

成本模型：資本支出 (CapEx) vs. 營運支出 (OpEx)、以量計價、即付即用與保留容量

地端採購通常屬於資本支出 (CapEx)：前期一次性採購伺服器、儲存和網路設備，並在數年內攤提折舊。Azure 將此模型翻轉為營運支出 (OpEx)：服務根據實際用量——例如 CPU 秒數、GB-月、交易次數——來計量和計費，將支出轉移到價值實現的當下。這種以量計價的方式減少了過度佈建，並將成本與使用模式掛鉤。即付即用模型最大化了彈性：可以隨意啟動和停止資源，無需任何約期承諾。對於穩定狀態的工作負載，Azure 提供以預留為基礎的折扣，例如 Reserved Virtual Machine Instances、Azure SQL Database reserved capacity、Cosmos DB RU/s reservations 和 Storage reserved capacity。一年或三年的承諾可以帶來顯著的成本節省，同時可選擇性地啟用執行個體大小彈性，以及跨訂用帳戶的共用範圍。補充選項包括 Azure Savings Plans for Compute，它將折扣率應用於符合條件的各種運算服務；以及 Spot VMs，可用於可中斷的、批次型的工作負載，並享有大幅折扣。有效的成本治理是將正確的商務模型與工程控制相結合。自動擴展可以減少閒置容量；無伺服器層在閒置時能消除基礎設施成本；Azure Hybrid Benefit 可讓您沿用現有的 Windows Server 和 SQL Server 授權；開發/測試定價則降低了非生產環境的支出。Azure Cost Management + Billing 提供預算、異常偵測與成本分攤功能，以利持續優化。

• 即付即用 (Pay-as-you-go)
  • 承諾：無
  • 相較於 PAYG 的典型折扣：0%
  • 彈性：最大彈性；隨時啟動/停止
  • 最適合：無法預測或短期的工作負載
• Reserved VM Instances / Reserved capacity
  • 承諾：1 年或 3 年
  • 相較於 PAYG 的典型折扣：最高約 72% (搭配 Azure Hybrid Benefit)
  • 彈性：範圍可共用；允許交換；提前取消有費用
  • 最適合：穩定的 24x7 運算、資料庫、Cosmos DB
• Savings Plan for Compute
  • 承諾：1 年或 3 年的支出承諾
  • 相較於 PAYG 的典型折扣：最高約 65%
  • 彈性：適用於 VMs、AKS、Functions Premium、App Service
  • 最適合：混合使用不同執行個體類型的運算
• Spot VMs
  • 承諾：無 (視容量而定)
  • 相較於 PAYG 的典型折扣：最高約 90%
  • 彈性：可能被收回；無 SLA
  • 最適合：批次、無狀態、CI、渲染等工作

實務問題：PeakGear Retail：兼顧成本控制與韌性的季節性擴展

情境： PeakGear Retail 經營一個電子商務網站，其流量在月底和節慶期間會出現可預測的高峰。該公司希望從地端 VM 遷移至 Azure，以降低資本支出，為網站層維持 99.99% 的可用性目標，並實作一個 RTO 為四小時、RPO 為 15 分鐘的災難復原計畫。身分識別必須透過 Microsoft Entra ID 與現有使用者整合。

挑戰： 設計一個 Azure 架構與成本模型，既能為流量高峰提供彈性擴展、區域層級的容錯能力、跨區域的災難復原以及維運簡易性，同時在非高峰時段將成本降至最低。

建議方法：

1. 在 Azure App Service (PaaS) 上部署網站 API 與店面，使用 Premium v3 方案以獲得內建的自動擴展、受控的平台修補與區域備援選項。
2. 將兩個或多個 App Service 執行個體置於 Azure Front Door Standard/Premium 之後，以提供全球 anycast 入口、SSL 終止、WAF 及基於路徑的路由；並視需求啟用健康狀態探查與工作階段親和性。
3. 在主要區域使用具備區域備援的 Azure SQL Database Business Critical；設定主動式異地複寫至一個配對的次要區域，目標為 15 分鐘的 RPO。
4. 將靜態內容儲存在具備 RA-GRS 的 Azure Storage 中；前端搭配 Microsoft 的 Azure CDN，以卸載頻寬並改善延遲。
5. 根據 CPU、請求數和佇列深度來實作自動擴展規則，以便在高峰期間向外擴展，並在平靜時段向內縮減；對於背景作業，則使用 Azure Functions Consumption 或 Elastic Premium 方案。
6. 透過為 App Service 方案啟用區域備援 (多區域)，或在支援的地區將執行個體分散到不同的可用性區域，來達成 99.99% 的網站層可用性。
7. 初期採用隨用隨付模式以保持彈性；對於 30 天後識別出的穩定基準容量，為 App Service 方案購買一年期 Reserved Instance (透過涵蓋 App Service 的 Savings Plan for Compute) 以及為 SQL Database 購買保留容量，以降低經常性成本。
8. 整合 Microsoft Entra ID 進行使用者與管理員存取；使用內建角色與條件式存取來應用最低權限原則；將密鑰保護在 Azure Key Vault 中，並由 App Service 與部署管線參考。
9. 定義並測試 DR 執行手冊：將 SQL 容錯移轉至次要資料庫，更新 Front Door 的來源優先順序以啟動次要區域，並在四小時的 RTO 內驗證應用程式的健康狀態。
10. 實作 Azure Monitor 與 Log Analytics 以集中管理指標、追蹤與日誌；設定警示與儀表板；設定 Azure Cost Management 預算與異常警示，以持續優化支出。

Azure 理由： PaaS 服務 (App Service 和 Azure SQL Database) 在共同責任模型下，最大化了敏捷性並卸載了作業系統與平台的維護工作，同時也實現了彈性的自動擴展。區域備援部署與多區域複寫提供了區域內的容錯能力，以及跨區域的災難復原，滿足了指定的 RPO/RTO。Front Door 提供了全球傳入流量、基於健康狀態的路由與 WAF 保護。從隨用隨付開始，在遷移期間保留了彈性；針對測量出的基準用量承諾使用保留容量或 Savings Plan，可降低穩定用量的成本，而自動擴展則能在非高峰時段削減支出。Microsoft Entra ID 集中了身分識別與存取控制，而 Azure Monitor 搭配 Cost Management 則維持了維運與財務的可見度。

所有領域 · Azure 架構與全球基礎設施 →

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

瀏覽 Microsoft →