AWS Direct Connect Explained: How It Works and When to Use It
AWS Direct Connect gives your on-premises network a dedicated fiber path into AWS, one that never touches the public internet. For teams moving large volumes of data regularly or running latency-sensitive production workloads across cloud and on-premises, it is the right architecture. For most teams in early migration phases or with modest bandwidth needs, Site-to-Site VPN is simpler and sufficient.
Simple explanation
AWS Direct Connect is a dedicated network connection between your data center (or office) and AWS. Instead of your traffic traveling over the public internet as it does with VPN, it travels over a private fiber circuit that AWS has provisioned at a colocation facility near you.
The main reasons teams choose it: the connection has consistent, predictable latency; it can carry far more bandwidth than VPN allows; and in high-volume scenarios, the per-gigabyte data transfer cost from AWS can be lower than internet-based transfer.
It is usually not worth it if your bandwidth needs are modest, you need connectivity quickly, or you are still figuring out your cloud architecture. Direct Connect takes weeks to provision and costs more up front than a VPN setup.
Start with Site-to-Site VPN. Upgrade to Direct Connect when you are regularly moving multiple terabytes between on-premises and AWS, your applications need sub-10ms consistent latency, or compliance rules out the public internet entirely. Most teams reach that point later than they expect.
Why teams use AWS Direct Connect
As organizations deepen their AWS footprint, data volume between on-premises and cloud grows. A team running analytics workloads might regularly move dozens of terabytes between an on-premises data warehouse and Amazon Redshift or S3. At scale, the per-gigabyte cost of that data leaving AWS over the internet adds up quickly, and VPN’s bandwidth ceiling becomes a real constraint.
Predictable latency. Internet latency varies unpredictably: 20ms one moment, 80ms the next. Direct Connect typically delivers single-digit millisecond latency to the nearest AWS region, and it barely fluctuates. Applications that connect to databases or services across cloud and on-premises boundaries benefit most. See the Hybrid Connectivity Overview for a comparison of all three approaches side by side.
Higher throughput. Dedicated connections support 1 Gbps, 10 Gbps, and 100 Gbps. VPN tunnels cap at around 1.25 Gbps each. If your workload needs to sustain several gigabits per second, Direct Connect is the only option that scales.
Potential cost reduction on data transfer. AWS charges for data leaving the network (egress). The per-GB rate for Direct Connect egress is lower than standard internet egress. At high volumes, that difference can offset the port cost. At low volumes, it does not.
Compliance requirements. Some industries require that data never traverse the public internet. Direct Connect satisfies that requirement as a private circuit, though it is not encrypted by default. More on that in the resilience section below.
When it is not worth it. Many teams do not need it. If your data transfer volumes are low, your latency tolerance is normal, and you have no strict private-connectivity compliance requirements, VPN handles hybrid connectivity with far less setup time and cost.
How AWS Direct Connect works
The flow from your office to an AWS resource involves several steps. Most beginners picture a cable running from their building directly to an AWS data center. That is not how it works.
Your on-premises location. This is your data center, office, or colocation cage. This is where your routers and servers live.
The AWS Direct Connect location. This is a colocation facility (Equinix, CoreSite, CyrusOne, and similar operators) where AWS has deployed its own networking equipment. AWS has over 100 of these locations globally. Direct Connect traffic terminates here, not at an AWS data center.
Getting to the Direct Connect location. If your data center is physically inside the same colocation facility, you can order a cross-connect: a physical cable run from your cage to AWS’s cage. That is the fastest and simplest path. If you are somewhere else, you work with a carrier or an AWS Direct Connect Partner to provision a circuit between your location and the Direct Connect facility. This is where provisioning time and carrier cost come from.
The AWS port. AWS provisions a dedicated Ethernet port for your connection at the Direct Connect location. That port is yours. Bandwidth is not shared with other customers.
Virtual Interfaces (VIFs). On top of the physical port, you create one or more Virtual Interfaces. Each VIF is a VLAN-tagged logical connection that routes traffic to a specific AWS destination. VIFs are explained in detail in the next section.
Routing into AWS. Depending on your design, a VIF connects to a Virtual Private Gateway (VGW, attached to a single VPC), a Direct Connect Gateway (DCGW, lets you reach VPCs in multiple regions from one connection), or a Transit Gateway (TGW, a hub router for multi-VPC and multi-connection architectures). How VPC networks are structured affects which gateway option fits your design.
BGP handles route exchange. BGP (Border Gateway Protocol) is the routing protocol used for all Direct Connect connections. It is not optional. Your on-premises router and AWS exchange route advertisements over BGP. This is how AWS learns which on-premises CIDR blocks exist, and how your router learns which VPC CIDRs to route toward AWS. Route tables in AWS are updated automatically when route propagation is enabled on the Virtual Private Gateway.
Private rail analogy: VPN is like driving on a public highway. You share the road with everyone else, traffic varies, and speed is unpredictable. Direct Connect is like a private rail line between your facility and AWS: no shared road, no traffic jams, consistent performance. Laying the rail takes time and costs money. Whether it is worth it depends on how much cargo you are moving and how reliably it needs to arrive on schedule.
Dedicated vs hosted connections
There are two ways to get a Direct Connect connection: order a dedicated connection directly from AWS, or get a hosted connection through an AWS Direct Connect Partner.
| Feature | Dedicated Connection | Hosted Connection |
|---|---|---|
| Who orders it | You, directly with AWS | An AWS Direct Connect Partner orders on your behalf |
| Available speeds | 1 Gbps, 10 Gbps, 100 Gbps | 50 Mbps to 10 Gbps (varies by partner) |
| Number of VIFs | Up to 50 VIFs per port | One VIF (the partner manages the port) |
| Provisioning time | Weeks to months (physical infrastructure) | Potentially faster if partner has existing infrastructure |
| Cost profile | Full port cost (hourly) plus data transfer | Lower entry cost; fraction of a port |
| Control | Full control over VIF configuration | Partner manages the port; you manage one VIF |
| Best for | Large enterprise, multi-VIF, high-throughput workloads | Smaller requirements, faster time to connectivity, lower commitment |
Most large enterprise deployments use dedicated connections. Hosted connections are practical when you want to test Direct Connect before committing to a full port, or when your bandwidth needs sit comfortably below 1 Gbps.
Virtual interfaces explained
A Direct Connect port is a physical connection. Virtual Interfaces (VIFs) are logical connections you create on top of that port. Each one is a VLAN-tagged session that carries traffic to a different AWS destination. Getting the VIF type wrong is one of the most common setup mistakes.
Power strip analogy: Think of the Direct Connect port as a single power socket in the wall. VIFs are the individual plugs you run from that socket to different devices. One plug goes to your production VPC, one goes to your dev VPC, one goes directly to AWS public services like S3. Same physical socket, different logical destinations.
Private VIF
A Private VIF routes traffic to resources inside a VPC: EC2 instances, RDS databases, private subnets. You associate a Private VIF with a Virtual Private Gateway (VGW) attached to a specific VPC, or with a Transit Gateway for multi-VPC routing. This is the type most teams need for hybrid application connectivity.
Common confusion: a Private VIF does not reach AWS public service endpoints like S3 directly. For that, you need a Public VIF, or you can use a VPC endpoint inside your VPC.
Public VIF
A Public VIF routes traffic to AWS public endpoints: S3, DynamoDB, CloudFront, EC2 public IPs, and other AWS service endpoints that have public IP addresses. Traffic takes the Direct Connect path instead of the internet, but it does not enter a VPC. This is useful when your on-premises systems need to access S3 or other managed services without going through the internet.
A Public VIF cannot reach EC2 instances or RDS databases in private subnets. If your goal is to connect on-premises servers to VPC resources, you need a Private VIF. Teams that create a Public VIF for this purpose and then wonder why their EC2 instances are unreachable have hit this mistake.
Transit VIF
A Transit VIF connects to an AWS Transit Gateway. Use this when you have multiple VPCs and want to reach all of them through a single Direct Connect connection. The Transit Gateway acts as a hub: the Direct Connect link attaches once, and all attached VPCs are reachable. This is the right choice for organizations with more than a few VPCs in the same region.
A single dedicated connection can carry multiple VIFs. For example: one Private VIF for your production VPC, one Private VIF for your development VPC, and one Public VIF for S3 access. Hosted connections are limited to one VIF.
A Direct Connect Gateway (DCGW) allows one Direct Connect connection to reach VPCs in multiple AWS regions. Without it, reaching a second region requires a second Direct Connect connection. For multi-region architectures, a Direct Connect Gateway significantly reduces cost and operational overhead.
AWS Direct Connect vs Site-to-Site VPN
| Factor | Direct Connect | Site-to-Site VPN |
|---|---|---|
| Setup time | Weeks to months (physical provisioning) | Hours (no physical infrastructure needed) |
| Maximum bandwidth | Up to 100 Gbps (dedicated) | ~1.25 Gbps per tunnel |
| Latency consistency | Consistent, predictable (dedicated path) | Variable (traverses public internet) |
| Encryption | Not encrypted by default; private circuit only | Encrypted by default (IPSec) |
| Monthly cost | Higher; port-hour charges plus data transfer | Lower; connection fee plus data transfer |
| Operational complexity | Higher; BGP required, carrier coordination, VIF management | Lower; AWS console config, compatible with most firewalls |
| Resilience pattern | Single connection has no built-in redundancy; resilience requires deliberate design | Dual tunnels built in; both terminate in different AZs |
| Best use cases | Large data transfers, latency-sensitive production, compliance | Early migration, low bandwidth, encrypted internet path |
When VPN is the right answer: You need connectivity this week, your bandwidth is under a gigabit, your workloads can tolerate variable latency, or you are still measuring what your steady-state requirements actually are. Most teams in the first year of an AWS migration belong here. AWS Site-to-Site VPN is well-documented and straightforward to configure.
When Direct Connect is justified: You are regularly transferring multiple terabytes between on-premises and AWS, your applications have measurable latency sensitivity, you have compliance requirements that prohibit internet paths, or your bandwidth needs consistently exceed what VPN can sustain.
When Direct Connect plus VPN is the right pattern: Production hybrid architectures often use both. Direct Connect is the primary path for performance, and a Site-to-Site VPN acts as an automatic fallback if the Direct Connect link fails. BGP routes prefer Direct Connect when it is healthy and shift to VPN only when it goes down.
When to use Direct Connect
These scenarios genuinely benefit from a dedicated connection:
- Large recurring data transfers. Weekly or daily bulk sync jobs that move tens of terabytes between on-premises storage and S3 or Redshift. At scale, the lower egress rate on Direct Connect offsets the port cost.
- Hybrid production databases. An application running on EC2 that queries a database still on-premises. The latency difference between a consistent 4ms on Direct Connect and a variable 20 to 80ms on VPN can mean the difference between a responsive and a sluggish application.
- Strict private connectivity requirements. Financial services, healthcare, and government workloads that require data to never traverse the public internet. A dedicated physical circuit satisfies this where VPN over the internet does not, though you still need to add encryption separately if required.
- Multi-VPC production architectures. When you have several production VPCs and need reliable, high-bandwidth access across all of them from on-premises, a Transit VIF through a Transit Gateway with a Direct Connect Gateway handles this efficiently. See Shared VPC Architectures for related topology patterns.
- Migration phases with predictable bandwidth. Large-scale database or server migrations where consistent throughput matters more than speed of setup. Direct Connect removes the internet as a variable in migration planning.
When VPN is enough
Direct Connect is not the default answer. Use VPN when:
- You are in early migration phases. If you are still deciding which workloads move to AWS, committing to a Direct Connect provisioning cycle before your architecture is stable is premature.
- Bandwidth needs are low or variable. Accessing management tooling, syncing configuration files, running occasional batch jobs: these do not justify a dedicated port. VPN handles them without issue.
- Traffic is not latency-sensitive. ETL jobs, log shipping, and file transfers that run overnight have no latency requirements. VPN is adequate.
- You need connectivity quickly. VPN can be live in hours. If an on-premises system needs to reach AWS today, VPN is the path. Direct Connect will take weeks to months.
- Your team lacks enterprise networking maturity. Direct Connect requires BGP configuration, router coordination with carriers, VLAN management, and a solid understanding of how AWS routing works. If your team does not have those skills yet, VPN is a lower-risk starting point.
Many organizations run Site-to-Site VPN permanently and never need to upgrade. Measure your actual traffic volume and latency sensitivity before committing to Direct Connect. Do not pay for it based on anticipated future requirements that have not materialized.
Planning and prerequisites
Direct Connect involves more pre-work than VPN. Work through these before starting a provisioning request:
Router requirements. Your on-premises router must support BGP. It is the only routing protocol Direct Connect uses, and it is not optional. Confirm your router supports BGP and that your team can configure it. Most enterprise routers and firewalls do; consumer-grade equipment does not.
Colocation or carrier dependency. If your data center is not colocated at a Direct Connect location, you need a carrier circuit between your facility and the Direct Connect facility. Research which Direct Connect locations are closest to you and identify a carrier or Direct Connect Partner that can provision the circuit.
Teams regularly underestimate how long carrier provisioning takes. A circuit that “should be ready in two weeks” frequently arrives in six to ten weeks. If your migration timeline depends on a Direct Connect connection being available by a specific date, plan for worst-case carrier lead times and add buffer. Do not block a migration deadline on a circuit that is not yet delivered.
CIDR planning. Your on-premises CIDR ranges and VPC CIDR ranges must not overlap. Overlapping address spaces make routing ambiguous and break connectivity. Plan your VPC CIDR blocks before provisioning the connection. Overlapping CIDRs discovered after provisioning are expensive to fix. See VPC Networks Explained for how to design non-overlapping ranges.
Gateway design decisions. Decide whether you need a Virtual Private Gateway (single VPC), a Direct Connect Gateway (multiple regions), or a Transit Gateway (multiple VPCs in the same region). Getting this wrong later means re-provisioning VIFs. For most production architectures with more than one VPC, a Transit Gateway is the right starting point.
Resilience design. A single Direct Connect connection with no backup is a single point of failure. Before provisioning, decide whether you will add a VPN backup, a second Direct Connect connection to a different location, or both. This decision affects your architecture and cost estimate.
Pricing and cost considerations
Direct Connect has several cost components. Exact pricing varies by region, port speed, and partner. Treat the numbers in AWS documentation as the authoritative source rather than any cached figures here.
Port-hour charges. AWS charges an hourly fee for the Direct Connect port, billed from when the port is provisioned regardless of how much traffic flows through it. The rate scales with port speed: a 10 Gbps port costs more per hour than a 1 Gbps port. This is the fixed baseline cost.
Data transfer charges. AWS charges for data leaving its network (egress). The per-GB rate on Direct Connect is lower than the equivalent internet egress rate. At high transfer volumes (multi-terabyte per month workloads), this difference can more than offset the port cost. At low transfer volumes, the port cost dominates and Direct Connect works out more expensive than VPN.
Carrier and cross-connect costs. These are billed by the carrier or colocation provider, not AWS. A cross-connect inside the same facility costs less than a carrier circuit spanning cities. These costs are outside AWS’s control and vary widely by location and provider.
If your monthly data transfer regularly runs into dozens or hundreds of terabytes from AWS, the lower per-GB rate typically produces a lower total bill than internet-based transfer. If you are transferring less than a few terabytes per month, the math rarely favors Direct Connect on cost alone. Run the calculation against your actual transfer volume before committing.
Resilience, security, and encryption
A dedicated circuit keeps your traffic off the public internet, but it does not encrypt it. If your compliance requirements specify encryption in transit (not just a private path), run a Site-to-Site VPN tunnel over the Direct Connect connection. You get the performance of the dedicated link with IPSec encryption on top. See Network Security Best Practices for how encryption requirements typically map to AWS connectivity options.
A single connection is not resilient. One Direct Connect connection to one Direct Connect location is a single point of failure. A fiber cut, a facility issue, or port maintenance can take down your hybrid connectivity entirely. For production workloads that cannot tolerate outages, design resilience in from the start.
VPN as a backup path. The most common resilience pattern: Direct Connect carries production traffic as the primary path, and a Site-to-Site VPN connection serves as a hot standby. BGP route preferences determine which path is used. Direct Connect routes are preferred when the link is healthy, and VPN routes take over automatically when BGP detects the failure. Failover typically completes in seconds to minutes depending on BGP timer configuration.
Dual connections for higher resilience. AWS recommends two Direct Connect connections to two different Direct Connect locations for production-critical workloads. This protects against a single location experiencing an event. Add a VPN backup on top of that for full redundancy. This level of investment is appropriate for mission-critical hybrid architectures, not typical workloads.
If your Direct Connect link goes down and you have no backup path, Troubleshooting Network Issues covers how to diagnose BGP session failures and verify route propagation.
Common beginner mistakes
- Assuming Direct Connect terminates at your building. Direct Connect goes to a colocation facility where AWS has equipment, not to your office. Understanding this is essential for lead time planning. If your facility is not in the same colocation building, you need a carrier circuit, which takes weeks to provision.
- Not configuring a backup path. A single Direct Connect connection has no built-in redundancy. A fiber cut or facility event takes down your hybrid connectivity completely. Always configure a VPN backup for production Direct Connect deployments.
- Mixing up Private VIF and Public VIF. A Public VIF reaches AWS public service endpoints like S3. A Private VIF reaches VPC private resources like EC2 and RDS. Using the wrong VIF type results in traffic not reaching its destination. Most hybrid connectivity use cases need a Private VIF.
- Underestimating provisioning time. Teams that plan a migration timeline around a Direct Connect circuit that should be ready in two weeks frequently discover the carrier delivers it in six to ten weeks. Always add buffer and plan for worst-case carrier lead times.
- Not planning CIDR ranges before provisioning. If your on-premises network and your VPC share overlapping address space, routing breaks and there is no clean fix without re-addressing. Resolve CIDR overlap before starting any connectivity setup.
- Choosing Direct Connect before measuring need. Direct Connect is a serious operational and financial commitment. Teams that provision it based on anticipated future requirements (without measuring current traffic) often find they are paying for capacity they do not use. Start with VPN, measure actual usage, and upgrade when the case is clear.
Real-world use cases
Financial data warehouse hybrid. A financial services firm runs its core database on-premises for compliance reasons but runs analytics workloads on Amazon Redshift. Every night, hundreds of gigabytes flow from on-premises to Redshift. A 10 Gbps Direct Connect connection handles the nightly load reliably, with consistent latency for real-time reporting queries during business hours.
Multi-VPC enterprise connectivity. A large company has a production VPC, a staging VPC, and a shared-services VPC across two AWS regions. They use a single Direct Connect connection with a Transit VIF into a Transit Gateway, combined with a Direct Connect Gateway, to reach all VPCs across both regions. One physical connection replaces what would otherwise have been multiple VPN tunnels and multiple Virtual Private Gateways.
Migration with bandwidth predictability. A team migrating a petabyte-scale database to AWS needs a reliable, high-throughput path for the initial transfer and ongoing replication during the cutover window. A temporary 10 Gbps Direct Connect connection removes the internet as a variable and gives the project team a predictable transfer timeline.
Healthcare compliance. A hospital network cannot route patient data over the public internet due to regulatory requirements. A dedicated Direct Connect circuit satisfies the private-connectivity requirement. A VPN tunnel over that connection adds IPSec encryption to meet the encryption-in-transit requirement.
Hybrid application server. A web application runs on EC2 but connects to a legacy on-premises database that cannot be migrated yet. The EC2-to-database query path needs sub-10ms latency consistently. A Direct Connect Private VIF through a Virtual Private Gateway delivers that. VPN over the internet did not: latency spiked to 60ms during business hours and caused timeout errors in the application.
Summary
- Direct Connect is a dedicated physical connection to AWS through a colocation facility. Your traffic never traverses the public internet.
- Available as dedicated connections (1, 10, or 100 Gbps) ordered directly from AWS, or hosted connections through partners at lower speeds from 50 Mbps.
- Virtual Interfaces (VIFs) are logical connections on top of the physical port: Private VIF for VPC resources, Public VIF for AWS public endpoints, Transit VIF for a Transit Gateway.
- BGP is required. It is the only routing protocol Direct Connect supports. Your on-premises router must support BGP.
- Direct Connect is private but not encrypted by default. Add a VPN tunnel over the connection if encryption in transit is required.
- A single connection has no built-in resilience. Run a Site-to-Site VPN as a BGP backup path for production deployments.
- Provisioning takes weeks to months. Account for carrier lead times in project planning.
- Use Direct Connect when you need high throughput, consistent low latency, or private connectivity compliance. Use VPN when you need connectivity fast, your bandwidth is modest, or your architecture is still evolving.
Frequently asked questions
Does Direct Connect terminate at my office or data center?
Usually not. Direct Connect terminates at an AWS Direct Connect location, which is a colocation facility where AWS has equipment. If your data center is not physically inside that colocation facility, you need a network provider (a carrier or AWS Direct Connect Partner) to extend a circuit from your location to the Direct Connect location. Your office connects via your existing WAN or a dedicated carrier circuit, not a wire straight into AWS.
Is Direct Connect encrypted?
No, not by default. Direct Connect is a private dedicated circuit, which means your traffic is isolated from the public internet, but there is no IPSec or TLS encryption applied automatically. If encryption is required for compliance, you can run a Site-to-Site VPN tunnel over the Direct Connect connection. That gives you both the performance of a dedicated link and IPSec encryption on top.
What is a Virtual Interface (VIF)?
A Virtual Interface is a logical connection you create on top of your Direct Connect port. It defines where your traffic goes. A Private VIF routes traffic into a VPC via a Virtual Private Gateway or Transit Gateway. A Public VIF routes traffic to AWS public service endpoints like S3 and DynamoDB, bypassing the internet. A Transit VIF connects to a Transit Gateway so you can reach multiple VPCs through a single interface. You can have multiple VIFs on a single dedicated connection.
How long does Direct Connect take to provision?
Typically four to twelve weeks for a dedicated connection, sometimes longer. The delay comes from the physical side: AWS must provision a port at the Direct Connect location, and if your data center is not in the same facility, a carrier must provision a circuit between your location and the AWS facility. Hosted connections through a Direct Connect Partner can be faster because the partner already has infrastructure in place, but you should still plan for weeks rather than days.
Do I need a Direct Connect Gateway or a Transit Gateway?
It depends on your architecture. A Direct Connect Gateway lets you use a single Direct Connect connection to reach VPCs in multiple AWS regions. Without it, each region needs its own connection. A Transit Gateway is a hub router that connects multiple VPCs and your hybrid connections together, enabling routing between them. For a single VPC in one region, you need neither. A Virtual Private Gateway on your VPC is sufficient. For multi-VPC or multi-region designs, a Direct Connect Gateway and optionally a Transit Gateway reduce both cost and complexity significantly.