Amazon ANS-C01: 混合连接：VPN 与 Direct Connect — 学习指南

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

属于 AWS Advanced Networking Specialty ANS-C01 — 学习指南. 使用经过验证的答案练习： Amazon 考试中心, 或参加限时模拟考试： ExamRoll.io.

核心概念

AWS 中的混合连接是指将私有配置的网络线路和加密的 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，并支持客户端分割隧道以限制流入 AWS 的流量。

AWS Direct Connect 提供您的本地环境与 AWS 之间的专用物理连接。连接可以是专用的（由 AWS 预置）或托管的（由合作伙伴预置）；您可以使用链路聚合组 (Link Aggregation Group, LAG) 聚合多个连接，以呈现单个逻辑接口并增加带宽；Direct Connect 支持连接到 VPC 的私有虚拟接口 (private VIF)、用于 AWS 公共端点的 public VIF，以及用于多区域或 Transit Gateway 连接的、连接到 Direct Connect Gateway 的 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 端口上运行的 gRPC over TLS）时，请使用 TCP/TLS 直通模式，例如 Network Load Balancer (NLB) 或在 EKS 节点上具有适当安全控制的直接公共端点；当在边缘终止 TLS 可以接受时，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 身份提供商集成，并通过为 Client VPN 端点分配足够的 CIDR 地址范围来支持并发扩展。

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 路由表进行集中路由。

设计模式与权衡

若要实现高吞吐量和低故障切换时间，可选择双活架构，将两个 Direct Connect 连接放置在不同位置，使用 BGP 宣告相同的前缀，并在站点内使用 LAG 进行链路捆绑。采用 BGP 多路径的双活模式可提供卓越的性能和真正的负载分担；但这需要对称路由、兼容的本地 BGP，以及对 AS-path 和 local‑preference 的精细调整。使用 Site‑to‑Site VPN 作为自动的主备备份，因为 IPsec 隧道具有弹性且可全局访问，但与 Direct Connect 相比，预计抖动会更高、吞吐量更低、故障切换时间更长。在必须保证确定性的低延迟连接的场景下，尽管成本更高，但第二个 DX 连接是更优选的方案。

对于应用级别的 TLS 要求，设计选择取决于是否允许负载均衡器看到解密后的流量。如果需要端到端的双向 TLS (mTLS)，则应在后端终止 TLS，方法是使用处于 TCP/TLS 直通模式的 NLB，并让 Kubernetes Ingress Pod 处理 mTLS；为 EKS 使用 ip 类型的目标，以便 Pod 可以扩展，并且 Cluster Autoscaler 可以在不更改 NLB 配置的情况下添加节点，如果需要在 Pod 中获取原始客户端源 IP，请启用 proxy protocol v2。如果可以在 ALB 上终止 TLS，则使用带有 HTTPS 侦听器的 ALB，在 ACM 中配置证书，为 gRPC 支持启用 HTTP/2，并依靠 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 Groups) 和网络 ACL (Network ACLs) 进行精细控制。其权衡之处在于管理 TGW 路由表所带来的操作复杂性，以及需要仔细设计 IAM 和账户边界。

常见陷阱与决策标准

一个常见的错误是为每个 VPC 依赖单个 VIF，而没有考虑到 VIF 的限制以及随着 VPC 数量增长带来的运维复杂性；当您预期会有大量 VPC 或多个区域时，应使用 Direct Connect Gateway 和 transit VIF。另一个常见的陷阱是假设 VPN 和 Direct Connect 的行为完全相同：IPsec 重新生成密钥、MTU 的影响以及各隧道吞吐量的差异意味着 VPN 是一个可靠的备份，但在性能上并不等同。错误配置 TLS 终止以及对下游客户端 IP 的预期是另一个错误来源——如果需要真正的端到端 TLS 和 mTLS，请选择 NLB 直通模式；如果边缘可以终止 TLS，则选择 ALB 终止并处理 X-Forwarded-For 头部。

最后，监控和可见性至关重要。为 Direct Connect 启用 CloudWatch 指标 (ConnectionBpsEgress/Ingress)，为 VPC 可见性启用流日志，并使用 CloudWatch 警报来触发自动化操作以转移流量或通知网络工程师。当多个业务部门在 LAG 上共享带宽时，为了进行流量归属的取证分析，需要关联 VIF 统计数据和 VPC 流日志，并考虑在边缘设备上实施基于 VPC 的带宽控制，以避免“吵闹邻居”问题。

实际问题：用例场景

公司：Meridian Medical Analytics。挑战：Meridian 在全球运营着一批医疗成像设备，这些设备使用 gRPC 通过 TCP 443 端口将大容量加密数据流上传到托管在 us-east-1 区域的 Amazon EKS 集群中的后端服务。这些设备需要使用 mTLS（双向 TLS）进行客户端身份验证，并支持数千个并发的、长连接。EKS 集群通过 Cluster Autoscaler 和 HPA 自动扩展。Meridian 需要从其主数据中心获得可预测的低延迟连接，并能自动故障转移到云上的 VPN。

方案：

在 EKS 服务前配置一个 Network Load Balancer (NLB)，为其设置 TCP 443 端口的侦听器，并将目标类型设置为 IP，以便 Pod 端点可以直接作为目标；将 NLB 配置为 TLS 直通模式（不要在 NLB 上终止 TLS），这样 mTLS 协商就可以与后端 Pod 进行。使用 aws elbv2 create-load-balancer 和 create-listener 来配置 NLB 和目标组。
配置 EKS Pod 容器（通过 Ingress 或 sidecar 模式）使用来自私有 CA 的服务器和客户端证书来终止 mTLS（使用 ACM Private CA 颁发服务器证书；客户端证书预置到设备上）。确保 Pod 支持 HTTP/2 gRPC，并通过 HPA 和 Cluster Autoscaler 进行扩展；针对长连接调整目标组的注销延迟时间。
对于本地连接，如果有多条物理线路可用，则配置一条 Direct Connect 专用连接 (create-connection) 并通过 LAG 进行聚合；然后创建一个私有虚拟接口 (create-private-virtual-interface) 连接到已附加到 Transit Gateway 的 Direct Connect Gateway，以实现到 EKS VPC 的路由。如果运营商和地理位置支持，请在配置时启用 MACsec 以保护第二层传输的安全。
实施一个 Site-to-Site VPN（通过 aws ec2 create-vpn-connection 连接到 Transit Gateway）作为自动故障转移路径；通过 BGP 属性来控制故障转移，优先选择 Direct Connect（设置更高的 local-preference），让 VPN 继承较低的优先级。在支持的情况下使用 BFD 以实现更快的路径故障检测。在 CloudWatch 中监控 Direct Connect 和 VPN 的指标，并设置警报以触发流量工程变更或发送通知。

AWS 理由：NLB 的 TCP 直通模式保留了端到端的 mTLS，因此设备的客户端证书可以由后端 Pod 进行验证，这满足了流量不在边缘解密的要求。目标类型设置为 IP 的 NLB 支持数千个并发长连接的扩展需求，同时可以通过代理协议（proxy protocol）保留客户端 IP，或者在需要时从 TLS 会话中读取客户端 IP。Direct Connect 提供了到 us-east-1 的确定性、高带宽连接，通过 LAG 提升容量，通过 MACsec 实现物理链路加密；Site-to-Site VPN 提供了一个全球可达、加密的备份路径，并由 BGP 控制故障转移。此设计在安全性、性能和可扩展性之间取得了平衡，同时符合 AWS Direct Connect 和 VPN 的配置最佳实践。

← VPC 设计与高级网络 · 所有领域 · Transit Gateway 与网络拓扑 →

练习这些题目 → · 在 ExamRoll.io 上限时练习 →