亚马逊AWS官方博客
AWS Direct Connect 故障演练实战指南
摘要：本文面向已部署 AWS Direct Connect 高可用方案的客户，系统性地介绍负载均衡与主备两种场景下专线故障演练的最佳实践，通过 CloudWatch 监控、BGP Failover Test 与 AWS Fault Injection Service 三种手段，帮助客户周期性验证混合云连接的切换能力，确保业务在真实故障中稳定可持续运行。
目录
一、引言
正如《为 Direct Connect 维护事件构建弹性，最大限度减少停机时间》一文所述，构建弹性的混合云连接是客户上云后必须面对的课题，而定期开展专线故障演练正是其中的重要一环。在实际支持工作中，我们发现部分客户虽然部署了 Direct Connect 高可用方案，但由于缺乏定期演练，真正故障发生时出现切换失败、BFD 未生效、备用链路带宽不足等问题，最终未能达到预期的高可用效果。为帮助客户规避此类风险，本文将系统性地梳理 AWS Direct Connect 故障演练的最佳实践，指导客户按场景、按步骤地开展演练，确保主专线不可用时，备用链路（专线或 VPN）能够迅速接管并持续提供服务，从而保障业务的连续性和稳定性。
二、多条专线流量负载均衡场景
如果混合云环境中的多条专线采用负载均衡模式（即所有线路同时承载生产流量），通常无需进行切换演练，因为负载均衡架构本身已经具备流量自动分配和单点故障容错能力。但需要特别警惕的是：一旦其中一条或多条链路失效，剩余链路必须能够独立承担全部流量且不被拥塞。
一个常见的经验阈值是：两条专线时，每条利用率需控制在 50% 以下；四条专线时，控制在 25% 以下。否则当部分链路故障时，幸存链路会立即被打满，从而引发丢包、延迟抖动甚至整体服务中断。
Direct Connect 会将每条物理连接（Connection）的入向和出向流量指标以 ConnectionBpsEgress 和 ConnectionBpsIngress 的形式持续上报到 Amazon CloudWatch 的 AWS/DX 命名空间。您可以在CloudWatch metric 中查看特定时间范围内的带宽使用情况：
[图1] |
您也可以通过以下 CLI 命令快速查看指标的统计值：
为了实现主动式的容量预警，建议配置 CloudWatch 告警：以物理连接带宽为分母计算利用率阈值，当持续一段时间超过上述经验阈值时，通过 Amazon SNS 通知运维团队。以下示例为一条 10 Gbps 专线配置 50% 利用率告警（阈值 5,000,000,000 bps）：
收到告警后，请及时评估并规划带宽扩容（增加链路或升级端口速率），避免临时故障叠加高峰流量导致的连锁反应。
三、多条专线流量主备场景
在主备模式下，主线路承担全部生产流量，备用线路（专线或 VPN）处于待命状态，仅在主线路出现故障时接管流量。由于备用线路长期不承载流量，其链路存活性、路由收敛性、带宽质量往往处于“盲区”，一旦主线路故障，问题才会暴露。因此，定期演练对主备架构尤为重要。
3.1 演练前的准备工作
3.1.1 确认网络配置
在演练之前，请务必确认以下关键配置：
- 多专线部署：是否已遵循 Direct Connect 弹性建议（多位置、多设备）；备用专线与主专线的带宽是否一致；主备路由优先级（AS_PATH prepend、Local Preference、MED）是否正确；BFD（双向转发检测）是否已在两端正确启用。
- VPN 作为备份：确认VPN 备份 Direct Connect 的架构和配置，确保 VPN 隧道已正确建立，且 VPN 路由在主专线故障后能够自动被优选。
3.1.2 通知相关人员
- 提前通知运维团队、业务团队及可能受影响的用户，明确演练时间、范围及预期影响。
- 建议在业务低峰期或维护窗口进行演练；若演练可能对业务造成较大影响，需提前制定并沟通回退计划。
3.1.3 准备监控工具
在演练全程建议启用以下监控手段，以便实时洞察切换行为：
- CloudWatch Network Synthetic Monitor：模拟端到端请求，监测网络层面的可用性、丢包和延迟。
- CloudWatch Metrics：收集 Direct Connect的关键指标。
- ping：持续观察切换瞬间的丢包数量。
- mtr：逐跳分析流量路径，确认切换后链路是否符合预期。
- iperf：在条件允许时测试备用链路的实际吞吐能力。
3.2 演练步骤
根据操作侧的不同，主备切换演练有两种实施方式。推荐优先使用“在 AWS 上操作”的方式，因为它是 AWS 官方提供的无破坏性的故障注入能力，时间可控、回退简单。
3.2.1 方式一：在客户本地路由器上操作
第一步，中断主专线。登录本地路由器，关闭连接主专线的子接口。以 Cisco IOS 为例，假设主专线对应子接口为 GigabitEthernet0/0.101：
第二步，观察切换效果。主专线中断后，请分别从以下三个维度确认切换是否成功：
- 端到端连通性：使用 ping 命令持续打流，记录切换过程中的丢包数量。BFD 配置正确的情况下，丢包通常应控制在 3 个包以内。
- 流量路径：使用 mtr 命令观察流量是否已切换至备用线路，路径是否符合预期。
- 业务指标：观察业务系统的关键指标（可用性、错误率、延迟等），确认无异常。
第三步，恢复主专线。确认备用线路已稳定接管流量后，登录本地路由器，开启之前关闭的子接口：
3.2.2 方式二：在 AWS 侧使用 BGP Failover Test
Direct Connect 原生提供 BGP Failover Test 能力，允许您在不影响物理链路的前提下，模拟指定虚拟接口（Virtual Interface）的 BGP 邻居中断，默认持续 180 分钟，到期自动恢复。相比本地路由器操作，这种方式更安全、可审计，且具备自动回退保护。
第一步，针对主专线对应的 Virtual Interface 发起 BGP 故障注入测试（示例中断 30 分钟）：
查看虚拟接口状态以确认测试已进入 testing 状态：
第二步，观察切换效果。观察维度与方式一完全一致：
- 端到端连通性：ping 持续打流，切换瞬间丢包数应在 3 个包以内（依赖 BFD）。
- 流量路径：mtr 确认流量已切换至备用专线或 VPN。
- 业务指标：关注业务层面可用性、错误率、延迟等核心指标。
第三步，恢复主专线。测试到期后 AWS 会自动恢复 BGP 会话；若演练目标已达成并希望提前恢复，可执行以下命令手动结束测试：
3.2.3 进阶：使用 AWS Fault Injection Service 编排演练
AWS 去年宣布 Direct Connect 已支持通过 AWS Fault Injection Service（FIS）进行弹性测试，官方新增了 aws:directconnect:bgp-failover-test 动作类型。相比单次手动调用 API，FIS 的优势在于可以将“中断主专线—等待观测—收集 CloudWatch 指标—自动回退”编排为可复用的实验模板，并与 CloudWatch Alarm 停止条件联动，一旦业务指标越过红线即立即终止实验。对于具备多条 VIF、需要同时演练多个故障域的大型客户，推荐使用 FIS 将演练流程标准化、自动化，从“偶发手动演练”升级为“可持续的混沌工程实践”。
四、总结
本文围绕 AWS Direct Connect 故障演练，分别给出了负载均衡与主备两类常见场景下的最佳实践。负载均衡场景的核心在于容量预留——通过 CloudWatch 指标与告警确保单链路故障时幸存链路不过载；主备场景的核心在于定期验证——通过客户侧 shutdown 子接口或 AWS 侧 BGP Failover Test，周期性地验证备用链路的存活性、BFD 收敛速度及业务层面的平滑切换。建议客户将故障演练纳入季度运维计划，并逐步引入 AWS Fault Injection Service 实现自动化演练，真正将高可用方案的“设计态”转化为“运行态”的可靠保障。
➡️ 下一步行动：
相关产品：
- Amazon Connect — AI 客户体验解决方案
- Amazon CloudWatch — 可观测性工具
- Amazon SNS — 发布/订阅和推送通知
相关文章：
- 为 Direct Connect 维护事件构建弹性，最大限度减少停机时间
- 基于 AWS DevOps Agent 构建 AI 驱动的运维分析系统
- AWS Interconnect 现已正式上线，新增了一项功能，旨在简化最后一英里的连接
- DX 维护通知全球自动化处理方案 — 基于 Severless 的跨账号/跨区域实践
*前述特定亚马逊云科技生成式人工智能相关的服务目前在亚马逊云科技海外区域可用。亚马逊云科技中国区域相关云服务由西云数据和光环新网运营，具体信息以中国区域官网为准。
本篇作者
AWS 架构师中心：云端创新的引领者探索 AWS 架构师中心，获取经实战验证的最佳实践与架构指南，助您高效构建安全、可靠的云上应用
|
 |
