An AWS Site-to-Site VPN joins your VPC to one other network (an office, a data center, another cloud) across the public internet. Traffic is encrypted with IPsec, so both sides talk over private IPs as if they shared a LAN. Typical reasons to build one:
| Use case | What the VPN gives you |
|---|---|
| Hybrid apps | An app in AWS reaches a database still on-premises |
| Gradual migration | Both sides stay connected while workloads move |
| Private admin access | Reach EC2 over private IPs; no SSH/RDP open to the internet |
| Multi-cloud | A service in Azure or GCP calls a private service in AWS |
Four resources, two tunnels
AWS models a VPN as four resources: the VPC, an AWS-side gateway, a customer gateway record describing the remote device, and the VPN connection joining them. Every connection gets two IPsec tunnels to two AWS endpoints in different AZs; configure both.
| Component | Role |
|---|---|
| VPC | Your private network in AWS, e.g. 10.0.0.0/16 |
| Virtual Private Gateway (VGW) | AWS-side VPN router, attached to exactly one VPC |
| Customer Gateway (CGW) | AWS record of the remote device: public IP and optional BGP ASN |
| Customer gateway device | The real firewall/router on the other side (Fortinet, Cisco, Azure VPN Gateway etc.) |
| VPN connection | Two IPsec tunnels between gateway and CGW, each with its own pre-shared key and 169.254.x.x/30 inside IPs |
The AWS-side gateway is your first choice:
| Option | Trade-off |
|---|---|
| Virtual Private Gateway | Simplest and cheapest for one VPC; standard 1.25 Gbps tunnels only |
| Transit Gateway | Shares one VPN across many VPCs; unlocks 5 Gbps Large Bandwidth Tunnels and ECMP, but adds attachment and per-GB fees |
Routing is the second:
| Option | Trade-off |
|---|---|
| Static | Works on any device; you type remote CIDRs by hand and failover is slower |
| Dynamic (BGP) | Routes exchanged and failed over automatically; device must speak BGP and you manage ASNs |
This guide uses a VGW with either routing mode. Encryption handshakes use IKEv1 or IKEv2 (Phase 1 builds the control channel, Phase 2 the data tunnel).
One office, one VPC
The worked example connects an office LAN to one VPC through a VGW. Traffic leaves the office firewall, crosses the internet in tunnel 1 (tunnel 2 on standby), and lands on the EC2 instance.
Office network 192.168.1.0/24 AWS VPC 10.0.0.0/16 ┌──────────────────────────────┐ ┌──────────────────────────────┐ │ Office PC 192.168.1.50 │ │ EC2 10.0.1.25 (private) │ │ Office firewall (CGW device) │ tunnel 1 │ VGW prod-vgw │ │ public IP 203.0.113.10 │◀══ active ══▶│ 2 AWS tunnel endpoints │ │ = customer gateway office-cgw │ tunnel 2 │ route table: │ │ │◀══ backup ══▶│ 192.168.1.0/24 - prod-vgw │ └──────────────────────────────┘ └──────────────────────────────┘ └──────── public internet, IPsec encrypted ────────┘ | Item | Example value |
|---|---|
| Office LAN | 192.168.1.0/24 |
| Office firewall public IP | 203.0.113.10 |
| VPC CIDR | 10.0.0.0/16 |
| Test EC2 instance | 10.0.1.25, private subnet |
Before starting, confirm the non-negotiables:
| Prerequisite | Why it matters |
|---|---|
| Non-overlapping CIDRs | Overlapping ranges can't be routed over the VPN; fixing it later means re-addressing |
| Static public IP on the remote device | The customer gateway record is pinned to it |
| VPN-capable device and admin access | Someone must apply the AWS config on the other side |
| AWS permissions for VPC resources | Needed to create gateways, the connection and routes |
| Routing choice made | Static vs BGP changes steps 1, 4 and the remote config |
Five console steps, in order
Everything lives in the VPC console > Virtual private network (VPN). Each step uses what the previous one created, so keep the order. Both tunnels will read DOWN until the remote side is configured; that's expected.
| Step | Console path | What to set |
|---|---|---|
| 1. Customer gateway | Customer gateways - Create | Name office-cgw; IP 203.0.113.10; BGP ASN 65000 (or your router's ASN) |
| 2. Virtual private gateway | Virtual private gateways - Create | Name prod-vgw; Amazon default ASN 64512 (must differ from the CGW's) |
| 3. Attach | Select VGW - Actions - Attach to VPC | Pick the 10.0.0.0/16 VPC; wait for Attached |
| 4. VPN connection | Site-to-Site VPN connections - Create | Name office-to-aws; target prod-vgw; CGW office-cgw; routing Static (prefix 192.168.1.0/24) or Dynamic; leave tunnel PSKs/inside CIDRs blank so AWS generates them |
| 5. Routing & access | Route tables, Security groups, NACLs | Enable route propagation for prod-vgw (or static route 192.168.1.0/24 - prod-vgw); allow 192.168.1.0/24 in the instance's security group; check custom NACLs |
Customer gateways - Create
Virtual private gateways - Create
wait for Attached
Step 4's Local / Remote IPv4 CIDR fields decide which traffic may enter the tunnel (AWS calls the on-prem side local, the AWS side remote):
| Option | Trade-off |
|---|---|
Leave defaults 0.0.0.0/0 | Works for route-based devices; least to get wrong |
Narrow to 192.168.1.0/24 (local) and 10.0.0.0/16 (remote) | Required by many policy-based firewalls; must be updated when networks grow |
Note: match the vendor's tunnel requirements before downloading the config. Many devices and clouds insist on specific values (a single IKE version, fixed lifetimes, one DH group). AWS defaults accept a broad set, so narrow them to what the remote side requires: set them under Advanced options while creating the connection, or afterwards via VPN connection > Actions > Modify VPN tunnel options, one tunnel at a time (each tunnel restarts briefly while it updates). Do this before you download the configuration file, and check the file reflects the values.
| Tunnel option | AWS default | Typical vendor requirement |
|---|---|---|
| IKE version | IKEv1 and IKEv2 | One only, e.g. ikev2 |
| Phase 1 lifetime | 28,800 s | Must equal the remote value, e.g. 28,800 s |
| Phase 2 lifetime | 3,600 s | Must equal the remote value, e.g. 3,600 s |
| Phase 1 / 2 encryption | AES-128, AES-256 (and GCM variants) | One fixed cipher, e.g. AES-256 |
| Phase 1 / 2 integrity | SHA-1, SHA-2 (256/384/512) | One fixed hash, e.g. SHA-256 |
| Phase 1 / 2 DH groups | Several (2, 14–24; 5 also in Phase 2) | One group, e.g. 14 |
| DPD timeout / action | 30 s / Clear | Often Restart |
| Startup action | Add (remote side initiates) | Start, if the device won't initiate |
The remote side mirrors AWS
Select the connection - Download configuration - pick vendor, platform, software and IKE version (or Generic). The file holds settings for both tunnels. Every value below must match exactly on both ends; one mismatch keeps a tunnel down.
| Setting | Example |
|---|---|
| AWS outside IPs (one per tunnel) | Tunnel 1 3.x.x.x, Tunnel 2 52.x.x.x |
| Your public IP | 203.0.113.10 |
| Pre-shared key (one per tunnel) | Long random string from the file |
| IKE version | IKEv2 (preferred) |
| Phase 1 / Phase 2 crypto | AES-256 · SHA-256 · DH/PFS group 14 |
| Inside tunnel IPs | 169.254.10.1/30 (AWS) · 169.254.10.2/30 (you) |
| BGP ASNs (dynamic only) | AWS 64512 · you 65000 |
| Networks | 192.168.1.0/24 ↔ 10.0.0.0/16 |
The device also needs four things the file won't do for you:
| Requirement | Why |
|---|---|
| Both tunnels configured | AWS takes one tunnel down at a time for endpoint maintenance; a single-tunnel setup goes dark during it |
| UDP 500, UDP 4500, ESP open to AWS | IKE, NAT traversal and encrypted traffic |
NAT exemption for 192.168.1.0/24 - 10.0.0.0/16 | VPN traffic must keep its private source IP |
| Firewall policy LAN ↔ tunnel | Most firewalls deny tunnel traffic by default |
Other clouds use the same values: Azure = Local Network Gateway and Connection; GCP = HA VPN and peer VPN gateway.
UP in AWS, ping both ways
A working VPN shows at least one tunnel UP and passes traffic in both directions. Check from the tunnel outward:
| Check | Pass looks like |
|---|---|
| VPN connection - Tunnel details | Status UP; with BGP, e.g. "1 BGP ROUTES" |
| Remote device | Phase 1 (IKE SA) and Phase 2 (IPsec SA) established |
| Subnet route table | 192.168.1.0/24 - prod-vgw, Propagated: Yes |
ping 10.0.1.25 from the office, ping 192.168.1.50 from EC2 | Replies both ways |
| SSH / RDP / app port | Connects, proving security groups allow it |
Idle tunnels can drop. Keep them up with one of:
| Option | Trade-off |
|---|---|
| Startup action: Start and DPD action: Restart | AWS brings the tunnel up itself; set per tunnel in AWS |
| Scheduled ping from the office | Works with any device; one more job to own |
Then alarm on TunnelState (1 = up, 0 = down) in the CloudWatch AWS/VPN namespace, and enable tunnel activity logs for IKE details.
Down means mismatch, up-but-silent means routing
A tunnel that won't come up is almost always a settings mismatch; a tunnel that's UP but passes nothing is a route or firewall gap. When stuck, the tunnel activity logs usually name the disagreeing parameter.
| Symptom | Fix |
|---|---|
| Both tunnels DOWN, nothing in device logs | Open UDP 500/4500 and ESP; confirm the CGW public IP |
| Phase 1 fails | Re-copy the PSK; align IKE version, encryption, integrity, DH group |
| Phase 1 up, Phase 2 fails | Align Phase 2 and PFS; on policy-based devices narrow AWS local/remote CIDRs |
| Drops after idle | Startup action Start, DPD action Restart, or keep-alive ping |
| UP, ping fails both ways | Add route propagation / static route to prod-vgw; allow ICMP in the security group |
| Ping works one way | Add the return route on the office device; add NAT exemption |
| BGP UP, "0 BGP ROUTES" | Advertise 192.168.1.0/24; check both ASNs and inside IPs |
| Big transfers stall | Clamp TCP MSS to 1406 and set MTU 1446 on the tunnel interface (AWS doesn't support PMTUD) |
| Same CIDR on both sides | Re-address one side; overlaps can't be routed without NAT |
About $36 a month, plus outbound data
A standard VPN costs $0.05 per connection-hour (≈ $36.50/month running 24/7, US example rate) plus standard data-transfer-out; inbound data is free. A 5 Gbps connection is $0.60/hour. The VGW and CGW cost nothing; deleting the connection stops the meter. Confirm current rates on the AWS VPN pricing page.
| Practice | Why |
|---|---|
| Plan non-overlapping CIDRs first | Re-addressing later is painful |
| Configure both tunnels | Survives AWS maintenance |
| Prefer BGP and IKEv2 | Faster failover, fewer manual routes |
| AES-256, SHA-256, DH group 14+ only | Removes weak legacy options |
| Keep PSKs in Secrets Manager; rotate | Keys are the tunnel's password |
| Security groups scoped to office subnets/ports | Least privilege |
Alarm on TunnelState | Hear about outages first |
| Codify in CloudFormation/Terraform | Rebuild identically |
When one VPN to one VPC isn't enough, pick one of:
| Option | Trade-off |
|---|---|
| Transit Gateway hub | Many VPCs share one VPN; adds hourly attachment and per-GB processing fees |
| Large Bandwidth Tunnels (5 Gbps) | 4× throughput without ECMP; TGW/Cloud WAN only, $0.60/hour |
| ECMP across tunnels on a TGW | Scales past 5 Gbps; requires BGP and more tunnels to manage |
| Accelerated Site-to-Site VPN | Steadier path over the AWS backbone; Global Accelerator fees on top |
| AWS Direct Connect (VPN as backup) | Consistent private bandwidth; lead time and port costs |
Sources
• AWS Site-to-Site VPN tunnel options
• AWS Site-to-Site VPN quotas
• AWS announcement: 5 Gbps bandwidth tunnels (Nov 12, 2025)
• AWS VPN pricing
