Start from the requirement, not the product
Every hybrid connectivity decision should start with three questions: how much bandwidth, how consistent does latency need to be, and what’s the cost of an hour of connectivity loss. The answer determines whether you need Direct Connect at all — and for a large share of real workloads, you don’t.
Site-to-Site VPN vs Direct Connect vs DX+VPN failover
| Site-to-Site VPN | Direct Connect | DX + VPN failover | |
|---|---|---|---|
| Path | Encrypted tunnel over the public internet | Dedicated physical/logical circuit to an AWS Direct Connect location | DX primary, VPN as backup path |
| Bandwidth | Capped per-tunnel (traditional VPN); multiple tunnels/ECMP can aggregate, but each tunnel has a ceiling — get the current per-tunnel figure from AWS before sizing | Dedicated connections are offered at 1, 10, 100 and 400 Gbps over single-mode fiber; AWS Direct Connect Partners provision hosted connections, including sub-1 Gbps capacities (Direct Connect quotas and connection types, AWS docs). Consistent at the provisioned rate | DX rate when healthy, drops to VPN’s lower ceiling on failover |
| Latency determinism | Variable — subject to internet path congestion, no SLA on latency | Consistent, predictable latency — doesn’t share capacity with general internet traffic | Consistent when on DX; variable if failed over |
| Setup time | Minutes to hours — software configuration only | Weeks to months — physical cross-connect, possibly a circuit from a telecom provider, location dependent | Same as DX, plus VPN setup |
| Cost shape | Low fixed cost, pay for the VPN connection hours plus data transfer | Port-hour charge plus data transfer, plus third-party circuit cost if not colocated at a DX location | Both cost structures, VPN as the cheaper insurance policy |
| Operational dependency | None beyond your router/firewall and AWS | Physical circuit — outages require your provider or a site visit to resolve | Automatic failover to VPN masks most DX circuit outages |
VPN is the correct engineering answer, not a compromise, when: bandwidth needs are modest (tens to a few hundred Mbps sustained), the workload tolerates variable latency (batch jobs, async replication, most B2B integrations), and you need connectivity live in hours, not months. Spending on Direct Connect for a workload that would never notice VPN’s latency variance is money spent on a guarantee nobody needs.
Direct Connect earns its cost when: you’re moving sustained high-bandwidth traffic where VPN’s per-tunnel ceiling actually bites, you have latency-sensitive synchronous traffic (database replication with tight RPO, a monitored trading or control system, VDI), or your egress data transfer volume is high enough that DX’s typically lower per-GB data transfer pricing changes the cost equation at scale. Verify current DX data transfer pricing against AWS’s published rates — this is one of the areas where the VPN-vs-DX cost crossover point depends heavily on your actual volume, and it moves as AWS adjusts pricing.
DX + VPN failover is the pattern for workloads that need DX’s performance but can’t tolerate the circuit’s physical-world failure modes (backhoe fade, provider outage, a bad day for the cross-connect). The VPN backup won’t match DX’s throughput, so define explicitly what “degraded but still running at VPN speed” looks like for your application, and test that your monitoring actually distinguishes “on DX” from “failed over to VPN” — silent failover means you don’t find out you’ve been running on VPN bandwidth for three days until something saturates it.
Transit Gateway as the hybrid hub
Once you have more than one VPC needing on-prem connectivity, attach your Direct Connect gateway or VPN connections to a Transit Gateway rather than wiring each VPC to its own DX/VPN connection. A transit gateway is “a network transit hub used to interconnect virtual private clouds (VPCs) and on-premises networks,” and its attachment types include VPCs, a Direct Connect gateway, VPN connections, SD-WAN appliances, and peering with another transit gateway (Transit Gateway, AWS docs). One set of hybrid connections, shared across every attached VPC through TGW route tables, instead of duplicating VPN tunnels or DX virtual interfaces per VPC.
Two quota facts worth knowing before you draw the diagram: a dedicated connection supports 4 transit virtual interfaces (counted inside a 51-virtual-interface total), and a Direct Connect gateway can associate with 6 transit gateways and 20 virtual private gateways. Those are hard limits that cannot be raised.
The design decision that matters here is route table segmentation within TGW. Don’t put every attachment in one shared TGW route table by default — that makes every VPC and every on-prem network transitively reachable from every other, which is rarely what you actually want (your sandbox VPC usually shouldn’t have a route to the on-prem production database segment). The mechanism that makes segmentation possible is the association model: “each attachment is associated with exactly one route table. Each route table can be associated with zero to many attachments.” Use separate TGW route tables per trust zone, and associate attachments deliberately, propagating only the routes that zone should see. Note that route propagation is not uniform by attachment type — a VPN connection or Direct Connect gateway propagates dynamically via BGP, Connect attachments propagate by default, but a VPC attachment requires you to create static routes, and a peering attachment requires a static route pointing at the peering attachment. Assuming “routes just propagate” is a standard source of a half-working hub.
BGP basics that actually matter for this
Direct Connect and most VPN configurations use BGP to exchange routes dynamically rather than relying on static routes. You don’t need deep BGP operations expertise, but these specifics will bite you if ignored:
- AS path and local preference control path selection when you have multiple paths (DX + VPN, or dual DX circuits). Set these deliberately so failover goes the direction you intend — the default behavior when you haven’t configured preference explicitly is not guaranteed to match your intended primary/backup roles.
- Prefix limits, and what exceeding them actually does. On a Direct Connect private or transit virtual interface, the default is 100 routes each for IPv4 and IPv6 advertised from on-premises to AWS, raisable to 1,000 each using prefix controls. AWS is explicit about the failure mode: “if you advertise more route prefixes than your configured allocations for IPv4 and IPv6 over the BGP session, the BGP session will go into an idle state and be reported with BGP session status DOWN” (Direct Connect quotas, AWS docs). That is a connectivity outage, not a dropped route. A public virtual interface allows 1,000 routes and cannot be increased. Separately, only 200 prefixes (IPv4 and IPv6 combined) are advertised from a Transit Gateway to on-premises over a transit VIF — a limit that bites in the other direction as your VPC estate grows. If your on-prem network advertises a large number of specific /32s instead of summarized blocks, you can hit these limits unexpectedly. Summarize routes on your side before advertising.
- BFD (Bidirectional Forwarding Detection), where supported on your router, detects link failure far faster than BGP’s own hold-timer-based detection — on the order of sub-second versus the default BGP hold timer’s tens of seconds. For DX+VPN failover where every second of detection time is downtime, enable BFD if your edge device supports it.
- Route propagation direction matters as much as the route itself. Confirm you’re not accidentally propagating a default route (0.0.0.0/0) from on-prem into AWS and overriding your NAT gateway egress path — this has genuinely happened to teams who didn’t scope what their on-prem BGP session advertises.
Overlapping CIDR: the problem that stalls more hybrid projects than anything else
If your on-prem network and your AWS VPCs share overlapping address space, you cannot route between them — full stop, no workaround at the routing layer. This is the single most common hybrid connectivity blocker, and it’s entirely preventable with planning done before any VPC exists (see the CIDR planning discipline covered in the VPC design reference).
When you inherit overlap after the fact — common in M&A scenarios, or when two previously-separate environments get connected — your real options are:
- Re-address one side. Expensive and disruptive, but the clean long-term fix. Usually only realistic for the AWS side (re-IP-ing an entire on-prem estate is rarely feasible on any reasonable timeline).
- NAT the overlap. Translate the overlapping ranges so they can route — in AWS this is typically done with a private NAT gateway behind a Transit Gateway, or with a NAT appliance in the path; confirm the current supported pattern against AWS documentation before committing to a design, because the components that can perform this have changed. This works but adds operational complexity — every troubleshooting session now needs to account for a translated address, and NAT doesn’t scale cleanly past a handful of overlapping segments.
- Scope connectivity to the non-overlapping subset. If only part of each network overlaps, sometimes the pragmatic fix is connecting only the ranges that don’t collide and accepting that the overlapping segments stay unreachable from each other — a partial but immediate solution while a proper re-addressing project is scoped.
None of these are good compared to having planned non-overlapping CIDRs from the start. The cost asymmetry is stark: an hour of planning versus a NAT workaround you’ll maintain indefinitely or a re-addressing project measured in weeks.
Direct Connect is not encrypted by default
This surprises people coming from a VPN-first mental model. A Direct Connect circuit is a private, dedicated network path — but “private” means isolated from the public internet, not encrypted by a mechanism you control. The precise position is worth stating carefully, because AWS’s own wording cuts both ways: the cross-connect between your router and the Direct Connect location is unencrypted unless you add MACsec, while AWS states it “provides additional security by encrypting all data at the physical layer as it flows across the network between Direct Connect locations and AWS Regions” (MAC Security in Direct Connect, AWS docs). So the exposed segment is the last mile into the DX facility, not the AWS backbone — but that is still a segment your compliance control probably cares about, and it is not encryption you chose, keyed, or can evidence.
Two ways to close that gap, with different trade-offs:
- MACsec on Direct Connect — supported on 10, 100 and 400 Gbps dedicated connections at selected points of presence, and on link aggregation groups composed of MACsec-capable connections. It is explicitly not supported on hosted connections, requires a MACsec-capable interface on your edge device, uses static CAK mode with 256-bit keys only, and carries no additional charge. It encrypts at line rate with minimal latency overhead. Note the default encryption mode on a new MACsec-enabled connection is
should_encrypt, which falls back to unencrypted traffic if negotiation fails — if your requirement is “encrypted or nothing,” you must setmust_encryptdeliberately and accept that a MACsec problem then becomes a connectivity outage. MACsec is also point-to-point on an Ethernet link, so AWS cautions it “does not provide end-to-end encryption across multiple sequential Ethernet or other network segments.” - IPsec VPN over Direct Connect — run a VPN tunnel across the DX path instead of (or alongside) using DX’s own transit VIF directly. You get DX’s throughput and determinism plus encryption, at the cost of IPsec’s own overhead eating into the circuit’s effective throughput, and the added operational complexity of managing a VPN on top of the physical circuit.
For workloads subject to a compliance requirement mandating encryption in transit, confirm which model applies before assuming “it’s on Direct Connect” satisfies the control — it doesn’t, by itself.
Redundancy: diverse locations, not just diverse circuits
A single Direct Connect circuit, however reliable, is a single physical path — one cross-connect, one set of route optics, one building. Real DX redundancy means two connections terminating at different Direct Connect locations, ideally served by different last-mile providers, so a single fiber cut, a single provider outage, or a single facility event doesn’t take down both paths simultaneously. Two circuits landing at the same DX location, on the same provider’s backhaul, is redundancy on paper that collapses under the specific failure it was meant to survive. Pair this with DX+VPN failover for defense in depth: diverse DX paths for the common case, VPN as the fallback when something takes out DX entirely.