Microsoft AZ-305: Well-Architected Framework 與設計原則 — 學習指南

By Laurynas Brazys · 11 August 2026 · #microsoft #az-305 #certification #exam-prep #study-guide

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

總覽

Azure 良好架構框架 (Well-Architected Framework, WAF) 是一套指導性原則，用於指引在 Azure 上設計、建置及營運可靠、安全、符合成本效益、卓越營運且具備高效能的工作負載。將解決方案與五大支柱——可靠性、安全性、成本最佳化、卓越營運及效能效率——對齊，可確保架構決策是在充分了解業務優先順序、風險承受能力以及資料主權和預算等限制條件下，所做出的明確權衡。要實現大規模的一致性，需要將登陸區 (landing zones)、策略驅動的治理以及自動化作為預設標準。現代設計強調解耦合、事件驅動通訊，以及如 CQRS、Strangler Fig 和微服務等模式，並透過 Azure 原生服務和整合的可觀測性來實作，以同時適應快速變更和嚴格的合規性要求。

五大支柱：可靠性、安全性、成本、卓越營運、效能

可靠性確保工作負載在發生故障和變更期間，仍能持續滿足業務的 SLA。透過跨可用性區域 (Availability Zones) 或區域配對部署、選擇內建高可用性 (HA) 的託管服務，以及實作彈性模式，來針對容錯網域和更新網域進行設計。利用混沌工程和災難復原演練來測試可復原性。對於具狀態的資料，應選擇具備 RPO/RTO 功能的服務——例如 Azure SQL Database 的 Active Geo-Replication 或 Cosmos DB 的多區域寫入——並搭配自動化備份和經過測試的執行手冊 (runbooks)。

安全性是基於零信任 (Zero Trust) 原則的深度分層防禦。透過 Azure RBAC、Privileged Identity Management (PIM) 和存取審查來實施最低權限原則，以維持持續的授權健康狀態。使用私人端點、網路安全性群組 (NSG) 和 Azure Firewall 來隔離網路的爆炸半徑；在 Azure Front Door 或 Application Gateway 上整合 Web 應用程式防火牆 (WAF)。秉持「假設已遭入侵」的心態，透過 Defender for Cloud 進行持續監控、在 Sentinel 中進行威脅偵測，並實施嚴格的身分保護 (MFA、Conditional Access)。

成本最佳化旨在平衡業務價值與總體擁有成本 (TCO)。根據遙測資料適當調整運算資源和服務層級的規模；利用擴展來匹配需求，並關閉非生產環境的資源。對於穩定的工作負載，使用保留方案和節省方案來承諾用量；利用 Spot VM 處理可中斷的運算；對儲存和資料保留進行分層；並在工作負載特性符合時，優先選用無伺服器架構。強制執行標籤和預算管理，並使用 Azure Policy 來標準化成本控制措施。

卓越營運強調自動化、可重複性及學習循環。使用 Bicep/ARM 或 Terraform 將環境視為程式碼，強制執行漂移修復，並實作一致的 CI/CD。營運洞察來自結構化日誌、指標、追蹤和綜合測試，並將所有這些資料整合到警示和 SLO 儀表板中，以縮短平均復原時間 (MTTR) 並為前瞻性的改善提供資訊。

效能效率確保工作負載在不同負載下，皆能滿足輸送量和延遲的目標。設計時應考慮向外擴展 (scale-out)、積極快取、將內容推向邊緣，並選擇適合存取模式的資料分割區和讀取複本。透過擬真的負載測試進行驗證，並根據實證數據進行調校。

Azure 中的可靠性與效能模式

彈性模式可降低故障的機率和影響，同時保持可預測的延遲。

• 具備指數退避與抖動的重試：使用 Azure SDK 的可設定重試策略或像 Polly (.NET) 這類的函式庫，來處理來自 Storage、Service Bus 或 Cosmos DB 等服務的暫時性故障。具備抖動的退避機制可避免蜂擁問題 (thundering herds)；設定重試次數上限以保護 SLA 並及時呈現故障。

• 斷路器：將對外的呼叫 (例如，對外部 API) 用斷路器包裝起來，以便在錯誤率超過閾值時能快速失敗，從而提供復原期。在用戶端層級使用 Polly 實作，或在閘道層級使用 API Management 的策略 (重試、逾時和快取) 來避免連鎖故障。

• 艙壁：分割資源，使單一的「吵雜鄰居」不會耗盡整個系統的資源。隔離執行緒集區、容器複本和訊息處理分割區。在平台層級，針對每個限界上下文 (bounded context) 使用獨立的 App Service 方案、AKS 節點池或 Service Bus 佇列/主題，以控制故障範圍。

• 健康狀態端點監控：在服務中公開存活探測 (liveness probe) 和就緒探測 (readiness probe)。Application Gateway/Front Door 的健康狀態探測只會將流量路由到健康的執行個體。在 AKS 中，Kubernetes 的探測器負責管理 Pod 的重新啟動和部署閘門。結合 Application Insights 的可用性測試和自訂的「/healthz」端點，以提早偵測相依性服務的效能下降。

效能模式與彈性模式相輔相成：

• 快取策略：使用 Azure Cache for Redis 來處理熱門資料和工作階段卸載。在 Azure Front Door 或 API Management 上對冪等的 GET 請求應用輸出快取。在適當情況下，優先選用寫入穿透 (write-through) 或後寫 (write-behind) 模式；透過金鑰或事件來使快取失效，以維持資料新鮮度。在資料層，Cosmos DB 的整合式快取可為讀取密集型工作負載降低 RU 消耗。

• CDN：使用 Azure Front Door 或 Azure CDN 將靜態資產與動態內容推向更接近使用者的位置，並啟用壓縮、TLS 和 WAF。設定基於規則的快取、來源健康狀態檢查和地理篩選，以最佳化延遲和成本。

• 讀取複本：使用 Azure SQL Database 的可讀取次要複本 (Active Geo-Replication) 或 Hyperscale 的具名複本來擴展讀取密集型工作負載；使用 Azure Database for PostgreSQL/MySQL 的讀取複本進行分析或報表；在 Cosmos DB 中啟用多區域讀取，並根據業務需求選擇合適的一致性模型 (例如 Session、Consistent Prefix)。

• 自動擴展模式：透過 Virtual Machine Scale Sets、App Service 自動擴展規則、用於事件驅動擴展的 AKS HPA/KEDA，以及 Functions 的消費/進階方案來實作水平擴展。對於資料層，使用 Cosmos DB 的自動擴展 RU/s 和 Event Hubs 的自動擴充功能來處理突發流量。務必驗證擴展閾值和冷卻期間，以避免發生震盪。

卓越營運、成本最佳化與安全性設計原則

基礎設施即程式碼 (Infrastructure as code)：將 Bicep/ARM 或 Terraform 模組標準化，在 Git 中進行版本控制，並透過部署前測試與 policy-as-code 進行驗證。使用 template specs 或 Terraform registries 以便重複使用。針對每個環境進行參數化，並強制執行一致的標籤、資源鎖定與診斷設定。與 Azure DevOps 或 GitHub Actions 整合；使用分階段部署與核准機制來進行受控的升級。

部署自動化：優先採用 App Service、AKS (透過 Deployment 策略進行漸進式推出) 以及 Traffic Manager/Front Door (用於加權路由) 所支援的部署位置 (deployment slots)、藍綠部署 (blue-green) 與金絲雀 (canary) 策略。透過遷移管線與向後相容的合約，自動化資料庫結構描述的變更。使用健康狀態探查 (health probes) 與業務關鍵績效指標 (KPI) 來管制推出。

可觀測性 (Observability)：使用 OpenTelemetry 來檢測應用程式，並將資料匯出至 Application Insights 以進行分散式追蹤、指標收集與相依性對應。啟用 Azure Monitor 以收集平台指標，部署 Log Analytics 工作區，並為 SLO 與容量建立 Workbooks 和儀表板。定義具有動態閾值的警示規則，與 ITSM 整合，並將 Activity Logs 與診斷日誌集中儲存，以供稽核與鑑識之用。

適當調整規模與成本控制：使用 Azure Advisor、Azure Monitor 使用率指標與 Application Insights 分析來識別浪費 (例如閒置的核心、過度佈建的 vCore、過度配置的 RU/s)。將 Reservations/Savings Plans 應用於穩定的工作負載 (VM、SQL、Synapse)，為 Storage 採用保留容量，以及為 Cosmos DB 採用承諾層。為建置代理程式、批次處理與具備檢查點機制的機器學習訓練選擇 Spot VM。平衡架構上的權衡取捨：託管的 PaaS 能以較高的單位成本降低維運成本並提升可靠性；快取能降低資料傳輸與 RU 成本，但代價是快取失效的複雜性；多區域高可用性會增加支出，但可能是 RTO/RPO 的要求。

安全原則實務：

• 深度防禦：從身分識別到資料，層層設置控制措施。使用 Private Link 讓流量遠離公用網際網路，使用 NSG 與 ASG 進行微分段，使用 Azure Firewall Premium 進行 TLS 檢測，並在邊緣使用 WAF。啟用 Defender for Cloud 的建議與 VM 的 Just-In-Time 存取。
• 最低權限：實作細微度的 RBAC，並將範圍限定在管理群組/訂用帳戶/資源群組層級；優先使用受控識別，而非密鑰；透過 Azure Policy 大規模地進行治理，並對群組、企業應用程式與特權角色進行存取審查。
• 假設已遭入侵：要求 MFA 與條件式存取，並使用 Sentinel 進行監控；使用獨立的登陸區域與訂用帳戶來隔離工作負載。使用平台金鑰或 Key Vault 中的 CMK 來加密靜態資料；在法規要求時使用雙重加密。使用 SAS 進行有時間限制的儲存體存取，並透過原則輪替金鑰。
• 資料分類：使用 Microsoft Purview 將資料編目、標記敏感度，並強制執行 DLP。將加密、保留與存取策略與資料分類層級對齊；記錄對 PII 的存取，並在適用時透過 Dynamic Data Masking 與 Always Encrypted 等功能支援隱私權要求。

Azure 登陸區與現代化架構模式

Azure 登陸區 (Landing Zones) 能大規模地實踐該框架。組織一個管理群組階層 (根 → 平台 → 業務單位)，以界定 Azure Policy、RBAC 與預算的範圍。平台登陸區提供共享服務——身分識別 (Azure AD)、連線能力 (具備 Azure Firewall、DDoS、DNS 的中樞)、管理 (Log Analytics、Automation、Update Management) 及安全性 (Defender for Cloud)。應用程式登陸區託管工作負載，依據環境與合規性邊界進行分段，並繼承強制執行標籤、診斷及允許資源類型的原則。採用雲端採用框架 (CAF) 企業級設計，或基於 Terraform/Bicep 的登陸區加速器，以快速且一致地啟動。

Azure 上的微服務強調團隊解耦與可獨立部署的服務：

• 服務探索：在 AKS 中，使用 Kubernetes DNS/CoreDNS 進行叢集內解析；透過 Dapr sidecar 增強，以實現基於名稱的探索與重試。Service Fabric 為具狀態服務提供內建的命名與健康狀態管理。
• API 閘道模式：使用 Azure API Management 來集中化路由、版本控制、驗證 (OAuth 2.0/JWT 驗證)、配額與快取。在其前端放置 Azure Front Door 以提供全域 anycast、SSL 卸載與 WAF；依區域路由並安全地執行金絲雀發布。
• 事件驅動通訊：對具備工作階段的有序、交易式命令使用 Azure Service Bus；對高吞吐量的遙測資料選擇 Event Hubs；對反應式、推送風格的事件訂閱則使用 Event Grid。設計時需考量至少一次傳遞、冪等處理常式、無效訊息處理與 DLQ (死信佇列)。

CQRS 與事件溯源 (Event Sourcing) 分離寫入與讀取模型，以隔離效能與複雜性。將僅供附加的事件保存在事件儲存庫 (Cosmos DB、Azure SQL 或透過下游儲存體進行壓縮的 Event Hubs) 中，重播以重建狀態，並投影到為查詢最佳化的讀取模型中，例如 Azure SQL Database、Cosmos DB 容器或 Azure Cognitive Search。Cosmos DB 變更摘要是實現投影的關鍵：Azure Functions 或 Azure Stream Analytics 可以處理變更，以近乎即時地更新讀取儲存庫。Event Hubs 緩衝高容量的事件串流，而消費者可獨立擴展。採納最終一致性，並搭配明確的 SLA 與使用者體驗模式 (例如：命令確認後，接著是讀取模型的收斂)。

絞殺榕模式 (Strangler Fig pattern) 實現漸進式現代化。在單體應用程式前端放置 Azure API Management，將特定端點路由到新的微服務，其餘的則繼續導向舊有的後端。使用原則進行基於標頭的路由、回應轉換與驗證。透過異動資料擷取 (例如：Azure Data Factory 或 Database CDC 到 Event Hubs) 來同步資料，並使用 Cosmos DB + 變更摘要建構新的讀取模型，逐步淘汰單體應用程式的功能。透過功能旗標、在 Front Door 進行金絲雀路由，以及全面的可觀測性來比較行為，藉此管理風險。

實務問題情境

星巴克 (Starbucks) 正在現代化其全球訂單平台，該平台目前是託管在單一區域 VM 上的單體應用程式。他們必須提升跨區域的可靠性、降低行動用戶端的延遲、強制執行最低權限與零信任 (Zero Trust)，並在不中斷業務的情況下進行漸進式遷移。

1. 建立企業級登陸區

• 建立一個具備平台與應用程式登陸區的管理群組階層。套用 Azure Policy 以強制執行標籤、診斷、允許的 SKU 及私有端點。選擇 CAF 企業級參考架構來處理身分識別、連線能力 (具備 Azure Firewall Premium、Private DNS 的中樞) 及管理 (中央 Log Analytics)。 原因：登陸區強制執行一致的安全性、網路與治理基準，讓工作負載能依設計繼承控制項。

2. 在單體應用程式前端放置邊緣與 API 外觀

• 部署具備 WAF 的 Azure Front Door (Standard/Premium)，以提供全域 anycast 入口、TLS 終止與 DDoS 保護。將 Azure API Management 作為 API 閘道，並與 Front Door 整合，以驗證用戶端 (OAuth 2.0)、對每個消費者群組套用速率限制，並轉換請求/回應。 原因：Front Door 降低了延遲並在邊緣提供保護；API Management 實作了 API 閘道模式，從而實現了絞殺榕方法與針對特定租用戶的節流。

3. 實作絞殺榕遷移

• 使用 API Management 原則將選定的端點 (例如：菜單、店家定位器) 路由到在兩個區域的 AKS 上運行的微服務；所有其他路由則導向位於內部負載平衡器後方的舊有單體應用程式。 原因：漸進式路由避免了一次性全面轉換 (big-bang cutovers)，並讓團隊能獨立遷移功能。

4. 以具備韌性且高效能的模式建構微服務

• 在 AKS 中，啟用 HPA 並搭配 KEDA 以實現事件驅動的自動擴展。使用 Dapr 進行服務探索、具備指數退避的重試，以及服務間的斷路器。整合 Azure Cache for Redis 以進行熱讀取與工作階段卸載。 原因：AKS 與 Dapr 提供了平台無關的韌性與服務探索；快取則降低了讀取延遲與後端負載。

5. 採納事件驅動通訊與 CQRS

• 將領域事件發布到 Azure Event Hubs；將訂單保存在 Cosmos DB 中，並依客戶或店家進行分割。使用 Cosmos DB 變更摘要搭配 Azure Functions，將資料投影到 Azure SQL Database (用於報告) 與 Azure Cognitive Search (用於店家庫存搜尋) 的讀取模型中。 原因：Event Hubs 以高吞吐量解耦了生產者與消費者；變更摘要則能在不影響寫入效能的情況下，為 CQRS 實現近乎即時的具體化視觀表。

6. 強化安全性與身分識別

• 對資料服務強制使用私有端點、使用 NSG/ASG 進行分段，並使用 Azure Firewall 進行出口流量控制。為所有工作負載使用受控識別、為特權角色使用 PIM，並對 API Management 產品訂閱進行存取審查。為維運人員啟用條件式存取與 MFA。 原因：深度防禦與最低權限原則減少了爆炸半徑與憑證風險；存取審查則維持了授權的健全性。

7. 為可靠性與可觀測性進行工程設計

• 在每個區域中跨可用性區域部署，並採用 active-active 的 Front Door 路由與 API Management 多區域部署。透過 Front Door 與 AKS 探測器啟用健康狀態端點監控；為新服務設定金絲雀發布。使用 OpenTelemetry 將遙測資料傳送到 Application Insights、將日誌集中到 Log Analytics，並建立具備警示的 SLO 儀表板。為具狀態的儲存體實作備份/災難復原，並執行混沌實驗。 原因：區域性與地區性的備援、由健康狀態驅動的路由，以及全面的可觀測性，有助於維持 SLA 並實現快速的事件應變。

8. 持續最佳化成本

• 根據遙測資料適當調整 AKS 節點集區與 App Service 方案的規模；對穩定的運算資源套用保留 (Reservations)/節省方案 (Savings Plans)；對非關鍵的批次處理使用 Spot VM。啟用 Cosmos DB 自動擴展並評估承諾層級。強制執行預算/標籤，並每月檢視 Azure Advisor 的建議。 原因：系統性的成本治理在維持效能的同時，能將浪費與單位成本降至最低。

← 遷移與現代化 · 所有領域

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

瀏覽 Microsoft →