AWS Hybrid Connectivity Explained: VPN vs Direct Connect vs Transit Gateway
Hybrid connectivity in AWS means connecting your on-premises network to your AWS VPCs so both sides can communicate using private IP addresses. Your data center, office, or branch location gets a direct private path into AWS. Traffic never touches the public internet, and your EC2 instances stay in private subnets with no public IPs required.
The real decision is which mechanism to use. Site-to-Site VPN works over your existing internet connection and can be up in hours. Direct Connect is a dedicated fiber circuit that bypasses the internet entirely but takes weeks to provision. Transit Gateway is not a transport at all; it is a hub that simplifies how multiple VPCs share those connections. Most teams start with VPN and add Direct Connect when production workloads demand it.
Need connectivity today? Start with Site-to-Site VPN. Moving terabytes of data regularly or running latency-sensitive production systems? Budget for Direct Connect. Managing more than two or three VPCs? Add Transit Gateway when the topology justifies it.
Simple explanation
Your AWS VPC is a private network in the cloud. By default it is isolated: nothing outside AWS can reach a resource in a private subnet without going through the public internet first. Hybrid connectivity creates a direct private channel between your on-premises router and that VPC, so both sides talk using private IPs without any public exposure.
A VPN does this over encrypted tunnels riding your normal internet connection. Direct Connect does it over a dedicated physical circuit that never touches the public internet. Either way, on-premises servers can reach private subnets in AWS directly, and AWS instances can reach your data center without a public IP on either end.
Road analogy: VPN is like driving to a destination on the public highway. You can get there, the cargo is encrypted so no one can read it, but you share the road with everyone else and traffic slows you down unpredictably. Direct Connect is like having a private access road built directly between your building and AWS. It costs more and takes time to build, but once it exists you have it entirely to yourself.
Why hybrid connectivity matters
Most organizations moving to AWS run a hybrid environment for years. Some services move to the cloud while others stay on-premises because of compliance, licensing, or migration timelines. These systems need to communicate privately.
- Migrations in progress: On-premises and AWS systems run side by side during a lift-and-shift. Hybrid connectivity keeps them talking throughout the transition.
- Private application access: Internal tools hosted in AWS should not be exposed to the public internet. Employees reach them over a VPN or Direct Connect connection instead.
- Database access: Production databases that stay on-premises initially need a private path from AWS application servers.
- Predictable networking: For latency-sensitive workloads, the public internet introduces variable delay. A dedicated circuit removes that variability entirely.
- Compliance requirements: Some regulatory frameworks require production traffic to never traverse the public internet. Direct Connect satisfies this requirement; VPN does not always qualify.
How hybrid connectivity works
Whether you use VPN or Direct Connect, traffic follows the same logical path through six steps:
- On-premises router or firewall: Your device initiates or terminates the connection. For VPN this requires a compatible VPN appliance. For Direct Connect this is your edge router at a colocation facility.
- VPN tunnel or Direct Connect circuit: The encrypted IPSec tunnel (VPN) or dedicated fiber circuit (Direct Connect) carries traffic between your site and AWS.
- Virtual Private Gateway or Transit Gateway: The AWS-side termination point. A Virtual Private Gateway (VGW) attaches to a single VPC. Transit Gateway is a hub that attaches to multiple VPCs at once.
- Route tables: The route tables in your VPC subnets must include a route to the on-premises CIDR range pointing at the VGW or Transit Gateway. Without this route, traffic will not flow even if the tunnel is up.
- Subnets and resources: Once routing is correct, instances in your VPC can reach on-premises IPs as if they were on the same local network.
- DNS resolution (optional but usually needed): If you want EC2 instances to resolve on-premises hostnames by name rather than IP, configure Route 53 private hosted zones or Route 53 Resolver forwarding rules alongside the network connection.
AWS hybrid connectivity options at a glance
| Option | Best for | Setup time | Bandwidth | Latency | Cost | Main limitation |
|---|---|---|---|---|---|---|
| Site-to-Site VPN | Quick starts, migrations, branch office access | Hours to days | Up to ~1.25 Gbps per tunnel | Variable (internet-dependent) | Low | Inconsistent latency, internet-dependent |
| Direct Connect | Production workloads, large data transfer, compliance | Weeks to months | 50 Mbps to 100 Gbps | Consistent and low | Medium to high | Long provisioning time, higher cost |
| Transit Gateway | Multi-VPC environments, hub-and-spoke topologies | Minutes (software only) | Depends on attached transport | Minimal added hop | Per-attachment plus data processing | Not a transport; requires VPN or Direct Connect |
Site-to-Site VPN
AWS Site-to-Site VPN creates two encrypted IPSec tunnels between your on-premises VPN device and a Virtual Private Gateway attached to your VPC. Traffic flows over your existing internet connection, encrypted end to end.
Best use cases: Starting a migration quickly, providing branch office access to VPC resources, connecting smaller sites, and low to moderate bandwidth workloads.
Strengths: Can be configured in hours once you have a compatible VPN device. No physical infrastructure to order. Low cost: an hourly rate for the connection plus standard data transfer charges. Each tunnel caps at approximately 1.25 Gbps, but you can add multiple tunnels with ECMP through Transit Gateway to scale throughput.
Tradeoffs: Traffic shares the public internet, so latency fluctuates with conditions. Each tunnel provides active or passive redundancy by default, meaning only one tunnel carries traffic at a time unless configured otherwise.
When not to use it: Avoid VPN for production database replication, real-time application backends, latency-sensitive workloads, or sustained transfers above roughly 1 Gbps.
Direct Connect
AWS Direct Connect is a physical fiber connection between your on-premises location (or colocation facility) and an AWS Direct Connect location. Traffic bypasses the public internet entirely and travels over a dedicated circuit.
Best use cases: Production workloads requiring consistent latency, large-scale data migration or replication, compliance environments that prohibit public internet exposure, and sustained high-throughput data transfer.
Strengths: Bandwidth options from 50 Mbps to 100 Gbps. Latency stays consistent and does not vary with internet conditions. Data transfer pricing is often lower than internet-based egress at scale. Satisfies compliance requirements for private traffic paths.
Tradeoffs: Provisioning takes four to twelve weeks. It requires coordination between AWS, a colocation facility, and often a carrier. Monthly cost is significantly higher than VPN. Not suitable for temporary use cases or workloads with modest bandwidth needs.
When not to use it: Do not order Direct Connect for early experiments, short-term migrations, or workloads where bandwidth needs are modest. The cost and provisioning time are not justified unless you have a clear production requirement.
Transit Gateway
Transit Gateway is a managed network hub. It aggregates multiple VPC connections, VPN connections, and Direct Connect links into a single routing plane. It is not a connectivity mechanism on its own.
Transit Gateway does not create the actual network path between your office and AWS. You still need either a Site-to-Site VPN or a Direct Connect circuit to carry the traffic. Transit Gateway controls how multiple VPCs share and route across those paths.
Without Transit Gateway, connecting one Direct Connect link to five VPCs requires five separate Virtual Private Gateways. With Transit Gateway, the Direct Connect link attaches once, all five VPCs connect to the same hub, and the Transit Gateway handles routing between them.
Transit Gateway also enables transitive routing between VPCs, which VPC Peering does not support. Any VPC connected to the Transit Gateway can reach any other connected VPC and any connected on-premises network through the hub. For shared or multi-VPC architectures, this is the standard approach.
For a single VPC with one hybrid connection, a Virtual Private Gateway attached directly to that VPC is simpler and cheaper. Add Transit Gateway when topology complexity justifies it.
When to use this
Fast migration start
Use Site-to-Site VPN. It can be up in hours. Your on-premises servers and the AWS environment can communicate immediately while you build out the rest of the architecture.
Branch office or private app access
Use Site-to-Site VPN. Employees at a branch office can access internal applications running in AWS without those apps being publicly exposed on the internet.
Large continuous data transfer
Use Direct Connect. If you regularly move multi-terabyte datasets for analytics, backups, or database replication, Direct Connect provides better throughput and more predictable cost than internet-based transfer.
Latency-sensitive production systems
Use Direct Connect. If application performance depends on consistent round-trip times between on-premises and AWS, the public internet introduces too much variability to be reliable.
Multi-VPC enterprise environments
Use Transit Gateway with VPN or Direct Connect. If you have more than two or three VPCs that all need access to on-premises, Transit Gateway is far simpler to manage than separate gateways for each VPC.
High-availability hybrid design
Use Direct Connect as the primary path and Site-to-Site VPN as a failover. Configure BGP so that if the Direct Connect circuit fails, traffic automatically reroutes over the VPN backup.
VPN vs Direct Connect vs Transit Gateway
| Factor | Site-to-Site VPN | Direct Connect | Transit Gateway |
|---|---|---|---|
| Speed to deploy | Hours to days | Weeks to months | Minutes (software only) |
| Performance consistency | Variable (internet-dependent) | Consistent and predictable | Depends on attached transport |
| Max throughput | ~1.25 Gbps per tunnel | Up to 100 Gbps | Not applicable (routing only) |
| Complexity | Low | Medium to high | Medium (adds topology overhead) |
| Cost | Low | High | Per-attachment plus data processing fee |
| Topology scale | One VPC per VGW | One VPC per VGW (or many via Transit Gateway) | Hundreds of VPCs and attachments |
| Redundancy patterns | Two tunnels (active/passive) | Two circuits recommended | Multiple attachments per type |
Common architecture patterns
VPN only
On-premises VPN device connects via two IPSec tunnels to a Virtual Private Gateway attached to the VPC. Simple, fast, and sufficient for most early-stage workloads, branch offices, and non-latency-sensitive use cases.
Direct Connect only
On-premises router connects via a Direct Connect circuit to an AWS Direct Connect location, then to a Virtual Private Gateway in the VPC. Best for production workloads with sustained throughput requirements. Has a single point of failure unless you provision redundant circuits.
Direct Connect primary with VPN backup
This is the most common enterprise pattern. Direct Connect carries production traffic under normal conditions. A Site-to-Site VPN is configured in parallel. BGP route preferences are set so Direct Connect is preferred. If the circuit fails, BGP converges and VPN takes over automatically.
Transit Gateway for multiple VPCs
A single VPN or Direct Connect attachment connects to Transit Gateway. All VPCs attach to the same Transit Gateway. Route tables on the Transit Gateway control which VPCs can reach on-premises and which can reach each other. This replaces a mesh of individual VGW attachments.
Migration phase: start with VPN, evolve later
Most teams start with VPN because it is fast and cheap. As workloads mature and bandwidth or latency requirements grow, they add Direct Connect. If VPC count increases, they introduce Transit Gateway. You do not need to plan for the final architecture on day one.
Routing and DNS considerations
Static routes vs BGP
With static routing, you manually enter on-premises CIDR ranges in AWS and VPC CIDRs in your on-premises device. Simple to configure but requires manual updates whenever network ranges change.
With BGP, your router and AWS exchange routes automatically. BGP is preferred for Direct Connect because it enables automatic route propagation, graceful failover between primary and backup paths, and route filtering. Most enterprise routers support BGP.
Non-overlapping CIDRs
Your on-premises network CIDR and your VPC CIDR must not overlap. If both sides use addresses within 10.0.0.0/8, routing becomes ambiguous and connectivity will fail. Plan non-overlapping ranges before creating any VPCs. See VPC Networks Explained for CIDR planning guidance. Fixing this after VPCs are built is disruptive and expensive.
Route table updates
Adding a VPN or Direct Connect attachment does not automatically add routes to your VPC subnets. You must update the route tables in each subnet to include a route pointing at the Virtual Private Gateway or Transit Gateway for any on-premises CIDR you want to reach. Enable route propagation on the VGW to automate this for BGP-advertised routes.
Private DNS and Route 53 Resolver
By default, EC2 instances in your VPC cannot resolve on-premises hostnames, and on-premises servers cannot resolve private AWS DNS names. Configure Route 53 private hosted zones for your AWS domains and use Route 53 Resolver forwarding rules to forward on-premises DNS queries to your corporate DNS server. This is a common oversight that causes confusing failures after the network link is already working correctly.
Common mistakes
Overlapping CIDR ranges. The most common failure point. If your on-premises network and VPC both use addresses in the same range, routing breaks silently. Plan non-overlapping CIDRs at the architecture stage because reworking this after VPCs are built is painful.
Using VPN for latency-sensitive workloads. VPN traffic takes the public internet, so latency varies. For real-time application backends, database replication, or anything requiring consistent sub-20ms round trips, VPN is the wrong tool. Use Direct Connect for those workloads.
Forgetting route table updates. A new VPN or Direct Connect attachment does not automatically make your subnets routable. You must explicitly add routes in every subnet that needs on-premises access.
Misunderstanding VPN tunnel failover. Site-to-Site VPN provides two tunnels, but only one is active at a time by default. Some on-premises VPN devices require specific configuration to handle failover correctly. Test this before relying on it in production.
Underestimating Direct Connect lead time and cost. Direct Connect typically takes four to twelve weeks to provision. Do not assume you can order it and have it working in a few days. For small teams or early workloads, VPN is usually the correct starting point and Direct Connect is premature.
Adding Transit Gateway when it is not needed. If you have one VPC and one on-premises network, a Virtual Private Gateway is simpler and cheaper. Transit Gateway adds per-attachment and per-GB processing costs. Add it when topology complexity justifies it.
Skipping DNS configuration. A working network tunnel does not mean DNS works. If your tools resolve hostnames rather than IPs, the network will appear broken even when routing is correct. Configure Route 53 Resolver rules alongside the network connection.
Troubleshooting checklist
If hybrid connectivity is not working, work through this list before escalating. See also Troubleshooting Network Issues in AWS for a broader diagnostic guide.
Before checking routing or DNS, try connecting by IP address rather than hostname. If IP works but the hostname does not, the issue is DNS rather than networking. This one check saves a lot of time.
- Are the tunnels or circuits up? For VPN, check tunnel status in the AWS console. Both tunnels should show UP for full redundancy. For Direct Connect, verify connection state and virtual interface status.
- Are routes present in both directions? VPC route tables must have a route to the on-premises CIDR via the VGW or Transit Gateway. On-premises, your router must have a route to the VPC CIDR via the tunnel or circuit.
- Are CIDRs overlapping? Check whether the on-premises network range and VPC range overlap. Even partial overlap causes routing failures that are hard to diagnose.
- Are security groups and NACLs allowing the traffic? Even with correct routing, security groups on the EC2 instance or network ACLs on the subnet can silently block traffic. Confirm the relevant rules allow the on-premises IP range.
- Is DNS resolving correctly? Check Route 53 Resolver rules and private hosted zone configuration if hostname resolution is failing while IP connectivity works.
- Which path is primary and which is backup? For Direct Connect plus VPN architectures, confirm that BGP preferences are set correctly and traffic is actually using the expected path. Misconfigured BGP MED or local preference values can cause VPN to take over when it should not.
Summary
- Hybrid connectivity creates a private network path between on-premises infrastructure and AWS VPCs with no public internet required.
- Site-to-Site VPN uses encrypted IPSec tunnels over the internet. Fast to set up, roughly 1.25 Gbps per tunnel, variable latency. Best for quick starts and low-bandwidth workloads.
- Direct Connect uses a dedicated fiber circuit. 50 Mbps to 100 Gbps, consistent latency, takes weeks to provision and costs significantly more. Best for production, compliance, and high-throughput workloads.
- Transit Gateway is a routing hub, not a transport. It aggregates VPC attachments, VPN connections, and Direct Connect links. Valuable for multi-VPC topologies.
- Direct Connect as the primary path with VPN as backup is the standard high-availability pattern for enterprise environments.
- Route tables, non-overlapping CIDRs, and DNS configuration are the three most common causes of hybrid connectivity failures.
Frequently asked questions
What is hybrid connectivity in AWS?
Hybrid connectivity means creating a private network path between your on-premises infrastructure and your AWS VPCs. On-premises resources and AWS resources communicate using private IP addresses, with no public internet exposure required.
Can I use VPN and Direct Connect together?
Yes, and this is a common production pattern. Teams use Direct Connect as the primary path for reliable, high-throughput traffic and configure a Site-to-Site VPN as an automatic failover backup. If the Direct Connect circuit goes down, BGP routes traffic over the VPN automatically.
When should I choose Direct Connect over VPN?
Choose Direct Connect when you need consistent low latency, high sustained throughput above roughly 1 Gbps, or when compliance requirements prohibit traffic over the public internet. If your use case is occasional access, low bandwidth, or you need connectivity in days rather than weeks, VPN is usually the better starting point.
Do I need Transit Gateway for one VPC?
No. If you are connecting a single on-premises network to a single VPC, a Virtual Private Gateway attached directly to that VPC is sufficient. Transit Gateway becomes valuable when you have multiple VPCs or multiple hybrid connections to aggregate through a single hub.
What is the most common beginner mistake with hybrid connectivity?
Overlapping CIDR ranges. If your on-premises network and your VPC both use addresses within the same range, routing becomes ambiguous and traffic will not flow correctly. Plan non-overlapping CIDRs before creating any VPCs or hybrid connections.