AWS Site-to-Site VPN connects your on-premises network to an AWS VPC through encrypted IPsec tunnels. It is often the fastest practical way to give private workloads in AWS access to office, data center, or partner network resources without exposing those resources to the public internet.
For the broader route map, see our AWS services for developers guide.
Quick takeaway: Site-to-Site VPN is a hybrid-networking tool. The important parts are the customer gateway, the AWS-side gateway target, two redundant tunnels, route tables, and monitoring. If traffic does not flow, the issue is usually routing, BGP, firewall rules, or only one healthy tunnel.
Who This Guide Is For
This guide is for cloud engineers, DevOps engineers, and infrastructure teams who need a plain-English map of how AWS Site-to-Site VPN works before they configure or troubleshoot it.
- You need to connect an office, data center, or partner network to private AWS resources.
- You are comparing Site-to-Site VPN with Direct Connect, VPC peering, VPC endpoints, or Transit Gateway.
- You are preparing for an AWS or DevOps interview and need to explain the moving parts without hand-waving.
How AWS Site-to-Site VPN Works
A Site-to-Site VPN connection creates encrypted IPsec tunnels between your network device and an AWS gateway target. On your side, AWS represents the device as a customer gateway. On the AWS side, the VPN can terminate on a virtual private gateway for one VPC or on a transit gateway when the design needs broader hub-and-spoke routing.
AWS creates two tunnels for each VPN connection. The point is not higher speed by default; it is redundancy. A production setup should monitor both tunnels and make sure routes can move cleanly if one tunnel drops.
The Main Components
| Component | What it does | Common mistake |
|---|---|---|
| Customer Gateway | Represents your on-premises VPN device or firewall in AWS. | Using the wrong public IP or ASN and then troubleshooting the wrong layer. |
| Virtual Private Gateway | AWS-side target attached to a VPC for simpler VPN designs. | Expecting it to solve multi-VPC routing without additional architecture. |
| Transit Gateway | AWS-side hub for many VPCs and networks. | Forgetting that route tables still decide where packets go. |
| VPN Connection | Defines the IPsec tunnels and configuration values. | Treating “created” as “working” before tunnel and route checks pass. |
| Route Tables | Tell AWS and your network which CIDRs should use the VPN. | Having healthy tunnels but no return route. |
Site-to-Site VPN vs VPC Peering, VPC Endpoints, and Direct Connect
The biggest SEO and architecture trap is treating every private AWS connectivity feature as the same thing. They solve different jobs. Use Site-to-Site VPN when the source network is outside AWS and needs encrypted private access into AWS.
| Option | Best for | Not for |
|---|---|---|
| Site-to-Site VPN | Encrypted hybrid connectivity between on-premises networks and AWS. | Private access to AWS services without leaving AWS, or simple VPC-to-VPC links. |
| VPC Peering | Direct private routing between two VPCs. See the Amazon VPC peering guide for that use case. | On-premises-to-AWS connectivity. |
| VPC Endpoints | Private access from a VPC to supported AWS services. See the AWS VPC endpoint guide. | Replacing a hybrid network tunnel. |
| Direct Connect | Dedicated private connectivity with more predictable bandwidth and latency. | Fast initial setup when a VPN is good enough or the circuit is not ready. |
| Transit Gateway | Central routing across many VPCs and networks. See the VPC networking components guide for broader context. | A magic fix for missing route design. |
Setup Checklist Before You Call It Done
A VPN connection can exist in the AWS console and still be unusable. Before you treat it as production-ready, check the network design end to end.
- Confirm non-overlapping CIDR ranges between AWS and the on-premises network.
- Choose static routes or BGP based on how dynamic your routing needs to be.
- Validate the customer gateway public IP address and device configuration.
- Confirm that the AWS route table sends on-premises CIDRs toward the VPN target.
- Confirm that the on-premises router or firewall has return routes for the VPC CIDR.
- Allow the required traffic in security groups, network ACLs, and on-premises firewall rules.
- Monitor both tunnels, not just the first tunnel that came up.
Static Routing vs BGP
Static routing is easier to reason about in small environments: you list the remote CIDRs and keep the route tables simple. BGP is better when routes can change, when failover behavior matters, or when the VPN participates in a larger routing design.
| Routing mode | Use it when | Watch out for |
|---|---|---|
| Static routes | The network is small and CIDRs rarely change. | Manual updates become brittle as the environment grows. |
| BGP | You need dynamic route exchange or cleaner failover. | ASN mismatch, firewall rules, and tunnel options can stop BGP from establishing. |
Troubleshooting Common Site-to-Site VPN Problems
Most Site-to-Site VPN incidents are not mysterious AWS failures. They usually come down to tunnel state, route propagation, or traffic being blocked somewhere between the source and destination.
| Symptom | Likely cause | What to check |
|---|---|---|
| Tunnel is down | IPsec parameters, firewall, or customer gateway mismatch. | Tunnel options, pre-shared keys, public IP, NAT traversal, and device logs. |
| Only one tunnel is up | Redundancy path not configured or blocked. | Second tunnel configuration and whether routing can fail over. |
| Tunnel is up but no traffic flows | Missing AWS or on-premises route. | VPC route table, propagated routes, and return route on the customer network. |
| BGP does not establish | ASN, peer IP, or firewall issue. | BGP neighbor settings and whether TCP 179 is allowed where required. |
| Traffic works one way | Asymmetric routing or security rules. | Return path, security groups, NACLs, and on-premises firewall policy. |
AWS Documentation Worth Keeping Open
For implementation details, keep the official AWS documentation open while you configure the connection: AWS Site-to-Site VPN overview, VPN setup workflow, VPN monitoring, and route priority.
FAQ
These are the questions that usually decide whether Site-to-Site VPN is the right pattern or whether another AWS connectivity option fits better.
What is AWS Site-to-Site VPN used for?
AWS Site-to-Site VPN is used to create encrypted IPsec connectivity between an on-premises network and AWS. It is a common fit for hybrid access to private VPC resources when a dedicated Direct Connect circuit is not required or not ready yet.
Why does AWS create two VPN tunnels?
AWS creates two tunnels for redundancy. A healthy design should monitor both tunnels and make sure routing can fail over instead of depending on a single tunnel path.
Do I need BGP for AWS Site-to-Site VPN?
No. AWS Site-to-Site VPN supports static routing and dynamic routing with BGP. BGP is usually better when routes can change or when you need automated failover behavior, while static routes can work for simpler networks.
How is Site-to-Site VPN different from Direct Connect?
Site-to-Site VPN runs encrypted tunnels over the internet. Direct Connect uses a dedicated private network connection to AWS. Many teams use VPN first for speed and Direct Connect later for predictable bandwidth, latency, or compliance requirements.
Can Site-to-Site VPN connect two VPCs?
It is not the default tool for VPC-to-VPC connectivity. For VPC-to-VPC traffic, VPC peering, Transit Gateway, or PrivateLink/VPC endpoints are usually better fits depending on the architecture.
Bottom Line
Use AWS Site-to-Site VPN when you need encrypted hybrid connectivity into AWS and can accept internet-based tunnels. Keep it separate from VPC peering, VPC endpoints, and Direct Connect in your architecture decisions. The connection is only healthy when both tunnel monitoring and end-to-end routing checks agree.
Leave a Reply