AWS Networking · Deep Dive16 min read

Site-to-Site VPN: Follow One Packet

Forget the bullet-point overview. We'll follow a single packet from an office laptop all the way into a VPC, and every concept will reveal itself along the trip.

From your mentor

VPN sounds mysterious until you watch one packet make the journey. Encrypt, cross the internet, decrypt, arrive. Hold that picture and every detail, tunnels, IKE, BGP, just slots onto the path.

A Site-to-Site VPN is just an encrypted tunnel between your office and your VPC, over the public internet.

In 12 minutes you’ll follow one packet end to end. You do NOT need to memorize IKE parameters yet.

Pick your way in, same idea, 5 doors

You want your office network and your AWS network to talk as if they’re one. A Site-to-Site VPN is a secret, locked tunnel through the public internet between them, so traffic stays private even though it travels the open road.

Next: watch a single packet leave the office and arrive inside the VPC.

The whole trip, in one picture

A Site-to-Site VPN connects your on-prem network to a VPC over the public internet, securely, so the two behave like one private network. Here's a packet making that trip:

Office laptop

10.10.0.5

Customer Gateway

your router

Public internet

encrypted

AWS VPN endpoint

VGW / TGW

EC2 in the VPC

10.0.1.20

IPsec

One packet: it leaves the laptop in plaintext, your Customer Gateway encrypts it, it crosses the public internet inside an IPsec tunnel, the AWS endpoint decrypts it, and it arrives at the EC2 instance as if they shared a LAN. Every section below is one leg of this trip.

In plain English

The magic word is tunnel. The packet still travels the ordinary, hostile public internet, but wrapped in encryption so strong that to anyone in between it’s meaningless noise. On-prem and AWS act like they’re on the same LAN, even though they’re cities apart.

The two ends of the tunnel

Every VPN has a device at each end. Your side is always the Customer Gateway; the AWS side is one of two things.

End	What it is	Notes
Customer Gateway (CGW)	A resource representing YOUR on-prem device (router/firewall)	You give AWS its public IP (or cert) and BGP ASN
Virtual Private Gateway (VGW)	The AWS endpoint attached to a single VPC	Simplest; one VPC; no accelerated VPN
Transit Gateway (TGW)	The AWS endpoint for many VPCs at once	Supports ECMP active/active + accelerated VPN

Pick the AWS side by scale

One VPC, simple need → VGW. Multiple VPCs, or you want active/active bandwidth and acceleration → terminate the VPN on a Transit Gateway instead.

How the tunnel gets built: IKE & IPsec

Before any data flows, the two ends negotiate. It happens in two phases, trust first, then encryption.

Your customer gatewayAWS VPN endpoint

Phase 1, IKE SA (build a secure channel)

Propose ciphers + prove identity (pre-shared key or certificate)

Agree on ciphers, authenticate back, secure management channel up

Phase 2, IPsec SA (build the data tunnel)

Negotiate the keys that will encrypt the actual traffic

Tunnel established, data now flows encrypted

IKE (IKEv2) builds trust first, then IPsec encrypts every packet. Keys are rotated automatically (rekey), and Dead Peer Detection notices if the other end goes quiet.

What you actually configure

In practice you set a pre-shared key (or certificate), the IKE version (IKEv2), and the allowed ciphers/DH groups. AWS hands you a downloadable config for your exact device model, you rarely hand-craft this.

Why there are always two tunnels

A single VPN connection isn't one tunnel, it's two, on purpose. This trips up everyone the first time.

Customer Gateway

Tunnel 1 · AZ-a

Tunnel 2 · AZ-b

AWS endpoints

Every VPN connection is two tunnels, terminating in two different AZs. If one drops, traffic fails over to the other. With BGP on a Transit Gateway both run at once (ECMP).

Nice, that’s the win

AWS gives you redundancy for free: two tunnels to two Availability Zones. The classic beginner mistake is configuring only one side and wondering why failover doesn’t work, always configure both tunnels on your device. With BGP on a Transit Gateway, both carry traffic at once instead of one sitting idle.

Static vs BGP, how each end learns the routes

The tunnel is up, but how does each side know which networks live on the other? Two options. Toggle them:

Dynamic routing (BGP)

Routes are exchanged automatically, add a subnet on-prem and AWS learns it.
Fast failover via BGP liveness + Dead Peer Detection.
Enables ECMP across tunnels on a Transit Gateway for higher bandwidth.
AWS-recommended whenever your device speaks BGP.

The interview-favourite reason for BGP

BGP isn’t just about avoiding manual routes, its liveness detection drives fast failover to the second tunnel and unlocks ECMP. Static routing can’t do either. If your device speaks BGP, use it.

How fast can it go?

A VPN rides the public internet, so performance is inherently variable, but the hard ceilings and the ways around them are worth knowing.

Dimension	Value
Per tunnel (standard)	Up to ~1.25 Gbps
Scaling with ECMP (on TGW, BGP only)	Aggregate many tunnels, up to ~50 Gbps
Large/5 Gbps connection option	Higher single-connection throughput (priced higher)
Accelerated VPN	Routes via AWS Global Accelerator to the nearest edge, TGW only, not VGW

Worth pondering

Two levers when a VPN is too slow: add tunnels and let ECMP aggregate them (needs BGP + Transit Gateway), or turn on accelerated VPN so traffic hops onto the AWS backbone at the nearest edge instead of crossing the open internet the whole way. If you need guaranteed bandwidth, that’s the signal to consider Direct Connect instead.

The cost model

Cheap to start, with the usual data-transfer tail.

Charge	Amount
VPN connection	~$0.05 per connection-hour (standard)
5 Gbps connection option	~$0.60 per hour
Data transfer out	Standard egress rates apply

Why teams start here

At ~$36/month a standard VPN is a fraction of Direct Connect and sets up in minutes. Many run a VPN as the cheap primary or as a low-cost backup to a Direct Connect link.

The climb

From a fragile single tunnel to a resilient, fast hybrid link.

On-prem ↔ AWS linkthe climb

Rung 0 · Naive
Single static tunnel to a VGW
Configure one tunnel, static routes, terminating on a VGW for one VPC.
One tunnel = no failover; static routes don’t move on failure; can’t scale bandwidth.
Better
Both tunnels + BGP
Configure both tunnels on your device with BGP dynamic routing.
Automatic route exchange and fast failover, the baseline a production VPN should meet.
Best practice today
VPN on a Transit Gateway, ECMP + accelerated
Terminate on a TGW with BGP, run both tunnels active/active via ECMP, and enable accelerated VPN; keep a second connection for resilience.
Higher aggregate bandwidth, best path over the AWS backbone, and reaches all your VPCs through one hub.

How this shows up in interviews

Interview angle

“Connect our on-prem data centre to AWS securely and reliably. Walk me through it.”

How to answer it

Trace the packet: the two gateways, IPsec, the two tunnels, BGP for failover, and when you'd escalate to Direct Connect. Mentioning ECMP/accelerated marks senior.

1A Customer Gateway for our on-prem router and an AWS endpoint, a VGW for one VPC, or a Transit Gateway if multiple VPCs.
2An IPsec Site-to-Site VPN with both tunnels configured, terminating in two AZs for redundancy.
3BGP dynamic routing so routes propagate automatically and failover is fast, not static.
4If we need more than ~1.25 Gbps/tunnel, terminate on a TGW and aggregate tunnels with ECMP, or enable accelerated VPN.
5For guaranteed bandwidth/latency, add Direct Connect and keep the VPN as encrypted backup.

Green flags

Configures BOTH tunnels and uses BGP
Knows VPN is over the internet (variable) vs Direct Connect (dedicated)
Escalates to ECMP/accelerated/DX when bandwidth matters

Red flags

Sets up one tunnel and calls it HA
Uses static routing and expects fast failover
Thinks a VPN guarantees bandwidth

Q.Why does a VPN connection have two tunnels?

A.Redundancy, the two tunnels terminate in two different AZs on the AWS side; one fails, traffic moves to the other.

You must configure BOTH tunnels on your device.
Most “VPN isn’t HA” problems are a missing second tunnel.

They’re checking: That you configure both tunnels, not just one.

Q.Static vs BGP routing, which and why?

A.Use BGP whenever your device supports it; static only as a fallback.

Static

BGP

Routes entered by hand

Routes exchanged automatically

Slow/manual failover

Fast failover via liveness checks

Single tunnel

ECMP across tunnels for bandwidth

They’re checking: That you default to BGP for auto-routing, fast failover, and ECMP.

Q.A single tunnel caps at ~1.25 Gbps, how do you get more?

A.Terminate the VPN on a Transit Gateway and ECMP across multiple tunnels (needs BGP), up to ~50 Gbps.

ECMP requires BGP; accelerated VPN (Global Accelerator) helps with jitter.
Beyond that, Direct Connect for dedicated bandwidth.

They’re checking: That you know one tunnel is capped and ECMP-on-TGW is the scale path.

Q.VPN vs Direct Connect?

A.VPN: encrypted internet path, minutes, cheap, variable. DX: a private line, consistent, but costly and weeks to provision.

Site-to-Site VPN

Direct Connect

Encrypted over the internet

Dedicated private line

Minutes, ~$0.05/hr

Weeks, costlier

Variable performance

Consistent, high-bandwidth

They’re checking: That you pair them (DX primary, VPN backup) rather than treat it as either/or.

Your turn, stand up a VPN connection

You can create the AWS side without a real on-prem device (use a placeholder public IP). It bills hourly, so tear it down after.

Now do it in your own account

~20 min Not free, a VPN connection bills ~$0.05/hr. Tear down today.

Stand up the AWS side of a VPN, even without a real on-prem device (use a placeholder public IP). It bills hourly, so tear it down after.

Before you start

3 to have ready

Your IAM admin user from Lesson 1.

AWS CLI v2 signed in.

aws sts get-caller-identity

The VPC from the networking lessons, and a placeholder on-prem public IP to explore (real tunnels need a real device).

1
Create a Customer Gateway representing your on-prem device.
Free tier
Your terminal
aws cli
```
$ aws ec2 create-customer-gateway --type ipsec.1 --public-ip 203.0.113.10 --bgp-asn 65000
```
AWS docs: create-customer-gateway
You should see: a CustomerGatewayId.
2
Create a Virtual Private Gateway and attach it to your VPC (or use a TGW).
Free tier
Your terminal
aws cli
```
$ aws ec2 create-vpn-gateway --type ipsec.1
```
AWS docs: create-vpn-gateway
You should see: a VpnGatewayId, then attached to the VPC.
3
Create the VPN connection, this provisions the two tunnels.
Costs money
Your terminal
aws cli
```
$ aws ec2 create-vpn-connection --type ipsec.1 --customer-gateway-id <cgw-id> --vpn-gateway-id <vgw-id>
```
AWS docs: create-vpn-connection
You should see: a VpnConnectionId with two tunnels provisioned.
Billing starts here. Add --options for static, or omit for BGP. Tear down today.
4
Download the device configuration and inspect what AWS generated.
Free tier
Console → VPC → Site-to-Site VPN connections → Download configuration
You should see: two tunnel endpoints, pre-shared keys, and BGP details.

Last step: tear it down

Once you’ve seen it work, remove everything so nothing keeps billing.

A VPN connection bills ~$0.05/hour, delete it the same day you create it.

Delete the VPN connection first.

aws ec2 delete-vpn-connection --vpn-connection-id <vpn-id>

Then detach + delete the Virtual Private Gateway, and delete the Customer Gateway.

Without a real on-prem device the tunnels stay DOWN, that’s expected, you’re only exploring the AWS side.

Next up

Related deep dives

Site-to-Site VPN pairs with Transit Gateway (terminate here for ECMP + many VPCs) and Direct Connect (dedicated alternative). Both have their own pages.