Microsoft AZ-104: Azure App Service 與 PaaS 計算 — 學習指南

By Laurynas Brazys · 7 August 2026 · #microsoft #az-104 #certification #exam-prep #study-guide

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

總覽

Azure 的 PaaS 運算產品組合結合了全託管的 Web/App 託管服務、無伺服器函式、工作流程自動化、隨選容器與容器協調服務。作為一名管理員，成功的關鍵在於了解每項服務的界線、它們如何進行網路連線與驗證，以及如何可靠地部署與擴展。本節涵蓋 App Service (方案、部署位置、網路與內建驗證)、Azure Functions 與 Logic Apps (方案、觸發程序、連接器)、Azure Container Instances 與 AKS (排程、擴展、維運工具)，以及隔離的 App Service Environment。

App Service 與 Functions 運算基礎

App Service 方案決定了 Web Apps、API Apps 與在專用方案上執行的 Function Apps 的運算資源集區。各層級有不同的功能與擴展模型：

Free (F1) 與 Shared (D1) 在共享的基礎架構上執行，設有配額且無 SLA。它們僅適用於實驗性質。部署位置、VNet 整合與自動擴展等功能皆無法使用。
Basic (B) 以小規模配置專用 VM，並提供手動向外擴展。它缺乏自動擴展與部署位置功能。
Standard (S) 開始提供自動擴展、多個執行個體、每日備份與部署位置。是需要預備環境的生產工作負載的入門選擇。
Premium (Pv2/Pv3) 提升了 CPU/記憶體、I/O 效能與功能限制 (更多執行個體、更多位置)，並新增了進階網路功能，如 Private Endpoint 整合與區域備援。
Isolated/Isolated v2 在 App Service Environment 內執行，提供單一租用戶、位於您虛擬網路內的專用運算資源，以符合嚴格的隔離與合規性要求。

擴展分為向上擴展 (變更定價層/VM 大小) 與向外擴展 (變更執行個體數量)。自動擴展需要 Standard 或更高層級，並由 Azure Monitor 規則 (CPU、透過 App Service Metrics 取得的記憶體，或自訂計量) 驅動。擴展操作是針對每個 App Service 方案進行，並會影響方案內的所有應用程式。

部署位置在同一個方案中提供即時的應用程式執行個體，用以預備變更。部署位置存在於 Standard 及更高層級，Standard 支援較少的位置，而 Premium/Isolated 則支援更多。交換 (Swap) 操作透過交換位置的內容與組態來協調零停機的升級，同時會遵循位置設定 (會保留在位置上的「黏性」應用程式設定與連線字串)。「交換並預覽」會在完成前預熱目標位置並評估其健康狀況。「生產環境中測試」會將一定比例的生產流量路由到一個或多個位置；路由對每個用戶端都是黏性的，以在測試期間維持工作階段同質性。

App Service 網路提供受控的輸出與輸入連線能力：

區域 VNet 整合會將輸出流量路由到同區域虛擬網路中的一個委派子網路。它能讓流量輸出至 private endpoints、透過 VPN/ExpressRoute 連線到地端，以及 service endpoints。它不會改變公開的輸入行為。
Private Endpoint 透過將應用程式的前端對應到一個私有 IP，將應用程式私密地發佈在您的 VNet 內；結合存取限制，可在 ASE 之外強制執行僅限私有的傳入流量。
Hybrid Connections 透過 Azure Relay，提供從應用程式到地端或其他網路中特定 host:port 端點的輸出 TCP 連線，無需變更輸入防火牆規則。它不是一個通用的 VNet 通道，且不支援 UDP。
存取限制會評估針對用戶端 IP、服務標籤與虛擬網路流量 (透過 Private Endpoints 或多租用戶 VNet 規則) 的有序允許/拒絕規則。鎖定到特定的範圍、VNet 或前端，以符合合規性要求。

內建驗證/授權 (「Easy Auth」) 在您的應用程式前端加上一個託管的驗證處理器，無需修改程式碼即可卸載權杖驗證的工作。支援的提供者包括 Microsoft Entra ID (Azure AD)、Microsoft Account、Google、Facebook、Twitter 與通用的 OpenID Connect。您可以強制所有請求都需登入，或將請求傳遞給應用程式處理；也可以設定允許的對象，並限制到特定的租用戶。選用的權杖存放區會快取提供者的權杖，並透過 /.auth/me 端點與請求標頭公開宣告 (claims)。結合系統指派的受控識別，可以安全地呼叫下游的 Azure 服務。

Azure Functions 提供事件驅動的運算，橫跨三種託管模型：

Consumption 方案是無伺服器的，採每次執行、每 GB 秒計費，並具備自動向外擴展與縮減至零的功能。它有冷啟動問題，且過去某些觸發程序不支援 VNet 整合；雖然新功能涵蓋範圍更廣，但對網路敏感的工作負載仍應驗證其支援性。
Premium 方案透過預先暖好的執行個體來消除冷啟動，支援 VNet 整合與 Private Endpoints，並根據事件進行擴展，且可控制最小/最大執行個體數量。
Dedicated 方案 (App Service 方案) 在您的 App Service 方案容量上執行 Functions；成本是針對保留的執行個體計算，與使用量無關，並可在方案層級選擇性地使用自動擴展。 Functions 的觸發程序包括 HTTP、計時器、儲存體 (Queue/Blob/Table)、Service Bus、Event Hubs、Event Grid、Cosmos DB 等等，並透過輸入/輸出繫結以宣告方式連接服務。Durable Functions 使用協調器 (orchestrator) 與活動 (activity) 函式，在程式碼優先 (code-first) 的模型中增加了具狀態的協調能力，從而實現了如 fan-out/fan-in、非同步 HTTP、人為互動與 sagas 等模式。狀態會被保存在一個儲存體提供者中 (Azure Storage 很常見)，確保工作流程具備彈性且可重播。

App Service 方案與 Consumption 模型的成本與擴展行為有實質上的差異。App Service 方案根據永遠在線的執行個體的大小與數量收費，並依照方案規則進行擴展。Functions 的 Consumption 模型僅針對執行時間與記憶體收費，並具備基於並行性的自動擴展與縮減至零的功能。Premium 則介於兩者之間，結合了保留的暖機容量與突發擴展能力。

容器與 Kubernetes

Azure Container Instances (ACI) 提供依需求、以秒計費的容器，無需管理虛擬機器或協調器。其部署單位是容器群組 (container group)：一或多個排程在同一主機上的容器，共享 IP、連接埠、磁碟區與生命週期。您可以為每個容器定義 CPU/記憶體、公開連接埠，並掛載如 Azure Files、secrets 和 emptyDir 等磁碟區。環境變數可以是純文字或安全的 (會從日誌/中繼資料介面中排除)。重新啟動原則控制生命週期：Always (長期執行服務的預設值)、OnFailure (適用於應在非零結束時重試的作業)，以及 Never (適用於您想在不重新啟動的情況下檢查結束狀態的「執行到完成」任務)。網路方面支援公用 IP、可透過 VNet 注入到委派子網路的私有 IP，以及用於公用端點的 DNS 名稱標籤。

Azure Kubernetes Service (AKS) 是一個受控的 Kubernetes 控制平面，其節點集區 (node pools) 是以 Virtual Machine Scale Sets 的形式佈建。節點集區區分了系統工作負載 (kube-system 元件) 和使用者工作負載，支援多種 VM 大小，並且可以執行 Linux 和 Windows (Windows 至少需要一個 Linux 系統集區)。集區可以被加上污點 (taint) 以控制排程。升級是按集區進行協調的，而 maxPods、可用性區域和暫時性 OS 磁碟則在集區建立時設定。叢集自動擴展器 (cluster autoscaler) 與 Kubernetes 排程整合，當有待處理的 pod 無法排程或節點使用率過低時，會在最小/最大範圍內修改節點數量；它會遵循 Pod 中斷預算 (Pod Disruption Budgets)，且只在安全的情況下才會縮減。水平 Pod 自動擴展器 (Horizontal Pod Autoscaler) 則透過根據指標擴展 Deployment 中的複本數量來輔助此功能。

kubectl 叢集管理基礎：

使用 az aks get-credentials 連線以合併 kubeconfig 並選擇 context。
檢視資源：kubectl get nodes/pods/deployments -o wide；kubectl describe 用於查看詳細資訊和事件。
診斷與互動：kubectl logs 用於取得 stdout/stderr，kubectl exec -it 用於進行互動式疑難排解。
套用期望狀態：kubectl apply -f manifests.yml；使用命名空間 (namespaces) 來界定資源範圍；kubectl config set-context 用於切換命名空間。

網路外掛程式 (Azure CNI 或 kubenet)、身分識別 (受控識別 vs. 服務主體) 以及 RBAC/Entra ID 整合，共同決定了 pod IP 的分配、叢集驗證與授權。請確保叢集身分識別擁有對負載平衡器、受控磁碟和節點資源群組的權限。

整合、網路與安全性

Logic Apps 提供一個受控的工作流程引擎，內建數百個連接至 SaaS 和 Azure 服務的連接器。一個工作流程包含一個啟動執行的觸發程序 (trigger) 和執行各步驟的動作 (actions)。觸發程序包括 HTTP 要求、週期性 (Recurrence)、Service Bus 訊息、Event Grid 事件、儲存體事件，以及許多 SaaS 事件 (例如，在 Dynamics 365 中建立一筆記錄時)。動作包括控制結構 (條件、迴圈、切換)、資料作業 (撰寫、剖析 JSON、變數)，以及連接器操作 (傳送電子郵件、將訊息加入佇列、呼叫 API)。它與 Azure 服務的整合非常深入：

Service Bus 和 Event Grid 為解耦的架構提供可靠的訊息傳遞和事件處理。
Functions 可被叫用以執行自訂程式碼步驟 (同步 HTTP 或透過佇列的非同步)。
受控識別 (Managed identity) 能保護對 Key Vault、Storage、SQL 及其他 Azure 資源的存取，無需使用祕密。 Logic Apps 消費方案 (Consumption，多租用戶) 依據每個動作的執行和連接器使用量計費；Logic Apps 標準方案 (Standard，單一租用戶) 在 App Service Plan 或 Premium 方案中的 Functions 執行階段上運行，支援本機開發、VNet 整合、私人端點和更高的輸送量。消費方案中的整合服務環境 (Integration Service Environment, ISE) 可在需要時為受控連接器提供 VNet 隔離。

App Service 環境 (App Service Environment, ASE) 實作了 App Service 的隔離 (Isolated) 層。ASE 部署在您的虛擬網路中，提供具備網路控制能力的單一租用戶、專用的運算和儲存體戳記。外部 ASE 會公開公用的輸入端點；而內部負載平衡器 (ILB) ASE 則只發布一個私有 VIP，用於嚴格的私密存取。ASE 中的應用程式使用隔離 (Isolated/Isolated v2) 定價層。您需要支付環境的戳記費用 (stamp fee) 以及每個執行個體背景工作角色的成本。當合規性、網路隔離或擴展需求超出多租用戶 App Service 的能力時，就會選擇 ASE。透過 ASE v3，部署和網路設定被簡化了，但其核心價值主張不變：以您的 VNet 為邊界，提供專用、可私下定址的 App Service。

跨這些服務的存取治理依賴 Azure RBAC 進行資源操作、受控識別 (managed identities) 進行服務對服務的驗證，以及在身分識別平面上的條件式存取 (Conditional Access)。對於 App Service 的輸入控制，可視需求結合私人端點 (Private Endpoints) 或 ILB ASE，並搭配存取限制和啟用 WAF 的前端 (例如 Application Gateway 或 Azure Front Door)。對於輸出控制，則使用 VNet 整合搭配 NSG、路由表和用於資料服務的私人端點。

部署與擴展作業

要對 App Service 進行可靠的發布，可使用部署位置在交換前驗證健康狀態並暖機快取。將每個環境不同的組態標示為「位置設定」，這樣它在交換期間就不會跟著移動（例如，連線字串、功能旗標）。使用交換預覽來執行健康狀態探查或應用程式特定的暖機端點；若不健康，就中止交換。在 Canary 部署期間，啟用流量路由，將一小部分具黏性的百分比流量導向預備位置，然後再逐步增加。特定於位置的應用程式設定可以安全地切換 Beta 功能。

App Service Plan 的自動擴展是在方案資源上設定的，使用設定檔（基於時間的最小/最大/預設值）和規則（帶有擴展步驟和冷卻時間的計量閾值）。結合 CPU 與自訂計量（例如佇列長度）以實現更精確的擴展。對於 Functions，Consumption（消費）方案會自動擴展；監控並行性並設定 host.json 以調整每個觸發程序的行為（例如 Service Bus 的批次大小和預先擷取）。Premium 方案會擴展預先暖機的執行個體和高載執行個體；將最小執行個體數量與延遲目標對齊。

在容器中，ACI 的重新啟動原則應反映其意圖：批次作業使用 Never 或 OnFailure 以避免無限迴圈；服務則使用 Always。使用環境變數進行組態，並使用 Azure Key Vault 存放祕密，透過 Managed Identity 和啟動程式碼注入，或在適當情況下將祕密掛載為磁碟區。在 AKS 中，啟用叢集自動擴展器，為每個節點集區設定合理的最小/最大範圍，並為關鍵的 Deployments 設定 HPA。為預留空間編列預算，並設定 Pod Disruption Budgets 以在升級和縮減期間保護可用性。在廣泛推出叢集或集區升級之前，先在 Canary 節點集區中驗證升級。

實務問題情境

Fabrikam, Inc. 營運一個客戶入口網站和背景處理服務。他們必須現代化至 PaaS、強制對資料存放區進行私有網路存取、支援藍綠部署，並在不管理 VM 的情況下執行夜間的容器化 ETL 作業。

將入口網站託管於具有部署位置的 App Service Premium

在 Premium v3 中建立一個 App Service Plan 以獲得更高性能和更多位置，並部署帶有預備位置的 Web App。
為環境特定值設定位置設定，並啟用交換預覽和健康狀態檢查。
理由：Premium 提供自動擴展、更多位置、Private Endpoint 支援以及適合生產流量的 SLA。部署位置則提供安全的藍綠發布和 Canary 路由。

強制私有傳入流量並控制傳出流量

為 Web App 啟用 Private Endpoint，並設定存取限制以拒絕公用網路。
設定 Regional VNet Integration 到一個委派的子網路，以便透過 ExpressRoute 對私有資料存放區和地端環境進行對外存取。
理由：Private Endpoint 加上存取限制可確保僅限私有存取；VNet Integration 將傳出流量透過 VNet 邊界路由，以實現一致的防火牆策略。

使用 Azure Functions Premium 實作背景處理

在 Premium 方案上部署一個 Function App，並使用系統指派的受控識別，透過 Service Bus 和 Storage 觸發程序來處理佇列驅動的工作負載。
設定最小預先暖機執行個體以消除冷啟動，並與同一個 VNet 整合。
理由：Premium Functions 滿足低延遲和 VNet 整合的需求，同時為高載工作負載保留無伺服器的擴展能力。

使用 Logic Apps Standard 來協調跨服務工作流程

建立工作流程以協調客戶上線流程：由 Service Bus 訊息觸發，呼叫 Function App，寫入 Storage，並透過 Microsoft 365 連接器發出通知。
使用受控識別存取 Key Vault 和 Storage，並部署在同一個 App Service Plan 中，以利用 VNet 整合和私有端點。
理由：Logic Apps 提供具彈性、視覺化的協調功能和原生連接器；Standard 方案則提供 VNet 整合和單一租用戶的效能。

在 Azure Container Instances 中執行夜間 ETL

定義一個包含 ETL 容器的容器群組，掛載一個 Azure Files 共用作為中繼資料儲存，設定安全的環境變數，並使用 restartPolicy: Never。
將該群組附加到 VNet 的委派子網路，以私有存取資料庫。
理由：ACI 提供以秒計費、以作業為導向的運算能力，無需叢集額外負擔，並與 VNet 整合以確保資料局部性和安全性。

使用 AKS 為容器化的微服務做準備

建立一個 AKS 叢集，包含一個小型的 Linux 系統節點集區和一個根據預期負載調整大小的使用者節點集區，啟用叢集自動擴展器（設定最小/最大範圍），並與 Entra ID 和 Azure CNI 整合以提供 Pod 層級的 IP。
使用 kubectl 部署一個 Canary 微服務，並根據 CPU 和自訂計量設定 HPA。
理由：當服務數量增加時，AKS 提供企業級的協調能力；自動擴展器和 HPA 能使容量與需求對齊，而 kubectl 則提供標準的操作控制。

← Azure 儲存體 · 所有領域 · Azure 資料庫與資料服務 →

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