Direct Connect vs Site-to-Site VPN: Choosing for a Migration
Start a migration on an AWS Site-to-Site VPN over the public internet, because you can bring it up in hours, and add AWS Direct Connect only when you need consistent latency, sustained throughput above what a VPN gives you, or a cheaper path for bulk data transfer. The choice between Direct Connect vs Site-to-Site VPN is really a decision about lead time, throughput and cost, not about security. Neither is a drop-in replacement for the other, and plenty of teams end up running both.
This matters most during a migration, when you are moving large volumes of data on a schedule and cannot afford to discover a throughput ceiling on cutover weekend. The rest of this article is the detail behind that answer: what to check first, the numbers that actually decide it, and the phased approach that keeps you moving while the physical circuit gets provisioned.
Direct Connect vs Site-to-Site VPN: what each one actually is
A Site-to-Site VPN is an IPsec connection between your customer gateway (a firewall or router on your side) and AWS, running over the public internet. It is fully managed, and a single VPN connection gives you two tunnels for redundancy. You can create it entirely in software, which is why it is the fast option.
Direct Connect is a physical circuit. (cite index="dc-faq">A dedicated connection is made through a 1 Gbps, 10 Gbps, 100 Gbps, or 400 Gbps Ethernet port dedicated to a single customer</cite>, ordered through the Direct Connect console or a Direct Connect Partner. Because it is a physical port in a colocation facility, it has real lead time, and you cannot change the port speed after the fact. Per the AWS docs, the possible port values are 1, 10, 100 and 400 Gbps and you cannot change the port speed after you create the connection request; to change it you create a new connection.
The two are not mutually exclusive. AWS explicitly supports Direct Connect plus Site-to-Site VPN, where you run IPsec tunnels over a Direct Connect public virtual interface to get an encrypted, low-latency, higher-bandwidth path that behaves more predictably than an internet VPN.
What to check before you change anything
Do this before you order a circuit or terminate a tunnel. The order matters because a Direct Connect circuit can take weeks to light, and you do not want that discovery on the critical path.
- Confirm your on-premises equipment. Your customer gateway device has to support the throughput you are planning. AWS is explicit that if you want the higher VPN tunnel bandwidth, you must ensure your firewall or VPN appliance and internet connection support higher throughput. A 5 Gbps tunnel behind a 1 Gbps internet uplink is still a 1 Gbps path.
- Decide static or dynamic routing now. If you plan to aggregate tunnels for bandwidth, you need BGP. Per the AWS quotas page, ECMP requires the VPN connection to be configured for dynamic routing and is not supported on static-routing connections. Retrofitting BGP later is more disruptive than starting with it.
- Check whether you have equipment in a Direct Connect location. The AWS docs are blunt: if you do not have equipment in the Direct Connect location, you cannot order a cross connect for yourself there. If you do not, you are working through a partner, which adds time.
- Plan your IP address space and CIDRs so on-premises and VPC ranges do not overlap. Overlapping ranges are the most common reason a working tunnel routes nothing.
The numbers that actually decide it
Throughput is usually the deciding factor for a migration, so be precise about it.
A Site-to-Site VPN tunnel has a bandwidth ceiling. The default is 1.25 Gbps per tunnel, and AWS now offers a higher tier: Site-to-Site VPN supports up to 5 Gbps per tunnel, a 4x improvement from the existing 1.25 Gbps limit. There is a catch worth reading twice: the Large (5 Gbps) tunnel option is supported for Transit Gateway VPN and Cloud WAN VPN, but not for virtual private gateway (VGW) based VPN. If your architecture terminates on a VGW, you are capped at the Standard tier.
Two more constraints on VPN throughput. First, a single flow cannot exceed one tunnel, so ECMP raises aggregate bandwidth, not per-flow bandwidth. Second, realized bandwidth is not guaranteed: on the public internet, your throughput varies with congestion you do not control.
Direct Connect removes the internet-path variability and gives you a fixed port speed. For a large lift-and-shift or a database move where you are pushing terabytes on a deadline, a dedicated port is the difference between a predictable transfer window and a moving target.
Encryption: neither option is automatic the way you think
This is where teams get caught. A VPN is encrypted; a plain Direct Connect is not. The AWS whitepaper says it directly: Direct Connect is not encrypted by default; for 10 or 100 Gbps dedicated connections you can use MACsec, and for connections of 1 Gbps or less you can run VPN tunnels on top.
So if your compliance posture requires encryption in transit, a Direct Connect on its own does not satisfy it unless you add MACsec (available only on the larger ports) or layer IPsec over it. That layered pattern is the DX-plus-VPN design: you get the end-to-end secure IPsec connection combined with the low latency and increased bandwidth of Direct Connect, which is more consistent than an internet-based VPN.
| Consideration | Site-to-Site VPN | Direct Connect |
|---|---|---|
| Time to stand up | Hours | Weeks (physical circuit and cross connect) |
| Per-tunnel bandwidth | 1.25 Gbps default, up to 5 Gbps on TGW/Cloud WAN | Fixed port: 1, 10, 100 or 400 Gbps |
| Path | Public internet, variable | Dedicated, predictable |
| Encryption | IPsec, built in | Not by default; add MACsec or IPsec |
| Redundancy for SLA | Two tunnels per connection | Second connection needed for the higher SLA tier |
A phased approach that fits a real migration
The pattern that works: VPN first, Direct Connect in parallel, then cut the bulk transfer over to Direct Connect once it is live. It keeps you unblocked while the circuit provisions.
Phase 1: VPN now. Stand up a Site-to-Site VPN on a Transit Gateway with dynamic routing (BGP). This gives you connectivity today and, because it is on a Transit Gateway rather than a VGW, keeps the 5 Gbps tunnel and ECMP options open. If a single 5 Gbps tunnel is not enough, you can combine tunnels: AWS notes you can combine two 5 Gbps tunnels in a single VPN connection to reach 10 Gbps, and aggregate across connections for more, subject to your customer gateway supporting ECMP.
The trade-off you are accepting: the VPN rides the public internet, so latency and throughput vary, and per-flow bandwidth is capped. For steady replication traffic (many flows) that is usually fine. For a single large stream it can bottleneck.
Phase 2: order Direct Connect in parallel. Start the circuit on day one so lead time runs alongside your build. Expect a paperwork loop: AWS issues a Letter of Authorization and Connecting Facility Assignment (LOA-CFA). Your network provider needs the LOA-CFA to order the cross connect.
Phase 3: design for the SLA you need. One circuit is a single point of failure. Use the Direct Connect Resiliency Toolkit, which offers models mapped to targets: Maximum resiliency for a 99.99% SLA, High resiliency for 99.9%, and a development and test model for non-critical workloads. The cost that shows up later if you skip this: a single-circuit design meets no meaningful SLA, and adding resilience after cutover means ordering more physical ports under time pressure.
Getting this sequencing right is most of what a clean cloud migration comes down to, and the connectivity design should be settled as part of your landing zone and network architecture rather than improvised at cutover.
The tier detail that trips people up
When you create the VPN connection, the tunnel bandwidth tier is set at the connection level and applies to both tunnels. If you do not explicitly select the higher tier, the connection defaults to the Standard (1.25 Gbps) tier. If you provisioned expecting 5 Gbps but did not select the higher tier, you will be quietly capped at a quarter of that.
Verify the applied tier on the VPN connection details after creation rather than assuming the request took, then confirm both tunnels report the bandwidth you expect before you point replication traffic at them.
Frequently asked questions
Is Direct Connect encrypted by default?
No. Direct Connect is not encrypted by default. On 10 or 100 Gbps dedicated ports you can enable MACsec, and on connections of 1 Gbps or less you layer IPsec VPN tunnels on top. If your controls require encryption in transit, plan for one of those from the start rather than treating a bare circuit as compliant.
How much throughput can a Site-to-Site VPN really carry?
The default is 1.25 Gbps per tunnel, and the higher tier reaches up to 5 Gbps per tunnel, but only on Transit Gateway or Cloud WAN, not on a virtual private gateway. A single TCP or UDP flow is pinned to one tunnel, so it cannot exceed that per-tunnel limit; ECMP with dynamic routing raises aggregate throughput across many flows. Realized bandwidth also depends on packet size, traffic mix and general internet conditions, so treat the ceiling as a maximum, not a guarantee.
Can I use both Direct Connect and a VPN at the same time?
Yes, and it is a documented pattern. You run IPsec tunnels over a Direct Connect public virtual interface to combine encryption with the low latency and higher, more consistent bandwidth of a dedicated circuit. Many teams also keep an internet VPN as a backup path in case the Direct Connect circuit fails.
How long does Direct Connect take to provision?
Longer than a VPN, which is the main reason to start a VPN first. After you request a dedicated connection AWS issues an LOA-CFA, and your network provider uses it to order the physical cross connect, which involves colocation lead times you do not fully control. If you have no equipment in a Direct Connect location you must work through a partner, which adds more time, so order the circuit at the very start of the project.
Should I terminate my VPN on a Transit Gateway or a virtual private gateway?
For a migration, prefer a Transit Gateway. It keeps the 5 Gbps Large tunnel option and ECMP aggregation available, both of which are unsupported on a virtual private gateway. A Transit Gateway also scales more cleanly when you connect additional VPCs and accounts, which most migrations end up needing.
