Amazon ANS-C01: VPC 設計與進階網路 — 學習指南

By Laurynas Brazys · 3 August 2026 · #amazon #ans-c01 #certification #exam-prep #study-guide

屬於 AWS Advanced Networking Specialty ANS-C01 — 學習指南. 使用經過驗證的解答練習： Amazon 考試中心, 或參加限時模擬考試： ExamRoll.io.

VPC 架構與子網路劃分基礎

VPC 是 AWS 中基礎的網路邊界，而您的 CIDR 配置方式決定了後續的一切。規劃 CIDR 區塊時，應考量未來的成長與跨帳戶連線需求：為每個帳戶/區域分配大型且不重疊的位址空間（例如，每個環境使用一個 /16），並將其細分為 /20–/24 的子網路，以便依功能和可用區域隔離工作負載。請記住，EKS 和其他容器平台會為 pod 的 ENI 或次要 IP 消耗 IP 位址；AWS VPC CNI 會從 VPC 子網路中為 pod 分配 IP，而每個執行個體的 ENI/IP 限制 (DescribeInstanceTypes) 則限制了 pod 的最大密度。若要採用 IPv6，建議優先選擇雙堆疊 (dual-stack) 設計，將面向公眾的服務轉移至 IPv6，同時保留 IPv4 以進行傳統系統整合；使用 API 呼叫

undefined

–vpc-id <vpc> –amazon-provided-ipv6-cidr-block 來關聯一個 Amazon 提供的 IPv6 CIDR 區塊，並透過 create-subnet 和 –ipv6-cidr-block 選項來啟用子網路層級的 IPv6 分配。為 IPv4 的出口流量規劃 NAT 資源，而對於 IPv6，則使用一個僅供輸出網際網路閘道器 (Egress-Only Internet Gateway)，可透過 CreateEgressOnlyInternetGateway 建立並附加到 VPC。

路由表和子網路的配置是強制執行拓撲和彈性的方法。使用 CreateRouteTable 和 CreateRoute 為每種用途的子網路（例如公有、帶有 NAT 的私有、帶有 Direct Connect 的私有，以及隔離的子網路）建立不同的路由表。在多個可用區域中使用多個 NAT Gateway（或具備自動擴展功能的 NAT 執行個體）以避免單一可用區域的出口流量故障；在使用 Transit Gateway (CreateTransitGateway, CreateTransitGatewayRouteTable) 時，要明確指定路由傳播，確保地端網路的前綴只被注入到預期的位置。對於帳戶內的服務發現，請使用 Route 53 私有託管區域 (private hosted zones)，並將其與需要這些記錄的 VPC 關聯，以避免 DNS 查詢洩漏到邊界之外。

關鍵服務與組態細節

關於私有連線，有三種主要的建構方式需要理解：VPC Peering、AWS Transit Gateway 和 AWS PrivateLink (interface VPC endpoints)。VPC Peering (CreateVpcPeeringConnection, AcceptVpcPeeringConnection) 是一種簡單、低成本的點對點連線，它需要在路由表中設定條目，且不支援傳遞式路由 (transitive routing)。Transit Gateway (CreateTransitGateway, CreateTransitGatewayVpcAttachment) 是一個可擴展的中心樞紐，支援數千個 VPC、集中式路由控制，並能與 Direct Connect Gateway 整合以實現混合雲連線；在 Transit Gateway 中使用路由表傳播和路由表關聯來控制東西向流量。PrivateLink（使用 CreateVpcEndpointServiceConfiguration 註冊一個由 NLB 支援的服務，並使用 CreateVpcEndpoint 建立 interface endpoints）能跨帳戶公開服務，而無需將 VPC 暴露於路由中，從而提供精細的、針對個別服務的安全性，並簡化安全群組的控制；它的擴展性很好，因為服務消費者會自行建立 interface endpoints，且流量停留在網卡 (NIC) 層級。

負載平衡和用戶端 IP 的保留是需要正確處理的常見設計選擇。Application Load Balancer (ALB) 會終止 TLS、在 L7 進行路由 (CreateLoadBalancer Type application)，並注入 X-Forwarded-For/X-Forwarded-Proto 標頭，後端必須信任這些標頭才能記錄用戶端 IP。Network Load Balancer (NLB) 會為目標群組保留來源 IP，並支援數百萬個連線；若要實現真正的 TLS pass-through 到後端，請使用帶有 TCP 接聽器 (CreateListener Protocol TCP) 的 NLB，並透過 IP 註冊目標，以便加密的會話能完整地到達 pod 或執行個體。對於 gRPC 和極高連線數的場景，建議在 EKS 前端使用 NLB，並將目標類型設為 ip，同時搭配 AWS Load Balancer Controller 的註解

undefined

來直接註冊 pod IP；這種組合能保留來源 IP、支援在 pod 層級終止 mTLS，並能與自動擴展器一同擴展。

VPC endpoints 移除了存取 AWS API 和熱門服務時所需的網際網路出口。用於 S3 和 DynamoDB 的 Gateway endpoints (使用 –service-name

undefined

的 CreateVpcEndpoint) 會新增路由到一個端點前綴列表，並且是免費的。Interface endpoints (使用 –vpc-endpoint-type Interface 的 CreateVpcEndpoint) 會建立具有私有 IP 和安全群組的彈性網路介面；它們按小時和每 GB 流量計費，但當與一個由 NLB 支援的服務配對時，能夠實現 PrivateLink 風格的服務使用方式和跨帳戶存取。

設計模式與權衡取捨

對於一個由多個帳戶中的眾多業務單位所共用的中央共享服務，當您需要對每個連線進行控制和隔離時，PrivateLink 和端點服務是最安全且可擴展的模式。將服務託管在共享服務 VPC 中的 Network Load Balancer 後方，建立一個 VPC 端點服務 (CreateVpcEndpointServiceConfiguration)，並讓消費者帳戶建立您所核准的介面端點。這樣可以避免完全網狀的複雜結構，並防止可轉送路由的發生，同時介面端點上的安全群組可讓您限制哪些消費者可以連線。其權衡之處在於每個端點的成本，以及接受和稽核端點連線所需的一些管理開銷。

當您有多個 VPC 需要廣泛的連線能力、集中式檢測，以及一個透過 Direct Connect 來宣告地端前綴的單一位置時，Transit Gateway 便能發揮最大效益 (CreateTransitGatewayRoute, CreateTransitGatewayRouteTable)。使用路由表分段和傳播控制來避免意外的橫向移動；Transit Gateway 支援路由優先級和路由表關聯，因此您可以將生產流量與信任度較低的網路隔離開來。其權衡之處在於 Transit Gateway 會集中流量，對於原本是本地的跨 VPC 流量可能會產生額外費用；它還會改變故障域，並需要謹慎的 CIDR 規劃以防止位址重疊。

對於 CIDR 重用受限的混合式架構，可考慮將 Direct Connect 與 Transit Gateway 和 Direct Connect Gateway (CreateDirectConnectGateway) 結合使用，以減少虛擬介面的數量。如果您需要在共享的實體鏈路上為每個業務單位隔離頻寬，可以配置多個私有虛擬介面，並監控每個 VIF 的 CloudWatch 指標 (指標名稱如 AWS/DX: BytesIn, BytesOut)，並使用 VIF 層級的 CloudWatch 警報。要識別高用量的消費者，請啟用 VPC Flow Logs (CreateFlowLogs) 將日誌傳送到 S3 或 CloudWatch Logs，並使用 Athena 或 CloudWatch Logs Insights 進行分析；若要對個別 VM 進行短時間的封包擷取，請使用 Traffic Mirroring (CreateTrafficMirrorSession)。

採用 IPv6 和雙堆疊設計可以減少對 NAT 的依賴，降低 NAT Gateway 的吞吐量成本，並簡化面向客戶端的定址。使用 API 呼叫

undefined

來指派一個 Amazon 提供的 IPv6 前綴，並建立具有 IPv6 CIDR 區塊的子網路。請注意，某些服務和第三方設備可能尚未支援 IPv6；在負載平衡器上使用雙堆疊 (使用 IpAddressType dualstack 執行 CreateLoadBalancer)，以同時支援 IPv4 和 IPv6 客戶端，而後端系統則維持 IPv4。

常見陷阱與決策標準

忽略 Kubernetes Pod 的 IP 位址消耗是服務中斷的常見原因。應考慮到每個執行個體類型的 ENI 和次要 IP 限制，並使用 VPC CNI 的設定 (如 WARM_IP_TARGETS 或前綴指派) 來提高 IP 的可用性。未能在 L7 保留客戶端 IP 是另一個常見的疏漏：如果必須在負載平衡器上終止 TLS，您必須確保應用程式能讀取 X-Forwarded-For 標頭，並且 ALB 的安全控制要限制直接存取，這樣標頭才能被信任。假設 VPC peering 可以無限擴展，往往會導致難以管理的網狀結構；在需要精細安全性和流量隔離的情況下，多對多連線應優先考慮 Transit Gateway，而一對多的服務暴露則應優先考慮 PrivateLink。

安全策略應結合使用安全群組和網路 ACL，並搭配命名空間層級的控制措施。若要嚴格強制只能透過 Global Accelerator 存取，而非直接使用 ALB 的 URL，可以依賴 AWS WAF IP 集 (使用已發布的 ip-ranges.json 自動填入 Global Accelerator 的 IP 範圍)，或是將 ALB 設計為內部使用，並在其前端放置一個由 Global Accelerator 作為目標的 NLB，然後僅暴露 Global Accelerator 的入口。務必自動化更新任何基於 IP 的控制措施，並使用 DescribePrefixLists 和定期擷取 ip-ranges.json 來進行驗證。

實務問題：使用案例情境

公司：Equinox Payments。挑戰：Equinox 執行一個由 EKS 支援的 gRPC 服務，需要為數千個並行連線提供端對端 mTLS、透過 Cluster Autoscaler 和 HPA 進行自動擴展，並為日誌記錄保留客戶端 IP。方法：1) 透過 AWS Load Balancer Controller，將服務部署在一個 Network Load Balancer 後方，該 NLB 設定一個在 443 埠上的 TCP 監聽器，並使用註解 service.beta.kubernetes.io/aws-load-balancer-type: “nlb-ip”，以便將 Pod IP 註冊為目標；2) 在 Pod 層級終止 TLS (而非在 NLB)，並在應用程式中實作相互 TLS (伺服器和客戶端憑證驗證)，使用 Kubernetes Secrets 存放憑證，並透過就緒探測來驅動目標註冊；3) 使用目標類型 ip 來保留客戶端來源 IP，僅在中間設備需要時才啟用代理協定，並依賴 Pod 端的日誌記錄從 TCP 連線中擷取客戶端 IP；4) 將健康檢查設定為 TCP 或感知 gRPC 的就緒探測，並確保 Cluster Autoscaler 策略和節點執行個體類型具有足夠的 ENI 和 IP 容量；5) 實作 CloudWatch Container Insights 和 VPC Flow Logs (CreateFlowLogs) 來監控連線計數和 VPC 層級的遙測資料。AWS 的理由：具有 TCP 監聽器的 NLB 在擴展至數百萬個連線的同時，能夠保留加密的會話和來源 IP；目標類型 ip 允許 Pod 無需經過 NAT 即可直接接收來源 IP；在 Pod 端終止 mTLS 滿足了端對端加密和雙向驗證的需求；自動擴展之所以能運作，是因為 Pod 的就緒狀態直接影響目標註冊，且 NLB 會隨著連線負載透明地擴展。

所有領域 · 混合式連線：VPN 與 Direct Connect →

練習這些題目 → · 在 ExamRoll.io 上限時練習 →