亚马逊云分销商 AWS Direct Connect 与 VPN 如何选择：企业混合云网络连接方案配置与排障指南

当用户搜索“AWS Direct Connect 与 VPN：企业混合云网络连接方案”时，通常不是想看定义，而是已经进入方案评估或实施阶段。最常见的决策问题有四类：第一，业务到底该先上 VPN 还是直接申请 Direct Connect；第二，专线开通周期较长时，如何先让系统上线；第三，双链路如何做主备或并行；第四，出现路由不通、抖动、丢包、BGP 不建立时该从哪里查。下面的内容直接围绕这些实际问题展开。

一、企业在决策阶段最关心的不是“选型”，而是上线风险

亚马逊云分销商 从实际项目看，用户通常面对以下场景：

• 本地机房已有核心系统，要把应用迁到 AWS，但数据库或部分内网服务短期仍留在本地。
• 新系统部署在 AWS，需要访问本地 AD、ERP、文件服务或旧数据库。
• 分支机构、工厂、门店通过总部网络访问 AWS，要求网络稳定，不能只靠公网出口临时接入。
• 跨境业务对链路波动比较敏感，希望固定路径、可预测带宽和更稳定时延。

这时真正需要回答的是下面这张决策表，而不是抽象比较。

如果你现在还没开通专线，但项目必须先上线，最实用的办法通常不是二选一，而是“先 VPN，后 Direct Connect，再做双链路容灾”。

二、实施前准备：哪些参数没确认，后面一定返工

很多项目失败不是出在 AWS 控制台操作，而是前置参数没收齐。建议在创建前先整理下面的清单。

1. 账号与权限

• AWS 账号具备创建 VPC、Virtual Private Gateway、Transit Gateway、Direct Connect Gateway、VPN Connection 的权限。
• 如果是多账号架构，需要确认网络账号是否统一承载 DXGW 或 TGW。
• 本地侧网络团队需要能修改边界路由器、防火墙、BGP 和 NAT 策略。

2. 必须提前确定的网络参数

3. 本地设备侧前置条件

如果接 VPN，需要确认边界设备是否支持 IPsec 与 BGP。如果接 Direct Connect，需要确认接入机房、运营商或合作伙伴资源，及本地路由器光口、电口、单模多模模块是否匹配。很多专线交付延期，原因不是 AWS，而是企业本地机房接入条件没准备好。

亚马逊云分销商 三、快速上线方案：先用 AWS Site-to-Site VPN 建立混合云互通

对于需要快速打通本地与 AWS 的场景，VPN 更适合作为第一阶段方案。下面按控制台操作说明。

步骤1：创建 AWS 侧网关

登录 AWS 控制台，进入 VPC。若你的网络是单 VPC 架构，可创建 Virtual Private Gateway 并附加到目标 VPC；如果有多 VPC 或未来多账号互通需求，优先考虑 Transit Gateway，再把 VPN 挂到 TGW 上，后续扩展更方便。

填写时注意：

• 单 VPC、业务简单：选 Virtual Private Gateway。
• 多 VPC、共享出口、多个账号：选 Transit Gateway。
• 如果未来要接入 Direct Connect，建议尽量避免后期重复迁移路由结构。

步骤2：创建 Customer Gateway

在 VPC 控制台创建 Customer Gateway，填写本地边界设备公网 IP 和 BGP ASN。这里最容易出错的是公网 IP 填了出口 NAT 地址，但实际设备并不是发起 IPsec 的那个设备，结果隧道一直起不来。

参数填写建议：

步骤3：创建 Site-to-Site VPN 连接

选择 AWS 侧网关与 Customer Gateway，创建 VPN Connection。下载对应厂商配置模板，常见如 Cisco、FortiGate、Palo Alto、Juniper。下载后不要直接套用，先核对 IKE、IPsec、BGP 邻居地址与隧道内网段。

这里的关键注意点：

• AWS 默认提供两条隧道，生产环境应同时配置。
• 如果本地设备支持 BGP，优先用动态路由，不建议长期依赖静态路由。
• 如果业务只允许特定网段互通，要同步调整防火墙策略和路由通告范围。

步骤4：在本地设备导入配置并放通策略

在本地防火墙或路由器上配置 IKE/IPsec 隧道、BGP 邻居、感兴趣流量和安全策略。很多“隧道已建立但业务不通”的问题都发生在这一层：IPsec 正常、BGP 正常，但防火墙没有放行源目地址和端口。

建议至少放通以下内容进行测试：

• ICMP 用于基本连通性验证
• TCP 22 用于 Linux SSH
• TCP 3389 用于 Windows RDP
• 业务端口，如 80、443、3306、6379

步骤5：在 AWS 路由表中关联目标网段

亚马逊云分销商 进入子网对应路由表，添加本地网段路由，下一跳指向 VGW 或 TGW。如果漏了这一步，EC2 会认为去本地网段没有合法路径，表现就是 AWS 到本地不通，而本地到 AWS 看似有流量。

步骤6：验证与排障

先从 EC2 测试 ping 或 telnet 到本地目标地址，再从本地测试 AWS 内网地址。如果能 ping 网关但不能访问业务端口，优先检查安全组、网络 ACL、本地防火墙和主机防火墙。

四、生产稳定方案：使用 AWS Direct Connect 建立专线接入

当业务从测试转为长期生产，尤其是数据库同步、备份、文件分发、核心交易或跨境系统访问时，Direct Connect 通常是主链路方案。重点不在于创建连接本身，而在于你选择了哪种接入方式。

1. 先决定接入模式：Dedicated 还是 Hosted

如果企业没有机房直接进入 AWS Direct Connect 接入点，通常会通过网络服务商或 IDC 合作伙伴接入 Hosted Connection，这比自建 Dedicated 更容易落地。

2. 控制台创建 Direct Connect 资源的顺序

推荐顺序如下：

• 亚马逊云分销商 进入 Direct Connect 控制台创建 Connection 或接受伙伴提供的 Hosted Connection。
• 创建 Private VIF，用于访问 VPC 私网资源。
• 如果有多个 VPC 或多个账号，创建 Direct Connect Gateway。
• 将 DXGW 关联到 Virtual Private Gateway 或 Transit Gateway。
• 在本地路由器配置 BGP 对等。

参数填写上最容易出问题的地方是 VLAN、BGP ASN、BGP 对端 IP、MTU 以及关联对象选错。例如企业已经规划走 Transit Gateway，却把 Private VIF 直接关联到 VGW，后面再做多 VPC 扩展就要重构。

3. Private VIF 参数怎么填

4. 路由发布建议

生产中不要把大量非必要网段全部发布到 AWS。建议只通告需要互通的业务网段，并统一汇总路由，减少误通告风险。若通过 Transit Gateway 汇聚多 VPC，建议在 TGW 路由表中按业务环境区分，如生产、测试、共享服务，不要把所有传播路由都默认打开。

5. Direct Connect 开通后的验证顺序

• 物理层：端口 Up，光模块、速率、双工一致。
• 链路层：VLAN 正确，子接口正常。
• 路由层：BGP Established，已学习到对端路由。
• AWS 侧：DXGW 与 VGW/TGW 关联完成，路由表生效。
• 业务层：EC2、RDS、内部应用可正常连通。

五、最实用的落地方式：Direct Connect 做主链路，VPN 做备份链路

很多企业最后采用的并不是“只用专线”或“只用 VPN”，而是混合模式。这样既能降低专线交付期间的上线风险，也能在专线故障或维护时保留备份路径。

推荐架构做法

• 主链路：Direct Connect 通过 Private VIF 接入 TGW 或 VGW。
• 备链路：Site-to-Site VPN 接同一 TGW 或 VGW。
• 路由策略：通过 BGP Local Preference、AS Path Prepend 或 AWS 路由优先级控制主备。
• 监控：对 BGP 状态、隧道状态、丢包率、时延分别监控。

如果业务要求在主链路异常时自动切换，建议在本地路由器上明确设置路由优先级，而不是依赖人工干预。否则故障时链路明明可切，但业务仍会黑洞几分钟到几十分钟。

切换测试建议

上线前至少做三次演练：

• 断开 Direct Connect BGP，会不会自动走 VPN。
• 恢复 Direct Connect 后，流量是否回切。
• 在大流量场景下切换，业务会不会出现 TCP 会话中断。

数据库复制、长连接中间件和文件传输系统对切换更敏感，建议在低峰期验证。

六、按业务场景给配置建议，避免“配置过大”或“后期重做”

1. 个人开发者或小团队测试环境

如果只是打通办公网、测试环境或开发机访问 AWS 私网服务，直接用 Site-to-Site VPN 即可。无需一开始就上 Direct Connect。VPC 网段建议一次规划清楚，避免和办公室或家庭网络冲突。

2. 企业正式生产环境

建议采用 TGW 汇聚架构，主链路 Direct Connect，VPN 备份。数据库、AD、日志平台、备份网络分别规划子网和路由表，避免所有业务混跑在一条扁平网络里。

3. 跨境业务

跨境场景重点不是“有没有链路”，而是时延稳定性和抖动控制。建议前期用 VPN 测试链路质量和应用容忍度，正式生产切到 Direct Connect，并对 DNS 解析、TLS 握手时延、数据库连接池超时时间做联动调整。

4. 网站应用

如果 AWS 上的网站需要访问本地数据库或认证服务，优先减少跨链路调用次数。可把数据库读副本、缓存层或认证代理逐步迁到云上，降低 Direct Connect 或 VPN 质量波动对前端页面响应的影响。

5. 数据库业务

数据库同步、备份和大批量导入导出更适合 Direct Connect。尤其 MySQL 主从复制、PostgreSQL 逻辑复制、Oracle Data Guard 这类持续流量场景，不建议长期只靠公网 VPN 作为唯一生产通道。

七、常见故障不是“链路坏了”，而是配置细节错了

1. BGP 邻居起不来

优先检查 ASN、对等 IP、掩码、VLAN 和防火墙是否放行 TCP 179。Direct Connect 场景下还要确认子接口是否绑定到正确端口。VPN 场景下则要先确认 IPsec 隧道已经建立，否则 BGP 不可能正常。

2. 隧道已 Up，但业务不通

通常是以下四类问题：

• AWS 路由表没有指向 VGW/TGW。
• 本地侧没有回程路由。
• 安全组或网络 ACL 拦截。
• 主机自身防火墙未放通端口。

亚马逊云分销商 3. 能 ping，不能连数据库

不要只看网络层。以 MySQL 为例，除了 TCP 3306 放通，还要检查数据库监听地址、授权主机范围、SSL 要求、连接数限制和 DNS 反查超时。Redis 则要额外确认 bind、protected-mode 和 AUTH 配置。

4. 时延不高，但应用仍然慢

这类问题常见于跨链路数据库调用。单次网络时延看起来不大，但应用每个请求都执行多次同步查询，累计就会放大。处理方法不是单纯加带宽，而是减少远程调用次数、启用连接池、加本地缓存、优化 SQL。

5. 大包传输失败，小包正常

多半是 MTU/MSS 问题。VPN 尤其容易出现这种情况。可以在本地防火墙或路由器启用 TCP MSS Clamp，并在服务器侧用 ping 带 DF 标志测试最大不分片报文。

八、上线后要持续优化的四件事

1. 安全优化

• 只发布必要网段，不做全网互通。
• 数据库端口仅对指定源网段开放。
• VPN 预共享密钥定期轮换，专线侧 BGP 配置最小权限变更。
• 在 AWS 使用安全组分层控制，避免所有子网共用一个宽泛规则。

2. 性能优化

• 对数据库同步、备份、批处理流量安排专用窗口。
• 通过 CloudWatch、VPC Flow Logs、本地 NMS 同时观察丢包与流量突增。
• 跨链路应用开启连接池，避免频繁建连。
• 大流量业务先压测，再决定是否升带宽或拆分链路。

3. 成本优化

• 亚马逊云分销商 项目初期先用 VPN 验证业务，减少盲目开专线。
• Direct Connect 带宽选择按峰值和持续流量分开评估，不要只看瞬时峰值。
• 亚马逊云分销商 如果多账号多 VPC 共用网络，优先设计 TGW 或 DXGW 汇聚，减少重复接入成本。

4. 稳定性优化

• 亚马逊云分销商 主备链路务必做故障演练。
• 关键业务设置双机房或双边界设备，不要只有一台本地防火墙承担全部隧道。
• 监控项至少包括 BGP 状态、VPN 隧道状态、流量、丢包、接口错误和应用连接错误数。

如果你的企业还在方案评审阶段，实际可执行的建议很明确：短期先用 VPN 快速上线，中长期把生产流量迁到 Direct Connect，最终形成 Direct Connect 主链路、VPN 备份链路的混合云网络连接方案。这样不仅能满足上线时间要求，也更容易在后续扩展多 VPC、数据库迁移、跨境访问和容灾切换时保持网络结构稳定。