On this page
TL;DR
Watch traffic ride two IPsec tunnels across the public internet and decrypt inside AWS. Then get the consultant's call on when site-to-site VPN fits, the production gotchas, and when to reach for something else.
When "just connect them" stops being simple
Who this is for
You can spin up a VPC, but when someone says "connect our data center to AWS, securely," you freeze. By the end of this you should be able to whiteboard a site-to-site VPN, explain its trade-offs, and say when to reach for something else.
You have two private networks: your on-prem data center and your AWS VPC. Between them sits the public internet, which you do not trust and do not control. You cannot just route private traffic across it in clear text, anyone on the path could read it. So you need a way to make the open internet behave like a private cable.
A site-to-site VPN is an encrypted tunnel that makes the public internet behave like a private wire between your office and your VPC.
See it work
Press play. Watch a packet leave on-prem, get encrypted at the customer gateway, cross the internet through one of two IPsec tunnels, and get decrypted at the AWS side. Then break a tunnel to see failover, and turn encryption off to see exactly why the tunnel exists.
Site-to-Site VPN, live
On-prem network
your data center
Public internet
untrusted
AWS VPC
private subnet
Customer Gateway
encrypts here
Virtual Private GW
decrypts here
Break a tunnel to watch traffic fail over. Turn encryption off to see what the internet would otherwise read.
How it actually works
- 1
Two gateways
A customer gateway (your side: the on-prem router or firewall) and a virtual private gateway, or transit gateway, on the AWS side.
- 2
Two IPsec tunnels
AWS provisions two tunnels per connection, to two different AWS endpoints, so a single tunnel failing does not take you offline.
- 3
Encrypt, encapsulate, send
Traffic is encrypted with IPsec at the customer gateway, wrapped up, and sent across the public internet as unreadable noise.
- 4
Decrypt and route
The AWS gateway decrypts the traffic and routes it into your VPC, as long as the route table points the on-prem CIDR at the gateway.
- 5
Routing: BGP or static
Dynamic routing (BGP) advertises networks automatically and handles failover cleanly. Static means you list every prefix by hand, fine for tiny setups, painful at scale.
Why teams reach for it
- Fast to stand up: hours, not the weeks a dedicated circuit takes.
- Cheap: it rides commodity internet, no leased line to pay for.
- Encrypted by default: IPsec is the whole point, the data is protected in transit.
- Great for branch offices and as a backup to a Direct Connect link.
The gotchas that bite in production
- 1Performance is variable. It runs over the public internet, so latency wanders and throughput is capped per tunnel (around 1.25 Gbps). You cannot promise low, steady latency on a VPN.
- 2One customer gateway is a single point of failure. Two tunnels protect the AWS side, but if your one on-prem device dies, you are down. Real HA needs two customer gateways.
- 3Overlapping CIDRs break everything. If on-prem and your VPC use the same address range, routing cannot tell them apart. Plan address space first.
- 4Static routing does not scale. Past a handful of networks, switch to BGP or you will hand-maintain route lists forever.
- 5It depends on the internet. Your ISP having a bad day is your VPN having a bad day.
Alternatives, and when to pick them
| Option | Reach for it when |
|---|---|
| Site-to-Site VPN | You want a fast, cheap, encrypted link and variable performance is acceptable. Branch offices, backups, getting started quickly. |
| Direct Connect | You need consistent low latency and high, predictable throughput. A dedicated circuit, weeks to provision and more expensive, but rock steady. |
| Transit Gateway + VPN | Many VPCs or accounts need on-prem access. Attach the VPN to a transit gateway hub instead of building a separate VPN per VPC. |
| Client VPN | Individual people (laptops) need into the VPC, not a whole site. A different tool for a different job. |
The consultant's answer
If someone puts you on the spot
- It is an encrypted IPsec tunnel that turns the public internet into a private link between on-prem and your VPC.
- Always two tunnels for failover; use two customer gateways for genuine high availability.
- Pros: fast, cheap, encrypted. Cons: rides the internet, so variable performance and capped throughput.
- Pick Direct Connect for predictable performance, Transit Gateway when many networks must connect, Client VPN for individual users.
- First checks on any design: no overlapping CIDRs, BGP over static at scale, and a plan for when the internet misbehaves.
Want the layer underneath this? Solidify subnets, route tables, and gateways in VPC fundamentals, then get your hands dirty in the networking lab.
You need to connect networks or a user to AWS securely. Site-to-site VPN, or something else?
Check your understanding
1. In a site-to-site VPN between an on-prem data center and an AWS VPC, where does a packet get encrypted and decrypted?
2. Why does a site-to-site VPN exist at all, rather than just routing private traffic across the internet directly?
Frequently asked questions
What does a site-to-site VPN actually do?
It is an encrypted tunnel that makes the public internet behave like a private wire between two whole networks, such as your on-prem data center and your AWS VPC. Traffic is encrypted at the customer gateway, crosses the internet through IPsec tunnels, and is decrypted on the AWS side.
Why are there two IPsec tunnels?
The two tunnels provide redundancy, so if one tunnel breaks, traffic can fail over to the other. This keeps the connection between your networks available rather than dropping when a single tunnel goes down.
What happens if encryption were turned off?
The whole point of the tunnel is that the public internet is a path you do not trust or control, where anyone could read clear-text private traffic. Without encryption the traffic would be exposed, which is exactly why the tunnel exists.
Was this article helpful?
Want to go deeper?
This article covers concepts taught hands-on in the Cloud Engineer and DevOps career paths, with real terminal labs, production scenarios, and structured lessons.