A platform team migrating a trading system's on-prem risk engine to AWS spent a planning cycle debating Direct Connect versus VPN as if it were a single either/or purchase decision — pick the dedicated circuit for performance, or pick the VPN for speed of setup and lower cost. They eventually shipped both, with Direct Connect as primary and VPN as an automatic BGP failover path, and haven't touched that decision since. That combined architecture, not a pure either/or, is what AWS's own resiliency documentation and the majority of production reference architectures actually recommend for anything that counts as mission-critical.
If you already have a VPC Advanced topic covering Direct Connect and VPN individually, this is the part that topic-level content usually skips: how they're meant to work together, and the specific configuration details that determine whether your "redundant" setup actually fails over cleanly.
Direct Connect gives you a dedicated, private network connection between your on-premises environment and AWS — predictable latency and bandwidth, bypassing the public internet entirely. Site-to-Site VPN runs IPSec tunnels over the public internet, which means variable latency and a hard bandwidth ceiling per tunnel, but far faster to provision and no dedicated circuit cost.
The production pattern combines them: all traffic flows over Direct Connect during normal operation, while a Site-to-Site VPN tunnel stays active but idle, standing by. When both are configured with dynamic BGP routing to the same destination, AWS automatically prefers the Direct Connect path — no manual intervention needed on either side of a failure or recovery event. If Direct Connect goes down, BGP detects it and traffic reroutes over the VPN tunnel automatically; when Direct Connect recovers, traffic shifts back the same way.
This is explicitly the architecture the AWS Well-Architected Framework's reliability pillar points toward: a single connectivity provider, a single Direct Connect connection, or a single VPN path with no backup is treated as a high-risk anti-pattern, not an acceptable production configuration.
Here's the detail that breaks this pattern for teams that don't plan around it: a single Site-to-Site VPN tunnel supports up to 1.25 Gbps of throughput and doesn't support Equal Cost Multi-Path (ECMP) routing when multiple tunnels terminate on the same Virtual Gateway. That's fine as a backup for smaller Direct Connect circuits, but AWS explicitly does not recommend using a single VPN tunnel as backup for Direct Connect connections faster than 1 Gbps — your production traffic could exceed 10 Gbps on Direct Connect and collapse to a fraction of that the moment it fails over.
The fix is architectural, not just a config toggle: terminate multiple VPN tunnels on an AWS Transit Gateway instead of a VGW, and enable ECMP. With ECMP across enough tunnels, aggregate VPN backup throughput can reach up to 50 Gbps — enough to carry most enterprise production workloads through a complete Direct Connect outage. If your failover design still routes through a single VGW-terminated tunnel, you likely have a backup path that looks redundant on a diagram but silently throttles you the moment you actually need it.
Even with both connections configured, there's a subtle BGP requirement that determines whether AWS actually prefers Direct Connect the way you expect: for Direct Connect to be preferred over VPN, the prefixes received across both connections need to be either the same or more specific on the Direct Connect side. If your VPN accidentally advertises a more specific route than Direct Connect does, traffic can end up flowing over the internet-based VPN path even while your dedicated circuit is completely healthy — and this failure mode doesn't throw an alarm, because nothing is actually "down." It just quietly costs you the performance you paid for Direct Connect to get.
This is exactly the kind of asymmetric-routing issue that shows up in AWS's own support forums as a recurring pattern, and it's why testing failover — genuinely triggering a Direct Connect outage in a controlled way and confirming traffic both fails over and fails back correctly — matters more than confirming the VPN tunnel shows "up" in the console.
Standalone characteristics:
| Factor |
Direct Connect |
Site-to-Site VPN |
| Transport |
Dedicated private circuit |
IPSec over public internet |
| Latency/bandwidth predictability |
High |
Variable |
| Per-tunnel bandwidth ceiling |
Up to 100 Gbps (port speed dependent) |
1.25 Gbps per tunnel |
| Provisioning lead time |
Weeks (physical circuit) |
Minutes |
Combined-pattern design factors:
| Factor |
Single VPN tunnel (VGW) |
Multi-tunnel VPN + TGW + ECMP |
| Failover bandwidth |
Up to 1.25 Gbps |
Up to 50 Gbps aggregate |
| Recommended for DX speeds above |
Not recommended above 1 Gbps DX |
Suitable for larger DX circuits |
| Complexity |
Lower |
Higher — requires TGW + ECMP config |
For any workload you'd classify as mission-critical, design Direct Connect as primary with Site-to-Site VPN as an automatic BGP failover path from the start, rather than treating VPN as a stopgap until Direct Connect is provisioned — the combined pattern is the production-grade design AWS's own reference architectures converge on, not an interim measure.
Size your VPN backup deliberately: if your Direct Connect circuit runs faster than 1 Gbps, terminate multiple VPN tunnels on a Transit Gateway with ECMP enabled rather than relying on a single VGW-attached tunnel, since a single tunnel will silently cap your failover bandwidth far below what your primary path carries.
Verify your BGP prefix advertisement matches across both paths, and — this is the step most teams skip — actually test the failover periodically rather than trusting a diagram. Simulate a Direct Connect outage on a schedule, confirm traffic reroutes to VPN and back cleanly, and check CloudWatch alarms fire on both connections independently, since a backup path you've never tested carries the same risk as no backup path at all.
INFORMATIONReferences and Further Reading
Discussion0