AWS Single-Tunnel Notice: When It Actually Matters

An AWS Health notice saying one tunnel is down usually arrives when nothing appears to be broken. That is exactly why it gets dismissed. The notice is not describing an outage; it is describing a redundancy state that has persisted past AWS's observation window. Whether you act depends on what your design can survive, not on how the dashboard feels.

What the notice actually measured

Each Site-to-Site connection has two tunnels, terminated on different AWS endpoints. AWS's monitoring documentation recommends configuring both for redundancy and raises the notification when one stays down for the documented period. That period matters, because a flap and a permanent loss look identical in a single graph.

Read per-tunnel telemetry rather than the connection's overall state. aws ec2 describe-vpn-connections --vpn-connection-ids vpn-0123 --query 'VpnConnections[0].VgwTelemetry' returns a status and message for each tunnel, which is the evidence the notice is based on.

Three conditions that decide your response

Work through the three before you decide whether this is a ticket or a shrug.

First, can the surviving tunnel carry the load, including any bandwidth ceiling and the prefixes it advertises? Second, does failover actually happen, given that a second tunnel down since creation has never been proven to come up? Third, would your next planned change take both tunnels down at once, which turns a cosmetic warning into a maintenance-window problem. If any answer is no or unknown, the notice is a real finding.

If all three are demonstrably fine, write down why it is tolerable and move on. That note is worth more than the argument next quarter.

What a standby peer does not prove

A customer gateway with a configured backup peer is not evidence that AWS sees two healthy tunnels. The customer side can hold a cold peer that needs a fresh negotiation, and that can be a legitimate design. It is still not the same observation as two live tunnels.

Two physical routers do not fix the opposite case either. When both tunnels terminate on one device or leave through one uplink, the redundancy exists on paper.

Match the change to its blast radius

AWS's endpoint replacement documentation separates the cases, and the distinction is easy to skim past. AWS-managed updates are applied to one tunnel at a time. Customer-initiated changes to the target gateway, the customer gateway or the connection options make both tunnels unavailable while replacement endpoints are provisioned.

Changing options on a single tunnel is a third case with its own stated impact: that tunnel is unavailable during its own update and the other keeps running.

Prove the alternate before you need it

Schedule the test instead of waiting for the event. Bring the healthy tunnel down inside a maintenance window, confirm the alternate negotiates, then confirm real traffic crosses it in both directions. Check return routing as well as tunnel status, because a phase-two mismatch leaves the tunnel up and the workload dead. Time the transition while you are there.

Keep the notice, the telemetry output and the change plan in one record. That record turns next quarter's notice into a two-minute review rather than a debate about whether anyone has ever tested the backup.