Serverless 與容器架構

Serverless 與容器是現代 AWS 架構新工作負載的預設設計選擇，SAA-C03 考試指南的任務陳述 2.1 將 Serverless 與容器歸類於「設計可擴展且鬆耦合的架構」範疇進行考核。本章將帶你以 Solutions Architect Associate 實際需要的深度學習 AWS 上的 Serverless 與容器——不只是「什麼是 Lambda」，而是 Lambda reserved concurrency 與 provisioned concurrency 有何不同、SnapStart 如何消除 JVM 冷啟動、Fargate task definitions 如何對應 CPU 與記憶體、何時 App Runner 優於 ECS、何時 EKS 又優於兩者。Serverless 與容器共同構成 SAA-C03 Domain 2 的核心，將兩者視為統一的設計空間，是建立考試直覺最有效率的途徑。

什麼是 AWS 上的 Serverless 與容器

Serverless 與容器是兩種執行典範，共同目標只有一個：讓你在不必持有虛擬機器的情況下交付應用程式程式碼。在 AWS 上，Serverless 與容器匯聚在一小組服務上——AWS Lambda 負責 Serverless 函式、AWS Fargate 負責 Serverless 容器、Amazon ECS 與 Amazon EKS 負責容器編排、AWS App Runner 則提供全託管的容器化網頁應用程式。Serverless 與容器並列於 SAA-C03 考試指南，是因為架構師幾乎永遠面對的是「哪種 Serverless 或容器選項適合這個工作負載」，而非「Serverless 還是 EC2」。

SAA-C03 對 Serverless 與容器的考核深度遠超 CLF-C02。在助理級別，你需要能夠：

• 依據延遲、執行時間、並行數及運維成本，在 Serverless 與容器之間為特定工作負載做出選擇。
• 為生產環境設定 AWS Lambda——runtime 選擇、記憶體調校、逾時、VPC 掛載、Layers、Destinations、dead-letter queues、reserved concurrency、provisioned concurrency 及 SnapStart。
• 設計與 Application Load Balancer、Auto Scaling、AWS Fargate 整合的 ECS task definitions 與服務。
• 識別何時 Amazon EKS 上的受管 Kubernetes 值得支付額外的 control plane 費用。
• 以 AWS App Runner 作為無狀態網頁應用程式的快速解法。
• 將 Serverless 與容器和事件來源——API Gateway、EventBridge、SQS、SNS、S3、Kinesis——組合成生產等級的事件驅動模式。

Serverless 與容器也與 messaging-and-decoupling（姊妹主題）及 api-gateway-and-edge 高度重疊。SAA-C03 的情境題預期會三者混合出現；本章聚焦於運算層，並在整合介面處提示連結關係。

為何 Serverless 與容器主導 Domain 2

SAA-C03 的 Domain 2 佔考試 26%，僅任務陳述 2.1 在 ExamHub SAA-C03 題庫中就衍生出約 450 道題目。在任務 2.1 內，Serverless 與容器佔比最大，因為幾乎每一道「設計可擴展、鬆耦合架構」的情境，最終都指向 Lambda 搭配 API Gateway、Fargate 搭配 ALB，或涉及 Serverless 與容器的事件驅動 pipeline。精通 Serverless 與容器，是備考 SAA-C03 最高槓桿的單一行動。

白話文解釋 Serverless and Containers

要在腦中內建 Serverless 與容器的直覺，最快的方法是用三組不同類別的類比把責任邊界與付費粒度具象化。Serverless 與容器並不是兩個對立的東西，而是責任光譜上相鄰的兩段。

類比一：便當店的備餐方式 (Bento Shop Prep Styles)

把 Serverless 與容器放進台灣便當店的情境，比 CLF-C02 的版本再加一層顆粒度：

• Amazon EC2 = 自家廚房：整間廚房你買下，OS、runtime、patch 都要自己顧。長期穩定、極度客製時才選。
• Amazon ECS on EC2 = 共用食堂的工作台：你只關心自己的便當（container），但食堂（EC2 host）還是你打掃。
• Amazon ECS on Fargate = 廚房完全外包：你把便當丟進展示櫃，AWS 幫你把爐火、瓦斯、清潔全處理掉，按使用秒數收費。
• Amazon EKS = 連鎖便當中央廚房：Kubernetes 標準化的出餐流程，能在任何縣市開分店，但要付中央廚房管理費（EKS control plane fee）。
• AWS App Runner = 外帶快餐窗口：你只給食譜與食材（container image 或 source repo），AWS 擺好窗口、自動開關、自動擴張。
• AWS Lambda = 外送雲廚房，按秒計費：你把食譜（function code）丟過去，真的有人下單才開火（事件觸發），最多煮 15 分鐘，不煮不收錢。

在 Serverless 與容器的光譜上，愈往右邊 AWS 幫你做愈多、計費粒度愈細；愈往左邊你掌控愈多、但要自己打掃。記住這條光譜就能回答一半的 SAA-C03 情境題。

類比二：瑞士刀與專用工具 (Swiss Army Knife vs Specialized Tools)

把 Serverless 與容器想成工具箱裡不同的工具：

• AWS Lambda = 瑞士刀：小巧、隨身、能應付大部分突發狀況。但你不會拿瑞士刀鋸一棵樹（> 15 分鐘就不行）。
• AWS Fargate = 電動起子：能長時間工作、還能換不同批次的螺絲頭（CPU / memory 任意組合），但你不用自備發電機（host）。
• Amazon ECS = 工具收納推車：幫你把所有工具、位置、排程整理好。AWS-native，不用學額外框架。
• Amazon EKS = 國際標準機械維修站：任何機器廠牌都能進來，因為講 Kubernetes 這個通用語言，但建站成本較高。
• AWS App Runner = 一鍵壓縮機：投入原材料（source 或 image）就會自動產出成品，完全不用你調參數。

Serverless 與容器的選擇，就是在「我要最會用的工具」（Lambda 一把抓）與「我要最正確的工具」（Fargate / ECS / EKS / App Runner 依情境挑）之間取捨。

類比三：交通工具光譜 (Modes of Transport)

用交通類比重新掃一次 Serverless 與容器，特別強調啟動時間與付費粒度：

• AWS Lambda = 共享電動滑板車：掃 QR 碼 1 秒就走（warm start），偶爾要等站點派車（cold start），按分鐘付錢，15 分鐘內還車。
• AWS Lambda + Provisioned Concurrency = 專屬 VIP 滑板車：車輛已在站點熱機待命，付一點閒置費換 0 cold start。
• AWS Lambda + SnapStart = 已經預熱的引擎：引擎先啟動過、記憶體快照儲存，真正要開車時直接載入快照，JVM 冷啟時間降一個量級。
• AWS Fargate = 自駕計程車：啟動需要 20–60 秒 provision，但一旦上路就持續跑，不受 15 分鐘限制。
• Amazon ECS / EKS on EC2 = 租一整排計程車：你要管車隊排班（host capacity），但平均單位成本最低。
• AWS App Runner = 機場接駁車：固定路線、全自動、看乘客量自動加車，不用你管司機排班。

三個類比交疊後，你會看到 Serverless 與容器其實是同一條光譜上，AWS 責任、啟動時間、付費粒度三個軸一起滑動的結果。

Serverless 與容器的核心運作原則

Serverless 與容器共享三個運作原則，幾乎出現在每一道 SAA-C03 情境題中。

原則一——責任漸層

Serverless 與容器形成 AWS 受管責任的漸層。左端由你管理 OS（EC2-backed ECS / EKS）；中段 AWS 管理 host，但你仍需為每個 task 定義 CPU / memory（Fargate）；右端 AWS 管理一切，包含擴展決策（Lambda、App Runner）。每往右一步，運維負擔減少，但可調旋鈕也跟著減少。SAA-C03 的題目利用這條漸層篩選服務：「完全受管」→ App Runner 或 Lambda；「我還需要選擇 instance type」→ ECS on EC2 或 EKS on EC2。

原則二——各服務的擴展單位不同

Serverless 與容器均以水平方式擴展，但擴展單位各異。Lambda 以 invocations（每個請求）擴展；Fargate 以 tasks（每個容器群組）擴展；ECS 服務依據 CloudWatch 指標在 load balancer 後端擴展 tasks；EKS 透過 Horizontal Pod Autoscaler 擴展 pods；App Runner 以並行請求處理器擴展。了解擴展單位，就能預判瓶頸將在哪裡出現，以及該監控哪個指標。

原則三——為實際工作付費，而非閒置容量

AWS 上的 Serverless 與容器均依實際工作量計費，但粒度從毫秒（Lambda）到秒（Fargate、App Runner）到小時（EKS control plane）不等。這種計費形狀的差異，驅動了 cost-optimized-compute 主題所涵蓋的成本最佳化決策。

AWS Lambda SAA-C03 深度解析

AWS Lambda 是 AWS Serverless 與容器中最具代表性的 Serverless 運算服務。SAA-C03 對 Lambda 的考核深度遠超 CLF-C02——你需要為生產環境設定 Lambda，而不只是認識它。

Lambda Runtimes 與封裝方式

Lambda 支援受管 runtimes（Python、Node.js、Java、Go、.NET、Ruby），以及透過 Lambda Runtime API 或最大 10 GB 的容器映像檔提供的自訂 runtimes。部署套件可為：

• 直接上傳的 Zip 檔（壓縮後最大 50 MB，未壓縮最大 250 MB）。
• 從 S3 參照的 Zip 檔（相同大小限制）。
• 來自 Amazon ECR 的容器映像檔（最大 10 GB）。

Runtime 的選擇會影響冷啟動時間：Python 與 Node.js 通常在 200 ms 以內啟動，Go 速度相當，Java 與 .NET 歷史上冷啟動需 1–5 秒——這正是 SnapStart 存在的原因。

必須熟記的 Lambda 硬性限制

• 逾時（Timeout）：每次 invocation 最長 15 分鐘（900 秒），預設為 3 秒。
• 記憶體（Memory）：最小 128 MB，最大 10,240 MB（10 GB），以 1 MB 為單位遞增。vCPU 與記憶體成比例增加，10 GB 時達到 6 vCPUs。
• 暫時 /tmp 儲存空間：預設 512 MB，最高可設定至 10,240 MB。
• 部署套件：直接 zip 50 MB，未壓縮 250 MB，容器映像檔 10 GB。
• Payload：同步 invocation 6 MB，非同步事件 256 KB。
• 環境變數：每個函式總計 4 KB。
• 並行執行數（Concurrent executions）：每個帳戶每個 Region 預設 1,000（軟性限制，可透過 Service Quotas 提升）。

Lambda 記憶體與效能調校

Lambda 的記憶體同時也是 CPU 的調節旋鈕。將記憶體從 512 MB 翻倍至 1,024 MB，vCPU 配置也跟著翻倍，執行時間往往減半，整體而言成本可能反而下降。因此，記憶體的適當調校兼具效能與成本兩個面向。AWS Lambda Power Tuning（開源的 Step Functions 狀態機）是自動化此調校流程的標準工具。SAA-C03 要求你知道記憶體是 Lambda 最主要的調校旋鈕。

Lambda 與 VPC

Lambda 預設執行於 AWS 受管的 VPC，並具備公開網際網路 egress。若需連接私有資源（private subnet 內的 RDS、ElastiCache、內部 ALB、透過 Direct Connect 連接的地端環境），需將 Lambda 掛載至你的 VPC，並指定 subnets 與 security groups。Hyperplane ENIs（共享的 Elastic Network Interfaces）以每個函式每個 subnet 為基礎建立，因此現代的 VPC-attached Lambda 不再有過去那 10 秒冷啟動的懲罰。

SAA-C03 必知的 VPC-attached Lambda 重點：

• 至少掛載至不同可用區域的兩個 subnets，以確保高可用性。
• VPC-attached Lambda 無法連上公開網際網路，除非 subnet 的路由經過 NAT gateway 或 VPC endpoint。
• 若要從 VPC Lambda 私密存取 S3 或 DynamoDB，請使用 VPC Gateway Endpoints（免費），而非 NAT gateway（收費）。

Lambda Layers

Lambda Layers 將共用的函式庫、相依套件或自訂 runtimes 封裝為可重複使用的構件，掛載至多個函式使用。每個函式最多可掛載 5 個 Layers，Layers 加上程式碼的總未壓縮大小須維持在 250 MB 以內。Layers 能縮小部署套件大小、集中管理函式庫更新，並讓組織在數十個函式間共用通用程式碼（日誌、追蹤、專有 SDK 包裝器），無需複製貼上相依套件。

Layers 的典型使用情境：

• 將大型相依套件（NumPy、Pandas）統一封裝，供多個 Python 函式使用。
• 發布全公司通用的可觀測性 SDK。
• 為 Lambda 原生不支援的語言提供自訂 runtime。

Lambda Destinations

Lambda Destinations 無需撰寫串接程式碼，即可將非同步 invocation 的成功或失敗結果路由至另一個 AWS 服務。支援的 destinations 包含 SQS、SNS、EventBridge，以及另一個 Lambda 函式。Destinations 取代了臨時撰寫發布結果的程式碼，是僅使用 DLQ 處理的後繼模式。

• On success destination：接收完整的請求與回應 context；適合用於鏈式呼叫。
• On failure destination：在所有重試耗盡後接收；取代或補充 DLQ。

Lambda 並行模型——Reserved vs Provisioned

Concurrency 是 Lambda 函式同時執行 invocations 的數量。SAA-C03 大量考核兩種常被混淆的 concurrency 控制機制。

Reserved concurrency 為函式保證一個並行執行數的底板，同時設定上限。保留值既是該函式能達到的最大值，也是從帳戶層級 pool 中劃出的數量。設定 reserved concurrency 的理由：

• 保護下游系統（例如有連線數限制的 RDS 資料庫）免於被過度並行衝擊。
• 確保關鍵函式即使在其他函式耗盡帳戶 quota 時，仍保有可用的 concurrency。
• 將 reserved concurrency 設為零，作為斷路器來停用函式。

Provisioned concurrency 預先初始化指定數量的執行環境，使其保持暖機狀態，隨時能在無冷啟動的情況下回應請求。Provisioned concurrency 在標準 invocation 費用之外另有每小時計費，是對延遲敏感 API 消除冷啟動的標準做法。

SAA-C03 的關鍵區別：

• Reserved concurrency 是對 concurrency 的限制（與保留）。它不能消除冷啟動。
• Provisioned concurrency 是預先初始化執行環境的暖池。它能為已配置的數量消除冷啟動。
• 兩者可以組合使用：reserved = 200、provisioned = 50，意為「上限 200，保持 50 個暖機」。

Lambda SnapStart

Lambda SnapStart 透過對初始化完成的執行環境拍取 Firecracker microVM 快照，並在冷啟動時從該快照還原，大幅降低 Java、Python 及 .NET 函式的冷啟動延遲。SnapStart 免費（不額外收費），沒有像 provisioned concurrency 的每小時費用，是流量不可預測的 Java 工作負載的首選。

SnapStart 重點：

• 適用於支援的受管 runtimes；不支援容器映像檔函式。
• 快照在 init 階段之後拍取，因此在 init 中建立的任何單例 client 都會以暖機狀態被捕捉。
• 由於快照被重複使用，必須注意唯一性問題（在 init 時一次性產生的隨機種子、唯一 ID，在還原的環境中會重複出現）。AWS 提供 runtime hooks 以重新初始化此類狀態。
• 典型 Java Spring Boot 應用的冷啟動時間，可從數秒降至次秒級別。

Lambda 事件來源

Lambda 之所以是 Serverless 與容器中的瑞士刀，部分原因在於龐大的事件來源清單。SAA-C03 最相關的事件來源：

• 同步觸發器（Synchronous invokers）：API Gateway、Application Load Balancer、Cognito、Step Functions（Task states）。
• 非同步觸發器（Asynchronous invokers）：S3 events、SNS、EventBridge、SES、CodeCommit。
• 輪詢式（Poll-based，event source mapping）：SQS、Kinesis Data Streams、DynamoDB Streams、Amazon MQ、Kafka（MSK 與自管）。

每種觸發器類型有不同的重試語意——同步觸發器的重試由用戶端負責，非同步觸發器以指數退避重試兩次，輪詢式來源從串流或佇列重新交付。SAA-C03 關於冪等性與重試的情境題，通常取決於使用哪種觸發器類型。

AWS Fargate——Serverless 容器

AWS Fargate 在容器粒度上實現了 Serverless 與容器的「Serverless」一半。Fargate 並非獨立的編排器；它是 ECS 與 EKS 皆可使用的 Serverless 運算引擎。

Fargate 是什麼，不是什麼

Fargate 是容器的 Serverless launch type。你提供 task definition（ECS）或 pod spec（EKS）並附上 CPU 與記憶體需求，Fargate 即在背後透明地佈建 host 容量。Fargate 必須透過 ECS 或 EKS 使用——你無法單獨使用 Fargate。

Fargate 核心特性：

• 依 task 保留的 vCPU 與記憶體按秒計費。
• Task 層級隔離（每個 task 透過 Firecracker 執行於各自的 microVM）。
• 無需 patch 的 EC2 instances、無 host 層級調校、無叢集容量規劃。
• 支援 Linux（x86 與 Graviton ARM64）及 Windows 容器。

ECS Task Definition——Fargate 版本

ECS task definition 是容器的藍圖。SAA-C03 重點欄位：

• Family 與 revision——版本化的識別碼。
• Task CPU 與 task memory——task 的總量。Fargate 允許特定的 CPU / memory 組合（例如 0.25 vCPU 搭配 0.5–2 GB、1 vCPU 搭配 2–8 GB，最高至 16 vCPU 搭配 120 GB）。
• Network mode——Fargate 必須使用 awsvpc。每個 task 取得自己的 ENI 與主要私有 IP。
• Container definitions——映像檔、port mappings、環境變數、secrets（來自 Secrets Manager 或 Parameter Store）、日誌設定（CloudWatch Logs、Firelens）。
• Task role——授予應用程式程式碼存取 AWS 服務（例如讀取 S3 bucket）的 IAM role。
• Execution role——Fargate 代表你拉取 ECR 映像檔並寫入日誌時所使用的 IAM role。

Task role 與 execution role 之間的區別，是 SAA-C03 關於 Fargate 最高產值的考點之一。

Fargate Launch Type vs EC2 Launch Type

Amazon ECS 支援兩種 launch types：Fargate 與 EC2。兩者執行相同的 task definitions（網路模式與 volume 有些許差異），但運作模式不同。

• Fargate launch type：無需管理 EC2、按秒計費、單位價格略高、task 啟動時間 20–60 秒，適合變動或突刺型工作負載。
• EC2 launch type：你管理 EC2 叢集（capacity providers 自動化擴展），在穩定狀態下（尤其搭配 Spot 或 Reserved Instances）成本更低，可使用 instance-store 磁碟，支援 GPU 與 bare metal。

Amazon ECS——AWS 原生容器編排

Amazon ECS 是 AWS 上 Serverless 與容器的 AWS 原生編排器。ECS 與每個 AWS 基礎元件深度整合（IAM、VPC、ALB、CloudWatch、EventBridge、Secrets Manager），且無 control plane 費用。在 SAA-C03 深度上，你必須了解 ECS task、service 與 cluster 的角色及其擴展行為。

ECS 建構模組

• Cluster——運算容量的邏輯分組（Fargate tasks 或已註冊為 container instances 的 EC2 instances）。
• Task definition——藍圖（映像檔、CPU、memory、網路、IAM、日誌）。
• Task——task definition 的執行中實例。
• Service——維持 N 個目標 tasks 運行，並將其註冊至 load balancer target group 的控制器。Services 處理滾動式與藍/綠部署。
• Container instance——執行 ECS agent 的 EC2 instance；僅適用於 EC2 launch type。
• Capacity provider——抽象化支撐 service 的運算資源（Fargate、Fargate Spot、EC2 Auto Scaling Group）。

ECS Service 擴展

ECS services 在兩個維度上擴展：

1. Service Auto Scaling（task 數量）——基於 CloudWatch 指標（如 CPU 使用率、記憶體使用率、ALB 每目標請求數或自訂指標）的目標追蹤、步進擴展或排程擴展。
2. Cluster Auto Scaling（僅限 EC2 launch type）——capacity providers 自動擴展底層 Auto Scaling Group，以便放置待處理的 tasks。

SAA-C03 常見的擴展模式：ALB 在 ECS service 前方、以 ALBRequestCountPerTarget 進行目標追蹤、由 Fargate 支撐，因此無需擔心 host 層級的擴展。

ECS 與 ALB 整合

ECS 透過 target groups 與 Application Load Balancer 及 Network Load Balancer 原生整合。每個 task 在啟動時將其 ENI 與 port 註冊至 target group，停止時取消註冊。此機制實現了零停機的滾動部署與藍/綠部署（透過 CodeDeploy 整合）。

Amazon EKS——受管 Kubernetes

Amazon EKS 是 AWS 的受管 Kubernetes 服務，也是 AWS Serverless 與容器中另一個主要的容器編排器。EKS 執行上游 Kubernetes，符合 CNCF 規範，並讓你帶入任何 Kubernetes 原生工具（kubectl、Helm、Argo CD、Istio、Flux）。

何時選擇 EKS 而非 ECS

• 團隊已在地端或其他雲端操作 Kubernetes 叢集。
• 需要多雲或混合雲的可攜性（相同的 manifests 可在 EKS、GKE、AKS 上執行）。
• 依賴 Kubernetes 原生軟體（operators、自訂 controllers）。
• 供應商以 Helm charts 而非 AWS 原生範本交付軟體。
• 合規、平台或開發者標準化要求使用 Kubernetes APIs。

EKS control plane 費用為每叢集每小時 $0.10（每個叢集每月約 $73），加上底層 EC2 或 Fargate 的運算費用。ECS control plane 免費，這也是為何成本敏感的 SAA-C03 情境通常偏向 ECS，除非明確提出 Kubernetes 需求。

EKS 運算選項

EKS 支援三種運算後端：

• Managed node groups——EKS 佈建並管理由 worker nodes 組成的 EC2 Auto Scaling Group。
• Self-managed nodes——你自行佈建 EC2 instances 並加入叢集。
• Fargate profiles——符合 profile 的 pods 在 Fargate 上執行，Serverless。

Fargate 支撐的 EKS 在 Kubernetes 層實現了 Serverless 與容器的承諾，但部分叢集範圍的 daemons（CNI plugins、透過 DaemonSet 的 log agents）無法在 Fargate 上執行，叢集附加元件仍需要 managed nodes。

AWS App Runner——全託管的容器網頁應用程式

AWS App Runner 是 AWS Serverless 與容器中最新也最簡單的成員。App Runner 從容器映像檔（ECR）或直接從原始碼（GitHub）執行無狀態網頁應用程式與 API，無需任何基礎設施決策——不用設定 VPC、load balancer，也不用調整 auto scaling 政策。

App Runner 核心能力

• 從 ECR 映像檔或 GitHub 原始碼部署，自動建構。
• 含受管 TLS 憑證的自動 HTTPS endpoint。
• 以每個 instance 的並行請求數為基礎，自動從零擴展至可設定的最大值。
• 內建 VPC connector 以連接 RDS、ElastiCache 或內部服務。
• vCPU 與記憶體按秒計費，加上少量的每請求費用。

App Runner 適合 SaaS 後端、內部工具、原型 API，以及任何原本需要小型 Fargate service 的無狀態網頁工作負載。取捨在於靈活性較低：不支援 sidecars、VPC connector 以外無自訂網路、不支援 WebSocket（截至 SAA-C03 考試指南 v1.5），以及不支援非 HTTP 工作負載。

何時 App Runner 優於 ECS 或 Lambda

• 無狀態 HTTP API，需要執行超過 15 分鐘（排除 Lambda）。
• 團隊希望零基礎設施管理，且接受既定的預設值（排除 ECS 的設定負擔）。
• 流量中等且不穩定；縮減至零可節省成本。
• 部署簡單性至上——推送至 main，App Runner 自動重新部署。

AWS Step Functions——編排 Serverless 與容器

Step Functions 是將 Serverless 與容器縫合成持久工作流程的編排層。你以 Amazon States Language（JSON）描述狀態機，包含 Task、Choice、Parallel、Map、Wait 等狀態。每個 Task state 可以 invoke Lambda、執行 ECS task、呼叫任何 AWS SDK 動作，或等待 callback。

SAA-C03 在 Serverless 與容器設計中加入 Step Functions 的理由：

• 以視覺化狀態追蹤編排跨 Lambda、ECS 與 SQS 的多步驟 pipeline。
• 以宣告式設定取代自製的重試、逾時與錯誤處理程式碼。
• 透過在最長 1 年的 Standard workflow 內（或 Express workflows 的 5 分鐘）鏈式呼叫較短的 Lambda invocations，協調長時間執行的工作負載。
• 以 Map state 並行擴展處理並彙整結果。

Express 與 Standard workflows 是 SAA-C03 常見考點：Standard 適合長時間執行的持久工作流程（最長 1 年，exactly-once，至少一次的步驟）；Express 適合高量事件處理（最長 5 分鐘，至少一次，每秒最多 100,000 次狀態轉換）。

Serverless 與容器的冷啟動緩解策略

冷啟動是 SAA-C03 中 Serverless 與容器最常被考核的延遲問題。以下是完整工具包，依優先順序排列。

1. 選擇快速啟動的 runtime——Python、Node.js、Go 冷啟動最快；Java 與 .NET 最慢。
2. 保持部署套件小巧——剪除未使用的相依套件，將共用程式碼分離至 Layers。
3. 在 handler 外部進行重型 SDK client 的延遲初始化，但避免破壞 SnapStart 的全域狀態。
4. 為 Java、Python、.NET 啟用 SnapStart——免費，基於快照的初始化加速。
5. 設定 Provisioned Concurrency，用於對延遲敏感的 API——保持 N 個執行環境暖機。
6. 增加記憶體——更大的記憶體意味著更多 CPU，初始化與 handler 執行速度都更快。
7. 若函式不需要私有資源，移除 VPC 掛載——不過現代的 VPC-attached Lambda 已比以前快得多。
8. 預熱 Fargate services——維持最小 task 數量，確保擴展事件不在關鍵路徑上。

結合 Serverless 與容器的事件驅動模式

AWS 上的 Serverless 與容器，在與事件來源結合成可重複使用的模式時最為閃耀。SAA-C03 熱愛模式比對題。

模式一——API Gateway + Lambda + DynamoDB

典型的三層 Serverless 模式。API Gateway 終止 HTTPS、透過 Cognito 或 Lambda authorizer 強制驗證、進行速率限制，並轉發至 Lambda。Lambda 讀寫 DynamoDB。端對端零伺服器管理，從零擴展至每秒數萬個請求。

模式二——S3 Event → Lambda → 下游服務

使用者上傳物件，S3 發布 object-created 事件，Lambda 進行處理（生成縮圖、擷取文字、驗證），輸出存入另一個 S3 bucket 或 DynamoDB。若多個消費者需要該事件，可在中間使用 SNS 或 EventBridge。

模式三——SQS → Lambda（輪詢式）

佇列平滑流量突刺；Lambda event source mapping 批次輪詢 SQS。使用 reserved concurrency 保護下游資料庫免於 Lambda 並行衝擊。使用 DLQ 或 Lambda Destination 處理失敗。

模式四——Fargate Worker Pool + SQS

對於 CPU 密集或長時間執行（> 15 分鐘）的 tasks，以輪詢 SQS 的 Fargate service 取代 Lambda。依據佇列深度擴展 tasks（CloudWatch 自訂指標或 SQS ApproximateNumberOfMessages 目標追蹤）。

模式五——EventBridge + 多個目標

EventBridge event bus 接收來自 SaaS 合作夥伴、自訂應用程式或 AWS 服務的事件；規則路由至 Lambda、Step Functions、Fargate task、SQS 或 Kinesis。這是扇出與基於內容路由的首選模式。

模式六——Step Functions 編排 Lambda 與 ECS Tasks

Step Functions 協調 pipeline：以 Lambda 擷取資料、以 Fargate ECS task 轉換（執行 30 分鐘）、以 SNS 發送通知。明確的狀態機提供運維可見性與宣告式重試。

如何選擇——Serverless 與容器決策框架

SAA-C03 獎勵清晰的決策流程。依序套用以下篩選器。

步驟一——執行時間篩選

• 每次 invocation 在 15 分鐘內完成？Lambda 是可能的選擇。
• 部分 invocations 執行更長？排除 Lambda；移往容器或 EC2。

步驟二——封裝方式篩選

• 程式碼是由事件觸發的單一函式？Lambda。
• 程式碼是包含多個行程、sidecars 或非 HTTP 工作負載的完整應用程式？容器。
• 程式碼是來自 Git repo 或單一映像檔的無狀態 HTTP 服務？可考慮 App Runner。

步驟三——編排方式篩選

• 無 Kubernetes 需求、希望 AWS 原生、最低 control plane 成本？ECS。
• 團隊已操作 Kubernetes 或需要可攜性？EKS。
• 希望零編排決策？App Runner。

步驟四——Host 管理篩選

• 無需管理 EC2、按 task 計費、負載變動？Fargate（on ECS 或 EKS）。
• 需要特定 instance 類型、GPU 或穩定狀態成本最佳化？EC2 launch type（on ECS 或 EKS）。

步驟五——成本最佳化篩選

• 突刺或不可預測？Lambda 或 Fargate。
• 穩定且高量？搭配 Savings Plans 或 Spot 的 EC2 上容器。
• 可容忍中斷的批次？Fargate Spot 或 EC2 Spot。

Serverless 與容器中的無狀態 vs 有狀態

AWS 上的 Serverless 與容器最適合無狀態工作負載。有狀態工作負載需要有意識地設計狀態的存放位置。

• Lambda——設計上完全無狀態；任何所需的狀態應存放於 DynamoDB、RDS（透過 RDS Proxy）、ElastiCache 或 S3。
• Fargate tasks——預設為暫時性；使用 EFS volumes 共用狀態或使用外部資料存放。
• ECS / EKS on EC2——可使用 instance-store 進行本地高速狀態存取，但應將任何節點視為可拋棄的。
• App Runner——僅限無狀態；無持久 volumes。

對於資料庫，受管服務（Amazon RDS、Aurora、DynamoDB、ElastiCache、MemoryDB）是 SAA-C03 的預設答案；容器上的自管資料庫僅出現在少數邊緣案例中。

Serverless 與容器必背數字

• Lambda timeout：最長 15 分鐘（900 秒），預設 3 秒。
• Lambda memory：128 MB 至 10,240 MB，以 1 MB 為步進；10 GB 時達 6 vCPUs。
• Lambda /tmp：預設 512 MB，最高可設定至 10,240 MB。
• Lambda 部署套件：直接 zip 50 MB，未壓縮 250 MB，容器映像檔 10 GB。
• Lambda payload：同步 6 MB，非同步 256 KB。
• Lambda 並行執行數：每個 Region 預設 1,000（軟性限制）。
• Lambda Layers：每個函式 5 個 layers，含程式碼的總未壓縮大小 250 MB。
• Fargate CPU/memory 組合：0.25 vCPU（0.5–2 GB）至 16 vCPU（30–120 GB）。
• Fargate Spot 折扣：最高 70%。
• ECS control plane：免費。
• EKS control plane：每叢集每小時 $0.10（約每月 $73）。
• Step Functions Standard workflow 持續時間：每次執行最長 1 年。
• Step Functions Express workflow 持續時間：每次執行最長 5 分鐘。
• App Runner 計費：vCPU 與記憶體按秒計費，加上每請求費用。

Serverless 與容器的常見考試陷阱

陷阱模式在每次 SAA-C03 考試中反覆出現。認識它們就是送分。

陷阱一——Lambda 用於長時間執行的工作

「處理 3 小時的批次工作」絕對不是 Lambda 的答案。正確答案是 AWS Batch on Fargate 或 EC2、ECS task，或是 Step Functions 以 Map state 編排多個較短的 Lambda invocations。

陷阱二——Reserved Concurrency 與 Provisioned Concurrency 混淆

Reserved 限制並保留 quota；provisioned 預熱執行環境。若題目問的是冷啟動，正確答案是 provisioned concurrency 或 SnapStart——不是 reserved。

陷阱三——Fargate 被視為 ECS 的對等物

Fargate 是 ECS 與 EKS 的 launch type，不是獨立的編排器。正確說法是「ECS on Fargate」或「EKS on Fargate」。

陷阱四——當 ECS 更便宜且足夠時選擇了 EKS

若情境中未提及 Kubernetes、Helm、多雲或開源 operators，ECS on Fargate 通常是正確（且更便宜）的答案。

陷阱五——假設 VPC-Attached Lambda 有網際網路存取

VPC Lambda 需要 public subnet 中的 NAT gateway 才能對外 egress，或使用 VPC endpoints 存取 AWS 服務。此陷阱出現在提及外部 API 呼叫的情境中。

陷阱六——將 DLQ 視為足夠的可觀測性

現代架構使用 Lambda Destinations 同時路由成功與失敗。DLQ 是舊有的子集。

陷阱七——忽略 App Runner

SAA-C03 已將 App Runner 加入支援服務清單。對於來自 Git repo 或單一映像檔的無狀態 HTTP API，App Runner 往往是最佳答案——但不熟悉該服務的應試者通常會預設選 ECS on Fargate。

Serverless 與容器 vs 鄰近主題——邊界線

SAA-C03 將 Serverless 與容器和密切相關的主題分開考核。了解邊界。

• serverless-and-containers vs messaging-and-decoupling（同為任務 2.1）——運算面 vs 訊息面。SQS、SNS、EventBridge 屬於 messaging；Lambda 與 Fargate 屬於此處。大多數考試情境兩者兼有。
• serverless-and-containers vs elastic-compute-scaling（任務 3.2）——此主題涵蓋執行什麼；elastic-compute-scaling 涵蓋如何擴展與調整大小。Lambda concurrency 調校為兩個主題共有；instance 家族選擇屬於 elastic-compute-scaling。
• serverless-and-containers vs cost-optimized-compute（任務 4.2）——相同服務的成本視角。Spot Fargate、Lambda 記憶體調校與 Compute Savings Plans 屬於 cost-optimized-compute。
• serverless-and-containers vs api-gateway-and-edge（任務 2.1）——API Gateway 是觸發器，Lambda 是運算。整合模式跨越兩個主題。
• serverless-and-containers vs high-availability-multi-az（任務 2.2）——Lambda 與 Fargate 預設跨可用區域提供高可用性；跨 Region 的高可用性屬於 high-availability-multi-az。

練習題信號——任務 2.1 對應練習

使用 SAA-C03 題庫深入練習 Serverless 與容器模式。信號詞語與正確答案：

1. 「以最低運維負擔處理圖片上傳事件」→ S3 event → Lambda。
2. 「從 Git repository 執行無狀態 HTTP API，無需管理基礎設施」→ AWS App Runner。
3. 「容器化微服務，團隊已熟悉 Kubernetes」→ Amazon EKS。
4. 「長時間執行的容器 task（> 15 分鐘），無需管理 EC2」→ ECS on Fargate。
5. 「降低 Java API 的冷啟動延遲，且不增加每小時費用」→ Lambda SnapStart。
6. 「保證對延遲敏感的 endpoint 零冷啟動」→ Lambda Provisioned Concurrency。
7. 「防止 Lambda 函式壓垮 RDS 資料庫」→ 在 Lambda 函式上設定 Reserved concurrency。
8. 「在含有內建重試與視覺化的多步驟工作流程中協調 Lambda 與 Fargate 步驟」→ AWS Step Functions。
9. 「從一個來源扇出事件至多個 Lambda 函式與一個 SQS 佇列」→ EventBridge 或 SNS。
10. 「在可中斷容量上以成本效益方式執行超過 15 分鐘的批次工作負載」→ AWS Batch on Fargate Spot 或 EC2 Spot。

FAQ——Serverless 與容器熱門問題

Q1. 在 Serverless 與容器工作負載中，何時應選擇 AWS Lambda 而非 Fargate？

當工作負載是事件驅動、每次 invocation 在 15 分鐘內完成、能從毫秒計費中獲益，且不需要自訂網路堆疊或 sidecars 時，選擇 AWS Lambda。當工作負載是長時間執行的容器、需要包含 sidecars 的多容器 task 設計、執行非 HTTP 協議，或超過 Lambda 的 15 分鐘 timeout 時，選擇 AWS Fargate。許多生產架構兩者並用：Lambda 用於事件膠水與同步 API，Fargate 用於背景 workers 與 CPU 密集 tasks。

Q2. AWS Lambda 中 reserved concurrency 與 provisioned concurrency 有何不同？

Reserved concurrency 為單一 Lambda 函式的並行執行數設定上限與保障底板，並從帳戶層級 concurrency pool 中劃出該數量。Reserved concurrency 不能消除冷啟動。Provisioned concurrency 預先初始化指定數量的執行環境，使其能立即回應且無冷啟動，在 invocation 費用之外另有每小時計費，適合對延遲敏感的 API。兩者可組合使用：reserved concurrency 限制總並行數，provisioned concurrency 則預熱其中一部分執行環境。

Q3. Lambda SnapStart 如何降低冷啟動，以及何時應使用它而非 provisioned concurrency？

Lambda SnapStart 在 init 階段完成後拍取初始化執行環境的快照，並在需要冷啟動時從該快照還原。對於支援的 runtimes——Java、Python 及 .NET 受管 runtimes——SnapStart 能以零額外費用將冷啟動延遲從數秒降至次秒級別。SnapStart 可用時請優先使用，因為它是免費的。以下情況請改用 provisioned concurrency：SnapStart 不支援（容器映像檔、不支援的 runtimes）、需要保證無論初始化複雜度如何都能達到 p99 延遲低於 100 ms，或函式使用會破壞 SnapStart 語意的動態狀態。

Q4. 容器編排何時應選擇 Amazon EKS 而非 Amazon ECS？

當你的團隊已在地端或其他雲端操作 Kubernetes 且希望使用可攜的 manifests、依賴 Kubernetes 生態系（Helm、operators、Istio 等服務網格、Argo CD 等 GitOps 工具）、供應商軟體以 Kubernetes manifests 形式交付，或組織標準化要求使用 Kubernetes APIs 時，選擇 Amazon EKS。當你希望在 AWS 上從 Dockerfile 到生產環境的最快路徑、與 IAM / CloudWatch / ALB 的深度原生整合、最低 control plane 成本（ECS control plane 免費，EKS 每叢集每小時 $0.10），或不需要 Kubernetes 特定概念的更簡單心智模型時，選擇 Amazon ECS。對於大多數僅在 AWS 上的全新工作負載，ECS on Fargate 是最快且最便宜的選擇。

Q5. 何時 AWS App Runner 優於 ECS on Fargate？

當團隊希望零基礎設施管理時，AWS App Runner 是無狀態 HTTP 網頁應用程式與 API 的正確答案。App Runner 自動處理 load balancer、HTTPS 憑證、auto scaling、部署與 VPC connector。當工作負載為 HTTP 限定、無狀態、可從 ECR 映像檔或 GitHub 原始碼執行，且團隊偏好既定的預設值時，選擇 App Runner。當需要完整的網路控制、包含 sidecars 的多容器 task、非 HTTP 協議，或 CodeDeploy 藍/綠部署等精細部署策略時，選擇 ECS on Fargate。

Q6. 在 Serverless 與容器領域中，如何在不使用 Lambda 的情況下執行超過 15 分鐘的工作負載？

超過 Lambda 15 分鐘 timeout 的工作負載，在 Serverless 與容器空間中有幾個選項。ECS on Fargate 與 EKS on Fargate 無需管理 host，可執行任意時長的容器。AWS Batch 在 Fargate 或 EC2 上協調長時間執行的批次工作，並支援佇列、重試與 Spot。Step Functions Standard workflows 可協調最長 1 年的多步驟流程，以 Map 與 Parallel states 鏈接較短的 Lambda invocations。若需要最低運維負擔的長時間執行 HTTP 服務，AWS App Runner 也是一個選項。決策通常取決於工作負載是 HTTP 型（App Runner 或 Fargate behind ALB）、批次型（AWS Batch）還是多步驟編排型（Step Functions 驅動 Lambda 與 Fargate）。

Q7. 在 AWS 上結合 Serverless 與容器的正確事件驅動模式為何？

在 AWS 上結合 Serverless 與容器的標準事件驅動模式包含：API Gateway + Lambda + DynamoDB 用於三層 Serverless API；S3 events → Lambda 用於物件處理 pipeline；SQS → Lambda 搭配 reserved concurrency 用於保護下游系統；SQS → Fargate worker pool 用於 CPU 密集或長時間執行的 tasks；EventBridge 規則路由至 Lambda、Step Functions、Fargate 或 SNS 用於扇出與基於內容的路由；以及 Step Functions 編排 Lambda 與 Fargate tasks 用於持久的多步驟工作流程。Kinesis Data Streams 或 DynamoDB Streams → Lambda event source mapping 涵蓋即時串流處理。SAA-C03 考試獎勵從情境描述中識別這些模式，勝過記憶服務細節。

摘要——Serverless 與容器速覽

• AWS 上的 Serverless 與容器涵蓋 AWS Lambda（函式）、AWS Fargate（Serverless 容器）、Amazon ECS（AWS 原生編排）、Amazon EKS（受管 Kubernetes）及 AWS App Runner（全託管容器網頁應用程式）。
• Lambda 有 15 分鐘的硬性上限、記憶體 128 MB 至 10 GB、可掛載至 VPC，支援 Layers、Destinations、reserved concurrency、provisioned concurrency 及 SnapStart。
• Reserved concurrency 限制並行數；provisioned concurrency 預熱執行環境；SnapStart 對 init 階段拍取快照，以零成本降低 Java、Python、.NET 的冷啟動。
• Fargate 是 ECS 與 EKS 使用的 Serverless launch type——永遠不是獨立的編排器。Task definitions 捕捉 CPU、memory、網路、IAM roles、日誌設定。
• ECS 在 control plane 層免費，是 AWS 原生容器的最快路徑。EKS 每叢集每小時收費 $0.10，是需要 Kubernetes 可攜性或生態系時的正確答案。
• App Runner 是來自 ECR 或 GitHub 的無狀態 HTTP 應用程式的「零決策」選項。
• 冷啟動緩解優先順序：快速 runtime → 小套件 → SnapStart → provisioned concurrency → 更大記憶體。
• Serverless 與容器與 SQS、SNS、EventBridge、Kinesis 及 Step Functions 結合，形成主導 SAA-C03 Domain 2 的可重複使用事件驅動模式。
• 依序套用決策框架：執行時間篩選 → 封裝方式篩選 → 編排方式篩選 → Host 管理篩選 → 成本最佳化篩選。

在此深度精通 Serverless 與容器，SAA-C03 Domain 2.1 的 450 題就會從死背變成模式識別。當你繼續 AWS 認證之路，進入 DVA-C02 與 SAP-C02 時，同樣的心智模型也一樣適用。