AWS Site-to-Site VPN, Beyond the Basics
A working engineer's guide to how the two tunnels, IPsec negotiation, and BGP routing actually behave — and what decides whether a "connection is up" indicator means your traffic is really flowing.
If you already know that Site-to-Site VPN “creates an encrypted connection between your network and your VPC,” this article picks up from there. We’ll spend our time on what actually happens during tunnel negotiation, why every connection ships with two tunnels whether you asked for redundancy or not, how BGP path selection interacts with your on-premises router, and the monitoring signals that tell you a tunnel is “up” in name only. We’ll use a Virtual Private Gateway as the primary AWS-side endpoint for most of this discussion, calling out Transit Gateway attachment differences where they matter.
A fast recap of the endpoint decision, framed for someone choosing between Virtual Private Gateway and Transit Gateway attachment.
Site-to-Site VPN establishes an IPsec-encrypted connection between your on-premises network (or another cloud) and an AWS-side termination point. That termination point is either a Virtual Private Gateway (VGW) attached to a single VPC, or a Transit Gateway (TGW) attachment, which lets one VPN connection reach many VPCs through the transit gateway’s routing rather than being tied to just one.
Single VPC, simpler topology
A straightforward one-VPC-to-one-network connection where you don’t need to fan the connection out to multiple VPCs or share it across accounts.
Hub-and-spoke, multi-VPC, multi-account
One VPN connection terminating at the transit gateway can reach every VPC attached to it, and TGW additionally supports Equal-Cost Multi-Path (ECMP) routing across multiple VPN tunnels for higher aggregate throughput than a single VGW-based connection allows.
The other major decision this guide assumes you’ve already made is IPsec-based Site-to-Site VPN versus AWS Direct Connect. VPN runs over the public internet with variable latency and a practical per-tunnel throughput ceiling; Direct Connect is a dedicated physical link with predictable latency and much higher throughput, often used alongside a VPN connection as an automatic failover path rather than as a replacement for it.
The vocabulary intermediate Site-to-Site VPN work depends on.
Customer Gateway (CGW) — an AWS resource representing your on-premises (or other-cloud) VPN device: its public IP address, the BGP ASN if using dynamic routing, and the device type/vendor for reference. It’s a configuration object, not a piece of infrastructure AWS runs for you.
Virtual Private Gateway (VGW) — the AWS-side VPN concentrator attached to a VPC, terminating one or more VPN connections.
VPN Connection — the logical pairing of a Customer Gateway and a VGW or TGW attachment; every VPN connection is provisioned with exactly two tunnels, each terminating at a different AWS public IP address in a different underlying AWS facility, for redundancy that exists whether or not you actively use both.
Tunnel — a single IPsec-encrypted path within a VPN connection, each independently established via its own IKE negotiation and each with its own pair of public IP endpoints.
Routing Mode: Static vs BGP — static routing requires you to manually specify which CIDR ranges are reachable through the tunnel; BGP (Border Gateway Protocol) dynamic routing lets AWS and your router exchange routes automatically, propagate route changes without manual reconfiguration, and — critically — enables automatic failover between tunnels based on route advertisement rather than a manual cutover.
How the pieces fit together across the on-premises and AWS sides.
flowchart LR
subgraph OnPrem["On-Premises Network"]
Router["Customer Router
(Customer Gateway device)"]
end
subgraph AWS["AWS Side"]
T1["Tunnel 1
AWS Endpoint A"]
T2["Tunnel 2
AWS Endpoint B"]
VGW["Virtual Private Gateway"]
VPC["VPC Route Table"]
RT["Subnets & Resources"]
end
Router -->|IPsec / IKE| T1
Router -->|IPsec / IKE| T2
T1 --> VGW
T2 --> VGW
VGW --> VPC
VPC --> RT
On the on-premises side, the Customer Gateway device is whatever router or firewall appliance you operate — AWS provides sample configuration templates for common vendors, but the device itself and its uptime remain entirely your responsibility, unlike the AWS-side endpoints which AWS manages and automatically maintains for availability.
Route propagation from the VGW into your VPC’s route table can be enabled per route table, meaning routes learned over BGP (or configured statically) don’t automatically apply to every subnet’s route table unless you explicitly enable propagation for that table.
What actually happens before a single packet of your data crosses the tunnel.
Each tunnel establishes itself through a two-phase IKE (Internet Key Exchange) negotiation. IKE Phase 1 authenticates the two peers to each other (typically via a pre-shared key) and negotiates a secure channel used only to protect further negotiation — not your actual data yet. IKE Phase 2 uses that secure channel to negotiate the actual IPsec Security Associations (SAs) that will encrypt real traffic, agreeing on encryption algorithm, integrity algorithm, and Diffie-Hellman group.
Phase 1 is like two people meeting in person to agree on a private code language before writing any real letters to each other. Phase 2 is the two of them using that agreed code language to negotiate the specific cipher they’ll use for the actual correspondence that follows — nothing sensitive is exchanged until both phases are settled.
Both phases have configurable negotiation parameters (encryption algorithm, integrity algorithm, Diffie-Hellman group, and Security Association lifetime) on both the AWS and customer-gateway side — a mismatch in any one of these parameters between the two sides is one of the most common reasons a tunnel fails to establish at all, and is usually the first thing to check when a tunnel won’t come up.
The path a packet actually takes once both tunnel phases are established.
sequenceDiagram
participant App as On-Prem Application
participant CGW as Customer Gateway Device
participant Tunnel as IPsec Tunnel
participant VGW as Virtual Private Gateway
participant Res as VPC Resource
App->>CGW: Packet destined for VPC CIDR
CGW->>CGW: Route lookup selects VPN tunnel
CGW->>Tunnel: Encrypt packet (IPsec ESP)
Tunnel->>VGW: Encrypted packet over internet
VGW->>VGW: Decrypt packet
VGW->>Res: Deliver decrypted packet
Res-->>VGW: Response packet
VGW-->>Tunnel: Encrypt response
Tunnel-->>CGW: Encrypted response over internet
CGW-->>App: Decrypt & deliver response
Because the tunnel rides over the public internet rather than a dedicated circuit, packet loss, jitter, and variable latency on the underlying path directly affect your VPN traffic — this is the core trade-off against Direct Connect’s predictable, dedicated path, and it’s why latency-sensitive workloads often pair VPN with Direct Connect rather than relying on VPN alone.
Why two tunnels exist, and what actually triggers a switch between them.
The two tunnels in every VPN connection terminate at different AWS endpoints specifically so that scheduled maintenance or an unplanned issue affecting one endpoint doesn’t take down the whole connection. Whether failover between them is automatic and fast depends almost entirely on your routing mode and your on-premises router configuration.
BGP Dynamic Routing
- Automatic failover: if a tunnel’s BGP session drops, routes withdraw and traffic shifts to the surviving tunnel without manual intervention
- Supports route-based path preference (AS-path prepending, local preference) to actively steer traffic across tunnels
Static Routing
- No automatic route withdrawal on tunnel failure — failover depends entirely on your router’s own health-check and failover logic, if any exists
- Requires manual updates to route configuration whenever your network topology changes
Configuring only one of the two tunnels on the customer-gateway side defeats the redundancy the service was designed to provide. AWS performs periodic maintenance on tunnel endpoints, and a connection with only one active tunnel will experience a full outage during that maintenance window instead of a transparent failover.
Why a single VPN connection has a hard throughput ceiling, and how to get past it.
Each individual tunnel has a practical throughput ceiling (commonly cited around 1.25 Gbps), and — importantly — a single connection cannot use both of its tunnels simultaneously for the same traffic flow to increase aggregate throughput unless the AWS-side termination point is a Transit Gateway with Equal-Cost Multi-Path (ECMP) routing enabled. With ECMP, multiple VPN connections (each contributing tunnels) can be load-balanced across, multiplying the effective aggregate throughput beyond what a single VGW-attached connection can offer.
Scaling Beyond One Connection’s Ceiling
A common pattern for throughput-hungry hybrid workloads is provisioning multiple Site-to-Site VPN connections into the same Transit Gateway and letting ECMP distribute flows across all of them — this is a materially different scaling lever than simply hoping the two tunnels within one connection will share load, since VGW-attached connections do not do this automatically.
What’s actually protecting the data in transit, layer by layer.
- IPsec encryption — every packet traversing the tunnel is encrypted per the negotiated IKE Phase 2 parameters, protecting confidentiality over the public internet path.
- Pre-shared key or certificate authentication — authenticates the two tunnel endpoints to each other before any Phase 2 negotiation occurs, preventing an unauthorized peer from establishing a tunnel in the first place.
- VPC security groups and NACLs — apply on the AWS side exactly as they would for any other traffic source; a VPN tunnel being “up” grants network reachability, not an exemption from your existing security group rules.
- Route table scoping — enabling route propagation selectively per subnet, rather than blanket-wide, limits which parts of your VPC are actually reachable from the on-premises side.
An established, encrypted tunnel only guarantees confidentiality and authenticated endpoints — it says nothing about which resources on either side should actually be allowed to talk to which. Security groups, NACLs, and selective route propagation remain the mechanisms that enforce that.
The signals that tell you whether a tunnel is genuinely healthy, not just nominally “up.”
| Metric / Signal | What It Tells You | Watch For |
|---|---|---|
| TunnelState | Whether the IPsec tunnel is currently up (1) or down (0) | A tunnel repeatedly flapping between up and down usually points to a Phase 1/2 parameter mismatch or an unstable on-prem link |
| TunnelDataIn / TunnelDataOut | Bytes actually flowing through each tunnel | A tunnel showing “up” state but zero data flow often means routing, not the tunnel itself, is misconfigured |
| BGP session state (on-prem router) | Whether dynamic routing is actively exchanging routes | A down BGP session with an “up” IPsec tunnel means encryption is fine but no routes are being learned or advertised |
| Route table propagated routes | Which CIDRs are actually reachable through the VPN from a given subnet | Missing expected routes usually traces back to route propagation not being enabled on that specific route table |
The distinction between “tunnel state is up” and “traffic is actually flowing correctly” is one of the most common sources of confusion during VPN troubleshooting — a healthy IPsec tunnel with a broken BGP session or an unpropagated route will still show a green tunnel status while delivering zero usable connectivity.
How Site-to-Site VPN is provisioned and combined with other hybrid connectivity tools.
Customer Gateways, VPN connections, and route propagation settings are typically provisioned through Infrastructure as Code so that both tunnel configurations, BGP ASN values, and route table associations stay consistent and reviewable — a hand-configured VPN connection is one of the easier pieces of network infrastructure to accidentally leave asymmetric between its two tunnels.
Transit Gateway Attachment
Terminating VPN connections at a Transit Gateway rather than individual VGWs lets a single hybrid connection reach many VPCs, and is the natural fit once you’re managing more than one or two VPCs needing on-premises connectivity.
VPN as Direct Connect Failover
A common resilient design uses Direct Connect as the primary path and Site-to-Site VPN as an automatic BGP-based failover, so a Direct Connect outage degrades performance rather than causing a full connectivity loss.
What resilient hybrid connectivity design looks like — and the mistake that quietly removes your redundancy.
Dual-tunnel, BGP-first design — configuring both tunnels on the customer-gateway side and using BGP rather than static routes is the standard resilient baseline, since it lets AWS-side maintenance or transient failures resolve themselves without a human intervening.
Multi-connection ECMP for throughput — for workloads outgrowing a single connection’s ceiling, provisioning multiple VPN connections into the same Transit Gateway with ECMP is the correct scaling lever, rather than trying to force more throughput out of one connection’s two tunnels.
Pattern
Configuring only the primary tunnel on the on-premises router and leaving the secondary tunnel’s configuration unset “to keep things simple.”
Why It Fails
AWS performs periodic maintenance on individual tunnel endpoints as part of normal operations. A connection with only one configured tunnel has no failover path during that maintenance window and experiences a full, avoidable outage that the service’s built-in redundancy was specifically designed to prevent.
What To Do Instead
Configure both tunnels identically on the customer-gateway device from the start, and verify with a controlled test (or by observing a real maintenance event) that failover actually behaves as expected, rather than assuming it does.
Advantages
- Fast to provision — often usable within minutes, with no physical circuit installation required
- Built-in dual-tunnel redundancy at the AWS side by default
- BGP dynamic routing enables automatic failover and flexible path preference
- Significantly lower cost than a dedicated Direct Connect circuit for moderate bandwidth needs
Disadvantages & Trade-offs
- Traffic rides the public internet, inheriting its variable latency and jitter
- Per-tunnel throughput ceiling limits single-connection bandwidth without ECMP across multiple connections
- On-premises router configuration and uptime remain entirely the customer’s responsibility
- Static routing sacrifices automatic failover and flexible path control that BGP provides
Always configure both tunnels
Treat the second tunnel as mandatory, not optional — it is the entire mechanism behind the service’s advertised availability.
Prefer BGP over static routing wherever your router supports it
Static routing works, but it trades away automatic failover and forces manual updates on every topology change — a real ongoing operational cost.
Enable route propagation deliberately, per route table
Don’t assume a learned BGP route is automatically usable everywhere in your VPC — check which route tables actually have propagation enabled.
Match IKE/IPsec parameters exactly on both sides
Encryption algorithm, integrity algorithm, Diffie-Hellman group, and SA lifetime mismatches are the single most common reason a tunnel fails to establish — check these first during troubleshooting.
Monitor TunnelDataIn/Out, not just TunnelState
A tunnel can report “up” while carrying zero real traffic due to a routing misconfiguration — data flow metrics catch what state alone hides.
Rapid hybrid connectivity for M&A integration
Organizations integrating a newly acquired company’s network commonly reach for Site-to-Site VPN first, since it can be stood up in minutes compared to the lead time of provisioning a new Direct Connect circuit.
Direct Connect backup path
Enterprises with an existing Direct Connect circuit frequently layer a Site-to-Site VPN connection alongside it purely as an automatic BGP-based failover path for resilience against a Direct Connect outage.
Multi-cloud and branch-office connectivity
Because a Customer Gateway simply represents any device with a public IP and IKE/IPsec support, Site-to-Site VPN is commonly used to connect AWS not just to on-premises data centers but to another cloud provider’s network or to distributed branch offices.
Carry This Forward
- Every VPN connection ships with two tunnels by default — configuring only one defeats the built-in redundancy the service is designed to provide.
- Tunnel establishment is a two-phase IKE negotiation; mismatched Phase 1/2 parameters are the most common reason a tunnel won’t come up.
- BGP dynamic routing enables automatic failover and flexible path preference; static routing requires manual intervention on every change.
- A single connection’s two tunnels don’t share load automatically — real throughput scaling requires multiple connections and ECMP on a Transit Gateway.
- Route propagation must be enabled per route table; a learned route isn’t automatically usable everywhere in your VPC.
- An “up” tunnel state only confirms encryption is working — data flow metrics and BGP session health reveal whether traffic is actually routing correctly.
- VPN rides the public internet and inherits its variable latency; pairing it with Direct Connect is a common pattern for both performance and resilience.