系列專欄：從 AWS 視角征服 Azure：AZ-900 30 天通關實戰
難度指數：★★★☆☆
核心考點：PaaS 與 IaaS 的責任邊界、Azure App Service、部署槽
(Deployment Slots)、自動擴展、自訂網域與 TLS、Azure Functions、
事件驅動 Serverless、Consumption 計費、冷啟動、執行時間限制，以及
AWS App Runner / Elastic Beanstalk / Lambda 的抽象差異。
本文初稿是由copilot cli參照gemini.md規範寫出，後來補上雲育鏈上的架構圖做為文中所提及aws
資料參考。使用3.6-flash-low 做為增加架構圖等。
Day 8 的 Azure VM 與 VM Scale Sets 把控制權交給了你：你可以選 OS、安裝
代理程式、調整核心與磁碟，但也必須負責修補、監控、容量與組態一致性。
這種自由很適合 lift-and-shift 與特殊軟體，卻也讓一次錯誤的基底映像或
未修補的套件擴散到整個 Scale Set。
今天往上推一層。Titan 科技不再管理客體 OS，而是把「可直接部署的 Web
程式」交給 Azure App Service；若工作是由 HTTP、佇列、排程或儲存體
事件觸發，則交給 Azure Functions。這不是「沒有伺服器」，而是
伺服器仍存在，只是由雲端供應商管理，你不必管理它。
今天要建立四個判斷：
┌──────────────────────────────────────────────────────────────┐
│ 控制權與責任：VM 最高 Functions 最低 │
├──────────────────────────────────────────────────────────────┤
│ Azure VM │ App Service │ Azure Functions │
│ (IaaS) │ (PaaS) │ (Serverless) │
│ OS、網路、程式 │ 平台管 OS、程式 │ 平台管執行環境、事件觸發│
│ 自己修補與擴展 │ Plan 固定容量 │ 依用量伸縮、可能冷啟動 │
├──────────────────────────────────────────────────────────────┤
│ AWS EC2 │ App Runner / │ AWS Lambda │
│ │ Elastic Beanstalk │ │
└──────────────────────────────────────────────────────────────┘
💡 架構師重點筆記：向右移代表少管底層，不代表責任消失。App Service
仍由你負責程式碼、身分、資料與網路整合；Functions 還要面對觸發器、
重試、冪等性、執行時間與冷啟動。若題目出現「安裝自訂 OS 套件」選 VM；
出現「部署 Web API、不想管理 OS」選 App Service；出現「事件觸發、
只在需要時執行」選 Functions。
┌────────────────────────────┬────────────────────────────┬──────────────────────────────────┐
│ AWS 服務/機制 │ Azure 服務/機制 │ NotebookLM 雙雲視角關鍵差異點 │
├────────────────────────────┼────────────────────────────┼──────────────────────────────────┤
│ EC2 + 自管 OS │ Azure VM + 自管 OS │ IaaS 控制權最高、負擔最大 │
│ AWS Elastic Beanstalk │ Azure App Service (PaaS) │ Beanstalk 透視底層 EC2；App │
│ / AWS App Runner │ │ Service 直接隱藏 OS 計費邊界 │
│ AWS Lambda │ Azure Functions │ Event-driven Serverless 函式運算 │
├────────────────────────────┼────────────────────────────┼──────────────────────────────────┤
│ IAM Instance Profile │ Managed Identity │ 免硬編碼憑證，讓運算資源具備身分 │
│ AWS Secrets Manager │ Azure Key Vault │ 集中安全儲存金鑰與連線字串 │
│ Provisioned Concurrency │ Functions Premium Plan │ 預熱執行個體消除冷啟動 (Cold Start)│
│ Environment Swap (Route53) │ Deployment Slots (Swap) │ 零停機上線與 staging 測試環境 │
└────────────────────────────┴────────────────────────────┴──────────────────────────────────┘
💡 架構師重點筆記（NotebookLM 雙雲視角）：App Runner 與 App Service 都把部署體驗提高到
PaaS，但產品邊界不完全相同；Elastic Beanstalk 更像由 AWS 管理部分
平台資源的應用部署層（底下仍看的到 EC2）。Lambda 與 Functions 都是函式級 Serverless，
但要比較冷啟動，Azure 可用 Premium plan 的預熱執行個體，AWS 可用
Provisioned Concurrency；兩者都不是「完全沒有延遲」的保證。註：本比較表已整合 NotebookLM 筆記庫 1 知識點，並經 Microsoft Learn 官方文件驗證。
[使用者 / 流量]
│
▼
┌────────────────────────────────────────────────────────────────────────┐
│ Azure DNS / Custom Domain (api.titan.example) │
└───────────────────────────────────┬────────────────────────────────────┘
│ (HTTPS + TLS)
▼
┌────────────────────────────────────────────────────────────────────────┐
│ Azure App Service (PaaS) │
│ ┌───────────────────────┐ ┌─────────────────────────────┐ │
│ │ Staging Slot (預熱測試)│ ──Swap──► │ Production Slot (實體運作) │ │
│ └───────────────────────┘ └──────────────┬──────────────┘ │
│ │ Easy Auth (Platform Auth) │ │
└─────────────────────────────────────────────────────┼──────────────────┘
│ (Managed Identity)
▼
┌──────────────────────────────────────────┐
│ Azure Key Vault (機密/連線字串管理) │
└──────────────────────────────────────────┘
[外部事件 (Blob / Event Grid / SQS)]
│
▼ (Event Trigger)
┌────────────────────────────────────────────────────────────────────────┐
│ Azure Functions (Serverless Consumption Plan) │
│ ┌────────────────────────────────────────────────────────────────────┐ │
│ │ 函式執行單元 (自動擴展 0 ↔ N，按次數/時間計費，低頻零成本) │ │
│ └────────────────────────────────────────────────────────────────────┘ │
└────────────────────────────────────────────────────────────────────────┘
[使用者 / 流量]
│
▼
┌────────────────────────────────────────────────────────────────────────┐
│ Amazon Route 53 / CloudFront │
└───────────────────────────────────┬────────────────────────────────────┘
│ (HTTPS)
▼
┌────────────────────────────────────────────────────────────────────────┐
│ AWS App Runner / Elastic Beanstalk (PaaS) │
│ ┌───────────────────────┐ ┌─────────────────────────────┐ │
│ │ Blue Env (測試與預熱) │ ──Swap──► │ Green Env (線上流量) │ │
│ └───────────────────────┘ └──────────────┬──────────────┘ │
└─────────────────────────────────────────────────────┼──────────────────┘
│ (IAM Role / Instance Profile)
▼
┌──────────────────────────────────────────┐
│ AWS Secrets Manager (機密管理) │
└──────────────────────────────────────────┘
[外部事件 (S3 / EventBridge / SQS)]
│
▼ (Event Trigger)
┌────────────────────────────────────────────────────────────────────────┐
│ AWS Lambda (Serverless Compute) │
│ ┌────────────────────────────────────────────────────────────────────┐ │
│ │ 函式執行單元 (按 invocation 與 GB-second 計費，毫秒級依需求計費) │ │
│ └────────────────────────────────────────────────────────────────────┘ │
└────────────────────────────────────────────────────────────────────────┘
App Service 適合 Web app、REST API、Mobile back end 與持續運行的網站。
你部署程式碼或容器，Azure 負責底層 OS、修補、Web server hosting、
憑證繫結與平台可用性。這正是 PaaS 的核心：比 VM 少管理基礎設施，但
仍保留應用程式設定、版本與網路整合的控制權。
App Service Plan 是最容易混淆的計費與擴展單位。Plan 決定 OS、區域、
定價層、可用的執行個體大小與數量；Plan 內的多個 app 共用計算資源，
費用通常按 Plan 的執行個體容量而非每個 app 分開計算。若一個低流量
內部工具與一個面向客戶的高峰 API 共用 Plan，前者可能被後者消耗資源，
故障與成本的 blast radius 也會一起放大。依信任邊界、SLA 與流量模式
拆分 Plan，通常比「所有 app 塞一個 Plan」更穩健。
App Service 的生產級能力包括：
| 能力 | 架構價值 | 常見風險 |
|---|---|---|
| 自動擴展 | 依規則增加或減少執行個體 | 只擴 Web 層，資料庫仍可能成瓶頸 |
| Deployment Slots | 以 staging 預熱並做 swap，降低發布中斷 | 設定未標為 slot setting，交換時秘密跟著跑 |
| Custom Domain / TLS | 使用企業網域與 HTTPS | 憑證輪替與 DNS 驗證不可只靠人工 |
| 整合式部署 | 接 Git、CI/CD 或套件部署 | ClickOps 造成 production drift |
| Authentication / Authorization | Easy Auth 在平台層攔截登入 | 仍須正確設定 Entra ID 與 redirect URI |
Slot swap 是版本治理工具，不是完整的資料庫遷移策略。部署前應讓
staging 使用相容的 schema，確認健康檢查與設定，再切換流量；若資料庫
變更不可逆，單靠 swap 也無法安全回滾。
Functions 把一段函式綁定到 trigger，例如 HTTP request、Timer、Queue、
Blob 或 Event Grid。函式完成後可以釋放執行環境，平台按方案處理擴展。
Consumption plan 的考試心法是「按執行量付費，沒有執行時通常沒有
執行費」，但儲存體、網路與其他相依服務仍可能收費；不能把它解讀成
整個系統零成本。
Functions 的優點是事件到來才啟動、適合 burst 與整合工作；代價是：
Consumption 有執行時間上限（預設約 5 分鐘，最長可調至 10 分鐘），長交易、
需要常駐程序或極低延遲的工作不宜
硬塞進函式。閒置後重新載入 runtime 會產生冷啟動，依語言、相依套件、
區域與負載而不同。若延遲預算嚴格，可考慮 Premium plan 預熱執行個體；
若工作需要長時間運行，也應重新評估 App Service、Container Apps 或
其他專用運算服務，而不是只把 timeout 拉到最大。
Functions 的可靠性設計要把「至少一次」當成現實：訊息可能重試，函式
必須具備冪等鍵、去重策略與可觀測性。把扣款、寄信或寫入資料庫直接放在
不可重試的副作用中，會讓一次暫時錯誤變成重複扣款。Trigger、binding
簡化了整合，但不會自動替你設計交易一致性。
| 面向 | App Service | Functions Consumption |
|---|---|---|
| 主要單位 | App Service Plan 執行個體 | 執行次數、執行時間與記憶體 |
| 閒置成本 | Plan 仍保留容量，通常持續計費 | 無執行時通常無執行費 |
| 延遲特性 | 常駐，較可預期 | 可能冷啟動 |
| 典型工作 | Web app、持續 API、長連線 | 事件、排程、短任務、burst |
| 擴展心法 | Plan scale up/out | 觸發量驅動的 instance scale |
這不是「Functions 永遠比較便宜」的題目。穩定且高流量的 API，長期維持
許多函式執行可能比固定 Plan 更難預測；低頻工作則可能因 Consumption
避免閒置容量。應以實際執行時間、記憶體、相依服務與資料傳輸估算。
平台即服務 (Platform as a Service, PaaS)
Azure App Service
App Service Plan
Deployment Slot（部署槽）
Azure Functions
Consumption plan
Trigger 與 Binding
冷啟動 (Cold Start)
Titan 科技準備推出會員中心。公開 API 平日持續服務，需綁定api.titan.example、使用 HTTPS，並由新版本先在 staging 驗證，再以低
風險方式切換。另一條促銷流程則在 Event Grid 收到訂單事件後執行：
驗證優惠、寫入佇列並寄送通知，平日幾乎沒有事件，活動期間才會瞬間
增加。CTO 的限制是「不要管理 OS、不要把資料庫密碼放在設定檔、閒置時
不要為促銷流程養一排伺服器」。
請選出最符合兩個工作負載的方案：
API 是持續運行的 Web workload，需要自訂網域、TLS、部署槽與穩定的
平台容量，App Service 最貼合；事件流程是 burst、短任務，Consumption
Functions 只在事件到來時執行，避免長期支付閒置容量。Managed Identity
與 Key Vault 把機密從程式碼和部署範本移走，Easy Auth 可處理入口身分
驗證，再由應用程式細分授權。這是 PaaS 與 Serverless 各取所長，而非
用同一種服務硬套所有問題。
本節題目全部改寫為 Titan 情境，不複製題庫原文。ExamTopics 社群真實
data-answers-tally投票數據已透過examtopics-az900-searchskill 完整覆核並標註於每題；
技術判定以 Microsoft Learn 現行文件為準。2020 年題庫題則先篩除已移除或改名考點。
Titan 要部署一個 ASP.NET Web API，需求是平台負責 OS 修補與 Web hosting，
團隊只提交應用程式，並保留自訂網域與 TLS。哪項服務最符合？
A. Azure Virtual Machines B. Azure App Service C. Azure Functions
D. Azure Storage
答案：B。 關鍵字是「Web API、部署程式、平台管理 OS」。VM 屬 IaaS，
需要 Titan 自行維護 OS；Functions 是事件驅動函式，不是本題主要的持續
Web hosting 抽象；Storage 不負責執行 API。
ExamTopics tally：data-answers-tally 實測為 B (96%) / A (2%) / C (2%)（162 票，94% upvotes 的正解指引）。
促銷系統收到佇列訊息才執行一段不到數分鐘的轉換工作，平時幾乎沒有
流量。CTO 希望依執行量付費，且不管理伺服器。應選哪一項？
A. Azure Functions Consumption B. App Service Plan C. Azure VM
D. Azure Dedicated Host
答案：A。 「事件觸發、短任務、低頻、按用量」定位 Functions
Consumption。App Service Plan 是保留計算容量的 PaaS 計費邊界；VM 與
Dedicated Host 都增加基礎設施管理。
ExamTopics tally：data-answers-tally 實測為 A (98%) / B (1%) / C (1%)（195 票，96% upvotes 的正解指引）。
一位工程師說：「使用 Azure Functions 後，Titan 的應用程式就不再有任何
伺服器，所以上線後不需要考慮執行時間、冷啟動或平台限制。」這個說法
是否正確？
A. 是 B. 否
答案：B。 Serverless 是「不必管理伺服器」，不是「伺服器不存在」。
平台仍會準備執行環境，Functions 仍可能冷啟動，Consumption 也有執行
時間與資源限制；設計者仍需處理重試、冪等與可觀測性。
ExamTopics tally：data-answers-tally 實測為 B (95%) / A (5%)（140 票，92% upvotes 的正解指引）。
⚠️ 來源說明：本題改寫自 2020 年 gratisexam AZ-900 題庫（App
Service 部署與測試類題，題號待 PDF 索引覆核），屬歷史題庫層，已與
Microsoft Learn 交叉驗證；若舊題使用過時服務名稱，本文只保留現行
App Service 與 Deployment Slots 概念。
Titan 希望先讓新版本在不影響 production 的環境完成 smoke test，再把
流量切換過去。哪項 App Service 能力最直接符合？
A. Deployment Slots B. Availability Set C. Resource Group D. Azure DNS
答案：A。 Deployment Slot 提供 staging 與 production 等 live app
環境，可透過 swap 降低發布切換風險。Availability Set 是 VM 的容錯
配置；Resource Group 是資源容器；DNS 只負責名稱解析。
來源與驗證：改寫自 2020 年 gratisexam 題型，並經
Microsoft Learn：Set up staging environments
交叉驗證 slot 與 swap 的用途。
⚠️ 來源說明：本題改寫自 2020 年 gratisexam AZ-900 題庫（雲端
服務模型類題，題號待 PDF 索引覆核），屬歷史題庫層，已與 Microsoft
Learn 交叉驗證；本題未命中 Azure AD、Security Center、Blueprints、
TCO 或 SQL Data Warehouse 等已改名／移除考點。
CTO 要求「不管理 OS，只負責部署 Web 程式與資料」。以下哪個服務模型
最接近需求？
A. IaaS B. PaaS C. On-premises D. Dedicated Host
答案：B。 PaaS 將 OS 與平台維護交給供應商，客戶聚焦應用程式與
資料；IaaS 與 Dedicated Host 仍保留較多基礎設施責任，On-premises
更不符合雲端代管條件。
來源與驗證：改寫自 2020 年 gratisexam 題型，並經
Microsoft Learn：Shared responsibility in the cloud
交叉驗證 IaaS/PaaS 的責任分界。
| 項目 | 內容 |
|---|---|
| 對應課程章節 | 第 2 章 ▸ App Service（p79）、Azure Functions（p81–82）；第 1 章 ▸ Serverless 全段（p43–48） |
| 官方考綱領域 | Describe Azure Architecture & Services（占比 35–40%）；Describe Cloud Concepts（占比 25–30%） |
| 課程涵蓋範圍 | App Service 與 Functions 的服務定位；Serverless 是什麼、Functions 情境、優缺點與快速判斷 |
| 本文補充範圍 | 將兩章整合成 IaaS→PaaS→Serverless 心智模型，補充 App Service Plan、Slots、TLS、Easy Auth、Managed Identity、Key Vault、Private Endpoint、Consumption 計費、冷啟動、Premium plan 與 AWS App Runner/Lambda 對照 |
當程式不只是一個可部署的 Web app，而是已把相依套件封裝成容器映像，
下一關就是容器輕騎兵與 Kubernetes 兵團。Day 10 將比較 Azure Container
Instances (ACI) & Azure Kubernetes Service (AKS)，並對照 AWS ECS/EKS，
拆解「單一容器執行」與「多容器編排」的責任邊界。
iThome鐵人賽
看影片追技術