API 管理、邊緣加速與 CDN

什麼是 AWS 上的 API Gateway 與 Edge 架構

AWS 上的 API Gateway 與 Edge 架構，是介於終端使用者與後端運算、資料庫、儲存之間的那一層。對 SAA-C03 考試而言，API Gateway 與 Edge 代表三個主要服務協同運作：Amazon API Gateway 用於發佈與管理 HTTP、REST、WebSocket API；Amazon CloudFront 負責全球內容分發與 HTTP 層級的 Edge 加速；AWS Global Accelerator 則透過 AWS 骨幹網路提供 TCP/UDP anycast 加速。在 API Gateway 與 Edge 情境中會出現的支援服務，還包括 Lambda@Edge、CloudFront Functions、Route 53 路由政策、AWS WAF 以及 AWS Shield。

API Gateway 與 Edge 這個主題位於 SAA-C03 Task 2.1「設計可擴展且鬆散耦合的架構」，但也跨及 Task 3.4（高效能網路）和 Task 4.4（成本最佳化網路）。你會看到 API Gateway 與 Edge 的題目以情境取捨的方式出現：一家全球 SaaS 公司需要低延遲的靜態資產交付（CloudFront）、一款多人連線遊戲需要靜態 IP 以便企業防火牆設定白名單（Global Accelerator）、一家新創公司想在 Lambda 前面放一個便宜的 HTTP 入口（HTTP API），以及一家企業需要對每位客戶設定速率限制並透過 API 金鑰商業化（REST API 搭配 Usage Plan）。掌握 API Gateway 與 Edge，就是要知道每種情境該選哪一個入口。

這個 SAA-C03 主題與基礎的 CLF-C02 網路服務主題有兩點不同。第一，API Gateway 與 Edge 的考試門檻很具體：你必須在 REST API 和 HTTP API 之間根據成本與功能取捨做出選擇、在 CloudFront 和 Global Accelerator 之間根據協定與快取需求做出選擇，以及在 Lambda@Edge 和 CloudFront Functions 之間根據延遲和語言限制做出選擇。第二，API Gateway 與 Edge 主題預設你已經熟悉 VPC、IAM、Lambda 和 ALB——那些是設計決策的輸入條件，而非決策本身。範疇確定後，我們就來深入 SAA-C03 API Gateway 與 Edge 的考試重點。

白話文解釋 API Gateway and Edge

API Gateway 與 Edge 這套組合可以用幾個生活化的類比快速建立心智模型，這些類比在考場遇到 scenario 題時會幫你一秒回憶服務邊界。

類比 1 — 百貨公司服務台（API Gateway）

想像一棟大型百貨公司。API Gateway 就是大門口的服務台。每位訪客（HTTP 請求）都必須先經過服務台，才能進入百貨深處。服務台同時做五件事，這五件事直接對應 API Gateway 的功能：核對識別證（透過 IAM、Cognito 或 Lambda Authorizer 進行身分驗證）；確認你被允許前往哪些樓層（授權）；執行每分鐘限制入場人數的排隊管制繩（流量限制）；針對熱門問題直接發放預印的說明單，而不是每次都打電話給各專櫃（快取）；以及在票根上蓋章記錄你的拜訪序號以供稽核（請求/回應日誌）。不同等級的客戶在服務台領到不同手環——一般會員、銀卡、金卡——而服務台追蹤每個等級本月已使用多少次（Usage Plan 搭配 API 金鑰）。沒有服務台，每位訪客就會直接衝進每個專櫃，而每家專櫃都得自己實作身分核對、人流管制和結算機制。有了 API Gateway 這個服務台，各專櫃（你的 Lambda function、ECS 服務、HTTP 後端）只需專心做生意。

類比 2 — 全台連鎖便利商店（CloudFront）

Amazon CloudFront 就像遍布全台每個街角的連鎖便利商店。消費者不必每次都大老遠跑去亞馬遜中央倉庫（你的 origin：S3、ALB 或自訂 HTTP 伺服器）取貨，直接走進附近的便利商店（CloudFront Edge 節點）就能拿到想要的東西。每家店裡備有常賣品的庫存（快取），只有當本店缺貨時，店員才會致電中央倉庫補貨（快取未命中，向 origin 取回）。CloudFront distribution 就是整個加盟體系——你告訴 CloudFront「這是我的中央倉庫地址，請在全球開店並指向它。」Cache behavior 是每個貨架區的補貨策略（「飲料保鮮 24 小時；報紙只放 1 小時」）。Signed URL 是號碼取貨單——只有持有第 4782 號單據的顧客，才能在櫃台取走預付商品。Lambda@Edge 是駐店店長，可以在把收據交還給你之前，替你改寫內容（「根據顧客所在縣市加上折扣碼」）。而 Origin Access Control（OAC） 則是一條嚴格規定：倉庫只接受連鎖店的訂單——直接走進倉庫大門的散客一律拒絕。

類比 3 — 企業免付費客服專線（Global Accelerator）

AWS Global Accelerator 就是印在每張名片上的企業 0800 免費客服電話。不管你從哪裡撥——台北、東京、塔林——電信公司都會在最近的交換局將你的電話接入企業私有電話網路（AWS 骨幹），再快速穩定地轉接到正確的內線分機（特定 AWS 區域的 ALB、NLB 或 EC2 端點）。這個類比帶出兩個關鍵特性。第一，免費號碼永遠不變——就算企業總部從西雅圖搬到都柏林，名片上的電話號碼不會改（靜態 anycast IP 不受區域或端點更換影響）。第二，電信公司的私有網路比讓打電話的人自己穿越公共電話網路更快、更穩定，不再中途斷線、輾轉換線（Global Accelerator 走 AWS 骨幹，而非公共網路）。你也可以在維護期間將特定內線的通話量調低（Traffic Dial，0–100%），或是將電話優先轉給資深客服（Endpoint Weight）。

類比 4 — 門禁感應卡系統（Lambda Authorizer）

Lambda Authorizer 就是多租戶辦公大樓的電子門禁感應卡系統。當你在大門刷卡時，一台小電腦（Lambda function）查詢你的員工編號，確認你隸屬於 X 公司，並判定「允許進入 3 到 5 樓，但不得進入 7 樓。」API Gateway 會將這個判定結果快取 5 分鐘，讓同一張卡的下次刷卡無需每次都跑去資料庫比對——這就是 Lambda Authorizer 結果快取 TTL。如果卡片過期或被撤銷，系統回應「拒絕」，門就鎖著。這個類比說明了為何 Lambda Authorizer 非常適合 OAuth/JWT 驗證、自訂 HMAC 簽章，或是不符合 IAM 或 Cognito 規格的老舊企業 SSO 系統。

有了服務台、便利商店、企業免費專線和門禁感應卡這四個心智錨點，SAA-C03 上的 API Gateway 與 Edge 題目就變成模式比對練習。

Amazon API Gateway — 託管式 API 入口

Amazon API Gateway 是一項全託管服務，讓你可以在任意規模下發佈、保護、監控與商業化 HTTP、REST 和 WebSocket API。對於 SAA-C03 的 API Gateway 與 Edge 情境，請將 API Gateway 視為 Lambda、ECS/EKS 服務、ALB/NLB 或任何公開 HTTP 後端前方的 API 外觀（facade）。API Gateway 開箱即提供 TLS、身分驗證、流量限制、快取、請求/回應轉換及 CloudWatch 指標，讓後端的 Lambda 或容器只需專注於商業邏輯。

REST API vs HTTP API vs WebSocket API — 三種類型

API Gateway 提供三種 API 類型，SAA-C03 經常要你在它們之間做選擇：

• REST API（v1） — 功能齊全的旗艦版。支援 API 金鑰、Usage Plan、請求驗證、WAF 整合、VPC 內的私有 API、請求/回應轉換（mapping template）、Edge 最佳化端點（內建 CloudFront），以及所有 Authorizer 類型。三種類型中延遲最高，每百萬次呼叫費用也最貴。
• HTTP API（v2） — 2020 年推出的更輕量、更快、更便宜的繼任版。比 REST API 便宜最多 70%，延遲約低 60%。原生支援 JWT Authorizer（OIDC 不需要 Lambda）、Lambda proxy 與 HTTP proxy 整合，以及 CORS。捨棄了部分 REST 功能：無 API 金鑰／Usage Plan、無請求驗證、無回應 mapping template、無 AWS WAF 直接整合（依現行範疇）、無 Edge 最佳化模式。
• WebSocket API — 雙向持久連線，適用於即時應用程式（聊天、協作工具、即時儀表板、多人遊戲狀態）。依客戶端傳入的 $default、$connect、$disconnect 或從 payload 萃取的自訂路由鍵來路由訊息。後端整合可為 Lambda、HTTP 或 AWS 服務。

端點類型 — Edge 最佳化 vs 區域 vs 私有

REST API 提供三種部署端點類型，這是 SAA-C03 最愛出的陷阱之一：

• Edge 最佳化（REST 預設）— 客戶端連到 CloudFront Edge，由 Edge 將請求轉送至 API 所在區域的 API Gateway。最適合全球分散的客戶端連到單一區域。
• 區域（Regional） — 客戶端直接連到該區域的 API Gateway 端點。最適合客戶端與 API 在同一區域，或是你想要在前面放上自己的 CloudFront distribution（以便自訂快取、多個 origin 或 Lambda@Edge）。如果想搭配 AWS Global Accelerator，也必須使用此類型。
• 私有（Private） — API 只能從 VPC 內部透過 Interface VPC Endpoint（AWS PrivateLink）存取。適合內部專用的微服務。

HTTP API 僅支援區域類型。

API Gateway 上的身分驗證與授權

API Gateway 支援四種身分驗證模式。了解各自的適用時機，是 API Gateway 與 Edge 複習中投報率最高的部分：

1. IAM 授權（AWS_IAM） — 呼叫端使用 AWS 憑證以 SigV4 簽署請求。用於 AWS 內部的服務對服務呼叫，或每位呼叫端都已有 IAM 身分的內部工具。支援 REST 與 HTTP API。
2. Amazon Cognito User Pool — 呼叫端向 Cognito User Pool 驗證並取得 JWT，API Gateway 自動驗證 JWT。專為行動與網頁應用程式的使用者驗證而生。支援 REST（Cognito authorizer）與 HTTP（指向 Cognito issuer 的 JWT authorizer）。
3. Lambda Authorizer（舊稱 Custom Authorizer） — API Gateway 以傳入的 token 或請求上下文呼叫你的 Lambda；Lambda 回傳 IAM 風格的政策文件，決定允許或拒絕。適用於第三方 OAuth／OIDC、HMAC 簽章、SAML assertion，或任何不符合 IAM 或 Cognito 規格的自訂驗證。結果快取最長 1 小時，可減少 Lambda 被呼叫的次數。
4. API 金鑰搭配 Usage Plan（僅限 REST） — 並非真正的身分驗證，比較像識別加上配額執行。用於 SaaS 商業化模型中的 API 用量計費。

Stage、Deployment 與 Stage Variable

API Gateway 將 API 定義與執行期部署解耦。你編輯 API 定義後，建立一個 deployment（不可變的快照），再將一個 stage（dev、test、prod）指向該 deployment。Stage variable 類似環境變數——同一份 API 定義可以在不同 stage 指向不同的 Lambda ARN（例如 ${stageVariables.functionArn}）。Stage 上的 Canary deployment 可以讓你將一定比例的流量導向新的 deployment，同時保留其餘流量在穩定版本上，這就是 API Gateway 版本的藍綠部署。

API Gateway 的流量限制與快取

流量限制保護後端不受流量突波衝擊，並防止單一客戶端耗盡所有容量：

• 帳戶層級限制 — 每個區域預設每秒 10,000 個請求（穩定）和 5,000 個請求（突波），為軟性限制。
• Stage 層級限制 — 可按 Stage 覆寫。
• 方法層級限制 — 可在 Stage 內按資源加方法覆寫。
• 每客戶端（Usage Plan）限制 — 以 API 金鑰為單位限制（僅限 REST）。

快取（僅限 REST）以獨立快取叢集的方式佈建並附加至 Stage，容量從 0.5 GB 到 237 GB。快取鍵預設為完整的請求 URL；你可以將 header 或查詢參數納入鍵值中。快取 TTL 預設 300 秒，最長 3600 秒。要使快取失效，呼叫端需傳送 Cache-Control: max-age=0，且需有 InvalidateCache 權限。

Usage Plan 與 API 金鑰 — 商業化原語

Usage Plan（僅限 REST）將 API 金鑰與配額（每日／週／月的請求數）及流量限制（每秒請求數與突波上限）綁定。典型的 SaaS 模式：建立三個 Usage Plan — 免費版（每月 1,000 次，10 RPS）、專業版（每月 100,000 次，100 RPS）、企業版（自訂） — 每位客戶取得與其方案關聯的 API 金鑰。超出配額時 API Gateway 以 429 Too Many Requests 拒絕請求。API 金鑰本身不做身分驗證；在端點處理敏感資料時，務必搭配 IAM、Cognito 或 Lambda Authorizer 做真正的安全驗證。

API Gateway vs Application Load Balancer — 如何抉擇

SAA-C03 經常考這組配對。當你需要託管式 API 功能時選 API Gateway：原生 Lambda 整合、API 金鑰／Usage Plan、請求驗證、多種驗證方式、按方法設定流量限制，或純 serverless 架構。當你需要最便宜的 HTTPS 負載平衡器來承載容器或 EC2 工作負載、大規模路徑／主機路由、gRPC 支援，或是每次請求的成本壓力很大且 API Gateway 帳戶預設的 10,000 RPS 讓你擔心時，選 ALB。HTTP API 大幅縮小了價格差距——對於 serverless Lambda 後端，在每天約 100 萬次呼叫以內，HTTP API 的成本通常低於 ALB + Lambda。

Amazon CloudFront — 全球 CDN 與 Edge 入口

Amazon CloudFront 是 AWS 的內容交付網路，擁有 600 個以上的 Edge 節點和數百個區域 Edge 快取（介於 Edge 節點與 origin 之間的第二層快取）。對 SAA-C03 的 API Gateway 與 Edge 情境而言，CloudFront 扮演三種角色：在靠近使用者的地方快取 HTTP/S 內容、在 Edge 終止 TLS（使用 ACM 憑證），以及套用 Edge 端邏輯（WAF 規則、Lambda@Edge、CloudFront Functions、Signed URL）。

Distribution、Origin 與 Cache Behavior

Distribution 是 CloudFront 的頂層設定，以 d1234abcd.cloudfront.net 主機名稱識別（可用自訂網域加上 ACM 設定別名）。每個 distribution 有一個或多個 origin — 當快取未命中時 CloudFront 向其取回資料的後端。Origin 類型包括 Amazon S3、S3 靜態網站端點、Application Load Balancer、EC2、API Gateway（Regional）、Elemental MediaStore/MediaPackage、AWS Elemental 服務，以及任何可從網際網路存取的 HTTP 伺服器（自訂 origin）。

Cache behavior 將 URL 路徑模式對應至 origin，並設定各路徑的參數（快取 TTL、允許的 HTTP 方法、轉送的 header／cookie／查詢字串、訪客協定政策、Signed URL 的受信任簽署者）。Behavior 依序評估，第一個符合的路徑勝出，預設 behavior（*）捕捉所有其他請求。典型模式：/api/* behavior 轉送至 ALB／API Gateway 且停用快取、/static/* 轉送至 S3 並快取 1 天、* 轉送至 ALB 處理動態 HTML。

Origin Group 與 Origin 容錯移轉

在 Origin Group 中定義一個主要和一個次要 origin，當主要 origin 回傳設定的 HTTP 狀態碼（通常是 5xx 和 4xx）時，CloudFront 自動切換至次要 origin。這樣不需要 DNS 容錯移轉就能實現 origin 的災難復原，且切換對訪客透明無感。

TTL、快取鍵與快取失效

CloudFront 快取 TTL 由 origin 的 Cache-Control 和 Expires header 控制，或由 distribution 的最小／預設／最大 TTL 設定控制。快取鍵預設為主機名稱加路徑；可透過 cache policy 選擇性地納入 header、cookie 或查詢字串。Invalidation 強制清除所有 Edge 節點上的物件；每月前 1,000 個路徑免費，超過則收費。最佳實踐：避免 invalidation，改用版本化的檔案名稱（app.v42.js）。

Edge 的安全性 — OAC、WAF、Shield、Signed URL、Signed Cookie

Origin Access Control（OAC） 是目前鎖定 S3 origin 的推薦方式，確保只有 CloudFront 可以讀取。OAC 取代了舊版的 Origin Access Identity（OAI）。CloudFront 以 SigV4 簽署 origin 請求，S3 儲存貯體政策透過 AWS:SourceArn 條件，僅授予特定 CloudFront distribution 存取權。使用 OAC 後，你封鎖所有 S3 公開存取，完全透過 CloudFront 提供服務——儲存貯體從公共網路上消失。

AWS WAF 附加至 CloudFront distribution，在 Edge 過濾惡意 HTTP 請求——SQL injection、XSS、Bot 模式、速率型規則、受管規則群組及自訂規則。AWS Shield Standard 免費且自動套用於每個 CloudFront distribution（一般 DDoS 防護）。AWS Shield Advanced 新增 L3/L4/L7 保護、全天候 DDoS 應變團隊存取，以及攻擊造成擴展事件的成本保護點數。

Signed URL 限制對單一物件的存取，並在你設定的時間戳記到期。Signed Cookie 以單一 cookie 限制對一組物件的存取（例如整個影片目錄或付費使用者區域），涵蓋多個 URL。兩者都依賴上傳至 CloudFront 的受信任金鑰群組中的公開金鑰；你的後端以對應的私密金鑰簽署。單次下載連結用 Signed URL；多個檔案共用同一存取邊界時用 Signed Cookie。

Lambda@Edge vs CloudFront Functions — Edge 運算的選擇

兩者都在 CloudFront Edge 節點上執行你的程式碼，但各自針對不同的工作最佳化：

• CloudFront Functions — 僅限 JavaScript（ECMAScript 5.1），毫秒以下執行，在 Edge 節點本身運作，每個 distribution 每秒最多 1,000 萬個請求。範疇：HTTP header 操作、URL 改寫、快取鍵正規化，僅限 viewer-request／viewer-response 事件類型（不支援 origin 端）。最多 1 ms CPU，2 MB 記憶體。對相同請求量，成本約為 Lambda@Edge 的六分之一。無法呼叫其他 AWS 服務或網路。
• Lambda@Edge — Node.js 或 Python，在區域 Edge 快取上運作（Lambda@Edge 是將 Lambda function 部署至特定 Edge 區域）。範疇：全部四種事件類型（viewer-request、viewer-response、origin-request、origin-response）。最多 5 秒（viewer 事件）或 30 秒（origin 事件），128 MB–10 GB 記憶體，可呼叫 AWS 服務和發出網路請求。延遲高於 CloudFront Functions。

決策規則：只需要以線速改寫 header 或 URL，用 CloudFront Functions。如果需要從 DynamoDB 取資料、呼叫其他服務，或在 origin 端做較重的邏輯，用 Lambda@Edge。

即時日誌與標準日誌

CloudFront 標準日誌每隔幾分鐘將存取日誌交付至 S3（延遲最長 24 小時，盡力交付）。即時日誌在數秒內串流至 Kinesis Data Streams，適用於即時儀表板、攻擊偵測或日誌驅動的自動化。即時日誌每條記錄收費較高，但提供近乎即時的可視性。

AWS Global Accelerator — 透過 AWS 骨幹的靜態 Anycast

AWS Global Accelerator 提供兩個靜態 anycast IP 位址（或自訂的 BYOIP 前綴），作為應用程式的固定入口。使用者的流量在最近的 AWS Edge POP（與 CloudFront 共用的 POP）進入 AWS 全球網路，然後透過 AWS 私有骨幹傳遞至特定區域的應用程式端點——在大部分的路徑上繞過擁塞的公共網路。

三個層次：Listener、Endpoint Group、Endpoint

• Accelerator — 頂層資源，擁有兩個靜態 anycast IP 和類似 a1234.awsglobalaccelerator.com 的 DNS 名稱。
• Listener — 在 anycast IP 上綁定連接埠與協定（TCP 或 UDP）。
• Endpoint Group — 按區域分組的目標，搭配 Traffic Dial（0–100%），控制路由至此區域的流量中實際打到端點的百分比（其餘流量轉移至其他區域或捨棄）。
• Endpoint — Endpoint Group 內的特定 ALB、NLB、EC2 實例或 Elastic IP。每個 Endpoint 有一個 Weight（0–255），在同一群組內的 Endpoint 之間分配流量。

Traffic Dial 與 Endpoint Weight — 運維控制手段

Traffic Dial 是 SAA-C03 中 Global Accelerator 的核心考點。將某區域的 dial 設為 0，可在數秒內將該區域的所有流量排空——非常適合藍綠區域切換、維護窗口，或在不動 DNS 的情況下降低問題區域的流量。Endpoint Weight 用於區域內的分發：將某個端點的 weight 設為 0，可將其從輪詢中移除，同時保持其暖機狀態。

CloudFront vs Global Accelerator — 標準比較

這是 SAA-C03 中最常考的 API Gateway 與 Edge 陷阱。請熟記以下對照表：

決策捷徑：若情境提到 HTTP／HTTPS 且快取有幫助，答案是 CloudFront。若情境提到 TCP／UDP、需要靜態 IP 以設定防火牆白名單，或需要不依賴 DNS TTL 的快速跨區域容錯移轉，答案是 Global Accelerator。兩者並非互斥——有些架構在同一產品中同時使用 CloudFront 負責靜態資產，以及 Global Accelerator 負責即時 TCP API。

客戶端 IP 保留

當端點為 ALB 或 Network Load Balancer 時，Global Accelerator 支援客戶端 IP 保留——你的後端看到的是原始訪客的 IP，而非 Global Accelerator 的內部 IP。這對地理位置判斷、詐欺偵測和日誌記錄很重要。ALB 端點預設啟用客戶端 IP 保留；NLB 在 TCP listener 上也支援。

Route 53 路由政策在 API Gateway 與 Edge 中的角色

Route 53 路由政策經常與 API Gateway 和 Edge 服務一起出現，因為 DNS 是最終的流量方向盤。SAA-C03 要求你為情境挑選正確的政策：

• Simple — 單一記錄，無健康檢查。
• Weighted — 按權重在多筆記錄間分配流量。藍綠部署。
• Latency-based — 路由至客戶端量測延遲最低的區域。全球多區域應用程式。
• Failover — 主動-被動。主要端點正常時服務，健康檢查失敗後切換至次要端點。
• Geolocation — 依使用者的大陸／國家／州路由。法規要求的內容本地化。
• Geoproximity — 依地理距離加上偏移量路由。進階微調。
• Multi-value answer — 最多回傳 8 筆健康記錄。搭配健康檢查的簡易負載平衡。

將 Route 53 與 API Gateway 和 Edge 配對時請注意：Route 53 是 DNS 層的導流，容錯移轉的速度取決於 DNS TTL（一般 30–60 秒）。Global Accelerator 的容錯移轉在 anycast 層於 30 秒以內完成，不需等待 DNS。如果題目問的是「最快的容錯移轉」，Global Accelerator 勝過 Route 53。

Stage、Deployment 與環境模式

除了 API Gateway stage 以外，API Gateway 與 Edge 在多環境場景下的整體模式如下：

• dev：Regional HTTP API、無 CloudFront、dev Lambda alias、Traffic Dial 100%。
• staging：Regional REST API + Regional CloudFront distribution、staging Lambda alias、WAF 搭配 staging 規則。
• prod：Edge 最佳化 REST API（或 Regional API + CloudFront 以自訂快取）、prod Lambda alias、WAF 搭配完整規則集、Shield Advanced、若對延遲敏感或需要靜態 IP 則加上 Global Accelerator。

部署流水線透過 Canary deployment 逐步晉升 API Gateway stage，並透過加權 alias 晉升 Lambda alias — 這兩者是獨立的藍綠部署原語，值得特別記住這個細微差異。

何時搭配各 Edge 服務 — 五種標準架構

模式 1：S3 靜態網站 + CloudFront + OAC

經典 Jamstack。S3 存放靜態資產，CloudFront 全球快取，OAC 限制 S3 存取僅限 CloudFront distribution，Route 53 別名將頂點網域對應至 distribution，ACM 提供 TLS 憑證。WAF 新增 Bot 防護，Lambda@Edge（或 CloudFront Functions）改寫路徑（例如對目錄請求加上 index.html）。

模式 2：Serverless HTTP API + Lambda

HTTP API（便宜、快速）直接呼叫 Lambda。JWT Authorizer 驗證 Cognito User Pool token。預設不使用 CloudFront；僅在需要快取或 WAF 時才在前面加上 CloudFront。Usage Plan 在 HTTP API 上不可用——若需要 API 金鑰和配額，切換至 REST API。

模式 3：REST API + CloudFront（Edge 最佳化）+ Usage Plan

SaaS 商業化架構。Edge 最佳化 REST API 自動與 AWS 託管的 CloudFront 配對。Usage Plan 依客戶方案將 API 金鑰與配額綁定。Lambda Authorizer 驗證來自客戶 IdP 的 OAuth access token。WAF 附加至 API Gateway 層，依 IP 套用速率限制。按呼叫次數計費對應至 Usage Plan 報表。

模式 4：搭配 Global Accelerator 的全球多區域主動-主動

us-east-1 的 ALB 和 eu-west-1 的 ALB 各自在前端承接相同的 ECS 服務。一個 Global Accelerator 公開兩個靜態 anycast IP。兩個區域的 Traffic Dial 都設為 100%；anycast 加上 AWS 骨幹將每位使用者路由至最近的區域。若 us-east-1 故障，端點健康檢查在 30 秒以內將該區域移除，所有流量自動轉移至 eu-west-1，無需等待 DNS TTL。Route 53 僅用於將自訂 CNAME 指向 accelerator。

模式 5：遊戲 UDP 伺服器 + Global Accelerator + NLB

即時多人遊戲。多個區域各有一組 EC2 遊戲伺服器在 NLB 後方。Global Accelerator UDP Listener 轉送至各 NLB。客戶端連接到燒入遊戲客戶端的兩個靜態 IP——即使遊戲伺服器擴縮或新增區域，IP 永遠不變。Traffic Dial 讓維運人員在發版時排空某個區域的流量。

API Gateway 與 Edge 各層的快取策略

API Gateway 與 Edge 架構中的快取是分層的。從客戶端到資料庫：

1. 瀏覽器快取 — 由 CloudFront／API Gateway 的 Cache-Control 驅動。
2. CloudFront Edge 快取 — 快取政策加上 origin header，TTL 由你控制。
3. CloudFront 區域 Edge 快取 — 自動的第二層快取。
4. API Gateway 快取 — 每個 Stage 0.5–237 GB，僅限 REST API。
5. 應用程式快取（ElastiCache、DAX） — RDS 或 DynamoDB 前方的 Redis／Memcached。
6. 資料庫 buffer pool — RDS／Aurora 內部快取。

設計良好的 API Gateway 與 Edge 架構，在資料允許的範圍內盡可能在最外層快取，只有在未命中時才穿透至更深的層。當成本是考量因素時，CloudFront（依 GB 計費）通常比 API Gateway 快取（依小時固定計費）更划算，尤其是高扇出讀取場景。

API Gateway 與 Edge 常見考試陷阱

1. HTTP API 不支援 API 金鑰／Usage Plan — 需要這些功能？用 REST API。
2. Edge 最佳化僅限 REST — HTTP API 是 Regional；想要 Edge 快取，在前面放上自己的 CloudFront。
3. CloudFront 不支援 UDP — UDP 情境指向 Global Accelerator。
4. Global Accelerator 不做快取 — 「加速靜態內容」且需要快取，是 CloudFront。
5. Lambda Authorizer 結果快取是以 token 值為單位 — 改變 token 會繞過快取；快取鍵是 token 字串（REQUEST 類型 authorizer 則為請求上下文）。
6. Cognito User Pool vs Identity Pool — API Gateway JWT 用 User Pool；直接存取 S3／DynamoDB 的暫時 AWS 憑證用 Identity Pool。
7. OAI 是舊版；OAC 是現行版 — S3 + CloudFront 鎖定的新題選 OAC。
8. CloudFront Functions 無法呼叫 AWS 服務 — 需要網路呼叫或 AWS SDK 存取時，用 Lambda@Edge。
9. API Gateway 有 29 秒的整合逾時硬限制 — 長時間執行的請求需要非同步模式（SQS + Step Functions + WebSocket 推送）。
10. Global Accelerator 容錯移轉比 Route 53 快 — 區域切換在 30 秒以內，而 DNS TTL 等待通常是 60–120 秒。
11. REST API 請求／回應大小上限為 10 MB — 大型檔案上傳應透過 Pre-signed URL 直送 S3，不經過 API Gateway。
12. WAF 附加在 CloudFront 層（全球）或區域 API Gateway 層 — HTTP API 不支援直接附加 WAF。

一覽表：API Gateway 與 Edge 速查

API Gateway 與 Edge 題型練習

• 協定判斷：「需要全球加速的 UDP 或非 HTTP 流量？」→ Global Accelerator。
• 快取 vs 加速：「透過快取降低 origin 頻寬成本？」→ CloudFront。
• 驗證形式：「使用者已在 Cognito 中，JWT 驗證，最簡整合？」→ Cognito Authorizer（User Pool）。
• 驗證形式：「自訂 HMAC 或來自 Okta 的 OAuth？」→ Lambda Authorizer。
• API 類型：「需要 Usage Plan 和 API 金鑰進行商業化？」→ REST API。
• API 類型：「最便宜的 Lambda 入口，不需要商業化？」→ HTTP API。
• Edge 運算：「以每秒 1,000 萬次請求改寫 header，不呼叫 AWS SDK？」→ CloudFront Functions。
• Edge 運算：「在 origin 端選擇之前先查詢 DynamoDB 確認客戶方案？」→ Lambda@Edge origin-request。
• 靜態 IP 需求：「企業防火牆需要將固定 IP 加入白名單？」→ Global Accelerator。
• S3 鎖定：「只有 CloudFront 可以讀取 S3；儲存貯體無公開存取？」→ Origin Access Control（OAC）。
• 容錯移轉速度：「需要秒級區域容錯移轉，而非等待 DNS TTL？」→ Global Accelerator。
• 私有 API：「API 只能從 VPC 內部存取，不對網際網路開放？」→ REST API 搭配 Private Endpoint + VPC Interface Endpoint。

FAQ — API Gateway 與 Edge 熱門問題

Q1：在 SAA-C03 中，何時應選 API Gateway HTTP API 而非 REST API？

新建的 serverless API 預設選 HTTP API：費用約便宜 70%，延遲約低 60%，設定也更簡單。只有當你需要 HTTP API 不支援的功能時才選 REST API——附有 Usage Plan 的 API 金鑰（商業化）、請求驗證、舊有請求/回應轉換用的 mapping template、直接附加 AWS WAF、內建 CloudFront 的 Edge 最佳化端點，或是 VPC 內的私有 API。考試情境中，看到「API 金鑰」、「每位客戶配額」、「Usage Plan」或「按訂閱者限速」等字眼，都指向 REST API。看到「最便宜」、「最簡 Lambda proxy」或「只需要 JWT 驗證」等字眼，則指向 HTTP API。

Q2：Cognito User Pool 和 Cognito Identity Pool 在 API Gateway 中有什麼差別？

Cognito User Pool 是使用者目錄與 JWT 簽發者——處理註冊、登入、密碼重設、MFA，並回傳 ID/access token，API Gateway 可透過 Cognito Authorizer（REST）或 JWT Authorizer（HTTP）原生驗證。Cognito Identity Pool 是憑證仲介——將 User Pool token（或第三方 IdP token）換成暫時 AWS IAM 憑證，讓客戶端可以直接呼叫 S3 或 DynamoDB 等 AWS 服務。對 API Gateway 的身分驗證而言，幾乎都選 User Pool。只有當行動客戶端需要在沒有後端的情況下直接以 AWS SDK 存取資源時，才用 Identity Pool。兩者可以搭配使用：User Pool 負責登入、Identity Pool 提供直接上傳 S3 的憑證、API Gateway 負責商業邏輯。

Q3：何時應搭配使用 CloudFront 和 Global Accelerator，何時只用其中一個？

當你的應用程式同時有可快取的 HTTP 內容和不可快取的即時流量時，兩者搭配使用。例如：一家遊戲公司用 CloudFront 處理遊戲啟動器的靜態檔案（更新包、圖片、登陸頁），用 Global Accelerator 處理 UDP 遊戲伺服器流量。當流量 100% 是 HTTP/HTTPS 且快取帶來明顯效益時，只用 CloudFront——典型的 Web 和 API 工作負載。當你需要穩定 IP 以設定防火牆白名單、需要 UDP/非 HTTP 協定，或需要在 30 秒以內完成區域容錯移轉（比 DNS TTL 更快）時，只用 Global Accelerator。若答案選項中兩者都有，而情境是純 HTTP 且有快取，通常單獨使用 CloudFront 的答案在成本上優於兩者搭配的答案。

Q4：Origin Access Control（OAC）與舊版 Origin Access Identity（OAI）有何不同？

OAC 是 2022 年取代 OAI 的新版。OAC 支援 SSE-KMS 加密的 S3 儲存貯體（OAI 不支援）、適用於所有 AWS 區域（包含選擇加入區域）、使用 AWS SigV4 簽署，並支援 S3 Object Lambda 等進階使用場景。功能上兩者都鎖定 S3 儲存貯體，只允許 CloudFront distribution 讀取，但 OAC 是 AWS 針對新 distribution 的推薦模式。在 SAA-C03 中，若題目同時提供 OAC 和 OAI 作為選項，選 OAC。OAI 仍可向下相容。

Q5：Lambda@Edge 和 CloudFront Functions 有什麼差別，各自何時該選？

CloudFront Functions 在 Edge 節點本身執行 ECMAScript 5.1 JavaScript，每個 distribution 每秒可擴展至 1,000 萬個請求，CPU 上限 1 ms，記憶體 2 MB，僅支援 viewer-request 和 viewer-response 事件，無法呼叫 AWS 服務或網路。成本約為 Lambda@Edge 的六分之一。Lambda@Edge 在區域 Edge 快取執行 Node.js 或 Python，支援全部四種事件類型（viewer-request、viewer-response、origin-request、origin-response），允許 AWS SDK 和網路呼叫，限制上限更高（viewer 事件 5 秒、origin 事件 30 秒，記憶體最高 10 GB）。選 CloudFront Functions 用於 header/URL 改寫、快取鍵正規化、A/B cookie 指派、JWT 簽章預先檢查。選 Lambda@Edge 用於從 Edge 呼叫 DynamoDB、根據使用者屬性動態選擇 origin，或任何 CloudFront Functions 無法表達的邏輯。

Q6：API Gateway 的 Usage Plan、API 金鑰和流量限制如何協同運作？

Usage Plan 將配額（每日/週/月的請求數）和限速（穩定 RPS 加突波）綁定，並與一個或多個 API Gateway Stage 關聯。你將 API 金鑰附加到 Usage Plan。當一個請求帶著 x-api-key header 到達時，API Gateway 驗證金鑰、找到其 Usage Plan、檢查配額（超出則回傳 429）、並套用限速（超出 RPS 則回傳 429）。API 金鑰不驗證呼叫端身分——務必在上層疊加真正的驗證機制（IAM、Cognito、Lambda Authorizer）。Usage Plan 和 API 金鑰僅限 REST API。HTTP API 沒有等效功能；若需要商業化和按客戶配額，REST API 是正確答案。

Q7：為什麼我要把 API Gateway 放在 CloudFront 後面，而不是直接使用 Edge 最佳化端點？

Edge 最佳化 REST API 在你的 API 前面綁定了一個 AWS 託管的 CloudFront distribution，但你沒有任何可調整的旋鈕（快取政策、自訂 behavior、WAF 規則、Lambda@Edge）。當你需要這些自訂控制時，部署一個 Regional REST API 或 HTTP API，並在前面放上你自己的 CloudFront distribution。這樣你就掌控了快取 behavior（快取 GET 回應、跳過 POST）、附加有自訂規則的 WAF Web ACL、串接 Lambda@Edge function、添加多個 origin（例如在同一個網域下 /api/* 對應 API、/static/* 對應 S3），以及使用 Signed URL。雖然需另外支付 CloudFront 費用，但你獲得了 Edge 最佳化 REST 無法提供的彈性。

Q8：全球 API 跨 AWS 區域最快的容錯移轉選項是什麼？

Global Accelerator 最快。當 Endpoint Group 的端點通過健康檢查失敗時，Global Accelerator 在 anycast 層撤回該區域的 BGP 公告，30 秒以內流量完成切換——與任何 DNS TTL 無關。Route 53 容錯移轉取決於 DNS resolver 對 TTL 的遵守程度；典型容錯移轉時間為 60–120 秒，且部分 resolver 會忽略短 TTL。CloudFront origin 容錯移轉速度也很快（數秒），但只能在同一 distribution 的 origin 之間切換，無法自動跨後端區域。若需要在任意 TCP 或 UDP 協定上實現 30 秒以內的跨區域容錯移轉，SAA-C03 的答案是 Global Accelerator。

延伸閱讀

• AWS Well-Architected Framework — 效能效率支柱
• Amazon API Gateway 開發人員指南 — HTTP API 與 REST API 的選擇
• Amazon CloudFront 開發人員指南 — 入門、安全性與私有內容
• AWS Global Accelerator 開發人員指南 — Endpoint Group 與 Traffic Dial
• AWS Lambda@Edge 開發人員指南 — 事件類型與限制
• AWS re:Invent 議程：CloudFront Functions 與多區域主動-主動模式

掌握 API Gateway 與 Edge 服務——Amazon API Gateway（REST、HTTP、WebSocket）、Amazon CloudFront（含 OAC、Signed URL、Lambda@Edge、CloudFront Functions），以及 AWS Global Accelerator（附 Traffic Dial 的 anycast 靜態 IP）——能讓 SAA-C03 Task 2.1 的情境題變成模式比對練習。API Gateway 與 Edge 的標準陷阱（HTTP vs REST API、CloudFront vs Global Accelerator、CloudFront Functions vs Lambda@Edge、Cognito User Pool vs Identity Pool、OAC vs OAI）是反覆出現的考題；現在就建立心智模型，考試當天你就能立即辨識出來。SAA-C03 API Gateway 與 Edge 考試一切順利。