Should You Enable AWS VPN Tunnel Logs on a Live Tunnel?

Turning on tunnel activity logs for a Site-to-Site VPN is a small change that can drop the tunnel it is measuring. AWS warns that enabling logging on an existing tunnel can interrupt it for several minutes, so the interesting question is not how to flip the flag but which tunnel to flip it on and when. Three conditions settle the order: whether the other tunnel genuinely carries the routes, whether you need service events or BGP events, and whether the change goes through the console or through the tunnel options API. Get those wrong and you end up with either an outage or a log group full of nothing.

Three conditions decide the order

Start from the identity of the thing you are changing. You need the VPN connection ID, the Region, and the outside IP address of the specific tunnel, because every log setting in this feature is per tunnel rather than per connection. A change applied to the wrong outside address is a change to a tunnel nobody was debugging.

The destination is a CloudWatch log group in the same Region, with the retention and access policy you actually want. AWS recommends the /aws/vendedlogs/ prefix for these groups because it avoids resource-policy size limits that plain names can hit. A name like /aws/vendedlogs/vpn/branch-a-activity is only illustrative; what matters is that the group exists, that the delivery role can write to it, and that both are managed by whoever owns the VPN configuration. The name does not grant permissions, and a group created without the delivery policy produces silence rather than an error.

Condition one: a redundant tunnel that really carries traffic

This is the condition teams skip. Two configured tunnels are not proof that the application has a usable alternate path.

Before you touch one tunnel, confirm the other one is carrying the routes that matter: check the routing table on the customer gateway side and confirm the application can actually fail over. AWS's interruption window is minutes, not seconds, and a tunnel that exists only on paper turns a diagnostic change into an outage. If the redundant path is unproven, schedule the change with the same care as any other routing change instead of treating logging as passive. Instrument the tunnel whose behaviour you are trying to explain, not the one that is easier to reach.

Condition two: activity log or BGP log

This one decides what you will actually be able to read. Activity records cover service events such as IKE and IPsec state transitions and DPD messages, which is what you want when the tunnel will not come up or keeps rekeying. BGP records are a separate stream with their own controls, and they answer a different question: whether routes were exchanged and withdrawn as expected.

Enabling the activity flag is not a request for every stream the service can emit. If the suspicion is routing, enable both; if the suspicion is phase 1 or phase 2 negotiation, the activity stream is the one that will show it.

Neither stream is a packet capture, and that distinction decides more tickets than it should. Activity and BGP records tell you what the service did with the tunnel and the session, not what your application sent through it. Reaching for tunnel logs to debug an application timeout is a category error, and it usually costs an interruption window before anyone notices. Pick the question first, then the stream that can answer it.

Condition three: console change or tunnel options API

If a human is making a one-off change, the console path is fine: VPC console, Site-to-Site VPN connections, select the connection, Actions, Modify VPN tunnel options, pick the outside IP, enable Tunnel activity log, choose the group and the output format, save inside the window. If the VPN is managed as code, the same click is drift you will reconcile later.

For automation, the activity-log portion of the tunnel options has a fixed shape: LogOptions containing CloudWatchLogOptions with LogEnabled, LogGroupArn and LogOutputFormat. That block is a fragment, not a request; modify-vpn-tunnel-options still needs the connection ID and the tunnel outside IP, and the remaining tunnel settings have to be preserved by whoever owns the template. BGP logging uses its own BgpLogEnabled, BgpLogGroupArn and BgpLogOutputFormat keys in the same structure. Read the change back with describe-vpn-connections instead of trusting that the call applied.

What the records can and cannot tell you

Once the first tunnel is done and the intended path is available, repeat the same controlled sequence for the second tunnel if you need its logs too. One tunnel at a time is the whole point.

Records arrive in streams identified by the connection and the tunnel's outside address, so correlate against that identity rather than expecting history to appear retroactively. Nothing before the change exists, and no amount of waiting fills the gap. If you need a baseline, capture the current tunnel state and routing table before the change so there is something to compare against.

Keep the log group, its retention, its delivery permissions and the tunnel option block in the same inventory as the VPN itself, because they are one configuration spread across four places. The AWS enable-logs procedure documents the per-tunnel workflow and its interruption warning, and it is worth reading before the change rather than after. Then verify in order: the tunnel came back, records are appearing in the expected stream, and the records answer the question you opened the ticket for. If the third one fails, the problem was the choice of stream rather than the logging.