DOP-C02 中的可擴展性是負載平衡、快取和無伺服器容量在整個應用程式堆疊中的綜合體現。考試測試何時 ALB 優於 NLB、何時 CloudFront 優於 ElastiCache、何時 Lambda 預配置並行是比預留並行更好的答案、何時 DynamoDB 隨需模式優於預配置模式，以及 API Gateway 流量調整 (Throttling) 與 Fargate 容量提供者如何與堆疊的其他部分互動。領域 3.2（「可擴展以滿足業務要求」）是領域 3 中最大的單一子章節。
本指南假設您已瞭解 ALB 和 Lambda 函數。DOP-C02 的重點在於：ALB 目標群組、接聽程式、規則、NLB 與 Gateway Load Balancer 的使用案例、跨區域負載平衡 (Cross-zone load balancing) 的語義與定價、CloudFront 快取行為與來源故障轉移、ElastiCache Redis vs Memcached、用於 DynamoDB 讀取加速的 DAX、Lambda 預留 vs 預配置並行、API Gateway 爆發與穩態限制、ECS 中的 Fargate vs EC2 容量提供者、DynamoDB 隨需 vs 具備自動縮放的預配置模式，以及用於跨區域加速的 Global Accelerator。
為什麼可擴展性在 DOP-C02 中很重要
DOP-C02 將「識別並實作適當的自動縮放、負載平衡與快取解決方案」列為領域 3.2 的首項技能。社群考試回報指出，可擴展性情境是測試頻率最高的類別之一：「快閃促銷期間出現 100 倍流量尖峰；請選擇架構」 —— 答案是 API Gateway + Lambda 預配置並行 + DynamoDB 隨需模式 + CloudFront。「擁有 50,000 名客戶的多租戶 SaaS」 —— ALB 基於主機的路由 + ECS Fargate + Aurora Serverless。「具備亞毫秒延遲的即時遊戲後端」 —— NLB + 具備置放群組的 EC2 + ElastiCache Redis。考試測試對每一層的精確挑選。
考試還區分了擴展原語（ASG, Application Auto Scaling, Lambda 並行）、快取原語（CloudFront, ElastiCache, DAX, API Gateway 快取）以及負載平衡原語（ALB, NLB, GWLB）。針對瓶頸找出正確的層級是排除法的第一步。
- Application Load Balancer (ALB)：第 7 層負載平衡器；按主機標頭、路徑、查詢字串、標頭、來源 IP 路由；支持 HTTPS, HTTP/2, gRPC, WebSocket。
- Network Load Balancer (NLB)：第 4 層負載平衡器；超低延遲、每個亞區固定 IP、支持 TCP, UDP, TLS 透傳。
- Gateway Load Balancer (GWLB)：第 3/4 層透明轉發器，用於插入第三方網絡設備。
- 目標群組 (Target group)：附加到接聽程式規則的後端邏輯組（EC2、IP 地址、Lambda、作為目標的 ALB）。
- 跨區域負載平衡 (Cross-zone load balancing)：將流量均勻分佈到所有亞區；ALB 預設開啟（免費），NLB 預設關閉（啟用後需支付額外的跨亞區數據費用）。
- CloudFront：具備邊緣快取、AWS Shield Standard、自定義來源、Lambda@Edge、CloudFront Functions 的 AWS CDN。
- ElastiCache：用於記憶體內快取的受管 Redis 或 Memcached。
- DAX：專為 DynamoDB 設計的記憶體內快取；透明客戶端；亞毫秒級讀取。
- Lambda 預留並行 (Reserved concurrency)：限制函數的最大並行執行次數，並從帳戶池中預留該容量。
- Lambda 預配置並行 (Provisioned concurrency)：預先熱機的 Lambda 執行環境；消除冷啟動延遲。
- API Gateway 流量調整 (Throttling)：具備爆發和速率限制的按帳戶、按 API、按階段、按方法及按金鑰的流量限制。
- DynamoDB 隨需 (On-demand)：按請求付費的容量模式；自動擴展；在高穩態吞吐量下，每個請求的成本高於預配置模式。
- 容量提供者 (Capacity provider)：將 ECS 服務映射到計算後端的 ECS 建構；支持
FARGATE、FARGATE_SPOT、自定義 EC2 ASG。 - 參考：https://docs.aws.amazon.com/elasticloadbalancing/latest/userguide/what-is-load-balancing.html
白話文解釋可擴展性分層
其機制與非軟體領域中熟悉的容量管理模式相呼應。透過負載平衡、快取和無伺服器容量三個角度來理解。
類比 1：會議中心人群管理
一個擁有 50 個大廳的會議中心要處理數萬名與會者。ALB (第 7 層) 就像是服務台工作人員，讀取與會者的證件（HTTP 標頭），並按主題將他們引導至正確的大廳（「人工智慧講座去 A 廳，安全工作坊去 B 廳」）。NLB (第 4 層) 則是入口處的紅綠燈系統，僅測量車流量並引導至停車場，不檢查車內物品 —— 速度更快、更簡單、無視內容。Gateway Load Balancer 則是安全檢查站，透明地引導每輛車通過金屬探測器後再放行。
跨區域負載平衡是各廳之間的多入口路由 —— 如果 A 廳停車場滿了，即使 B 廳在不同側，也將車流導向 B 廳。ALB 免費執行此操作；NLB 則會收取側翼間的數據傳輸費。
CloudFront 是每個停車場入口處的服務台（邊緣站點） —— 常見問題（「註冊處在哪裡」）在本地即可回答，無需長途跋涉到中央服務台。
ElastiCache (Redis/Memcached) 是中央服務台的常見問題活頁夾 —— 許多與會者問過的事情都存放在活頁夾中，因此工作人員無需每次都致電策劃辦公室。
Lambda 預留並行是為特定會議室設定的專屬翻譯員池 —— 上限為 100 名同時在場的翻譯員，因此一個熱門會議室不會搶走所有其他房間的翻譯資源。
Lambda 預配置並行是預先在房間就位並預熱的翻譯團隊 —— 當第一位與會者提問時，無需等待準備時間。
類比 2：連鎖餐廳容量網絡
連鎖餐廳在多個層級管理容量。ALB 就像是領位員，在分配桌位前詢問您的聚餐人數、過敏史和座位偏好（第 7 層路由）。NLB 則是代客泊車處，僅計算車輛，不問問題，極速。GWLB 是廚房檢查員，透明地檢查每道出的菜。
CloudFront 是預先準備好區域特色菜單的分店 —— 減少了熱門菜色往返中央廚房的次數。
ElastiCache Redis 是備有快取食材的備菜廚房 —— 主廚房無需為每份訂單切洋蔥；常用的備菜會保持新鮮可用。
DAX 是 DynamoDB 等級的冷藏庫中專門的預焙點心 —— 以微秒級的速度返回特定品項，對廚師來說是透明的。
Lambda 預配置並行是預先配置好的人手生產線 —— 在尖峰開始前廚師就已就位。預留並行是特定工作站的人數上限，防止忙碌的工作站從其他站點抽調人手。
API Gateway 流量調整是領位員的爆發與穩態上限 —— 「我們在穩態下每分鐘可以接待 5 組散客，如果所有桌子都空著，爆發上限為 50 組」。
類比 3：電網負載分佈
區域電網管理需求與容量。ALB 就像是按工業、住宅、商業分類路由電力的變電站（第 7 層感知）。NLB 是主幹線輸電線路，不經檢查即可傳輸高壓電。GWLB 是每位客戶用電都必須經過的透明計量器。
CloudFront 是邊緣的分佈式太陽能場 —— 滿足本地需求而無需從主網取電。ElastiCache 是變電站的電池儲能 —— 平滑峰值並在本地服務頻繁的需求電流。
Lambda 預留並行是為醫院變電站設定的專用容量預留 —— 即使電網其他部分過載也能保證供電。Lambda 預配置並行是旋轉備用容量 (Spinning Reserve) —— 發電機組保持運轉，以便在幾毫秒內同步並供電，而不是數小時的冷啟動。
DynamoDB 隨需模式是按量計費的工業客戶 —— 無需承諾，但每度電價格較高。具備自動縮放的預配置模式是標準住宅合約，基線會自動調整。
對於 ALB/NLB/GWLB 的區別，會議中心領位員/泊車員/檢查員捕捉最清晰。對於快取層級（CloudFront vs ElastiCache vs DAX），餐廳備菜網絡更直觀。對於 Lambda 並行類型，電網預留容量映射了權衡。參考：https://docs.aws.amazon.com/elasticloadbalancing/latest/userguide/what-is-load-balancing.html
Elastic Load Balancing
三種負載平衡器類型涵蓋了大多數使用案例。
Application Load Balancer (ALB)
第 7 層。按主機標頭、路徑、HTTP 方法、查詢字串、標頭、來源 IP 路由請求。支持：
- 使用 ACM 憑證進行 HTTPS 終止。
- HTTP/2 和 gRPC。
- WebSocket。
- 將 Lambda 作為目標（每個請求進行同步調用）。
- 為以 NLB 為前端的 ALB 提供 ALB 作為目標的功能。
- 透過 Cognito 或 OIDC 進行身分驗證。
- 粘性 (Stickiness)（基於 Cookie 或由應用程式設定的 Cookie）。
ALB 是任何 Web/API 工作負載的預設選擇。跨區域負載平衡預設開啟且免費。
Network Load Balancer (NLB)
第 4 層 (TCP/UDP/TLS)。吞吐量最高、延遲最低。支持：
- 每個亞區固定 IP（可分配一個 EIP）。
- 來源 IP 保留（客戶端看到的是原始 IP）。
- TLS 終止。
- VPC 端點服務 (PrivateLink) 提供商。
NLB 的優勢在於：超低延遲工作負載（遊戲、交易）、防火牆允許清單中需要固定 IP 的工作負載，以及 PrivateLink 端點。跨區域負載平衡預設為「關閉」；啟用它會產生跨亞區數據傳輸費。
Gateway Load Balancer (GWLB)
第 3/4 層透明轉發。將第三方網絡設備（防火牆、IDS/IPS）插入流量流中。使用 GENEVE 封裝。常見於所有 VPC 出口流量都必須經過防火牆集群的安全架構中。
目標群組、接聽程式、規則
ALB 結構：接聽程式（通訊埠 + 協定）→ 接聽程式規則（優先順序排序的條件）→ 目標群組（後端 + 健康檢查）。
常見 ALB 模式：
- 基於主機的路由：
app1.example.com→ TG-1,app2.example.com→ TG-2。 - 基於路徑的路由：
/api/*→ TG-API,/static/*→ TG-Static。 - 加權目標群組：在藍/綠部署中將流量按 90/10 比例分配給金絲雀。
ALB 始終跨區域平衡，且您無法停用它（除非在某些上下文中透過目標群組配置）。NLB 預設為關閉，意味著每個亞區的 NLB 端點僅路由到該亞區內的目標。啟用 NLB 跨區域負載平衡是一項應付費的跨亞區數據傳輸費。這種不對稱性是常見的考試陷阱。參考：https://docs.aws.amazon.com/elasticloadbalancing/latest/userguide/how-elastic-load-balancing-works.html
CloudFront 與快取層級
三種快取層級通常會組合使用。
CloudFront (邊緣)
擁有 600 多個邊緣站點的全球 CDN。按 (來源, 快取索引鍵) 進行快取，其中快取索引鍵根據快取策略包含路徑、查詢字串組件、標頭。功能：
- 來源故障轉移 (Origin failover)：主要來源 + 次要來源對；CloudFront 在配置的 HTTP 錯誤代碼發生時進行切換。
- Lambda@Edge：在 viewer-request, viewer-response, origin-request, origin-response 時運行的完整 Node.js 或 Python —— 較重且較貴。
- CloudFront Functions：用於 viewer request/response 的輕量級 JS —— 更便宜、更快、API 範圍較窄。
- 帶簽名的 URL / 帶簽名的 Cookie：針對私有內容的限時存取。
- 欄位級加密：對特定請求欄位進行端對端加密。
ElastiCache (應用程式快取)
受管 Redis 或 Memcached：
- Memcached：簡單、多執行緒、分片、無持久性、無複寫。
- Redis：豐富的數據結構（列表、集合、有序集合、串流、地理位置）、持久性 (AOF, RDB)、複寫、用於分片的叢集模式、發布/訂閱 (Pub/Sub)。
對於高吞吐量的分片快取，請使用 Redis 叢集模式；當您需要簡單的鍵值對且每個節點需要高吞吐量且無需持久性時，請使用 Memcached。
DAX (DynamoDB 加速器)
對 DynamoDB 客戶端透明的記憶體內快取。SDK 調用首先命中 DAX；快取未命中則降級到 DynamoDB。亞毫秒級讀取。包含項目快取（點讀取）和查詢快取（查詢/掃描結果）。
當 DynamoDB 讀取吞吐量成為瓶頸且項目可以容忍最終一致性讀取時使用 —— DAX 會在配置的 TTL 內提供過時數據。
DAX 快取最終一致性讀取。強烈一致性讀取會繞過快取並直接命中 DynamoDB。寫入也會透過 DAX 傳遞到 DynamoDB。考試經常測試「針對寫入密集型工作負載使用 DAX」 —— 這沒有幫助。對於強烈一致性讀取，只有 DynamoDB 標準讀取有效。參考：https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/DAX.html
Lambda 並行
Lambda 有三個並行控制旋鈕。
帳戶並行池
每個帳戶、每個區域預設為 1000 個並行執行（可透過支持調高）。除非預留，否則在所有函數之間共享。
預留並行 (Reserved Concurrency)
在函數上設定預留並行：
- 將該函數的最大並行執行次數限制為該值。
- 從帳戶池中預留該容量（其他函數無法使用）。
- 適用於「不要讓這個函數消耗超過 1000 預算中的 100 個」或「保證該函數至少有 100 個容量」。
將預留並行設為 0 會有效地停用該函數 —— 在緊急流量調整時很有用。
預配置並行 (Provisioned Concurrency)
預先初始化的執行環境。為配置的並行調用次數消除冷啟動延遲。成本較高（無論是否調用都要為環境付費）。
預配置並行是按別名（或版本）配置的，因此您可以為 prod 預配置，而讓 $LATEST 保持非預配置。結合 Application Auto Scaling，預配置並行可以按排程或響應 ProvisionedConcurrencyUtilization 指標進行擴展。
您將預配置並行套用於 Lambda 別名或特定版本。對 $LATEST 的調用始終會冷啟動，因為它們無法使用預配置環境（預配置環境綁定到不可變版本）。為了獲得可預測的效能，請始終透過配置了預配置並行的別名進行調用。參考：https://docs.aws.amazon.com/lambda/latest/dg/configuration-concurrency.html
API Gateway 流量調整 (Throttling)
API Gateway 在多個層級執行流量調整：
- 帳戶層級：每個區域預設為每秒 10,000 個穩態請求，5,000 個爆發。
- 階段層級：部署中的每個階段。
- 方法層級：階段中的每個 HTTP 方法。
- 使用計劃 + API 金鑰：針對營利型 API 的按客戶流量調整。
權杖桶 (Token Bucket) 演算法：爆發至爆發限制，按速率限制填充。
當流量被調整時，API Gateway 返回 429 Too Many Requests。客戶端應使用指數回退進行重試。
對於已知的尖峰工作負載，請透過支持調高帳戶層級的穩態限制，並在 Lambda 整合上使用預配置並行以避免下游冷啟動。
Fargate 與 ECS 容量提供者
ECS 容量提供者將 ECS 服務映射到計算後端：
FARGATE：無伺服器 ECS —— 無執行個體管理，按 vCPU 收取溢價。FARGATE_SPOT：70% 折扣，可在 2 分鐘通知後被收回。- EC2 容量提供者：由您建立的 ASG 支持；ECS 根據任務管理 ASG 的預期容量。
容量提供者策略允許加權：
- 成本優化的無狀態工作負載：50% 在 FARGATE，50% 在 FARGATE_SPOT。
- 1 個權重在 FARGATE 以確保至少有一個穩定執行個體，額外容量來自 FARGATE_SPOT。
對於由 EC2 支持的 ECS，ECS 受管擴展會調整 ASG 以使 CapacityProviderReservation 指標保持在目標附近。
DynamoDB 容量模式
兩種容量模式：
- 預配置 (Provisioned)：指定 RCU/WCU。配合自動縮放，DynamoDB 在目標利用率（預設 70%）內將容量調整至最大值。
- 隨需 (On-demand)：不指定容量。按請求付費。瞬間擴展到每秒數千個請求。
隨需模式勝出時機：
- 流量不可預測（事件驅動、流量尖峰）。
- 無基準數據的新工作負載。
- 零星工作負載（無穩態吞吐量）。
具備自動縮放的預配置模式勝出時機：
- 可以建立容量基準的穩態吞吐量。
- 高一致性吞吐量下的成本考量（預配置模式每個請求更便宜）。
您每 24 小時可以切換一次模式。
Global Accelerator
來自 AWS 邊緣的 Anycast IP，透過 AWS 骨幹網絡路由到最近的健康端點。亞秒級故障轉移，延遲低於網際網路路由。
適用於：需要全球加速的 TCP/UDP 非 HTTP 工作負載（遊戲、物聯網）、需要固定 IP 的應用程式以及超低延遲的全球應用。CloudFront 為 HTTP/HTTPS 提供類似角色。
常考陷阱 (Common Pitfalls)
- 為非 HTTP 工作負載選擇 ALB：非 HTTP 請選 NLB 或 GWLB；ALB 無法終止原始 TCP。
- 忘記 NLB 跨區域平衡預設關閉：如果亞區的目標計數不對稱，會導致分佈不均。
- 將預配置並行視為函數級設定：它是別名級別的；對
$LATEST的調用始終冷啟動。 - 將 DAX 用於強烈一致性讀取：DAX 對強烈一致性讀取會直接繞過。
- 認為 DynamoDB 隨需模式普遍更便宜：對於穩定的高吞吐量，預配置模式要便宜得多。
- 忘記 API Gateway 爆發限制：在冷啟動時猛衝的客戶端必須遵守爆發配額。
- 在 CloudFront 即可滿足的情況下疊加 ElastiCache：對於靜態或近乎靜態的內容，邊緣快取更便宜且更快。
DOP-C02 考試優先順序 —— 使用 ELB、快取與無伺服器實現可擴展性。 此主題在 DOP-C02 考試中佔有舉足輕重的地位。掌握各 AWS 服務公開的權衡、決策邊界和成本/效能觸發因素 —— 考試將測試那些依賴於知道哪個服務是錯誤答案的情境，而不僅僅是哪個是正確的。
常見問題
Q1：我何時應該偏好 ALB 而非 CloudFront？
區域內請求路由用 ALB；靜態或可快取內容的全球邊緣快取用 CloudFront。它們可以組合：ALB 前置 CloudFront 是具備動態後端的全球 Web 應用的標準生產模式。
Q2：如何在 ElastiCache Redis 與 Memcached 之間做選擇？
Redis 適用於：持久性、複寫、複雜數據類型、發布/訂閱。Memcached 適用於：單個節點極高吞吐量的簡單鍵值對，且無需持久性。現代應用程式預設使用 Redis。
Q3：Lambda 預配置並行何時變得不划算？
當工作負載足夠密集，冷啟動已被分攤到許多請求中時，或者當延遲敏感的路徑可以移動到 Fargate 或 EC2 時。全天候 100% 利用率的預配置並行通常比運行小型 EC2 集群更貴。
Q4：我可以在 ALB 上使用加權目標群組進行金絲雀部署嗎？
可以。ALB 接聽程式規則支持向多個目標群組進行加權轉發（例如，95% 到穩定 TG，5% 到金絲雀 TG）。這是一種由 CodeDeploy 編排的模式；同樣的權重也是 ALB 實現藍/綠部署的方式。
Q5：DynamoDB 隨需模式如何處理流量尖峰？
隨需模式在 30 分鐘內可瞬間擴展至先前峰值的兩倍；超過先前峰值 2 倍的尖峰可能會被流量調整。對於史無前例的尖峰，建議在尖峰前透過逐漸增加流量來預熱資料表，或短暫切換到具備高 RCU/WCU 的預配置模式。
Q6：ASG、Application Auto Scaling 與容量提供者之間的關係是什麼？
ASG 直接擴展 EC2 集群。Application Auto Scaling 針對非 EC2 資源（DynamoDB 表、Aurora 複本、ECS 服務、Lambda 預配置並行、AppStream, Comprehend）。ECS 容量提供者封裝了 ASG，根據任務放置需求擴展執行個體。
Q7：何時應使用 Global Accelerator 而非 Route 53 以延遲為基礎的路由？
Global Accelerator：TCP/UDP、亞秒級故障轉移、AWS 骨幹網絡路由、固定 Anycast IP。Route 53 延遲路由：基於 DNS、受 TTL 限制的故障轉移、無固定 IP。對於 HTTP，CloudFront 通常優於兩者。對於非 HTTP 的全球低延遲需求，Global Accelerator 勝出。
總結
DOP-C02 中的可擴展性是負載平衡（HTTP 用 ALB，TCP/UDP 用 NLB，內聯設備用 GWLB）、快取（邊緣用 CloudFront，應用程式數據用 ElastiCache，DynamoDB 用 DAX）與無伺服器容量（Lambda 並行控制、API Gateway 流量調整、Fargate 容量提供者、DynamoDB 隨需 vs 預配置）的協奏。為瓶頸挑選正確的層級，記住跨區域預設值（ALB 開，NLB 關）、並行類型（預留限制，預配置預熱）以及容量模式的權衡（隨需應對不可預測，預配置應對高穩態吞吐量）。掌握了這些，可擴展性情境題目就能迎刃而解。