AWS creates every Site-to-Site VPN connection with two tunnels. Why two, and what does your side of the connection have to do for that redundancy to be real?

## Why AWS ships two When you create a Site-to-Site VPN connection, AWS returns two tunnels. Each has its own outside (public) IP address on the AWS side, its own inside addressing, and its own pre-shared key or certificate. They terminate on separate, independently maintained AWS endpoints. The reason is operational: AWS replaces tunnel endpoints for patching, hardware refresh and scaling. Those replacements happen on a schedule and are announced, and if you have only one tunnel configured, each replacement is a hybrid outage. This is the single most common cause of "our VPN dropped and nobody changed anything". ## The half AWS cannot do for you The downloadable device configuration AWS generates contains both tunnels. Bring both up. A surprising number of deployments configure tunnel 1, watch traffic flow, and never touch tunnel 2 — a redundant design that is in fact single-tunnel, and whose second half is discovered only when the first one goes away. Each tunnel carries its own key material and its own liveness detection. Dead peer detection settles what happens when the far side stops answering, and AWS exposes per-tunnel options for the DPD timeout action and for whether AWS or your device initiates the tunnel — the initiation setting matters when your device sits behind NAT and cannot be reached inbound. ## Static routing versus BGP How the two tunnels behave in practice is a routing question. **Static.** You declare your on-premises prefixes on the VPN connection. Traffic uses one tunnel; failover depends entirely on your device detecting the failure and moving traffic, and the AWS side has no way to learn that your network changed. Simple, and slower to converge. **Dynamic (BGP).** Your customer gateway peers over each tunnel and advertises your prefixes; AWS advertises the VPC prefixes back. If a tunnel drops, its session drops and the routes are withdrawn, and traffic moves within seconds. This is also how you add or remove on-premises networks without editing the VPN connection. **ECMP.** Terminating on a Transit Gateway rather than a virtual private gateway lets you enable equal-cost multipath so both tunnels — and tunnels of multiple VPN connections — carry traffic simultaneously. This is the supported way to exceed the per-tunnel throughput ceiling, since individual flows still pin to one tunnel and you are aggregating across flows. ## Getting the routes into the VPC A tunnel that is up but invisible in the VPC route table moves nothing. With a virtual private gateway, you enable route propagation on the VPC route tables so learned on-premises prefixes appear there; otherwise you add static entries pointing at the gateway. With a Transit Gateway, the VPN attachment propagates into the gateway's route tables, and the VPC route tables carry a route to the Transit Gateway. Forgetting propagation produces the exact same symptom as a down tunnel, so check it before you go looking at IPsec. ## The redundancy the two tunnels do not provide Both tunnels of one VPN connection terminate on **one** customer gateway — one device, one internet circuit, quite possibly one building. The two tunnels protect against an AWS-side endpoint failure, not against your router dying. Full redundancy means: - two customer gateway devices, ideally on different internet circuits; - a VPN connection from each, giving four tunnels; - BGP so route withdrawal handles failover between devices. And if a VPN is only the backup for a Direct Connect, remember that both paths should advertise the same prefixes so the failover is automatic rather than a change ticket. ## Watching it AWS publishes a per-tunnel state metric in CloudWatch, so alarming on "fewer than two tunnels up" catches the silent half-failure — the case where one tunnel died, everything still works, and nobody notices until the second one goes. That alarm is the practical payoff of understanding the two-tunnel design, and it is the answer interviewers most want to hear after the mechanics.