是否应在正在运行的隧道上启用 AWS VPN 隧道日志？

为 Site-to-Site VPN 打开隧道活动日志，看似只是个小改动，却可能把正在被观测的那条隧道弄断。AWS 明确提示：在已有隧道上启用日志，可能造成数分钟的中断，因此真正值得推敲的不是怎么拨这个开关，而是拨在哪条隧道上、什么时候拨。顺序由三个条件决定：另一条隧道是否真的承载路由、你需要的是服务事件还是 BGP 事件、改动走控制台还是走隧道选项 API。这几件事弄错，结果要么是一次中断，要么是一个空无一物的日志组。

三个条件决定顺序

先从你要改的对象本身入手。你需要 VPN 连接 ID、区域，以及具体那条隧道的外网 IP 地址，因为这项功能里的日志设置都是按隧道划分，而不是按连接划分。改错了外网地址，等于改了一条根本没人在排查的隧道。

目标是同区域内的一个 CloudWatch 日志组，保留期和访问策略都要按真实需求来定。AWS 建议这类日志组使用 /aws/vendedlogs/ 前缀，这样可以避开普通命名容易撞上的资源策略大小上限。像 /aws/vendedlogs/vpn/branch-a-activity 这样的名字只是示例；关键在于日志组确实存在、投递角色能写入，而且两者都由掌握 VPN 配置的人管理。名字本身不授予任何权限；没有投递策略就建好的日志组，得到的不是报错，而是彻底的沉默。

条件一：另一条隧道真的在承载流量

这一条常被团队跳过。配置里写着两条隧道，并不等于应用真的有一条可用的备用路径。

动其中一条之前，先确认另一条确实带着关键路由：检查客户网关一侧的路由表，并确认应用真的能切过去。AWS 的中断窗口以分钟计，不是以秒计；一条只存在于文档里的隧道，会把诊断性改动直接变成故障。备用路径没被验证过，就按对待任何路由变更的谨慎程度来排期，别把开日志当成没有影响的操作。要观测的是你想解释其行为的那条隧道，而不是更容易连上的那条。

条件二：活动日志还是 BGP 日志

这一条决定你实际能读到什么。活动记录覆盖 IKE、IPsec 状态迁移和 DPD 报文这类服务事件，正对应隧道起不来或不停重协商密钥的场景。BGP 记录是另一条独立的数据流，有自己的开关，回答的是另一个问题：路由是否按预期完成交换与撤销。

启用活动开关，并不等于要求服务把所有能发的流都发出来。怀疑是路由问题，就两条都开；怀疑是第 1 阶段或第 2 阶段协商，能给出答案的就是活动流。

两条流都不是抓包，这个区别解决的工单比想象中多。活动记录和 BGP 记录告诉你服务对隧道和会话做了什么，而不是你的应用从里面发了什么。拿隧道日志去查应用超时，属于类别错误，而且往往要耗掉一次中断窗口才有人反应过来。先确定问题，再挑能回答它的那条流。

条件三：控制台改动还是隧道选项 API

如果只是人工改一次，走控制台没问题：VPC console、Site-to-Site VPN connections、选中连接、Actions、Modify VPN tunnel options、选中外网 IP、启用 Tunnel activity log、选好日志组和输出格式，在窗口内保存。如果 VPN 是按代码管理的，同一次点击就是将来要收敛的偏差。

做自动化时，隧道选项里的活动日志部分形状是固定的：LogOptions 内含 CloudWatchLogOptions，后者带 LogEnabled、LogGroupArn 和 LogOutputFormat。这个块只是片段，不是请求；modify-vpn-tunnel-options 仍需要连接 ID 和隧道外网 IP，其余隧道设置也得由模板的维护者保住。BGP 日志在同一结构里用自己的一组键：BgpLogEnabled、BgpLogGroupArn、BgpLogOutputFormat。改完要用 describe-vpn-connections 回读，别假定调用已经生效。

记录能说明什么、不能说明什么

第一条隧道处理完、预期路径可用之后，如果第二条的日志也需要，就照同样的受控步骤再来一遍。一次只动一条，这才是关键。

记录按连接和隧道外网地址划分数据流，所以要按这个身份去关联，别指望历史会追溯出现。改动之前不存在任何数据，等多久也补不回来。需要基线，就在改之前把当前隧道状态和路由表记下来，以便有东西可对比。

日志组、保留期、投递权限和隧道选项块，要和 VPN 本身放在同一份清单里，因为它们是一套配置散落在四个地方。AWS 的启用日志流程写明了逐条隧道的操作步骤和中断警告，值得在改之前读完，而不是改完之后。然后按顺序核对：隧道回来了、记录出现在预期的流里、记录回答了当初开单的问题。第三条不成立，问题就出在选错了流，而不是日志本身。