Walk me through an AWS site-to-site VPN. What do you get, and how does it stay redundant?
Show the answer
Say this first
You create a customer gateway (your device's public IP and ASN), a virtual private gateway on the VPC or a transit gateway, and a VPN connection between them. Each VPN connection has two IPsec tunnels ending on two AWS endpoints in different AZs. You run BGP over both tunnels (or use static routes) and AWS gives each tunnel a /30 inside address from 169.254.0.0/16. For real redundancy you add a second customer device with its own VPN connection.
Go deeper
Pieces
- Customer gateway (CGW): a record of your public IP and BGP ASN.
- Virtual private gateway (VGW): attached to one VPC. Amazon side ASN defaults to 64512. Or terminate on a transit gateway to serve many VPCs.
- VPN connection: two tunnels, each to a different AWS endpoint. IKEv1 or IKEv2, PSK or certificates.
Inside addressing
Each tunnel gets a /30 such as 169.254.10.0/30. AWS uses the first host (169.254.10.1), your router
uses the second (169.254.10.2). BGP runs between those addresses.
Behaviour worth knowing
- By default your device must start IKE; AWS waits. Tunnel options can make AWS initiate with IKEv2.
- A standard tunnel carries around 1.25 Gbps. A VGW will not load-share across tunnels. A transit gateway can ECMP across tunnels and across several VPN connections with BGP.
- Dead peer detection timeout defaults to 30 seconds.
- AWS-provided sample configs clamp TCP MSS on the tunnel interface to avoid fragmentation.
Equivalents
- Azure VPN Gateway (route-based) lives in
GatewaySubnet. Active-standby uses one public IP; active-active, which Microsoft recommends, uses two. Default Azure ASN for BGP is 65515. - GCP HA VPN has two interfaces with two external IPs. With tunnels from both interfaces and BGP on Cloud Router it carries a 99.99% SLA; Classic VPN is 99.9%.
They will ask next
Why prefer BGP over static routes on a cloud VPN?
BGP withdraws routes when a tunnel dies, so failover is automatic and fast. With static routes AWS relies on tunnel state alone, and any new on-prem prefix needs a manual route change.
One tunnel shows DOWN in the console all the time. Is that a problem?
Yes, it means you have no redundancy. AWS performs maintenance on one endpoint at a time and expects both tunnels up. Configure both on your device.
Traps
- Configuring only one tunnel because "it works".
- Thinking a VGW load-balances over both tunnels. It does not; a TGW with ECMP does.