AWS Networking · Foundations12 min read

VPN Basics: Why It Exists, and How We Got to Site-to-Site

Before you build a Site-to-Site VPN, understand why VPNs were invented at all, and why, of all the ways to connect two networks, Site-to-Site became the elegant answer.

From your mentor

Most people learn Site-to-Site VPN as a checklist of steps. You'll learn it as the end of a story, once you see the problem it solves and what it replaced, the whole thing finally makes sense.

A VPN is just a way to make two separate networks behave like one, privately.

In 10 minutes you’ll see why VPNs were invented and how we got to Site-to-Site. You do NOT need crypto details yet.

Pick your way in, same idea, 5 doors

Two networks in two places, and you want them to talk as if they’re in the same room, without the whole internet listening in. A VPN is the private tunnel that makes that happen.

Next: see why, of all the options, Site-to-Site became the elegant answer.

Two networks, one hostile internet

The whole story starts with one need: two private networks, your office and your AWS VPC, have to talk, but the only road between them is the wide-open public internet.

In plain English

Imagine two office buildings across town that need to share files. You could shout across the street (public, anyone hears you), dig your own private tunnel between them (secure but absurdly expensive), or send sealed, unbreakable envelopes through the normal postal service. That last one is a VPN, and everything below is how we arrived at it.

What a VPN actually does in the background

Strip away the branding and a VPN is three things: tunnelling, encryption, and authentication. Here's the part nobody shows you, what happens to a single packet.

A VPN takes your normal packet and wraps it inside another packet (tunnelling), encrypts the original so no one in between can read it, and authenticates both ends so each trusts the other. In IPsec “tunnel mode,” the entire original packet is sealed inside a new one:

Your original packet

IP · 172.16.1.5 → 10.0.1.20your data

IPsec tunnel mode wraps the whole packet and encrypts it

What actually crosses the internet

NEW outer IP · CGW-EIP → AWS-endpointESP 172.16.1.5 → 10.0.1.20 · data

To anyone sniffing the internet, only the outer header (two gateway IPs) is visible, the real source, destination, and data are sealed inside an encrypted ESP envelope. That wrap-and- encrypt is the entire trick behind “VPN.”

That’s the magic word: tunnel

The packet still travels the same hostile public internet as everything else, but wrapped so that to any onlooker it’s meaningless noise. “Virtual Private Network” = a private conversation simulated over a public wire.

How we got to Site-to-Site

Site-to-Site VPN didn't appear from nowhere. It's the survivor of an evolution, where each era fixed the pain of the one before it.

Just expose it
Put services on public IPs, anyone can reach them. Dead simple.
The catch → Anyone can attack them too. No privacy, no trust.
Lease a private line
Rent a dedicated physical circuit between sites. Genuinely private and reliable.
The catch → Eye-watering cost, weeks to provision, rigid.
VPN over the internet
Encrypt a tunnel across the cheap public internet, private at internet prices. The VPN is born.
The catch → But who runs the tunnel, and for whom?
Client (remote-access) VPN
Each user’s device runs a VPN client to reach the network. Perfect for individual remote workers.
The catch → Doesn’t scale to “connect a whole office”, software on every device, every user.
Site-to-Site VPN
The gateway at each site runs ONE tunnel for everyone behind it. Devices need nothing, transparent and always-on.
The catch → You still run and patch the gateways, and it rides the variable internet.
Managed Site-to-Site (AWS)
AWS runs the cloud-side gateway: two tunnels across AZs, auto failover, BGP, scale via Transit Gateway, even acceleration.
The catch → Need guaranteed bandwidth? That’s where Direct Connect comes in.

Nice, that’s the win

See the pattern? Every step kept the win and killed the catch. Public exposure was simple but unsafe; leased lines were safe but ruinously expensive; VPNs made “private” affordable; and Site-to-Site made it effortless for an entire network instead of one device at a time.

Two kinds of VPN, and why they split

Once VPNs existed, they forked by who they connect: a single person, or a whole network. Mixing these up is the most common beginner confusion.

Client (remote-access) VPN

• Connects individual users / devices
• A VPN client app on every device
• Client ↔ server, on-demand, per user
• Best for remote workers, laptops, BYOD
• AWS service: AWS Client VPN

Site-to-Site VPN

• Connects entire networks (gateway ↔ gateway)
• Nothing installed on end devices
• Always-on, transparent to every device behind it
• Best for office / datacentre ↔ AWS
• AWS service: AWS Site-to-Site VPN

The deciding question

Connecting a person (a laptop, a remote worker)? That’s a client / remote-access VPN, software on the device. Connecting a network (an office, a datacentre) to AWS? That’s Site-to-Site, handled once at the gateway, invisible to every device behind it.

Why Site-to-Site is the elegant answer

For connecting networks, Site-to-Site wins on four counts, and they're exactly the pains the earlier eras couldn't solve.

Transparent

End devices need zero configuration, no client, no login. They send normal traffic; the gateways quietly encrypt and route it. A whole office “just reaches” AWS.

Always-on & one config

The tunnel lives at the gateway, configured once, up 24/7, not negotiated per device, per session. Add a server to the office and it can reach AWS instantly.

Cheap & fast to stand up

It rides the public internet, so there’s no leased-line cost or wait, minutes and ~$0.05/hour, versus weeks and thousands for dedicated circuits.

Managed & resilient on AWS

AWS runs the cloud-side gateway with two tunnels across AZs, automatic failover, and BGP, scaling to many VPCs via Transit Gateway, the resilience leased lines gave you, without the price.

In plain English

That’s the punchline: Site-to-Site VPN is “private like a leased line, cheap like the internet, invisible like it isn’t even there.” When you need guaranteed bandwidth and latency, you graduate to Direct Connect, but for most “connect our network to AWS,” Site-to-Site is the sweet spot.

Where to go next

Now that the why makes sense, go see the how, and practise it safely.

Next up

Site-to-Site VPN, Follow One Packet (deep dive)

The full build: the two gateways, the IKE/IPsec handshake, why there are two tunnels, static vs BGP, throughput, and cost.

Then break it safely

Try the VPN Simulator, make the real configuration choices (Customer Gateway IP, pre-shared key, security-group ports, route propagation) and watch the tunnel come up or fail, with a diagnosis pointing at your exact mistake. No AWS account, no risk.