AWS 認證準備 ch08 Serverless 與容器
下一章→
CH 08 中高頻考點

Serverless 與容器

LambdaAPI GatewayECSEKSFargateStep Functions

本章比較「不管伺服器」的兩條路線:Lambda(事件驅動、15 分鐘限制)與容器化(ECS / EKS 搭配 Fargate)。再加上 API Gateway 作為入口、Step Functions 串接多步驟流程,構成現代 Serverless 架構的核心組件。

  • 核心特性:事件驅動的 Serverless 函數,無需管理伺服器。按實際執行次數和時間計費(免費額度:每月 100 萬次調用)。
  • 執行限制:最長執行時間 15 分鐘(超過要考慮 ECS/Fargate);記憶體 128MB~10GB;儲存(/tmp)最大 10GB;並發限制每帳號預設 1000(可申請提升)。
  • 觸發器(Triggers):ALB、API Gateway、S3 事件、DynamoDB Streams、Kinesis、SQS、SNS、CloudWatch Events、Cognito 等。
  • Lambda Layers:共用函式庫、依賴套件,讓多個 Lambda 共用,減少每個 Lambda 的部署包大小。
  • 並發(Concurrency):
    ・Provisioned Concurrency:預先暖機,消除 Cold Start 問題,適合對延遲敏感的應用。
    ・Reserved Concurrency:為特定函數保留並發配額,防止其他函數耗盡資源。
  • Lambda 在 VPC 內:Lambda 預設在 AWS 管理的網路,若需要存取 VPC 內資源(RDS、ElastiCache),可以設定 VPC 連線。注意:VPC 內的 Lambda 預設無法連接互聯網,需要 NAT Gateway。
🚨 考試重點:Lambda 最長 15 分鐘。超過 15 分鐘的任務選 ECS/Fargate 或 Batch,不是 Lambda。
⭐ Cold Start:Lambda 初次被呼叫或長時間未使用後,需要時間初始化執行環境,導致延遲增加。Provisioned Concurrency 可以消除 Cold Start。

🧱 白話:API = 餐廳的服務生+菜單(客戶端照文件下單,不用管廚房怎麼做菜),API Gateway 就是「統一收單的門面」:驗證誰能點餐、限流(超量回 429)、管版本,再把單子轉給後面的 Lambda/EC2。API 與 REST 的地基見 基礎篇 ch08 API 與非同步。

  • 三種類型:
    ・REST API:功能最完整,支援 API Keys、Usage Plans、Request Validation、Cache、Throttling。
    ・HTTP API:比 REST API 便宜 70%,延遲更低,功能精簡(適合 Lambda + ALB 整合)。不支援 API Keys 和 AWS WAF 直接整合。
    ・WebSocket API:支援雙向即時通訊(聊天室、即時遊戲)。
  • 後端整合:Lambda、HTTP Endpoint、AWS 服務(如直接呼叫 DynamoDB、SQS)。
  • Stage 與 Deployment:API 需要 Deploy 到 Stage(如 dev、prod)才能使用。每個 Stage 可以有不同的 Throttling、Cache 設定。
  • Throttling:預設每秒 10,000 請求(Account 層級),每個 Stage 可以設定個別的 Throttling。超過限制回傳 429 Too Many Requests。
  • Canary Deployment:在同一個 Stage 把少量流量(如 5%)導向新版 Lambda,測試無誤後切換全部流量。
💡 REST API vs HTTP API:需要 WAF、API Keys、Usage Plans、完整 Cache → REST API;只需要輕量快速的 API → HTTP API(便宜 70%)。

🧱 容器 vs VM 的完整比較(共用公寓房間 vs 獨立套房)與 Fargate 在「抽象階梯」上的定位,見 基礎篇 ch05 虛擬化與容器。

先快速補一下背景知識:容器(Container)是把應用程式跟它需要的所有依賴(函式庫、環境設定)打包成一個獨立、可攜帶的執行單位,最有名的實作是 Docker——比起傳統直接在伺服器上跑程式,容器的好處是「在我電腦上跑得動」的環境差異問題大幅減少,因為打包好的東西到哪台機器都長一樣。當你的服務由幾十、幾百個容器組成,就需要一個「編排(Orchestration)」系統來自動決定容器要放哪台機器、掛了要不要重啟、流量怎麼分配——Kubernetes(K8s)是目前業界最主流的容器編排系統,而 AWS 提供了兩種選擇來跑容器:自家的 ECS,或托管版的 Kubernetes(EKS)。

  • ECS(Elastic Container Service):AWS 原生容器編排服務。使用 Task Definition 定義容器(映像、CPU、記憶體、環境變數)。
    ・EC2 Launch Type:自己管理 EC2 叢集,有更多控制權,可用 Spot Instances 節省費用。
    ・Fargate Launch Type:Serverless 容器,不需要管理 EC2,AWS 完全管理底層基礎設施,按 CPU/記憶體使用量計費。
  • EKS(Elastic Kubernetes Service):AWS 管理的 Kubernetes(K8s)。適合:已有 K8s 專業知識的團隊、需要跨雲或 On-Premises K8s 一致性。比 ECS 複雜但更強大靈活。也支援 Fargate(無需管理節點)。
  • ECR(Elastic Container Registry):AWS 的 Docker 映像倉庫,與 ECS/EKS 深度整合,支援 IAM 控制存取。
  • ECS Service Auto Scaling:根據 CPU、記憶體、SQS 佇列長度等指標自動調整 Task 數量。
⭐ 選擇原則:不熟 K8s → ECS;已有 K8s 基礎 → EKS;不想管伺服器 → Fargate(ECS 或 EKS 都支援)。
🚨 常見誤解:Fargate 的「Serverless」只代表沒有 EC2 主機要你開機、修補、算容量,不是什麼都不用管。容器映像裡的 OS 套件與 CVE 修補、Task Definition 的 CPU/記憶體組合、VPC/Security Group、Service Auto Scaling 規則,全部仍然是你的責任——共同責任模型的分界線只是往上移了一層,並沒有消失。
對照 Lambda:你交出去的是「一段函式程式碼」,連容器都不用碰;Fargate 你交出去的是「一個容器映像 + Task 定義」,容器裡面的一切都算你的。一句話記法:Lambda 不管伺服器也不管容器,Fargate 不管伺服器但要管容器。
🚨 考試陷阱:Fargate 不支援 GPU workload(需要用 ECS EC2 Launch Type 的 GPU 實例);任務執行時間超過 Lambda 的 15 分鐘限制,選 ECS/Fargate。

AWS Step Functions(工作流程編排):

  • 視覺化的狀態機器,編排多個 Lambda 函數和 AWS 服務的順序執行。
  • 支援:序列執行、並行執行、條件分支、重試、錯誤處理。
  • 最長執行時間:Standard 模式 1 年;Express 模式 5 分鐘。
  • 適合:訂單處理流程、資料處理 Pipeline、人工審核流程(等待人類操作)。

其他重要 Serverless 服務:

  • AWS Batch:完全託管的批次運算,不限執行時間(不像 Lambda 最多 15 分鐘)。使用 EC2/Spot 執行,適合大規模的批次處理任務。
  • AWS AppRunner:最簡單的方式部署 Web 應用和 API,從原始碼或容器映像自動建置和部署。
  • AWS SAM(Serverless Application Model):簡化 Serverless 應用(Lambda + API GW + DynamoDB 等)的開發和部署,IaC 工具,是 CloudFormation 的延伸。
💡 Step Functions vs SQS:Step Functions 用於複雜的多步驟工作流程(有條件、重試、視覺化);SQS 用於簡單的訊息佇列解耦(生產者消費者)。
Lambda vs EC2 vs Fargate
特性LambdaFargate(ECS/EKS)EC2
伺服器管理完全不管(連容器都不用)不管主機,容器映像自理主機 + OS 全部自管
你要負責什麼函式程式碼、記憶體/timeout、IAM Role、觸發來源容器映像(含 OS 套件與 CVE 修補)、Task 定義、VPC/Security Group以上全部 + 主機 OS 修補、叢集容量規劃
誰負責擴縮AWS 自動依請求數(你只設併發上限)自己設 Service Auto Scaling(挑指標、訂閾值)自己設 ASG,還要顧叢集有沒有空位
最長執行時間15 分鐘無限制無限制
計費方式按請求數 + 執行時間按 CPU + 記憶體使用量按小時(開機就收費)
Cold Start有(可用 Provisioned 解決)容器啟動時間無(已在運行)
適合事件驅動、短期任務長期運行的容器服務需要完整控制的應用
ECS vs EKS 選擇
維度ECSEKS
複雜度較低(AWS 原生,上手快)較高(K8s 學習曲線陡)
適合團隊AWS 原生、不熟 K8s已有 K8s 經驗、跨雲需求
Fargate 支援✅✅
生態系統AWS 深度整合K8s 豐富的開源生態
費用低(無控制平面費)有 EKS 控制平面費(每小時 $0.10)
API Gateway 三種類型
類型協定費用特性適合
REST APIHTTP/HTTPS較高功能最完整(API Keys、WAF、Cache)需要完整 API 管理功能
HTTP APIHTTP/HTTPS比 REST 便宜 70%延遲低、輕量、OIDC/OAuth2 整合Lambda 代理、簡單 API
WebSocket APIWebSocket中雙向即時通訊聊天室、即時遊戲、即時更新

練習題 點選選項查看解析

0 / 24
01 / 24
一個影像處理任務需要對上傳到 S3 的每張圖片進行 AI 分析,每次分析需要約 20 分鐘。應該使用哪個服務?
A 改用 AWS Lambda 處理
B 改用 ECS with Fargate
C 改用 AWS Glue 處理
D 改用 EC2 Spot Instances
解析
Lambda 的最長執行時間是 15 分鐘,20 分鐘的任務超出限制。ECS with Fargate 是正確選擇:它是 Serverless 容器(不需要管理 EC2),沒有執行時間限制,可以透過 SQS 佇列解耦(S3 事件 → SQS → ECS Task),按實際使用量計費。AWS Glue 是 ETL 服務,不適合 AI 分析。Spot Instance 需要自己管理基礎設施。
02 / 24
一個公司使用 Lambda 函數,在特定促銷活動開始的瞬間會湧入大量請求,用戶反映 API 回應時間很長(Cold Start 問題)。如何解決?
A 調高 Lambda 記憶體配置
B 啟用 Provisioned Concurrency
C 改用 EC2 Auto Scaling 服務
D 調高逾時時間上限設定
解析
Cold Start 是 Lambda 在冷啟動時需要初始化執行環境(下載程式碼、初始化 Runtime)導致的延遲。Provisioned Concurrency 讓 Lambda 預先維持一定數量的「熱」執行環境,呼叫時立即回應,消除 Cold Start。雖然增加 RAM 可以加快初始化,但不能消除 Cold Start 本身。
03 / 24
一個團隊要部署微服務應用,使用容器技術,但團隊對 Kubernetes 不熟悉,希望降低管理複雜度,且不想管理底層 EC2 伺服器。最適合的方案是?
A 用 EKS 搭配 EC2 節點組
B 用 ECS 搭配 Fargate
C 在 EC2 手動部署 Docker
D 用 Lambda 容器映像
解析
ECS with Fargate 是這個場景的最佳選擇:ECS 是 AWS 原生的容器編排服務(比 EKS/K8s 簡單),Fargate 是 Serverless 容器執行環境(完全不需要管理 EC2)。EKS 雖然也支援 Fargate,但 Kubernetes 本身的學習曲線高,與需求不符。Lambda with Container Image 有 15 分鐘執行時間限制,不適合長期運行的微服務。
04 / 24
一個電商訂單處理系統需要依序執行:驗證訂單 → 扣款 → 寄送確認信 → 通知倉庫出貨,中間每步驟都有可能失敗需要重試,且需要視覺化監控整個流程狀態。最適合的服務是?
A 多個 Lambda 互相直接呼叫
B 用 Amazon SQS 佇列串接
C 用 AWS Step Functions 編排
D 用 Amazon EventBridge 觸發
解析
AWS Step Functions 正是為這種複雜多步驟工作流程設計的:① 支援序列執行、條件分支、並行;② 內建重試和錯誤處理機制(不需要在每個 Lambda 都寫重試邏輯);③ 提供視覺化的狀態機器介面,可即時監控每個訂單在哪個步驟。Lambda 互相呼叫會讓邏輯分散且難以維護;SQS 只適合簡單的生產者-消費者模式。
05 / 24
關於 API Gateway HTTP API 和 REST API 的比較,以下哪項正確?
A HTTP API 功能完整含 Keys
B REST API 較便宜延遲更低
C HTTP API 便宜不支援 Keys
D WebSocket 是 REST 子集
解析
HTTP API 是輕量級的 API Gateway,比 REST API 便宜約 70%、延遲也更低,適合簡單的 Lambda 代理和 OIDC/OAuth2 整合。但 HTTP API 不支援:API Keys、Usage Plans、直接 AWS WAF 整合、請求驗證、自訂授權器的某些功能。如果需要這些進階功能,必須使用 REST API。
06 / 24
一個應用程式需要維護 WebSocket 連線,讓伺服器可以主動推送即時更新給客戶端(如股票行情、即時聊天)。哪個 AWS 服務最合適?
A 用 REST API 搭配輪詢方式
B 用 API Gateway WebSocket API
C 用 ALB 搭配 Sticky Session
D 用 SQS 讓客戶端輪詢查詢
解析
API Gateway WebSocket API 支援雙向持久連線(Persistent Connections),伺服器可以主動推送訊息給客戶端,而不需要客戶端反覆輪詢。這對即時應用(聊天室、即時行情、遊戲)非常重要。REST API 和 Long Polling 是單向的,效率低;SQS 需要客戶端主動輪詢,不是真正的即時推送。
07 / 24
一個 Lambda 函數運算較慢,想提升其 CPU 效能。在 Lambda 中如何做?
A 調高配置的記憶體大小
B 只能改寫程式邏輯
C 調高函數逾時時間
D 多設定幾個環境變數
解析
Lambda 的 CPU 與網路能力隨「配置的記憶體」等比例增加——調高記憶體即獲得更多 vCPU,常能讓 CPU 密集函數更快(有時反而更省,因執行時間縮短)。逾時只是允許跑更久、不加速。
08 / 24
一個 Lambda 需要存取私有子網路中的 RDS 資料庫。應如何設定?
A 連接該 VPC 的子網路與 SG
B Lambda 無法存取 VPC 資源
C 把 RDS 設為公開存取
D 用 NAT 反向連入 Lambda
解析
將 Lambda 設定為連接到目標 VPC 的子網路與 SG,它就能存取私有 RDS。若該 Lambda 同時要連網際網路,仍需經由 NAT(放私有子網路)。把 RDS 設公開是錯誤且不安全的做法。
09 / 24
想「保證」某關鍵 Lambda 隨時有一定的並發配額、不被帳號內其他函數搶走。應設定?
A Reserved Concurrency 保留並發
B Provisioned Concurrency 預熱
C 設定 Dead-Letter Queue
D 使用 Lambda Layer
解析
Reserved Concurrency 為特定函數保留(並上限)一定並發額度,確保它有配額也避免它耗盡帳號共用池。Provisioned Concurrency 則是「預熱」執行環境以消除冷啟動(用途不同,常一起考)。
10 / 24
想讓 Lambda 自動從 SQS 佇列拉取訊息批次處理。應設定?
A 用 Event Source Mapping
B 改用 API Gateway 整合
C 改用 CloudFront 觸發
D 改用 Step Functions
解析
Event Source Mapping 讓 Lambda 服務自動輪詢 SQS(或 Kinesis、DynamoDB Streams)並以批次觸發函數,你不需自己寫輪詢程式。API Gateway 是同步請求入口,用途不同。
11 / 24
一個非同步觸發的 Lambda 偶爾處理失敗,想把「處理失敗的事件」收集起來以便後續排查。應設定?
A 設定 DLQ 或 Destinations
B 調高記憶體配置大小設定
C 設定 Sticky Sessions 機制
D 直接關閉自動重試機制
解析
對非同步呼叫,設定 DLQ(SQS/SNS)或 Lambda Destinations(on-failure)可把失敗事件送到指定目標留存,方便後續分析與重放,避免默默丟失。
12 / 24
想對不同的 API 使用者做「用量配額與速率限制」,並用 API Key 識別。應使用 API Gateway 的?
A Usage Plans 搭配 API Keys
B 使用 WebSocket API
C 使用 Lambda Authorizer
D 使用 Stage Variables
解析
API Gateway 的 Usage Plans 搭配 API Keys 可對不同用戶端設定速率(throttling)與配額(quota),適合對外提供 API 的分級管理。Authorizer 管的是身分驗證/授權,不是配額。
13 / 24
一個 API 的某些回應內容變動不頻繁,想降低後端負載與延遲。API Gateway 可用?
A 啟用 API Gateway 回應快取
B 關閉 Throttling 限流設定
C 改用 WebSocket API
D 新增多個部署 Stage
解析
API Gateway 可對 stage 啟用回應快取(TTL 內相同請求直接回快取),降低後端呼叫與延遲,適合變動不頻繁的資料。與 throttling/WebSocket 無關。
14 / 24
想用 Cognito User Pool 驗證的 JWT token 保護 API Gateway 端點。應設定?
A 用 Cognito 或 Lambda Authorizer
B 設定 Usage Plan 用量配額
C 設定 API Key 身分驗證機制
D 啟用回應內容的 Caching
解析
API Gateway 可設定 Cognito Authorizer 直接驗證 User Pool 簽發的 JWT(或用 Lambda Authorizer 做自訂驗證邏輯)保護端點。API Key/Usage Plan 是用量識別,非身分驗證。
15 / 24
團隊要跑容器但「完全不想管理底層 EC2 主機、依用量計費」。ECS 應選哪種啟動類型?
A 選擇 Fargate 啟動類型
B 選擇 EC2 啟動類型
C 改為自建 Kubernetes
D 改用 AWS Lambda
解析
ECS 的 Fargate 啟動類型是 Serverless,AWS 管理底層運算、依 vCPU/記憶體用量計費,無需管理 EC2。EC2 啟動類型則要你自己維護叢集主機(換取更多控制、可能更省)。
16 / 24
要儲存與管理自建的 Docker 容器映像,供 ECS/EKS 拉取部署。應使用 AWS 的?
A 使用 Amazon ECR 倉庫
B 使用 Amazon S3 儲存
C 使用 AWS CodeCommit
D 使用 Amazon DynamoDB
解析
Amazon ECR 是全託管的容器映像倉庫,與 ECS/EKS/IAM 整合、支援漏洞掃描與私有存取控制。S3 存物件、CodeCommit 存 Git 原始碼,都不是容器映像倉庫。
17 / 24
一個團隊已在地端使用 Kubernetes,想在 AWS 上跑「標準 Kubernetes」並沿用既有 K8s 工具鏈與 YAML。應選?
A 選擇 Amazon EKS
B 選擇 Amazon ECS
C 改用純 AWS Lambda
D 改用 AWS App Runner
解析
EKS 提供託管的標準 Kubernetes 控制平面,適合已投資 K8s 生態、想跨雲/地端一致的團隊。ECS 是 AWS 專屬容器編排(較簡單但非標準 K8s);Lambda/App Runner 抽象更高、非 K8s。
18 / 24
一個高頻、短時(毫秒到分鐘)、大量觸發的事件處理工作流,想用 Step Functions 且成本最佳。應選哪種類型?
A 用 Step Functions Express
B 用 Step Functions Standard
C 只能選用 Standard 模式
D 改用 Lambda 直接取代
解析
Step Functions Express Workflows 針對高流量、短時效(≤5 分鐘)的工作流,以次數計費、成本低、吞吐高;Standard 適合長時間(可達 1 年)、需精確一次執行與完整稽核的流程。依時長與頻率選擇。
19 / 24
一個開發者只想「給一個容器映像或原始碼,就自動部署成可自動擴展的 Web 服務」,不想碰 ECS/負載平衡器等細節。最適合?
A 使用 AWS App Runner
B 自行架設 EKS 叢集
C 手動設定 EC2 加 ALB
D 改用 Step Functions
解析
AWS App Runner 是全託管服務,直接從容器映像或原始碼部署 Web 應用並自動處理擴展、負載平衡、憑證等,適合想要最少維運的 Web/API 服務。EKS/EC2+ALB 需要較多設定。
20 / 24
多個 Lambda 函數共用相同的相依函式庫,想避免每個函數都打包一份、方便共用管理。應使用?
A 使用 Lambda Layers 共用函式庫
B 使用環境變數方式設定
C 設定 Dead-Letter Queue 佇列
D 啟用 Provisioned Concurrency
解析
Lambda Layers 讓你把共用的函式庫/相依打包成層、供多個函數共用,減少重複打包、方便集中更新。與並發、DLQ、環境變數無關。
21 / 24
一個容器化服務需要「持續長時間運行」(不是短事件),且不想管理伺服器。相較 Lambda,較適合?
A 使用 AWS Fargate
B 使用 AWS Lambda
C 用 EC2 Spot 執行個體
D 使用 Step Functions
解析
Lambda 有 15 分鐘上限、偏事件驅動;長時間持續運行的容器化服務用 Fargate(Serverless 容器、無限時長、免管主機)更合適。EC2 需自管;Step Functions 是編排不是執行容器。
22 / 24
一個對外 API 需要 API Key + Usage Plan + 請求驗證 + 與多種 AWS 服務整合等「較完整功能」。API Gateway 應選?
A 選擇 REST API 類型使用
B 選擇 HTTP API 類型使用
C 選擇 WebSocket API 類型
D 目前類型都不支援此功能
解析
REST API 功能較完整(API Keys/Usage Plans、請求驗證、更多整合與 WAF 等),適合需要這些進階功能的情境;HTTP API 較精簡、延遲低、成本低,適合單純的代理型 API。依功能需求選擇。
23 / 24
團隊想用容器跑需要 GPU 的機器學習推論服務,原本打算全部用 Fargate 省去管理主機。這個規劃要怎麼調整?
A Fargate 設大一點的 CPU 即可
B 改用 ECS EC2 啟動類型搭 GPU 機型
C 改用 App Runner 自動部署
D 改用 Lambda 並把記憶體調到最大
解析
Fargate 不支援 GPU 工作負載,需要 GPU 時要改用 ECS 的 EC2 Launch Type,選用 GPU 執行個體(P/G 系列)。這代表要自己管理那批 EC2。Lambda 同樣沒有 GPU,調大記憶體只會增加 CPU 配額;App Runner 是簡化 Web 服務部署,也不提供 GPU。
24 / 24
API Gateway 後面接 Lambda,促銷活動時用戶端開始大量收到 HTTP 429 錯誤,Lambda 的日誌卻沒有看到任何錯誤。最可能的原因是?
A Lambda 發生 Cold Start
B Lambda 執行超過 15 分鐘
C 超過 API Gateway 的節流上限
D API 還沒部署到 Stage
解析
429 Too Many Requests 是 API Gateway 的 Throttling 回應:請求超過帳號層級(預設每秒 10,000)或 Stage 設定的上限時,API Gateway 直接擋下,請求根本沒到 Lambda,所以 Lambda 日誌乾淨。Cold Start 只會變慢不會回 429;執行逾時會在 Lambda 留下紀錄;沒部署到 Stage 則是完全無法呼叫。

點擊卡片翻面查看答案,共 5 張。

QUESTION
Lambda 最長執行時間?超過怎麼辦?
點擊翻面
ANSWER
最長 15 分鐘。超過的任務改用:
• ECS/Fargate(容器,無限制)
• AWS Batch(批次,無限制)
點擊翻回
QUESTION
Lambda Cold Start 是什麼?如何消除?
點擊翻面
ANSWER
Lambda 首次或長時間未使用後初始化執行環境的延遲。消除方法:啟用 Provisioned Concurrency(預先暖機)。
點擊翻回
QUESTION
ECS vs EKS 如何選?
點擊翻面
ANSWER
不熟 K8s → ECS(AWS 原生,簡單)
已有 K8s 經驗/跨雲 → EKS
兩者都不想管底層 EC2 → 選 Fargate 啟動類型
點擊翻回
QUESTION
Step Functions 的核心用途?
點擊翻面
ANSWER
視覺化多步驟工作流程編排(狀態機器)。支援序列/並行/分支/重試/錯誤處理。適合訂單流程、資料Pipeline、需要多 Lambda 協作的複雜任務。
點擊翻回
QUESTION
API Gateway HTTP API vs REST API 選哪個?
點擊翻面
ANSWER
需要 API Keys/WAF/Cache → REST API
只要輕量快速便宜 → HTTP API(便宜70%)
即時雙向通訊 → WebSocket API
點擊翻回