You need to connect an on-premises data center to a VPC. How do you choose between AWS Site-to-Site VPN and AWS Direct Connect?
answer
- days versus weeks to provision
- private is not the same as encrypted
- jitter matters more than mean latency
- egress rate is the cost lever
- one circuit is one point of failure
basics
~20 sSite-to-Site VPN is IPsec over the public internet: available the same day, cheap, but limited per-tunnel throughput and internet-grade latency. Direct Connect is a dedicated private link with predictable latency, high throughput and cheaper egress, but weeks of lead time and no encryption by default.
solid answer
~50 sStart with Site-to-Site VPN unless something rules it out. It is IPsec over the public internet, you can have it running the same day, it costs a small hourly charge plus normal egress rates, and AWS publishes roughly 1.25 Gbps as the maximum per tunnel — with the jitter and packet loss of whatever path the internet gives you. Direct Connect is a physical port at a Direct Connect location: dedicated 1, 10 or 100 Gbps, or a smaller hosted connection through a partner. You get predictable latency, sustained throughput and a lower per-GB data-transfer-out rate, but provisioning takes weeks and one connection is a single point of failure. The detail people miss is that Direct Connect is private but **not encrypted** — if you need encryption in transit you add MACsec on supported ports or run an IPsec VPN over it. The common landing is Direct Connect for the bulk path with a VPN as backup.
go deeper
Know the one-line difference: Site-to-Site VPN is encrypted IPsec over the public internet and is available immediately; Direct Connect is a dedicated physical link that takes weeks to provision.
Compare them on the axes that decide it — provisioning time, per-tunnel throughput versus port speed, latency consistency, egress pricing — and be ready to state plainly that Direct Connect is private but not encrypted.
Demonstrate the resilience design: never a lone circuit, a VPN or second connection as the failover path, BGP advertising the same prefixes for automatic cutover, and a Direct Connect gateway or Transit Gateway when many VPCs must be reached.
Frame it as a commitment decision — port and carrier contracts versus usage-based VPN, the egress volume at which the port pays for itself, and how much resiliency the business will fund against the cost of a hybrid outage.
## The two products **AWS Site-to-Site VPN** builds IPsec tunnels between your customer gateway device and an AWS endpoint — either a virtual private gateway attached to one VPC or a Transit Gateway serving many. The traffic crosses the public internet, encrypted. You create it through the API and it is usable in minutes once your network team configures the device. **AWS Direct Connect** is a physical cross-connect. You (or a partner) run a port at a Direct Connect location and AWS gives you a dedicated link — 1, 10 or 100 Gbps for a dedicated connection, or a smaller hosted connection from a partner. On top of that port you create virtual interfaces: a *private VIF* reaching a VPC through a virtual private gateway or a Direct Connect gateway, a *public VIF* reaching AWS public endpoints such as S3, and a *transit VIF* reaching a Transit Gateway. ## The axes that actually decide it **Lead time.** VPN: hours. Direct Connect: weeks to months, because it involves cross-connects, a colocation facility and possibly a carrier contract. This alone decides the first connection of almost every migration — you start on VPN because you have to. **Throughput.** AWS publishes about 1.25 Gbps as the maximum per VPN tunnel; you scale past that with multiple tunnels and equal-cost multipath when terminating on a Transit Gateway, not by making one tunnel faster. Direct Connect gives you the port speed you bought, sustained. **Latency consistency.** The internet path is usually fine and occasionally is not. Direct Connect's value is less about raw latency than about the *variance* — replication, chatty database protocols and file-system traffic care much more about jitter than about the mean. **Cost shape.** VPN has a small hourly charge and your data leaves at ordinary internet egress rates. Direct Connect has a port-hour charge plus a per-GB data-transfer-out rate that is materially lower than internet egress. High steady volume is what makes the port pay for itself; low volume never will. **Encryption.** This is the question inside the question. A VPN is encrypted by definition. Direct Connect is a private circuit, not an encrypted one — the packets are in the clear on that link. If a compliance regime demands encryption in transit you either enable MACsec, available on supported dedicated ports at supported locations, or run an IPsec VPN across the Direct Connect (historically over a public VIF; AWS also offers private-IP VPN over Direct Connect with a Transit Gateway). Candidates who assume "private line therefore encrypted" get caught here. ## Resilience, which is where real designs live One Direct Connect connection is one cable, one port, one facility, and it will eventually go down for maintenance or a fibre cut. The recognized patterns, in increasing order of cost: - a single connection with a Site-to-Site VPN as the failover path; - two connections at the same location on separate devices; - two connections at two different Direct Connect locations, which is what AWS calls maximum resiliency and what you want for anything production-critical. Both VPN and Direct Connect can advertise your on-premises prefixes to AWS with BGP and learn VPC prefixes back, which is what makes failover automatic instead of a change window. ## Reaching many VPCs A private VIF terminating on a virtual private gateway reaches exactly one VPC. Once you have several, you either put a Direct Connect gateway in front — letting one connection reach multiple VPCs, including across Regions — or attach a Transit Gateway via a transit VIF and let the hub distribute. The same question applies to VPN: terminating on a Transit Gateway instead of per-VPC virtual private gateways is what stops you from building one VPN connection per VPC. ## How to answer it out loud Ask what the workload is before choosing. Sustained bandwidth, jitter tolerance, egress volume, compliance requirements, and how soon it has to work. Then give a shaped answer: "VPN today because we need it this month; Direct Connect ordered in parallel if the replication volume holds, with the VPN kept as the backup path." That is what an operator says; a catalogue recital is not.
- Direct Connect is a private circuit — does that satisfy an encryption-in-transit requirement?No. Direct Connect is private but unencrypted; traffic crosses the link in the clear. To encrypt it you enable MACsec on a supported dedicated port and location, or run an IPsec Site-to-Site VPN over the Direct Connect. Auditors ask for the encryption control specifically, not for network privacy.
- A single 10 Gbps Direct Connect is not enough resilience. What are the options?Add a second connection — at the same location on a different device for basic redundancy, or at a second Direct Connect location for maximum resiliency. A cheaper middle ground is one Direct Connect with a Site-to-Site VPN as the failover path, with BGP advertising the same prefixes so failover is automatic.
- You need on-premises to reach twenty VPCs. Does that change the design?Yes — a private virtual interface on a virtual private gateway serves one VPC, which does not scale. Either put a Direct Connect gateway in front to reach many VPCs across accounts and Regions, or terminate on a Transit Gateway using a transit virtual interface and let the hub distribute routes.
saying these in an interview costs you the question
- Direct Connect is encrypted because it is a private line
- One VPN tunnel scales to 10 Gbps if the instance is big enough
- Direct Connect can be provisioned in an afternoon like a VPN
- A single Direct Connect connection is a highly available design
- Direct Connect makes data transfer out free