Amazon ANS-C01: 內容交付與邊緣網路 — 學習指南
屬於 AWS Advanced Networking Specialty ANS-C01 — 學習指南. 使用經過驗證的解答練習： Amazon 考試中心, 或參加限時模擬考試： ExamRoll.io.
核心概念
內容交付與邊緣網路分開了兩個相關的職責：以低延遲傳輸用戶端流量，以及作為靠近終端使用者的分散式快取/運算層。CloudFront 是一個 HTTP(S) CDN 和邊緣運算平台，它可以快取 HTTP 回應、在邊緣終止 TLS，並可使用 Lambda@Edge (完整的 Lambda 執行環境複製到各區域) 或 CloudFront Functions (用於在檢視器請求/回應時執行輕量級 JavaScript) 在邊緣站點執行程式碼。CloudFront 的行為是由透過 CreateDistribution 建立的分發設定物件所驅動，並使用 CachePolicy 和 OriginRequestPolicy 物件進行調整。快取策略欄位 (例如 DefaultTTL、MinTTL 和 MaxTTL) 以及包含在快取金鑰中的標頭、cookie 和查詢字串集合，決定了快取命中率和來源負載。來源控制項包括用於私有 S3 來源的 S3 OAC/OAI (CreateCloudFrontOriginAccessControl)，以及用於保護私有內容的簽署 URL 或簽署 cookie (CreateKeyGroup、CreatePublicKey 及簽署 URL 的簽署流程)。
Global Accelerator 和 Anycast 在 HTTP 層之下運作。Global Accelerator 從 AWS 邊緣網路宣告兩個靜態 anycast IP 位址，並將 TCP/UDP 流量路由到運作正常的區域性端點 (Network Load Balancers、Application Load Balancers、EC2 執行個體或 Elastic IP)。由於 Global Accelerator 屬於 L3/L4，當設定為 TCP 通透時，它會保留端對端的 TLS，並透過使用 AWS 內部骨幹網路作為到達區域性端點的「最後一哩路」來改善全球路由。對於非 HTTP 協定，或當用戶端與後端之間必須保留真正的端對端加密和相互 TLS (mTLS) 時，使用 Global Accelerator 作為 Network Load Balancer (NLB) 前端的 TCP 通透路徑是標準模式：NLB 在 L4 運作，可擴展至數百萬個連線，並可為 Amazon EKS 中的 pod 或節點註冊 IP 目標。
Lambda@Edge 函式與 CloudFront 行為相關聯，必須部署 (使用 Publish 執行 CreateFunction) 並在分發的 LambdaFunctionAssociations 中與 viewer-request、origin-request、origin-response 和 viewer-response 觸發器建立關聯。由於 Lambda@Edge 會複製到多個邊緣區域，版本和發佈語意非常重要；請使用有版本的 Lambda 物件並謹慎管理部署，以避免在更新期間出現行為不一致的情況。
主要服務與設定
CloudFront 分發設定依賴三個緊密耦合的物件：分發本身 (CreateDistribution / UpdateDistribution)、決定快取金鑰和 TTL 的 CachePolicy 物件 (CreateCachePolicy)，以及決定哪些標頭/cookie/查詢字串會傳送到來源的 OriginRequestPolicy 物件 (CreateOriginRequestPolicy)。對於私有 S3 內容，請使用 CreateCloudFrontOriginAccessControl 或舊版的 origin access identity，並使用 CreateKeyGroup 和 CreatePublicKey 透過簽署的 URL / 簽署的 cookie 進一步保護存取；SDK 或 cloudfront-signing 工具程式會產生簽署的 URL 或政策文件及 RSA 簽章。失效操作是透過 CreateInvalidation 執行，以選擇性地清除快取的物件。
Global Accelerator 的設定是透過 create-accelerator、create-listener 和 create-endpoint-group API 呼叫來建立的。接聽程式可以是 TCP:443 (用於 gRPC) 或任何 TCP 連接埠，並會將流量轉送到指向區域性 NLB 或 ALB 的端點群組。當使用 Global Accelerator 進行 TCP 通透以保留端對端 TLS 和 mTLS 時，請將其與一個在 443 上有 TCP 接聽程式的 Network Load Balancer 配對，其目標群組需註冊 pod IP (目標類型為 ip) 或節點連接埠。在 Kubernetes EKS 中，這通常是透過建立一個類型為 LoadBalancer 的 Service，並加上諸如 service.beta.kubernetes.io/aws-load-balancer-type: “nlb” 和 service.beta.kubernetes.io/aws-load-balancer-target-type: “ip” 等註解來實現，或是使用 AWS Load Balancer Controller 建立一個目標類型為 ip 的 NLB。透過在 Service 上設定 externalTrafficPolicy: Local，或使用會保留原始來源 IP 的 NLB 通透模式，來保留用戶端來源 IP 以便於記錄。
Global Accelerator 和區域性端點之間的網路層級強制執行，是使用 AWS 管理的前置詞清單來減少管理開銷。AWS CLI 呼叫 aws ec2 describe-managed-prefix-lists 會列出受管理的前置詞清單；其中名為 com.amazonaws.globalaccelerator 的清單可以在安全群組規則中被引用 (使用 –source-prefix-list 執行 AuthorizeSecurityGroupIngress)，以僅允許源自加速器的流量進入 ALB/NLB。在 ALB 終止 TLS 的情況下，請使用 X-Forwarded-For 標頭來記錄用戶端 IP；當使用 NLB 通透搭配 Global Accelerator 時，用戶端 IP 會被原生保留，而後端必須處理 TLS 終止/mTLS。
設計模式與權衡取捨
當需求是內容快取、邊緣運算以及低延遲的 HTTP 回應時，CloudFront 就是正確的工具。當不需要來源機密性時，CloudFront 應在邊緣終止 TLS；使用 CachePolicy 和 OriginRequestPolicy，在安全的情況下將標頭和 cookie 從快取金鑰中排除，以最小化對來源的請求。對於仍能從快取中受益的動態個人化內容，應使用快取金鑰正規化（基於一組最小的標頭或簽署的 cookie 進行變化），並透過版本化的物件金鑰來設計快取失效機制，而不是頻繁地呼叫 CreateInvalidation。
對於需要端到端 TLS 的協定、以及必須直到後端才能解密（用於 mTLS）的 HTTP/2 和 gRPC 流量，應在前端使用 Global Accelerator + NLB 搭配 TLS 通透來建立一個 TCP/L4 路徑。這樣做的取捨是會失去 CloudFront 的 HTTP 快取和邊緣運算能力；然而，Global Accelerator 提供了 anycast 靜態 IP、改善的路由以及區域性容錯移轉。當 ALB 終止 TLS 時，它支援 HTTP/2 和 gRPC，這使得應用層路由（基於主機/路徑）和 WAF 整合成為可能，但在 ALB 上終止會破壞端到端的 mTLS，並將憑證管理的工作放在負載平衡器上。對於大量的並行連線，NLB 在 L4 的擴展性更好——NLB 針對連線速率進行了優化並會保留來源 IP，而 ALB 則是為 HTTP 層級的路由和功能（如用於主機/路徑層級路由的接聽器規則以及與 Cognito/OIDC 的整合）而設計的。
安全控制和區域隔離模式需要在共享 VPC 對等互連、Transit Gateway、PrivateLink 和負載平衡器端點之間謹慎選擇。PrivateLink 提供細緻的服務層級存取控制，並且因為每個消費者都在自己的 VPC 中建立一個介面端點，所以對於眾多消費者來說擴展性良好。Transit Gateway 適用於高頻寬的集中化，但缺乏 PrivateLink 端點所能提供的每個服務的細緻控制以及 SNI/主機層級的可見性。設計時必須考慮路由限制、跨帳戶權限，以及在服務邊界應用安全群組的能力。
常見陷阱與決策標準
一個常見的錯誤是錯誤地混合使用快取控制：讓來源設定的 Cache-Control 標頭來驅動邊緣快取，同時又套用 CloudFront 的快取策略，這可能會產生非預期的 TTL；應優先使用明確的 CachePolicy 物件，除非是刻意為之，否則不要單獨依賴來源標頭。另一個陷阱是在需要端到端 TLS 或數百萬個同時 TCP 連線時選擇 ALB；由 ALB 終止 TLS 會妨礙 mTLS，並且在非常高的連線並行性下可能成為瓶頸。試圖限制對面向網際網路的 ALB 存取的安全設定，常常會忘記使用 Global Accelerator 前綴列表或 WAF 規則來鎖定存取；如果沒有明確的允許規則，該 ALB 仍然可以透過其公開 DNS 存取。最後，未使用版本化 Lambda 函數的 Lambda@Edge 部署，在推出新版時可能會導致行為不一致，因為分發中的關聯是綁定到一個特定的已發佈版本。
實務問題：使用案例情境
公司：AcmeTelemetrics — 挑戰：全球的 IoT 自動販賣機機隊使用 gRPC over TCP:443 連接到一個在 us-east-1 區域、運行於 Amazon EKS 上的後端；需求是端到端的相互 TLS (mTLS)，以便流量在傳輸過程中永不被解密，支援數千個並行連線，並且必須將靜態 IP 編寫到機器中。
方法：
- 建立一個 Global Accelerator (
undefined
)，配備兩個靜態 anycast IP 和一個在 port 443 上的 TCP 接聽器 (
undefined
)。設定一個端點群組，其目標為 us-east-1 區域中的一個 Network Load Balancer (
undefined
)。 2) 在 us-east-1 中配置一個 NLB，其 TCP 接聽器在 443 埠上，並有一個類型為 ip 的目標群組。在 Kubernetes 中，建立一個類型為 LoadBalancer 的 Service，並加上
undefined
和
undefined
的註解，設定
undefined
，並將 Pod IP 註冊為目標，以便 TLS 可以直接通透到 Pod。 3) 在 EKS 中部署 gRPC 伺服器，並在 Pod 的程序中終止 TLS/mTLS。將憑證和信任資料儲存在 Kubernetes Secrets 中；設定伺服器要求用戶端憑證驗證以實現相互 TLS。 4) 鎖定對 NLB 的直接存取，只允許 Global Accelerator 連入。做法是更新 NLB 的安全群組，使其僅允許來自 AWS 管理的 Global Accelerator 前綴列表的輸入流量（可透過
undefined
找到該列表，並在安全群組規則中引用），以防止機器繞過加速器直接連到 NLB。 5) 透過設定 Kubernetes HorizontalPodAutoscaler 和 Cluster Autoscaler 來監控連線並行性與擴展情況，並確保 NLB 目標群組的緩慢啟動和取消註冊延遲已針對優雅地縮減進行調整 (
undefined
)。使用來自 Global Accelerator、NLB 和 EKS 的 CloudWatch 指標來觀察連線計數和健康狀況。
AWS 的理由： Global Accelerator 提供了自動販賣機所需的靜態 anycast IP，並透過 AWS 骨幹網路將 TCP 流量路由到區域性的 NLB，從而提高了可靠性並降低了延遲。NLB 保留了原始用戶端的 TCP 連線和來源 IP，並支援大量的並行連線，使 Pod 能夠執行 mTLS 終止，而無需中間的 TLS 終止。在安全群組規則中使用 Global Accelerator 管理的前綴列表，可以防止直接繞過加速器，並強制流量只能透過 anycast IP 進入。這個組合滿足了端到端加密、
練習這些題目 → · 在 ExamRoll.io 上限時練習 →
Pass the whole exam — not just this question
You found this answer. Get every verified question and explanation in one place, and save hours of prep. Free to start.
通過考試 →