AWS Site-to-Site VPN: How It Works and When to Use It

Simple explanation

Site-to-Site VPN is a managed AWS service that creates a private, encrypted connection between your on-premises network and your VPC. Your office or data center acts as one end of the connection, and AWS manages the other end.

Once the tunnels are established, servers in your data center can reach EC2 instances, RDS databases, and other VPC resources using private IP addresses, as if both locations were on the same local network. Traffic is encrypted with IPSec so it cannot be read or modified in transit, even though it crosses the public internet.

AWS creates two tunnels automatically for redundancy. If one drops, traffic shifts to the other. For a broader picture of where Site-to-Site VPN fits alongside Direct Connect and Transit Gateway, see the Hybrid Connectivity Overview.

How AWS Site-to-Site VPN works

When you create a Site-to-Site VPN connection, AWS establishes two encrypted tunnels between your on-premises location and the AWS side. Here is the traffic path step by step:

1. Your on-premises VPN device (the customer gateway device) initiates or accepts the VPN tunnel. It encrypts outbound traffic destined for AWS and decrypts inbound traffic arriving from AWS.
2. The encrypted packets travel over the public internet to AWS VPN endpoints.
3. AWS receives the traffic at a target gateway. For most single-VPC setups this is a Virtual Private Gateway (VGW) attached to your VPC. For environments that need to reach multiple VPCs, a Transit Gateway can serve as the target instead.
4. The target gateway decrypts the traffic and forwards it to the correct subnet inside the VPC, following the route tables attached to those subnets.
5. Return traffic follows the same path in reverse: the VPC routes traffic back through the target gateway, encrypts it, and sends it over the internet back to your on-premises device.

Two tunnels and failover

Every VPN connection comes with two tunnels. Each terminates on a separate AWS VPN endpoint in a different Availability Zone. If one endpoint needs maintenance or fails, traffic shifts to the other tunnel automatically.

For failover to work, both tunnel endpoints must be configured on your on-premises device. Your device also needs to monitor tunnel health using Dead Peer Detection or an equivalent keepalive mechanism, so it switches to the backup tunnel quickly when needed.

Core components

Customer gateway device — your physical or software VPN appliance on-premises. It handles IPSec encryption and decryption and manages the tunnel endpoints. AWS publishes validated configurations for Cisco, Juniper, Palo Alto, Fortinet, pfSense, and other common devices. The device needs a static public IP and must support IKEv1 or IKEv2.

Customer Gateway (CGW) resource — an AWS configuration record representing your on-premises device. You create it by providing the device’s public IP and, optionally, its BGP ASN. This is not a physical device. It is the record AWS uses to know where to send the far end of the tunnel.

Target gateway — the AWS-side endpoint that terminates the VPN tunnels. For a standard single-VPC setup, this is a Virtual Private Gateway (VGW) that you create and attach to your VPC. For environments connecting multiple VPCs, a Transit Gateway can serve as the target instead. Most beginner setups use a VGW.

VPN Connection — the object that links your Customer Gateway to the target gateway. When you create it, AWS generates both tunnel configurations including pre-shared keys, endpoint IPs, and IKE parameters. You download a device-specific configuration file and load it into your on-premises appliance.

Static routing vs BGP

When you create a VPN connection, you choose how routes are exchanged between your on-premises network and AWS.

Static routing means you manually specify the on-premises CIDR blocks reachable over the VPN. AWS stores them as static routes in the VPC route tables, and your on-premises device is manually configured with the VPC CIDR. This is simple to set up and works well for small, stable networks where IP ranges rarely change.

BGP (Border Gateway Protocol) means your on-premises router and the AWS target gateway exchange route information automatically. Add a new subnet on-premises and it is advertised to AWS without any manual steps. BGP also enables more graceful failover: if you run Direct Connect as your primary path with VPN as a backup, BGP lets AWS prefer the Direct Connect route and fall back to VPN automatically when Direct Connect becomes unavailable.

When to use Site-to-Site VPN

Site-to-Site VPN is the right choice in these situations:

• You need connectivity quickly. VPN can be configured in hours using your existing internet connection. There is no physical infrastructure to provision or carrier coordination required.
• You are in a migration phase. Before committing to Direct Connect, VPN gives your on-premises systems access to AWS resources immediately. Many teams run VPN during migration and evaluate later whether Direct Connect is needed.
• You have modest bandwidth needs. Most internal application traffic, management access, and moderate data transfers fit comfortably within what a VPN tunnel can carry.
• You need encryption for compliance. IPSec encryption is built in. If your policy requires encrypted traffic between on-premises and cloud, Site-to-Site VPN satisfies that requirement out of the box.
• You are connecting branch offices to AWS. Branch locations with a supported router can connect directly to AWS without a full Direct Connect circuit.
• You need a backup path alongside Direct Connect. A VPN connection makes a cost-effective standby for Direct Connect resilience. With BGP, the failover between the two paths is automatic.

When not to use Site-to-Site VPN

VPN is not the right tool for every workload. Be clear-eyed about these limitations before committing it to scenarios where it will struggle:

• High-throughput workloads. Each VPN tunnel has a throughput ceiling. Workloads that regularly transfer large data volumes — database replication, high-volume data pipelines, bulk migrations — will run into that limit. For higher aggregate capacity, consider Direct Connect or multiple VPN connections with ECMP routing through Transit Gateway.
• Latency-sensitive applications. VPN traffic traverses the public internet and latency fluctuates with internet conditions. If your application needs consistent sub-20ms latency, Direct Connect is the right choice.
• Compliance that prohibits internet traversal. Even though the traffic is encrypted, it still crosses the public internet. Some compliance frameworks require that data never touch a public network. If yours does, you need Direct Connect.
• Complex large-scale multi-network topologies. Managing many individual VPN connections across dozens of branch offices or VPCs becomes operationally complex at scale. Transit Gateway with SD-WAN integrations may be a better fit.

AWS Site-to-Site VPN vs Direct Connect

The choice between VPN and Direct Connect comes down to your bandwidth requirements, latency sensitivity, and how quickly you need the connection.

The most common production pattern is both: Direct Connect as the primary path, with Site-to-Site VPN as an automatic backup. If Direct Connect fails, BGP detects it and routes traffic over VPN within seconds to minutes. This gives you Direct Connect’s performance for normal operations and VPN’s availability as a fallback.

Setup overview

Setting up a Site-to-Site VPN involves four main steps:

1. Create a Customer Gateway resource in AWS with your on-premises device’s public IP address and BGP ASN if you are using dynamic routing.
2. Create or identify a target gateway — typically a Virtual Private Gateway that you create and attach to your VPC, or an existing Transit Gateway for multi-VPC setups.
3. Create the VPN Connection, linking the Customer Gateway to the target gateway. AWS generates both tunnel configurations with pre-shared keys and IKE settings. Download the device-specific configuration file.
4. Configure your on-premises device using the downloaded file. Apply both tunnel configurations, then enable route propagation on your VPC route tables or add static routes so subnets know to forward on-premises-bound traffic through the target gateway.

# Create a Customer Gateway (your on-premises device)
aws ec2 create-customer-gateway \
  --type ipsec.1 \
  --public-ip 203.0.113.50 \
  --bgp-asn 65000

# Create a Virtual Private Gateway and attach it to your VPC
aws ec2 create-vpn-gateway --type ipsec.1
aws ec2 attach-vpn-gateway \
  --vpn-gateway-id vgw-0abc123def456789a \
  --vpc-id vpc-0abc123def456789a

# Create the VPN Connection (AWS generates both tunnel configs)
aws ec2 create-vpn-connection \
  --type ipsec.1 \
  --customer-gateway-id cgw-0abc123def456789a \
  --vpn-gateway-id vgw-0abc123def456789a

# Enable route propagation so the VGW injects BGP routes automatically
aws ec2 enable-vgw-route-propagation \
  --route-table-id rtb-0abc123def456789a \
  --gateway-id vgw-0abc123def456789a

After creating the connection, download the configuration file from the console and load it onto your on-premises device. AWS provides templates for Cisco, Juniper, Palo Alto, Fortinet, and other major vendors.

Route configuration is easy to overlook. Tunnels in an UP state do not automatically route traffic. Your VPC route tables need entries pointing on-premises-bound traffic toward the target gateway. Enable route propagation for BGP setups, or add static routes manually if you chose static routing.