邊緣架構 — CloudFront 與 Global Accelerator

ANS-C01 中的邊緣架構 (Edge Architecture) 是網域 1 (Domain 1: Network Design) 中最重要的設計槓桿：當工作負載為 HTTP/S 且受益於快取時，選擇 CloudFront；當工作負載為非 HTTP (TCP/UDP)、對延遲敏感，或需要永遠不變的靜態任播 (Static Anycast) IP 時，選擇 Global Accelerator。一個典型的 ANS-C01 考題會描述一個多區域 SaaS API，其流量來自三個區域的 ALB，外加一個使用 UDP 的即時多人遊戲伺服器群，以及一個包含大量靜態資產的單頁應用程式 (SPA)，還有一家公司客戶，其防火牆僅將兩個靜態 IP 列入白名單。考生必須組合成：CloudFront 用於 SPA，Global Accelerator 用於遊戲伺服器，以及精心設計的「Global-Accelerator-前端-ALB」模式用於 API，以提供公司客戶所需的靜態 IP。這是考試期望你在 90 秒內做出的多邊緣服務組合決策。

此主題完整涵蓋了網域 1 (網路設計，佔考試 30%) 的任務陳述 1.1。官方 ANS-C01 考試指南逐字列出了知識點：「內容分發網路的使用設計模式 (例如 Amazon CloudFront)」、「全域流量管理的使用設計模式 (例如 AWS Global Accelerator)」，以及「內容分發網路和全域流量管理與其他服務的整合模式 (例如 Elastic Load Balancing [ELB], Amazon API Gateway)」。在 65 題考試中，大約有 5 到 8 題涉及此領域，且通常包含服務選擇陷阱和整合細節。

為什麼邊緣架構在 ANS-C01 網域 1 中至關重要

對最終使用者的延遲是影響應用程式效能感知的關鍵因素。使用者與 AWS 區域之間的網路是不可預測的：BGP 路徑更改、擁塞的傳輸提供商以及路由繞道會增加數十到數百毫秒的延遲。CloudFront 和 Global Accelerator 從相反的方向解決了這個問題。CloudFront 在 600 多個節點 (Points of Presence, PoP) 快取內容，因此請求不需要回到源頭；Global Accelerator 從相同的邊緣位置任播一個靜態 IP，並透過 AWS 骨幹網路 (Backbone) 而非公共網際網路傳輸封包。

Specialty 考試測試這兩個服務之間的辨別能力，因為選擇錯誤的後果非常嚴重。如果為 UDP 遊戲工作負載選擇 CloudFront，應用程式會崩潰。如果為靜態資產 CDN 選擇 Global Accelerator，你將為本應快取的流量支付非快取流量的費用。考試獎勵的心理模型是：CloudFront 等於快取加邊緣的 L7 功能；Global Accelerator 等於快速的 L4 路徑加靜態任播 IP。

白話文解釋 Edge Architecture

CloudFront 與 Global Accelerator 的差異用具體類比能很快內化。

類比 1 — 連鎖比薩分店 vs 快遞專用高速公路

CloudFront 就像一家在全球擁有 600 多家鄰里分店的連鎖比薩店 — 當客戶訂購時，最近的分店會從架上取下預製好的比薩，並在 5 分鐘內送達。原始食譜 (源頭) 存放在中央廚房，但大多數訂單永遠不會到達那裡。Global Accelerator 就像是連接每個鄰里和中央廚房之間的私人快遞高速公路 — 每個訂單仍需在中央廚房烹製，但卡車永遠不會卡在車流量中。不變的靜態資產 (圖像、JS 組合包) 屬於比薩連鎖店。必須在中央廚房進行的現場烹飪 (即時遊戲、支付 API、語音聊天) 屬於快遞高速公路。

類比 2 — 公共圖書館分館 vs 外交郵袋

CloudFront 的運作就像一個分館網路 — 每個分館都保存最受歡迎書籍的副本，因此讀者只需走到最近的分館即可立即取書。中央圖書館 (源頭) 很少被諮詢，因為分館會保持副本的新鮮。Global Accelerator 的運作就像外交郵袋 — 文件不會在任何地方被快取，但它會搭乘私人飛機空運，避開商業航班的延誤。受益於「到處都有副本」的文件是 CloudFront 的工作。必須盡快到達特定目的地且不被快取的文件 (即時金融交易、IoT 控制命令) 是外交郵袋的工作。

類比 3 — 自動販賣機網路 vs 黑卡禮賓車服務

CloudFront 是預先存放熱門產品的自動販賣機鏈：客戶從最近的機器自助服務，倉庫僅在庫存不足時才補貨。CloudFront 的快取失效 (Invalidation) 就像「向每台機器發送補貨通知，告知其丟棄舊庫存」。Global Accelerator 是黑卡禮賓車服務：客戶仍需被載往中央餐廳，但座車使用 VIP 車道以避開每次交通堵塞。車子永遠不會把食物帶回客戶家 — 每個請求都必須前往廚房。選擇正確的服務：當大多數客戶想要架上已有的東西時，選擇 CloudFront；當每個客戶都必須快速到達特定目的地時，選擇 Global Accelerator。

CloudFront 架構 — 節點 (PoP)、區域邊緣快取與源頭

CloudFront 是一個全球分佈的 CDN，具有兩層快取層和靈活的源頭模型。

節點 (Points of Presence, PoP)

節點是託管 CloudFront 快取伺服器的邊緣位置，通常位於主要人口中心的 50 毫秒範圍內。AWS 在 100 多個城市運營著 600 多個節點。當使用者發出請求時，DNS 解析會返回附近節點的 IP；該節點會提供快取的響應，或從下一層獲取。

區域邊緣快取 (Regional Edge Caches, REC)

在節點和源頭之間存在一個較小層級但容量較大的快取層，稱為區域邊緣快取 (REC)，每個 AWS 區域一個。若節點的本地快取未命中 (Miss)，則會檢查 REC；REC 具有更大的儲存空間和更長的 TTL，可吸收長尾物件。這種兩層設計保護了源頭免受快取未命中風暴的影響。

源頭 (Origins)

源頭是內容的信任來源。CloudFront 支援四種源頭類型：S3 儲存貯體 (最常用於靜態資產)、S3 靜態網站端點 (具有網站重新導向和索引文件)、Application Load Balancer 或任何 HTTP/S 端點 (自訂源頭，包括具有公有 IP 的 EC2、內部部署伺服器或第三方服務)，以及用於影片工作流程的 MediaStore / MediaPackage。

分發 (Distribution)

分發是 CloudFront 的頂層資源。它具有唯一的網域名稱 (d1234.cloudfront.net)、一個或多個源頭、一個或多個快取行為、價格層級 (決定使用哪些節點)、TLS 配置以及 WAF/Shield 關聯。

快取行為 — 路徑模式排序與快取索引鍵

一個分發可以有多個快取行為，每個行為都綁定到一個路徑模式 (/api/*, /images/*, /static/* 等)。預設快取行為比對 * (所有內容)，並作為最後的兜底。

路徑模式排序 (Path pattern ordering)

CloudFront 依據列出的順序 (從上到下) 評估快取行為。第一個符合的模式勝出。預設模式始終排在最後。這種排序是 ANS-C01 最常測試的陷阱之一 — 將更通用的模式 (/api/*) 列在更具體的模式 (/api/v2/*) 之前，意味著具體模式永遠無法到達。

快取策略 (Cache policy)

快取策略控制 快取索引鍵 (Cache Key)：哪些請求屬性 (查詢字串、標頭、Cookie) 使一個請求與另一個請求不同。包含所有查詢字串的快取索引鍵意味著 ?utm_source=email 和 ?utm_source=twitter 會被分別快取，這會使快取規模膨脹。排除查詢字串的快取索引鍵意味著兩個 URL 共用一個快取項目，這會大幅提高相同內容的快取命中率。

快取策略還設定了最小、最大和預設 TTL。源頭可以透過 Cache-Control: max-age 標頭覆蓋預設 TTL；快取策略的最大 TTL 會限制源頭的覆蓋。

源頭請求策略 (Origin request policy)

與快取策略不同，源頭請求策略控制哪些請求屬性被轉發到源頭 (即使它們不是快取索引鍵的一部分)。例如：快取索引鍵排除 Authorization 標頭 (以便所有使用者都命中相同的快取項目)，但源頭請求策略將 Authorization 轉發到源頭 (以便源頭可以進行身分驗證)。這種權責分離大幅提高了受驗證 API 的快取命中率。

響應標頭策略 (Response headers policy)

較新的功能：響應標頭策略允許你在邊緣新增、修改或移除響應標頭 (CORS、安全性標頭、自訂標頭)，而無需更改源頭程式碼。

源頭存取 — OAC vs OAI vs 公有源頭

當源頭是 S3 時，你通常希望鎖定儲存貯體，使其只能透過 CloudFront 讀取，而不能直接讀取。AWS 提供兩種機制。

源頭存取身分 (Origin Access Identity, OAI) — 舊版

OAI 是原始的 CloudFront 到 S3 存取機制。CloudFront 具有一個「OAI 主體 (Principal)」 — 一個特殊的規範使用者。S3 儲存貯體策略將 s3:GetObject 授予該 OAI 規範使用者。當 CloudFront 從 S3 獲取內容時，它會呈現 OAI 憑證。

OAI 僅適用於相同分割區 (Commercial) 中的 S3 儲存貯體，並使用 SigV2 簽署 — 這些限制排除了 GovCloud、中國區域以及某些配置下使用 KMS 加密的儲存貯體。

源頭存取控制 (Origin Access Control, OAC) — 目前建議使用

OAC 是現代的替代方案。CloudFront 使用服務主體並以 SigV4 對源頭請求進行簽署。S3 儲存貯體策略透過與 CloudFront 分發 ARN 比對的服務主體條件來授予存取權限。

OAC 支援所有 S3 功能：SSE-KMS、GovCloud、中國區域、S3 Object Lambda 和動態內容源頭。AWS 建議為所有新分發使用 OAC；OAI 現在已被視為舊版。

自訂源頭 (ALB, HTTP 端點)

對於非 S3 源頭，CloudFront 沒有 OAC/OAI。相反，你通常透過自訂標頭中的共享金鑰來鎖定源頭 — CloudFront 發送 X-Origin-Verify: <secret>，而 ALB 的 WAF (或源頭應用程式) 拒絕沒有該標頭的請求。AWS Secrets Manager 可以自動輪換此標頭。

CloudFront 的 TLS — ACM、SNI 與 us-east-1 限制

CloudFront 在邊緣終止 TLS，並重新加密發往源頭。ACM (AWS Certificate Manager) 提供公有憑證。

us-east-1 ACM 要求

CloudFront 使用的憑證必須在 us-east-1 (維吉尼亞北部) 建立，不論源頭位於哪個區域。這是因為 CloudFront 是一個全域服務，並使用錨定在 us-east-1 的全域憑證存放區。位於 eu-west-1 的憑證無法附加到 CloudFront 分發。

TLS 協定與密碼策略 (Cipher Policy)

CloudFront 支援 TLS 1.0、1.1、1.2 和 1.3。AWS 提供預定義的安全性策略 (例如 TLSv1.2_2021, TLSv1_2019)。選擇更嚴格的策略 (最低 TLS 1.2) 會封鎖舊用戶端，但能提高安全性。ANS-C01 期望你能辨識需要 TLS 1.2+ 的合規性情境 (如 PCI-DSS)。

SNI vs 專用 IP (Dedicated IP)

SNI (伺服器名稱指示) 是現代的預設選項 — CloudFront 根據 TLS Client Hello 中的 SNI 主機名稱提供憑證。專用 IP 是為不支援 SNI 的用戶端提供的舊選項；每個分發每月費用為 600 美元，現今很少需要 (僅適用於 Windows XP / Android 2.x 的用戶端)。

源頭 TLS

CloudFront 到源頭的 TLS 使用單獨的憑證鏈 (源頭的憑證，由 CloudFront 驗證)。對於 ALB 源頭，ALB 區域中的 ACM 憑證是標準做法。CloudFront 支援透過源頭自訂標頭使用自訂 CA 憑證，以及為自我簽署源頭提供的驗證切換 (請謹慎使用)。

Lambda@Edge vs CloudFront Functions — 兩層邊緣運算層

CloudFront 支援兩種不同的邊緣運算模型。了解何時使用每一種是 ANS-C01 最常測試的區分點之一。

Lambda@Edge

Lambda@Edge 在 CloudFront 節點運行 Lambda 函數 (技術上：在區域邊緣快取和節點運行，取決於觸發器)。支援 Node.js 和 Python 執行期；具備完整的 Lambda 功能 (網路呼叫、AWS SDK 存取、大型程式庫，檢視器觸發器最多 5 秒，源頭觸發器最多 30 秒)。記憶體最高 10 GB。執行期成本為典型的 Lambda 定價外加一小部分邊緣溢價。

四個觸發點：

• 檢視器請求 (Viewer Request) — 當使用者請求到達節點時、快取查找之前執行。用於 URL 重寫、A/B 測試、身分驗證標頭注入。
• 源頭請求 (Origin Request) — 當快取未命中、CloudFront 即將呼叫源頭時執行。用於源頭選擇、動態源頭故障轉移。
• 源頭響應 (Origin Response) — 當源頭返回響應時、快取之前執行。用於響應轉換、標頭操作。
• 檢視器響應 (Viewer Response) — 在向使用者發送響應之前執行。用於新增安全性標頭、CORS、自訂分析。

部署是全域的 — 函數會自動複製到每個節點。更新需要 5-10 分鐘才能傳播。

CloudFront Functions

CloudFront Functions 是一個針對極其簡單的邊緣轉換的輕量級替代方案。僅支援 JavaScript (ES2020 的子集)。執行期受到限制：最大 1 毫秒執行時間、2 MB 記憶體、無網路呼叫、無 AWS SDK。成本大約是 Lambda@Edge 的六分之一。

兩個觸發點：檢視器請求和檢視器響應 (沒有源頭端觸發器)。

用途：URL 重寫、標頭操作、簡單的 A/B 測試路由、JWT 驗證 (使用嵌入式金鑰)、URL 簽署檢查、重新導向、CORS 注入。

何時使用哪一個

對於檢視器端亞毫秒級的 JavaScript 轉換，使用 CloudFront Functions。對於任何需要網路呼叫 (呼叫 DynamoDB, API Gateway)、源頭端邏輯、複雜運算或 JS 以外執行語言的需求，使用 Lambda@Edge。

源頭故障轉移 — 源頭群組與故障轉移準則

當主要源頭故障時，CloudFront 源頭故障轉移 (Origin Failover) 提供高可用性。

源頭群組 (Origin group)

一個源頭群組捆綁了一個主要源頭和一個次要源頭。CloudFront 將流量發送到主要源頭；如果主要源頭返回配置的失敗狀態碼，CloudFront 會針對次要源頭重試。

故障轉移準則 (Failover criteria)

可配置的 HTTP 狀態碼會觸發故障轉移：通常為 4xx 和 5xx (具體為 500, 502, 503, 504, 404, 403, 408, 416)。當主要源頭返回其中之一時，CloudFront 會在同一個請求上自動針對次要源頭重試，這對用戶端是透明的。

連線失敗

源頭故障轉移也會在連線層級失敗 (TCP 逾時、DNS 失敗、TLS 交握失敗) 時觸發。重試邏輯為健康路徑提供了有效的亞秒級跨區域故障轉移。

故障源頭的快取行為

CloudFront 不會長時間快取失敗的響應。一旦主要源頭恢復，後續請求會在下一次快取未命中時回到主要源頭。

限制

• 源頭故障轉移僅支援 HTTP GET、HEAD、OPTIONS (不重試寫入方法，以避免重複處理)。
• 故障轉移計為一次 CloudFront 請求 (不重複計費)。
• 如果函數修改了請求，源頭故障轉移無法與 Lambda@Edge 配合使用 — 評估順序很重要。

受簽署的 URL 與受簽署的 Cookie — 私有內容分發

CloudFront 可以使用受簽署的 URL 或受簽署的 Cookie 提供私有內容；簽署控制了誰可以存取什麼內容以及何時存取。

受簽署的 URL (Signed URLs)

受簽署的 URL 將簽署直接嵌入 URL 本身：https://d123.cloudfront.net/movie.mp4?Expires=...&Signature=...&Key-Pair-Id=...。用於每件內容具有唯一 URL 的情況 (每個物件一個受簽署的 URL)。

使用案例：串流播放單個影片、產生一次性下載連結、具有按物件存取控制的 RESTful API 端點。

受簽署的 Cookie (Signed cookies)

受簽署的 Cookie 設定在用戶端的瀏覽器中；隨後對分發的請求會自動包含該 Cookie。Cookie 的簽署授權對多個路徑或萬用字元的存取：CloudFront-Policy=...; CloudFront-Signature=...; CloudFront-Key-Pair-Id=...。

使用案例：授予對 HLS 影片片段目錄的存取權、一次向許多靜態資產驗證使用者、具有多個延遲載入資源的單頁應用程式。

受信任的金鑰群組 vs 受信任的簽署者 (舊版)

現代做法：使用上傳到 CloudFront 的公鑰建立受信任的金鑰群組 (Trusted key groups)。你的應用程式使用對應的私鑰對 URL/Cookie 進行簽署。

舊版做法：使用 AWS 帳戶根憑證的受信任的簽署者 (Trusted signers)。應避免使用 — 這是安全性反模式。

策略類型

• 固定策略 (Canned policy)：固定的到期時間和資源路徑。簽署較小，較簡單。
• 自訂策略 (Custom policy)：支援 IP 地址限制、多個路徑、日期範圍 (開始和結束)。簽署較大，較靈活。

欄位層級加密 — 針對敏感欄位的端到端機密性

欄位層級加密 (Field-Level Encryption, FLE) 是一項 CloudFront 功能，可在邊緣對 HTTP 請求的特定欄位進行加密，且僅能由源頭授權的金鑰持有者解密。

運作方式

你定義一個加密配置：一個公鑰 (RSA)、要加密的欄位清單 (透過 HTML 表單欄位名稱) 以及內容類型 (通常是 POST 表單資料或 JSON)。當使用者透過 CloudFront POST 資料時，CloudFront 會辨識具名欄位，並在轉發到源頭之前使用公鑰對其進行加密。

源頭伺服器擁有對應的私鑰。請求路徑中的其他系統 (負載平衡器、處理路由的應用程式伺服器、日誌彙總器) 看到的是加密後的密文，而非純文字。

使用案例

• PCI 合規性：從邊緣到後端加密信用卡號，使中間服務和日誌永遠看不到 PAN。
• HIPAA：對 PII 欄位 (身分證字號、健康記錄 ID) 進行端到端加密。
• 深層防禦：即使日誌洩漏，敏感欄位仍是密文。

限制

• 欄位名稱必須是可預測的 (表單欄位名稱或 JSON 鍵路徑)。
• 每個請求最多 10 個加密欄位。
• 增加處理延遲 (通常為 1-10 毫秒)。
• 請求需要使用 HTTPS (FLE 建立在 TLS 之上)。

CloudFront 地理限制與 WAF 整合

地理限制 (Geo-blocking)

CloudFront 具有內建的基於國家的地理限制：允許清單 (僅限特定國家) 或拒絕清單 (封鎖特定國家)。基於對檢視器 IP 的 MaxMind GeoIP 資料庫查找。免費、簡單，在 WAF 評估之前應用。

原生地理限制的限制

• 僅限國家層級 (而非州、區域或城市)。
• 基於 IP，因此 VPN 使用者可以繞過。
• 無例外處理 (無法在受封鎖國家中允許特定 IP)。

如需更精細的控制 (州層級、基於 ASN、例外清單)，請改用 WAF 地理比對規則，它更靈活但每次評估都需付費。

CloudFront + WAF

CloudFront 透過 Web ACL 關聯與 AWS WAF 整合。WAF Web ACL 必須處於 CLOUDFRONT 範圍 (全域，託管在 us-east-1) — 區域性 Web ACL 無法附加到 CloudFront。速率限制、IP 信譽、機器人控制和受管規則群組都在請求到達源頭之前的邊緣運作。

Shield Standard 與 Advanced

CloudFront 自動受益於 Shield Standard (免費，在 L3/L4 提供自動 DDoS 保護)。Shield Advanced (每月 3000 美元) 增加了主動式 DDoS 參與、成本保護保險和 SRT (Shield 響應團隊) 存取。

Global Accelerator 架構 — 任播與 AWS 骨幹網路

Global Accelerator 與 CloudFront 根本不同：它提供靜態任播 IP，並透過 AWS 骨幹網路為非快取、低延遲的連線路由封包。

靜態任播 (Static anycast) IP

Global Accelerator 在佈建時分配兩個靜態任播 IPv4 地址 (或你可以使用 BYOIP)。這些 IP 透過 BGP 任播從全球每個 AWS 邊緣位置發佈。用戶端的 ISP 將封包路由到拓撲上最近的邊緣。

邊緣進入骨幹網路

一旦封包到達 AWS 邊緣，Global Accelerator 就會透過 AWS 骨幹網路 (AWS 擁有的光纖) 將其隧道傳輸到目的地區域，避開公共網際網路的擁塞和路由低效率。對於跨洲流量，這通常能將延遲減少 30% 到 60%。

端點群組 (Endpoint groups)

Global Accelerator 接聽受器具有一個或多個端點群組，每個 AWS 區域一個。每個群組列出端點 (ALB、NLB、EC2 執行個體、彈性 IP)。每個端點的健康檢查決定路由資格。

流量撥號 (Traffic dial)

每個端點群組都有一個流量撥號 (0-100%)，控制有多少流量流向該區域。對於容量重新平衡、漸進式區域部署或災難情境非常有用 — 你可以將某個區域撥低至 0 以排乾流量，而無需更改 DNS。

端點權重 (Endpoint weights)

在端點群組內，每個端點都有一個權重 (0-255)，控制區域內的流量分配。用於區域內的藍綠部署或漸進式端點部署。

用戶端相似性 (Client affinity)

預設情況下，Global Accelerator 按每個封包進行負載平衡 (5-tuple 哈希)。你可以啟用 用戶端相似性 = SOURCE_IP，將來自相同來源 IP 的所有封包路由到相同的端點，這對於具有工作階段狀態的工作負載非常有用。

Global Accelerator 端點 — ALB、NLB、EC2、彈性 IP

Global Accelerator 支援四種端點類型，每種都有不同的行為。

Application Load Balancer (ALB)

ALB 端點可以是內部的或面向網際網路的。當 ALB 作為端點時，Global Accelerator 透過骨幹網路轉發到 ALB 的 IP。ALB 照常執行 L7 路由。

使用案例：需要靜態任播 IP (公司防火牆白名單) 的 HTTP/S API，或者因為響應不可快取但能從邊緣進入骨幹網路中受益而無法使用 CloudFront 的情況。

Network Load Balancer (NLB)

NLB 端點透過 Global Accelerator 保留來源 IP (需在 NLB 目標群組層級啟用 用戶端 IP 保留)。用於需要真實用戶端 IP 可見性的 L4 工作負載 — IDS/IPS、地理圍欄、稽核日誌。

EC2 執行個體

無需負載平衡器的直接 EC2 端點。用於簡單的高傳輸量單伺服器案例。健康檢查是 EC2 執行個體的可達性。

彈性 IP (Elastic IP)

EIP 端點允許將 Global Accelerator 指向任何 IP (包括透過 Direct Connect 或 VPN 連接的非 AWS 系統)。用於源頭位於內部部署的混合情境。

跨區域故障轉移

Global Accelerator 會自動繞過不健康的端點群組。一個區域的健康檢查失敗會導致流量在幾秒鐘內轉移到其他區域 — 這比受 TTL 限制的基於 DNS 的 Route 53 故障轉移快得多。

CloudFront vs Global Accelerator — 決策矩陣

最常測試的 ANS-C01 題目風格：「給定工作負載 X，選擇 CloudFront 還是 Global Accelerator」。請使用此矩陣。

何時將兩者搭配使用

對於需要靜態 IP 和邊緣快取的 HTTP/S 工作負載，你可以將 Global Accelerator 放在 CloudFront 前面 — 但這種情況很少見。更常見的做法：將 Global Accelerator 用於 API 層 (為公司防火牆白名單提供靜態 IP)，並將 CloudFront 用於靜態資產層 (快取)，兩者分別前端不同的 DNS 名稱。

整合模式 — CloudFront 與 ALB、API Gateway 及 S3

CloudFront 前端 ALB

動態 Web 應用程式最常見的模式。ALB 執行到後端的 L7 路由；CloudFront 快取靜態部分並轉發動態請求。使用共享金鑰自訂標頭來鎖定 ALB，使其僅接受源自 CloudFront 的請求；AWS Secrets Manager 會自動輪換該金鑰。

CloudFront 前端 API Gateway

用於受益於邊緣快取 (讀取密集的 GET 端點) 或邊緣驗證 (Lambda@Edge JWT 驗證) 的 HTTP API。API Gateway 的公有端點在底層已使用 CloudFront，但新增你自己的分發可以讓你控制快取、地理限制和 WAF。

CloudFront 前端 S3

用於靜態網站、下載、影片分發。使用 OAC 鎖定儲存貯體。結合受簽署的 URL/Cookie 用於私有內容。

CloudFront 搭配 Lambda 函數 URL

較新的模式：使用 Lambda 函數 URL 作為源頭的無伺服器應用程式。CloudFront 前端提供了快取、自訂網域、WAF 和邊緣運算。

Global Accelerator 搭配 ALB

公司客戶需要白名單 IP 的 HTTPS API 模式。Global Accelerator 提供 2 個靜態任播 IP；客戶的防火牆將這些 IP 列入白名單；流量在最近的邊緣進入 AWS 骨幹網路，並以亞 100 毫秒的延遲到達區域 ALB。

Global Accelerator 搭配 NLB 用於遊戲

連接埠 7777 的 UDP 遊戲工作負載。Global Accelerator 配合 UDP 接聽受器，每個區域一個 NLB 端點群組，NLB 目標是 EC2 遊戲伺服器。玩家連線到靜態任播 IP；他們的封包在最近的邊緣進入，透過 AWS 骨幹網路傳輸到區域 NLB，並以最小的抖動到達遊戲伺服器。

效能與成本優化模式

快取命中率優化

CloudFront 單一最大的成本槓桿是快取命中率。較高的命中率意味著較少的源頭請求和較少的源頭資料傳輸 (在許多情況下，源頭傳輸比 CloudFront 到使用者的資料傳輸昂貴得多)。

技術：

• 從快取索引鍵中移除不必要的查詢字串 (例如 utm_source 不會改變內容)。
• 從快取索引鍵中移除不必要的標頭 (例如 User-Agent 很少改變內容，但會使快取索引鍵基數激增)。
• 為靜態資產配置長的源頭 TTL 和 CloudFront 最大 TTL。
• 配置對 5xx 響應進行短時間快取，以便在故障期間吸收源頭壓力。

價格層級 (Price classes)

CloudFront 具有價格層級：所有邊緣位置 (效能最佳，成本最高)、美國、加拿大、歐洲 (成本較低，在亞洲/非洲延遲較高)、美國、加拿大、歐洲、亞洲 (中階)。對於成本敏感且使用者集中在特定區域的工作負載，請使用較小的價格層級。

源頭遮蔽 (Origin Shield)

區域邊緣快取和源頭之間的可選層：單個區域遮蔽快取，吸收全球所有 REC 未命中。對於熱門內容，可將源頭負載再降低 5-10 倍。每次請求會增加一小部分費用，但在流量高峰期間能保護源頭。

常見陷阱回顧 — ANS-C01 中的 CloudFront 與 Global Accelerator

陷阱 1：任何區域的 ACM 憑證都可用於 CloudFront

錯誤。CloudFront 特別要求憑證必須在 us-east-1。

陷阱 2：CloudFront 支援 UDP

錯誤。CloudFront 僅支援 HTTP/HTTPS。UDP 需要 Global Accelerator (或直接使用 NLB)。

陷阱 3：快取行為按最佳比對進行評估

錯誤。快取行為按列出的順序評估，第一個比對勝出。具體模式必須排在通用模式之前。

陷阱 4：OAI 支援 KMS 加密的 S3

大部分錯誤。OAI 使用 SigV2，在某些配置中與 KMS 加密的 S3 存在相容性問題。請使用 OAC。

陷阱 5：Lambda@Edge 始終是邊緣運算的正確選擇

錯誤。對於簡單的 JS 轉換，CloudFront Functions 更快且更便宜。僅在需要網路呼叫或非 JS 執行期時才使用 Lambda@Edge。

陷阱 6：源頭故障轉移處理 POST 請求

錯誤。源頭故障轉移僅重試安全方法：GET, HEAD, OPTIONS。POST/PUT 不會故障轉移。

陷阱 7：受簽署的 URL 與受簽署的 Cookie 是可互換的

錯誤。URL 是針對單個物件的；Cookie 涵蓋多物件工作階段。根據存取模式選擇。

陷阱 8：欄位層級加密替代了 TLS

錯誤。FLE 在 TLS 之上運行，增加了中間 AWS 服務 (ALB, 日誌) 看到的欄位層級機密性。

陷阱 9：Global Accelerator 快取內容

錯誤。Global Accelerator 不執行快取。純粹的 L4 路徑加速。

陷阱 10：Global Accelerator IP 會變動

錯誤。在加速器的生命週期內，IP 是靜態的。對於防火牆白名單情境，這正是該服務的核心價值。

陷阱 11：CloudFront 和 ALB 的 WAF Web ACL 是可互換的

錯誤。CloudFront 要求 CLOUDFRONT 範圍；ALB 要求 REGIONAL 範圍。即使規則相同，它們也是獨立的 Web ACL。

陷阱 12：CloudFront 地理限制支援美國各州

錯誤。原生地理限制是國家層級。州或城市精細度需要使用 WAF 地理比對規則。

陷阱 13：CloudFront 自動防禦 L7 DDoS

部分正確。Shield Standard 在邊緣提供自動 L3/L4 DDoS 緩解。L7 (HTTP 洪水) 需要 WAF 基於速率的規則，最好搭配 Shield Advanced。

陷阱 14：Global Accelerator 用戶端相似性根據使用者身分進行路由

錯誤。用戶端相似性是基於 SOURCE_IP 的 — 根據用戶端 IP 而非使用者身分進行路由。CGNAT 後面的行動使用者可能共享同一個來源 IP 並被路由到一起。

常見問答 — ANS-C01 邊緣架構

Q1: 何時該使用 CloudFront vs Global Accelerator vs Route 53 基於延遲的路由？

對於具有可快取內容 (靜態資產、讀取密集型 API、影片) 的 HTTP/HTTPS，使用 CloudFront。對於非 HTTP (UDP, TCP) 協定，或需要靜態任播 IP 的 HTTP/S 工作負載 (公司防火牆白名單)，或仍能從 AWS 骨幹網路進入中受益的不可快取 HTTP/S，使用 Global Accelerator。對於簡單的多區域流量分配，且希望使用者解析到區域端點並直接連線而不經過邊緣服務時，使用 Route 53 基於延遲的路由。基於延遲的路由比 Global Accelerator 便宜，但缺乏 AWS 骨幹網路路徑優勢。組合模式很常見：Route 53 用於區域選擇 + Global Accelerator 用於骨幹網路增強的 TCP，或 Route 53 + CloudFront 用於具備區域快取的 HTTP。ANS-C01 期望你進行組合，而非僅選其一。

Q2: 如何鎖定 ALB 以使其僅接受源自 CloudFront 的請求？

兩層方法。首先，在每個 CloudFront 到源頭的請求上設定一個帶有祕密值的 CloudFront 自訂源頭自訂標頭 (例如 X-Origin-Verify)。其次，在 ALB 上附加一個 WAF 規則，要求此標頭必須比對特定值；拒絕缺少該標頭的請求。AWS Secrets Manager 會按排程輪換祕密，CloudFront 在你更新分發時會自動獲取輪換後的值。此模式是生產部署的標準做法。若不這樣做，ALB 是公開可達的且會繞過 CloudFront 的 WAF，使 WAF 失去作用。

Q3: 為什麼 CloudFront 要求 ACM 憑證位於 us-east-1？

CloudFront 是一個全域服務，其配置錨定在 us-east-1。憑證授權單位鏈驗證、全域邊緣配置和分發設定都從 us-east-1 同步到所有節點。ACM 憑證是區域性資源，因此全域服務要求其憑證位於託管全域服務的區域，AWS 出於歷史原因選擇了 us-east-1。考試非常喜歡這個陷阱 — 「因為源頭在那裡，我在 eu-west-1 建立了憑證，但 CloudFront 拒絕使用它」。答案：在 us-east-1 重新建立憑證；源頭區域與此無關。

Q4: CloudFront Functions 可以呼叫 DynamoDB 或其他 AWS 服務嗎？

不可以。CloudFront Functions 在受限的執行期運行 — 無網路呼叫、無 AWS SDK、無 fetch。它專為對請求和響應進行純 JavaScript 轉換而設計。如果你需要查找資料 (例如根據使用者 ID 進行動態源頭選擇)，請使用具有源頭請求觸發器的 Lambda@Edge，它具備完整的 Lambda 功能。Lambda@Edge 可以呼叫 DynamoDB，但請注意：你應該呼叫距離節點最近區域的 DynamoDB Global Tables，否則增加的延遲會抵消邊緣運算的優勢。

Q5: Global Accelerator 定價與 CloudFront 相比如何？

Global Accelerator 的成本為每個加速器小時 0.025 美元 (約每月 18 美元) 外加資料傳輸費。資料傳輸費是在正常 AWS 資料傳輸之上收取的「資料傳輸溢價」(根據來源/目的地區域，每 GB 0.015 到 0.105 美元)。CloudFront 對請求數量和對外資料傳輸計費，由於 CloudFront 較低成本的邊緣到網際網路出口定價，資料傳輸費用通常低於直接源頭傳輸。對於 HTTP/S 可快取工作負載，CloudFront 便宜得多，因為快取命中完全避免了源頭傳輸。對於非 HTTP 工作負載或需要靜態 IP 的不可快取工作負載，Global Accelerator 是唯一的選擇且成本合理。請務必針對你的特定工作負載計算每次請求的經濟效益。

Q6: 如何為寫入密集的 API 實作源頭故障轉移？

CloudFront 源頭故障轉移僅處理 GET/HEAD/OPTIONS。對於 POST/PUT/DELETE，請使用具有主動-被動或主動-主動記錄的 Route 53 健康檢查故障轉移，並設定低 TTL (60 秒) 以實現快速故障轉移。或者，使用 Global Accelerator，它可以根據健康檢查在幾秒鐘內切換端點群組 (不受 DNS TTL 限制)。對於關鍵任務的寫入 API，搭配多區域 NLB 端點的 Global Accelerator 是標準模式：亞秒級故障轉移、保留來源 IP、無需等待 DNS 快取失效。

Q7: 透過 S3 提供私有 SPA (單頁應用程式) 的正確方法是什麼？

架構：僅具有私有存取權限的 S3 儲存貯體，指向該儲存貯體且帶有 OAC 的 CloudFront，CloudFront 對 SPA 資源使用受簽署的 Cookie。使用者的第一個請求命中登入頁面 (例如 Cognito 前端的 Lambda)，該頁面返回涵蓋 /app/* 的受簽署 Cookie。隨後對 HTML、JS、CSS、延遲載入區塊的所有請求都會攜帶該 Cookie 並獲得授權。請使用受簽署的 Cookie (而非受簽署的 URL)，因為 SPA 會載入數十個資源 — 預先簽署每個 URL 會非常昂貴且緩慢。Cookie 可以具有 IP 限制 (自訂策略) 以增強防禦。

Q8: Global Accelerator 如何處理 TLS — 它可以終止 TLS 嗎？

不可以，Global Accelerator 不終止 TLS。它是一個純粹的 L4 服務，透明地轉發封包。TLS 交握發生在用戶端和後端端點 (ALB, NLB, EC2) 之間。對於 HTTPS，憑證位於後端 ALB 或 NLB (或 NLB 上的 TLS 接聽受器) 上。這是與 CloudFront 的關鍵區別，CloudFront 始終在邊緣終止 TLS。如果你需要為 HTTPS 在邊緣終止 TLS，請使用 CloudFront — Global Accelerator 用於需要原始 TCP/UDP 透傳或應用程式在後端終止 TLS 的情況 (例如，為了向需要原始憑證鏈的後端實作端到端 TLS)。

Q9: 如何使用 CloudFront 在邊緣處理 CORS？

兩種方法。現代做法：使用具有 CORS 配置的響應標頭策略 — CloudFront 在不更改源頭程式碼的情況下向響應新增 CORS 標頭。較舊做法：使用 Lambda@Edge 檢視器響應觸發器，根據請求來源注入 Access-Control-Allow-Origin 標頭。對於靜態工作負載，甚至可以直接在 S3 儲存貯體上配置 CORS，並讓 CloudFront 透傳。響應標頭策略是推薦的現代模式 — 聲明式、無運算成本、無冷啟動。

Q10: 何時將 CloudFront 放在 API Gateway 前面是有意義的？

三種情境。第一，快取密集的 GET 端點：儘管 API Gateway 有自己的快取，但 CloudFront 的快取位於節點層，離使用者更近 (延遲更低，命中率更高)。第二，檢視器請求階段的邊緣驗證：Lambda@Edge 可以在請求到達 API Gateway 之前驗證 JWT，從而降低 API Gateway 呼叫成本並優化延遲。第三，邊緣的 WAF 和地理限制：雖然 API Gateway 支援 WAF，但將 WAF 放在 CloudFront 可以在管道的更早階段攔截惡意流量。權衡點：增加了一個網路跳轉和一個額外的管理服務。對於低流量 API，這種複雜性是不必要的。對於具有可快取子集的高流量客戶面向 API，分層方法是值得的。ANS-C01 期望你能辨識哪些情境受益，哪些不受益。

進階閱讀與相關操作模式

• Amazon CloudFront 開發者指南
• AWS Global Accelerator 開發者指南
• 限制對 S3 源頭的存取 (OAC)
• Lambda@Edge 開發者指南
• CloudFront Functions 開發者指南
• CloudFront 源頭故障轉移
• 受簽署的 URL 與受簽署的 Cookie
• 欄位層級加密
• Global Accelerator 流量撥號

一旦 CloudFront 和 Global Accelerator 的邊緣架構就緒，ANS-C01 的下一個自然操作層級是：Route 53 DNS — 公有、私有與混合架構，因為邊緣服務依賴 DNS 進行用戶端解析和流量引導策略；Elastic Load Balancing 設計 — ALB, NLB, GWLB，因為邊緣服務通常前端負載平衡器，且 ALB vs NLB 的選擇會影響邊緣的 TLS 終止決策；WAF, Shield 與 DDoS 防護架構，因為邊緣服務是第一道防線，Shield/WAF 整合在邊緣最為自然；以及網路監控與日誌設計，涵蓋 CloudFront 存取日誌、Global Accelerator 串流日誌和邊緣指標的觀測層。

• Route 53 DNS — 公有、私有與混合架構 — ANS-C01 學習筆記
• Elastic Load Balancing 設計 — ALB, NLB, GWLB — ANS-C01 學習筆記
• WAF, Shield 與 DDoS 防護架構 — ANS-C01 學習筆記
• 網路監控與日誌設計 — ANS-C01 學習筆記