Run AWS Direct Connect as primary and Site-to-Site VPN as BGP failover. Size the backup, set route preference and test it before an outage does.
A platform team moving a trading firm's risk engine to AWS spent a whole planning cycle debating Direct Connect against VPN as a single purchase. One option offered predictable latency, the other offered speed and low cost. They shipped both, with Direct Connect carrying traffic and a VPN waiting as an automatic BGP failover, and the debate has not come back.
For anything business-critical, that combined design is the one AWS's resiliency guidance steers you toward. The hard part is not buying two links. It is making sure the backup has enough bandwidth, that routes prefer the right path, and that failover works when you need it.
For production workloads, use both: Direct Connect as the primary path and Site-to-Site VPN as the standby. Pick only one when the workload is small and tolerant of outages (VPN alone) or when you can afford two Direct Connect circuits at different locations (Direct Connect alone).
| Factor | Direct Connect | Site-to-Site VPN |
|---|---|---|
| Transport | Dedicated private circuit | IPsec over internet |
| Latency | Predictable | Variable |
| Setup time | Weeks | Minutes |
Cost also differs. A 1 Gbps Direct Connect port lists at about $0.30 per hour (roughly $219 a month), and data transferred out costs about $0.02 per GB, against about $0.09 per GB over the internet. At those list prices the port fee pays for itself at roughly 3 TB of monthly egress, before cross-connect and carrier charges, which often dominate. Check current prices for your region.
Both paths run BGP to the same destinations. AWS prefers the Direct Connect route when prefixes are equal, so traffic flows over Direct Connect normally and shifts to the VPN when the circuit or its BGP session drops. When Direct Connect returns, traffic moves back with no manual step.
One more point on resilience. A single Direct Connect circuit, even with a VPN behind it, is the lower tier. AWS's resiliency model reserves its highest tier for redundant connections at two or more locations, and a VPN is the cheaper way to cover a failure when a second circuit is not justified.
A single tunnel supports up to 1.25 Gbps, and a virtual private gateway does not support ECMP across tunnels. If your Direct Connect carries 10 Gbps and fails over to one tunnel, you keep connectivity but lose most of your capacity at the worst moment, which is why AWS does not recommend a single tunnel as backup above 1 Gbps.
The fix is to terminate multiple VPN connections on a Transit Gateway with ECMP. Each active tunnel adds up to 1.25 Gbps, and AWS documents aggregate throughput up to about 50 Gbps across many tunnels.
resource "aws_ec2_transit_gateway" "main" { description = "hybrid-core" vpn_ecmp_support = "enable"} resource "aws_customer_gateway" "dc1" { bgp_asn = 65010 ip_address = "203.0.113.10" type = "ipsec.1"} resource "aws_vpn_connection" "dc1" { count = 4 customer_gateway_id = aws_customer_gateway.dc1.id transit_gateway_id = aws_ec2_transit_gateway.main.id type = "ipsec.1" static_routes_only = false}Three limits apply. ECMP balances per flow, so one large transfer still caps at 1.25 Gbps. Your on-premises router must support ECMP and advertise equal-cost routes on every tunnel. And ECMP works across VPN tunnels, not across Direct Connect and VPN together.
Size the backup for the traffic you must keep alive, not for 100% of the primary. If trading and payments need 3 Gbps during an outage, four to six well-balanced tunnels may be enough.
Advertise the same prefixes on both paths and make your own router prefer Direct Connect. Routers choose the longest prefix first, so a more specific route on the VPN wins even when Direct Connect is healthy, and no alarm fires because nothing is technically down.
Cover both directions. AWS prefers Direct Connect for traffic toward on-premises when prefixes match. For traffic toward AWS, your router decides, so set a higher local preference on routes learned over Direct Connect. The syntax below is illustrative (IOS style):
route-map FROM-DX permit 10 set local-preference 200route-map FROM-VPN permit 10 set local-preference 100router bgp 65010 neighbor 192.0.2.1 route-map FROM-DX in neighbor 169.254.20.1 route-map FROM-VPN inAlso consider AS path prepending on routes you advertise over the VPN, so AWS sees the VPN as longer and less attractive. Mismatched local preference between the two directions produces asymmetric routing, which stateful firewalls drop. That failure looks like random timeouts, not an outage.
Failover is only as fast as failure detection. Without BFD, a dead Direct Connect path can be noticed only after BGP hold timers expire, which can take up to 90 seconds on a virtual interface, and all that time traffic is black-holed.
Enable BFD on your router for the Direct Connect virtual interface. AWS turns on asynchronous BFD for virtual interfaces but it does nothing until your side is configured. A common starting point is a 300 ms interval with a multiplier of 3, giving detection in about a second. VPN tunnels use Dead Peer Detection and shorter BGP timers, so they usually recover on their own faster, but check the timers in your tunnel options.
Trigger a controlled Direct Connect failure on a schedule, then confirm traffic moves to the VPN, the application keeps working and traffic returns afterward. A VPN tunnel showing UP in the console only proves the tunnel exists.
Direct Connect includes a failover test that takes a virtual interface's BGP session down for a set time:
aws directconnect start-bgp-failover-test \ --virtual-interface-id dxvif-ffabc123 \ --test-duration-in-minutes 10Run it in a maintenance window, watch application error rates and latency, and then review results with list-virtual-interface-test-history. Check aws directconnect start-bgp-failover-test help for peer selection options.
Then alarm on each path independently using the CloudWatch metrics ConnectionState (namespace AWS/DirectConnect) and TunnelState (namespace AWS/VPN). A backup that fails silently is the same as no backup.
| Design | Failover capacity | Complexity |
|---|---|---|
| DX plus one VPN tunnel (VGW) | Up to 1.25 Gbps | Low |
| DX plus multi-tunnel VPN (TGW) | Up to about 50 Gbps | Medium |
| Two DX circuits, two sites | Full | High, higher cost |
A second Direct Connect circuit gives the strongest resilience but costs the most and takes weeks to provision. A multi-tunnel VPN on Transit Gateway is the usual middle path: a fraction of the cost, minutes to add, with enough capacity for critical traffic. Remember Transit Gateway adds its own attachment and per-GB processing charges.
ConnectionState and TunnelState.References and Further Reading
- AWS Direct Connect Resiliency Recommendations - Official redundancy tiers
- AWS Direct Connect User Guide - BFD, failover testing and virtual interfaces
- Site-to-Site VPN User Guide - Tunnel limits, ECMP and routing
- AWS VPC Connectivity Options - Hybrid design patterns
No. A tunnel tops out at 1.25 Gbps, and AWS does not recommend a single tunnel as backup for Direct Connect connections faster than 1 Gbps. Failover would work, but throughput would collapse to a fraction of normal capacity.
Terminate several VPN connections on a Transit Gateway instead of a virtual private gateway, with BGP and ECMP enabled. Each tunnel adds up to 1.25 Gbps and AWS documents aggregates up to about 50 Gbps, but ECMP balances per flow, so any single flow still caps at 1.25 Gbps.
Routing picks the longest prefix first. If the VPN advertises a more specific prefix than Direct Connect, or your router gives VPN routes a higher local preference, traffic takes the VPN with no alarm because nothing is down. Advertise identical prefixes on both paths and set local preference to favour Direct Connect.
Without BFD you wait for BGP hold timers, which can be up to 90 seconds on a Direct Connect virtual interface. Enabling BFD on your router (AWS supports it on the virtual interface) cuts detection to a few seconds, for example a 300 ms interval with multiplier 3.
No. Direct Connect is a private circuit, not an encrypted one. Add MACsec on supported dedicated connections, run an IPsec VPN over it, or use application-layer TLS when your compliance rules require encryption in transit. Site-to-Site VPN is encrypted with IPsec by default.
Discussion0