AWS 单隧道通知：究竟何时才真正重要

当一切看起来都正常时，AWS Health 却发来一条提示，说某条隧道断了。这正是不该忽视它的原因：通知描述的并不是一次故障，而是一种越过 AWS 观测窗口仍在持续的冗余状态。你该不该动手，取决于你的设计能承受什么，而不是控制面板给你的感觉。

这条通知究竟测了什么

每个 Site-to-Site 连接都有两条隧道，分别终止在不同的 AWS 终端节点上。AWS 的监控文档建议把两条都配置起来做冗余，并在其中一条按文档所述的时长持续断开时发出通知。这个时长很重要，因为短暂的抖动和永久性失效在同一张图里看起来一模一样。

请按隧道逐条读取遥测，而不是只看连接的整体状态。aws ec2 describe-vpn-connections --vpn-connection-ids vpn-0123 --query 'VpnConnections[0].VgwTelemetry' 会为每条隧道返回状态和消息，这正是通知所依据的证据。

决定你如何回应的三个条件

在判断这是一张工单还是耸耸肩之前，先把这三条过一遍。

第一，幸存的那条隧道扛得住负载吗，包括可能的带宽上限和它宣告的前缀？第二，考虑到第二条隧道自创建起就一直断开、从未被证明能恢复，故障切换真的会发生吗？第三，你下一次计划中的变更会不会让两条隧道同时中断，从而把一条表面上的警告变成维护窗口的难题。只要有一个答案是否定或未知，这条通知就是真实发现。

如果三条都能证明无碍，就把理由写下来，然后继续。那条记录比下个季度的争论更有价值。

备用对端证明不了什么

客户网关配置了备用对端，并不能证明 AWS 看到的是两条健康隧道。客户侧可以保留一个需要重新协商的冷对端，这可能是合理的设计。但它依然不等同于对两条活隧道的观测。

两台物理路由器也解决不了相反的情况。当两条隧道都终止在同一台设备上，或都从同一条上联出去，冗余只存在于纸面上。

让变更与其影响范围相匹配

AWS 关于 端点替换文档 的文档把几种情况分开了，而这个区别很容易被略过。AWS 托管的更新一次只作用于一条隧道。客户自行发起的、针对目标网关、客户网关或连接选项的变更，会在替换终端节点准备期间让两条隧道同时不可用。

只改一条隧道的选项是第三种情况，它有自己的既定影响：该隧道在自己的更新期间不可用，另一条继续运行。

在需要之前先证明备用路径

与其等事件发生，不如把测试排进日程。在维护窗口内把健康的那条隧道停掉，确认备用隧道能完成协商，再确认真实流量能双向通过。除了隧道状态，还要检查回程路由，因为第二阶段不匹配会让隧道看起来还在、工作负载却已经死了。既然人在现场，顺便把切换耗时也量一下。

把通知、遥测输出和变更计划放在同一份记录里。这份记录会让下个季度的通知变成两分钟的复核，而不是一场关于有没有人真正测过备用的争论。