Amazon ANS-C01: 混合式連線：VPN 與 Direct Connect — 學習指南
屬於 AWS Advanced Networking Specialty ANS-C01 — 學習指南. 使用經過驗證的解答練習： Amazon 考試中心, 或參加限時模擬考試： ExamRoll.io.
核心概念
AWS 中的混合式連線 (Hybrid connectivity) 是結合私有佈建的網路線路與加密的 IP 通道，將地端網路延伸至 AWS 雲端。Site-to-Site VPN 提供在 Virtual Private Gateway (VGW) 或 Transit Gateway 上終止的 IPsec 通道 (IKEv1/IKEv2)；為了備援能力，AWS 會為每個 VPN 連線佈建兩個獨立的通道，並支援 BGP 以進行動態路由，或在需要時支援靜態路由。Client VPN 是一個基於 OpenVPN 的託管端點，支援用於使用者身分的雙向憑證驗證 (ACM Private CA 或上傳的用戶端憑證) 或 SAML 聯邦、將路由傳播到 VPC 或 Transit Gateway，以及用戶端分割通道 (client-side split-tunnelling) 以限制傳入 AWS 的流量。
AWS Direct Connect 提供您的場所與 AWS 之間的專用實體連線。連線可以是專用 (由 AWS 佈建) 或託管 (由合作夥伴佈建)；您可以使用連結彙總群組 (Link Aggregation Group, LAG) 來彙總多個連線，以呈現單一邏輯介面並增加頻寬；Direct Connect 支援連至 VPC 的私有虛擬介面 (private VIF)、用於 AWS 公有端點的公有 VIF，以及連至 Direct Connect Gateway 以實現多區域或 Transit Gateway 連線的傳輸 VIF (transit VIF)。為了保護實體鏈路上的資料，在支援的地點可使用 MACsec，以在客戶邊緣和 AWS 邊緣之間提供第 2 層框架加密，而第 3 層的傳輸中加密則仍由 IPsec 或 TLS 端點負責。
可靠性與路由需要對容錯移轉和路徑選擇進行明確的控制。BGP 屬性 (local-preference、AS path prepending) 用於優先選擇 Direct Connect 而非 VPN，以獲得低延遲和高吞吐量，並由 Site-to-Site VPN 或次要的 DX 連線作為自動備援。當需要端對端 TLS，或當應用程式需要保留用戶端來源 IP 以及處理大量長時間存續的 TCP 連線 (例如在 443 埠上透過 TLS 的 gRPC) 時，請使用 TCP/TLS 直通模式，例如 Network Load Balancer (NLB) 或在 EKS 節點上具有適當安全控制的直接公有端點；當在邊緣終止連線是可以接受的情況下，Application Load Balancer (ALB) 支援 HTTP/2 和 gRPC 並會終止 TLS，同時插入 X-Forwarded-For 標頭，以便後端 pod 能夠記錄用戶端 IP。
主要服務與組態設定
在建立 Site-to-Site VPN 時，您會使用 EC2 的 CreateVpnConnection API (aws ec2 create-vpn-connection)，並通常將產生的 vpn-connection 附加到 virtual private gateway (create-vpn-gateway 和 attach-vpn-gateway) 或透過指定 transit-gateway-id 附加到 transit gateway。使用產生的通道參數來設定客戶閘道裝置：IKE 版本、加密演算法 (AES-GCM)、雜湊演算法 (SHA-2)、Diffie-Hellman 群組、生命週期以及預先共用金鑰。對於動態路由，請啟用 BGP 並設定 BGP 芳鄰 ASN 和 IP；為了在路由器層級更快地偵測到容錯移轉，請在地端裝置和 AWS 邊緣之間使用支援的 BFD。
Client VPN 端點是透過 EC2 的 CreateClientVpnEndpoint API (aws ec2 create-client-vpn-endpoint) 建立的。您需要提供一個來自 ACM 的伺服器憑證、一個驗證選項 (憑證或 SAML)，並將該端點與一個或多個 VPC 子網路建立關聯，以建立彈性網路介面。使用 authorize-client-vpn-ingress 根據授權規則開放允許的網路，並使用 create-client-vpn-route 將路由推送到 VPC 中。對於大量使用者群體和條件式存取，請將 Client VPN 與 AWS Directory Service 或 SAML 身分提供者整合，並透過指派足夠的 CIDR 位址範圍給 Client VPN 端點來同時擴展。
Direct Connect 的佈建使用 Direct Connect API，例如 create-connection；或者，對於合作夥伴連線，由合作夥伴佈建一個託管連線，然後您使用 allocate-hosted-connection 或 accept-virtual-interface API。要彙總實體連結，請呼叫 create-lag，然後呼叫 create-private-virtual-interface 或 create-transit-virtual-interface，將虛擬介面附加到 VPC 或 Direct Connect Gateway。對於 MACsec，請與合作夥伴或透過 AWS 訂購入口網站合作，為連線申請 MACsec；組態設定包括在客戶邊緣交換器上的金鑰交換和匹配的加密套件，而操作指令通常在佈建時進行協調。對於多 VPC 架構，建議優先使用帶有 transit VIF 的 Direct Connect Gateway 來連接到 Transit Gateway——這種方式比建立許多 private VIF 具有更好的擴展性，並允許透過 TGW 路由表進行集中式路由。
設計模式與權衡取捨
若要達到高吞吐量和低容錯移轉時間，可選擇主動-主動 (active-active) 架構，將兩個 Direct Connect 連線放置在不同地點，使用 BGP 公告相同的字首，並在單一站點內使用 LAG 進行鏈路捆綁。採用 BGP multipath 的主動-主動模式可提供更優越的效能和真正的負載分擔；然而，這需要對稱路由、相容的地端 BGP，以及謹慎的 AS-path 和 local-preference 調校。可使用 Site-to-Site VPN 作為自動的主動-被動 (active-passive) 備援，因為 IPsec 隧道具有彈性且可全球連線，但與 Direct Connect 相比，預期會有較高的抖動、較低的吞吐量和較長的容錯移轉時間。在必須要求確定性、低延遲連線的場景中，儘管成本較高，第二條 DX 連線仍是較佳的選擇。
對於應用程式層級的 TLS 需求，設計選擇取決於是否允許負載平衡器看到解密的流量。如果需要端對端的 mutual TLS (mTLS)，請使用 NLB 的 TCP/TLS 穿透模式，在後端終止 TLS，並讓 Kubernetes Ingress Pod 處理 mTLS；對 EKS 使用 target type ip，這樣 Pod 就可以擴展，且 Cluster Autoscaler 可以在不變更 NLB 組態的情況下新增節點，如果您需要在 Pod 中取得原始用戶端來源 IP，請啟用 proxy protocol v2。如果可以在 ALB 上終止 TLS，請使用帶有 HTTPS 接聽器的 ALB，在 ACM 中設定憑證，啟用 HTTP/2 以支援 gRPC，並依賴 X-Forwarded-For 標頭來取得用戶端 IP；ALB 提供基於路徑的路由，可將流量分派到多個目標群組，以實現基於 URL 的調度。
對於需要精細安全性和擴展性的多帳戶、多 VPC 連線需求，使用 Transit Gateway 和集中式 Direct Connect Gateway 的中樞輻射 (hub-and-spoke) 模式可提供最佳的擴展性。將每個業務單位的 VPC 連接到一個 Transit Gateway (TGW)，並透過 transit VIF 將 TGW 與 Direct Connect Gateway 關聯起來。使用 TGW 路由表來實施隔離，並使用資源層級政策、Security Group 和 Network ACL 進行精細控制。其權衡之處在於管理 TGW 路由表的操作複雜性，以及需要謹慎設計 IAM 和帳戶邊界。
常見的陷阱與決策標準
一個常見的錯誤是每個 VPC 只依賴單一的 VIF，而未考慮到 VIF 的限制以及隨著 VPC 數量增長而帶來的營運複雜性；當您預期會有許多 VPC 或多個區域時，請使用 Direct Connect Gateway 和 transit VIF。另一個常見的陷阱是假設 VPN 和 Direct Connect 的行為完全相同：IPsec rekey、MTU 的影響以及每個通道的吞吐量差異，意味著 VPN 是一個可靠的備援，但在效能上並非等價。錯誤設定 TLS 終止和下游用戶端 IP 的預期是另一個錯誤來源——若要實現帶有 mTLS 的真正端對端 TLS，請選擇 NLB passthrough；如果邊緣可以終止 TLS，則選擇 ALB 終止和 X-Forwarded-For 處理。
最後，監控和可視性至關重要。為 Direct Connect 啟用 CloudWatch 指標 (ConnectionBpsEgress/Ingress)、為 VPC 可視性啟用 flow logs，並使用 CloudWatch 警報來觸發自動化以轉移流量或通知網路工程師。當多個業務單位在 LAG 上共享頻寬時，為了進行流量歸屬的鑑識，請關聯 VIF 統計數據和 VPC flow logs，並考慮在邊緣進行每個 VPC 的頻寬控制，以避免「吵鬧的鄰居」問題。
實務問題：使用案例情境
公司：Meridian Medical Analytics。挑戰：Meridian 營運著一支全球性的醫療影像設備隊伍，這些設備使用透過 TCP 443 埠的 gRPC，將大流量的加密串流上傳到位於 us-east-1 的 Amazon EKS 叢集上託管的後端。這些設備需要 mutual TLS 進行雙向用戶端驗證，並支援數千個並行、長期的連線。EKS 叢集會透過 Cluster Autoscaler 和 HPA 自動擴展。Meridian 需要從其主要資料中心獲得確定的低延遲，並能自動容錯移轉到雲端 VPN。
方法：
- 在 EKS service 前方佈建一個 Network Load Balancer (NLB)，設定 TCP 接聽器在 443 埠上，並將目標類型設為 IP，以便 pod 端點可以直接成為目標；將 NLB 設定為 TLS passthrough (不要在 NLB 終止 TLS)，以便與後端 pod 協商 mutual TLS。使用
undefined
和
undefined
來設定 NLB 和目標群組。 2. 設定 EKS pod 容器 (Ingress 或 sidecar) 來終止 mutual TLS，使用來自私有 CA 的伺服器和用戶端憑證 (使用 ACM Private CA 簽發伺服器憑證；用戶端憑證則佈建到設備上)。確保 pod 支援 HTTP/2 gRPC 並透過 HPA 和 Cluster Autoscaler 進行擴展；使用針對長期連線調整過的目標群組取消註冊延遲。 3. 對於地端連線，佈建一個 Direct Connect 專用連線 (
undefined
)，如果有多個實體線路可用，則用 LAG 進行彙總，並建立一個 private virtual interface (
undefined
) 連接到附加至您 Transit Gateway 的 Direct Connect Gateway，以路由到 EKS VPC。如果在佈建時電信商和地點支援，請啟用 MACsec 以保護第 2 層傳輸。 4. 實作一個 Site-to-Site VPN (
undefined
到 Transit Gateway) 作為自動容錯移轉路徑；透過 BGP 屬性來控制容錯移轉，偏好 Direct Connect (較高的 local-preference)，並讓 VPN 繼承較低的 preference。在支援的情況下使用 BFD 以實現更快的路徑故障偵測。在 CloudWatch 中監控 Direct Connect 和 VPN 指標，並設定警報以觸發流量工程變更或通知。
AWS 的理由：NLB TCP passthrough 保留了端對端的 mutual TLS，因此設備的用戶端憑證可由後端 pod 進行驗證，這滿足了流量不得在邊緣解密的要求。目標類型 IP 和 NLB 支援數千個並行長期連線的擴展，同時透過 proxy protocol 或在需要時從 TLS session 讀取用戶端 IP 來保留用戶端 IP。Direct Connect 提供到 us-east-1 的確定性、高頻寬連線，使用 LAG 提供容量，並使用 MACsec 進行實體鏈路加密；Site-to-Site VPN 提供了一個全球可達、加密的備援路徑，並透過 BGP 進行容錯移轉。此設計在安全性、效能和可擴展性之間取得了平衡，同時也符合 AWS Direct Connect 和 VPN 的組態設定最佳實務。
← VPC 設計與進階網路 · 所有領域 · Transit Gateway 與網路拓撲 →
練習這些題目 → · 在 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.
通過考試 →