VPN & Direct Connect
Most companies do not move to the cloud all at once. They keep some servers in their own data center (their “on-premises” or “on-prem” network) and run the rest in AWS. To make those two worlds talk to each other as if they were one network, you need a private link between them. AWS gives you two main ways to build that link: a Site-to-Site VPN (a Virtual Private Network, an encrypted tunnel over the public internet) and AWS Direct Connect (a dedicated physical cable into AWS). This page explains how each works, when to pick which, and the traps that catch teams later.
What “hybrid networking” means
A hybrid network simply means part of your infrastructure lives on-premises and part lives in AWS, and the two are connected privately. Once connected, a server in your office can reach a database in your VPC (Virtual Private Cloud, your isolated network inside AWS) using private IP addresses, with no traffic crossing the open internet in plain text.
Both options connect to your VPC through a Virtual Private Gateway (VGW, the VPN/Direct Connect attachment point on the AWS side) or, more commonly today, through a Transit Gateway (a hub that connects many VPCs and on-prem networks together).
Site-to-Site VPN
A Site-to-Site VPN builds an IPsec tunnel (IPsec is a standard for encrypting network traffic) between your on-prem router and AWS, running over the normal internet. AWS provisions it in minutes and always creates two tunnels to two different AWS endpoints for redundancy.
When to use it: you need a connection today, your traffic volume is modest, and some variability in latency is acceptable. It is the right first step for almost everyone and a great backup for Direct Connect.
When NOT to use it: you push large, steady volumes of data, or you need guaranteed, consistent low latency (for example, replicating a busy database). Because it rides the public internet, performance can swing with internet congestion.
Console steps
- Open the VPC console and choose Virtual Private Gateways > Create virtual private gateway, then attach it to your VPC.
- Choose Customer Gateways > Create customer gateway and enter your on-prem router’s public IP address and its BGP ASN (Border Gateway Protocol Autonomous System Number, an ID used for dynamic routing) — or pick Static routing if your router does not run BGP.
- Choose Site-to-Site VPN Connections > Create VPN connection, select the virtual private gateway and customer gateway, then create it.
- Click Download Configuration to get a ready-made config file for your router brand (Cisco, Juniper, pfSense, etc.).
- In your VPC route tables, enable route propagation so on-prem routes appear automatically.
CLI equivalent
aws ec2 create-customer-gateway \
--type ipsec.1 \
--public-ip 203.0.113.10 \
--bgp-asn 65000
aws ec2 create-vpn-connection \
--type ipsec.1 \
--customer-gateway-id cgw-0a1b2c3d \
--vpn-gateway-id vgw-0a1b2c3d \
--options StaticRoutesOnly=false
Output:
{
"VpnConnection": {
"VpnConnectionId": "vpn-0a1b2c3d",
"State": "pending",
"Type": "ipsec.1",
"VgwTelemetry": [
{ "OutsideIpAddress": "18.205.10.1", "Status": "DOWN" },
{ "OutsideIpAddress": "52.46.20.2", "Status": "DOWN" }
]
}
}
The tunnels show DOWN until your on-prem router finishes negotiating IPsec; they flip to UP once both sides agree.
Tip: A VPN tunnel maxes out at about 1.25 Gbps per tunnel. If you need more throughput, use multiple tunnels with ECMP (Equal-Cost Multi-Path) on a Transit Gateway, or move to Direct Connect.
AWS Direct Connect
Direct Connect (often shortened to DX) is a dedicated, private fiber link from your network into an AWS Direct Connect location (a partner data center). Your traffic never touches the public internet, so latency is low and consistent, and large transfers are far cheaper per gigabyte.
When to use it: large or sustained data transfer, strict latency requirements, or compliance rules that forbid traffic over the public internet. Common for data warehouses, media workflows, and trading systems.
When NOT to use it: you need connectivity this week, or your volumes are small. Provisioning a physical cross-connect typically takes several weeks (sometimes months), and you pay even when idle.
How you get one
- In the Direct Connect console choose Connections > Create connection, pick a location, and pick a port speed (1, 10, or 100 Gbps), or order a slower hosted connection (50 Mbps–25 Gbps) through an AWS Partner.
- AWS issues a Letter of Authorization (LOA-CFA) — a document authorizing the physical cabling.
- Your data-center provider (or AWS Partner) completes the cross-connect (the physical cable).
- Create a Virtual Interface (VIF): a private VIF to reach your VPC, or a public VIF to reach AWS public services like S3.
aws directconnect create-private-virtual-interface \
--connection-id dxcon-0a1b2c3d \
--new-private-virtual-interface \
"virtualInterfaceName=prod-vif,vlan=100,asn=65000,virtualGatewayId=vgw-0a1b2c3d"
Output:
{
"virtualInterfaceId": "dxvif-0a1b2c3d",
"connectionId": "dxcon-0a1b2c3d",
"virtualInterfaceState": "pending",
"vlan": 100,
"addressFamily": "ipv4"
}
Gotcha: Direct Connect is not encrypted by default — it is private, but the bytes are not scrambled. If you have an encryption requirement, run an IPsec VPN over the Direct Connect link (a “VPN over DX” pattern). Also, a single DX connection is a single point of failure: if that one cable is cut, you are offline.
Resilience: don’t run a single line
Both services support redundancy, and AWS strongly recommends it for production.
| Pattern | How it works | Best for |
|---|---|---|
| Single VPN | Two tunnels, one customer gateway | Dev/test, low stakes |
| VPN + VPN | Two customer gateways in two sites | Cheap on-prem redundancy |
| Single DX + VPN backup | DX for daily traffic, VPN auto-takes over if DX fails | Most production hybrids |
| DX + DX | Two DX connections in two locations | Mission-critical, high volume |
The Single DX + VPN backup pattern is the sweet spot for most teams: you get DX performance day to day, and the VPN (already provisioned and far cheaper) catches you if the cable fails. Use BGP so failover happens automatically.
Site-to-Site VPN vs Direct Connect — when to use which
| Factor | Site-to-Site VPN | Direct Connect |
|---|---|---|
| Path | Public internet | Private dedicated line |
| Encryption | Yes (IPsec, built in) | No (add VPN over DX) |
| Setup time | Minutes | Weeks to months |
| Latency | Variable | Low and consistent |
| Throughput | ~1.25 Gbps per tunnel | Up to 100 Gbps |
| Cost model | Low hourly + standard data egress | Port-hour + cheaper per-GB transfer |
| Single connection redundant? | Two tunnels, but one ISP path | No — needs a second link |
Cost note: A VPN connection costs roughly $0.05 per hour (about $36/month) plus normal data-transfer-out rates. A 1 Gbps Direct Connect port runs around $0.30/hour (about $220/month) plus a port fee, but its per-GB data rate is far lower — so DX pays off once you move many terabytes per month.
Best Practices
- Start with a Site-to-Site VPN to move quickly, then add Direct Connect only when volume or latency justifies it.
- Never run production on a single connection — pair DX with a VPN backup, or use two DX links in different locations.
- Use BGP instead of static routes so failover and route changes happen automatically.
- If you have an encryption mandate, run IPsec over Direct Connect; DX alone is private but not encrypted.
- Terminate connections on a Transit Gateway when you have multiple VPCs, so you manage routing in one place.
- Budget realistic lead time for Direct Connect (weeks), and start the LOA-CFA and cross-connect paperwork early.
- Monitor tunnel and VIF state with CloudWatch alarms so you learn about a down link before your users do.