AWS Direct Connect: Dedicated Hybrid Cloud Connectivity (2026)

When your organization moves workloads to AWS, the internet connection you've been using for testing quickly becomes the bottleneck in production. Variable latency, shared bandwidth, and the public internet's inherent unpredictability are unacceptable for financial trading systems, real-time media processing, large-scale data migration, or compliance-sensitive workloads. AWS Direct Connect solves this by giving you a private, dedicated network path between your data center and AWS — bypassing the public internet entirely.

This guide covers everything you need to make an informed decision about Direct Connect and configure it correctly: connection types, virtual interfaces, Direct Connect Gateway, Link Aggregation Groups, BGP routing, VPN failover, pricing, and when VPN is actually the better choice.

What Is AWS Direct Connect?

AWS Direct Connect is a dedicated network service that establishes a private connection between your on-premises environment (data center, office, or colocation facility) and AWS. Traffic flows over a private fiber circuit rather than the public internet, delivering several key advantages:

• Consistent network performance: Dedicated bandwidth eliminates the jitter and packet loss common on public internet paths. Sub-millisecond latency variance is achievable.
• Reduced data transfer costs: Data transfer out via Direct Connect is typically 50—80% cheaper than standard internet data transfer pricing, depending on region.
• Higher bandwidth: Connections from 50 Mbps up to 100 Gbps — far beyond what a typical IPsec VPN can sustain.
• Compliance: For regulated industries (healthcare, finance, government), traffic never touches the public internet, simplifying audit requirements.

Direct Connect connects to AWS through Direct Connect Locations — carrier-neutral colocation facilities that house AWS network equipment. There are 100+ Direct Connect locations worldwide. If your data center is not in the same facility, you work with a network provider (your ISP or a colocation provider) to establish a cross-connect to the AWS equipment in the nearest DX location.

Connection Types: Dedicated vs Hosted

There are two ways to get a Direct Connect connection. Understanding the difference is essential before you start the provisioning process.

Dedicated Connections

A dedicated connection is a physical port on AWS network equipment, allocated exclusively to your account. You request it directly from AWS through the console or API. Available speeds: 1 Gbps, 10 Gbps, 100 Gbps.

• Lead time: typically 30—90 days for physical provisioning
• Requires a colocation agreement at a DX location (your equipment or a provider's cross-connect to AWS equipment)
• Supports up to 50 virtual interfaces per connection
• Supports MACsec encryption (10G and 100G)
• Best for: large enterprises with predictable, high-volume workloads

Hosted Connections

A hosted connection is provisioned by an AWS Direct Connect Partner (ISPs, carriers, and network providers who have pre-built physical connections to AWS DX locations). The partner partitions their dedicated connection and sells you a share of it. Available speeds: 50 Mbps, 100 Mbps, 200 Mbps, 300 Mbps, 400 Mbps, 500 Mbps, 1 Gbps, 2 Gbps, 5 Gbps, 10 Gbps.

• Lead time: days to 2 weeks (the physical infrastructure already exists)
• Only one VIF (virtual interface) per hosted connection
• No MACsec support
• Best for: organizations wanting to start small, those not located near a DX location, or those who need sub-1G connections

Virtual Interfaces: Private, Public, and Transit

A Direct Connect connection by itself doesn't route traffic anywhere. You must create one or more Virtual Interfaces (VIFs) on top of it. A VIF is a logical sub-interface (using IEEE 802.1Q VLAN tagging) that determines what your Direct Connect connection can reach.

Private VIF

A Private VIF connects to a specific Virtual Private Gateway (VGW) attached to a VPC. Traffic flows to private IP addresses within that VPC. You cannot use a Private VIF to reach AWS public endpoints (S3, DynamoDB, etc.).

• One Private VIF → one VGW → one VPC (or use Direct Connect Gateway for multi-VPC/multi-region, see below)
• BGP peer IPs must be in the 169.254.0.0/16 range
• Supports IPv4 and IPv6

Public VIF

A Public VIF gives you access to all AWS public services (S3, DynamoDB, SNS, SQS, API Gateway, EC2 public IPs, etc.) across all AWS regions. Traffic to public AWS endpoints routes over Direct Connect rather than the internet.

• You advertise your public IP prefixes to AWS over BGP
• AWS advertises all AWS public IP prefixes to you (a large BGP table — 4,000+ prefixes)
• Does not give access to private VPC resources
• Use case: large-scale S3 data migration, direct access to AWS APIs without internet exposure

Transit VIF

A Transit VIF connects your Direct Connect connection to a Direct Connect Gateway which is then associated with one or more Transit Gateways. This enables you to reach multiple VPCs across multiple regions through a single VIF — the most scalable architecture for large enterprises.

# Create a Private VIF on a dedicated connection
aws directconnect create-private-virtual-interface \
  --connection-id dxcon-abc12345 \
  --new-private-virtual-interface '{
    "virtualInterfaceName": "prod-private-vif",
    "vlan": 101,
    "asn": 65000,
    "authKey": "YourBGPAuthKey",
    "amazonAddress": "169.254.0.1/30",
    "customerAddress": "169.254.0.2/30",
    "addressFamily": "ipv4",
    "virtualGatewayId": "vgw-0a1b2c3d4e5f",
    "tags": [{"key": "Environment", "value": "Production"}]
  }'

# Create a Transit VIF for DX Gateway
aws directconnect create-transit-virtual-interface \
  --connection-id dxcon-abc12345 \
  --new-transit-virtual-interface '{
    "virtualInterfaceName": "prod-transit-vif",
    "vlan": 102,
    "asn": 65000,
    "mtu": 8500,
    "authKey": "YourBGPAuthKey",
    "amazonAddress": "169.254.1.1/30",
    "customerAddress": "169.254.1.2/30",
    "addressFamily": "ipv4",
    "directConnectGatewayId": "a1b2c3d4-e5f6-7890-abcd-ef1234567890"
  }'

Direct Connect Gateway

A Direct Connect Gateway (DXGW) is a global resource — it exists outside any specific AWS region — that acts as a hub for your Direct Connect connections. It enables one of the most important capabilities in Direct Connect architecture: connecting a single DX connection to multiple VPCs in multiple regions.

Without a Direct Connect Gateway, each Private VIF maps to exactly one Virtual Private Gateway in one VPC in one region. To reach 5 VPCs in 3 regions, you'd need 5 Private VIFs. With a DXGW:

1. Create one Transit VIF on your Direct Connect connection, pointing to the DXGW
2. Associate the DXGW with up to 10 Transit Gateways (in different regions)
3. Each Transit Gateway connects to up to 5,000 VPC attachments

This "hub-and-spoke over Direct Connect" pattern scales to virtually any enterprise network size with minimal VIF consumption.

# Terraform: Direct Connect Gateway + Transit Gateway association
resource "aws_dx_gateway" "main" {
  name            = "corp-dx-gateway"
  amazon_side_asn = 64512
}

resource "aws_ec2_transit_gateway" "us_east" {
  description     = "Transit Gateway US East"
  amazon_side_asn = 64513

  tags = {
    Name = "tgw-us-east-1"
  }
}

resource "aws_ec2_transit_gateway" "eu_west" {
  provider        = aws.eu_west_1
  description     = "Transit Gateway EU West"
  amazon_side_asn = 64514

  tags = {
    Name = "tgw-eu-west-1"
  }
}

# Associate DX Gateway with both Transit Gateways
resource "aws_dx_gateway_association" "us_east" {
  dx_gateway_id         = aws_dx_gateway.main.id
  associated_gateway_id = aws_ec2_transit_gateway.us_east.id

  allowed_prefixes = [
    "10.0.0.0/8",    # All VPC CIDRs reachable via this TGW
  ]
}

resource "aws_dx_gateway_association" "eu_west" {
  dx_gateway_id         = aws_dx_gateway.main.id
  associated_gateway_id = aws_ec2_transit_gateway.eu_west.id

  allowed_prefixes = [
    "10.0.0.0/8",
  ]
}

# Transit VIF points to DX Gateway
resource "aws_dx_transit_virtual_interface" "main" {
  connection_id    = var.dx_connection_id
  name             = "corp-transit-vif"
  vlan             = 200
  address_family   = "ipv4"
  bgp_asn          = 65000  # Your on-premises ASN
  amazon_address   = "169.254.2.1/30"
  customer_address = "169.254.2.2/30"
  bgp_auth_key     = var.bgp_auth_key
  mtu              = 8500   # Jumbo frames
  dx_gateway_id    = aws_dx_gateway.main.id
}

Link Aggregation Groups (LAG)

A Link Aggregation Group (LAG) combines multiple Direct Connect connections into a single logical connection, increasing total bandwidth and providing connection-level redundancy. All connections in a LAG must:

• Use the same bandwidth (e.g., all 10 Gbps)
• Terminate on the same AWS Direct Connect endpoint
• Be dedicated connections (LAG is not supported on hosted connections)

A LAG of four 10 Gbps connections gives you an aggregated 40 Gbps logical link. AWS uses LACP (Link Aggregation Control Protocol) to manage the bundle. You can configure a minimum number of active connections — if connections fall below that threshold, the entire LAG goes down rather than passing traffic through degraded capacity.

# Create a LAG with two existing 10G dedicated connections
aws directconnect create-lag \
  --number-of-connections 2 \
  --location "EqDC2" \
  --connections-bandwidth 10Gbps \
  --lag-name "corp-lag-primary" \
  --connection-id dxcon-abc12345 \
  --tags '[{"key":"Environment","value":"Production"}]'

# Get LAG ID from the output, then add the second connection
LAG_ID="dxlag-xyz98765"

aws directconnect associate-connection-with-lag \
  --connection-id dxcon-def67890 \
  --lag-id $LAG_ID

# Set minimum links — LAG goes down if fewer than 2 connections are active
aws directconnect update-lag \
  --lag-id $LAG_ID \
  --minimum-links 2

# Describe LAG status
aws directconnect describe-lags \
  --lag-id $LAG_ID \
  --query 'lags[0].{State:lagState,Connections:numberOfConnections,MinLinks:minimumLinks}'

BGP Routing Configuration

BGP (Border Gateway Protocol) is the routing protocol used for all Direct Connect VIFs. Understanding BGP configuration is critical for controlling which routes are advertised and how traffic is distributed when you have multiple connections.

BGP Communities for Traffic Engineering

AWS supports BGP community tags that you attach to routes you advertise to AWS. These communities influence how AWS routes traffic back to your network:

• 7224:9100 — Local AWS region only (advertise this route only in the same region as the DX connection)
• 7224:9200 — All AWS regions in the same continent
• 7224:9300 — All AWS regions globally

AWS also sends you BGP communities on routes it advertises, indicating the region that originated each prefix. You can use these to prefer routes through your primary DX connection over the backup.

AS Path Prepending for Active/Passive Routing

When you have two Direct Connect connections (primary and backup), use AS path prepending on the backup connection to make your on-premises AS path artificially longer. AWS will prefer the shorter AS path (primary connection) for return traffic.

# Example router configuration (Cisco IOS-XE style)
# On-premises ASN: 65000, AWS ASN: 64512

# Primary BGP session - announce routes normally
router bgp 65000
 neighbor 169.254.0.1 remote-as 64512
 neighbor 169.254.0.1 description AWS-DX-Primary
 neighbor 169.254.0.1 password YourBGPAuthKey
 neighbor 169.254.0.1 soft-reconfiguration inbound
 !
 address-family ipv4
  neighbor 169.254.0.1 activate
  neighbor 169.254.0.1 route-map RM-TO-AWS-PRIMARY out
  network 192.168.100.0 mask 255.255.255.0
 exit-address-family

# Backup BGP session - use AS path prepending (3x) to make it less preferred
route-map RM-TO-AWS-BACKUP permit 10
 set as-path prepend 65000 65000 65000  ! Prepend our ASN 3 times

router bgp 65000
 neighbor 169.254.2.1 remote-as 64512
 neighbor 169.254.2.1 description AWS-DX-Backup
 neighbor 169.254.2.1 password YourBGPAuthKey2
 !
 address-family ipv4
  neighbor 169.254.2.1 activate
  neighbor 169.254.2.1 route-map RM-TO-AWS-BACKUP out
  network 192.168.100.0 mask 255.255.255.0
 exit-address-family

# For traffic FROM AWS to on-premises, use LOCAL_PREF on received routes
route-map RM-FROM-AWS-PRIMARY permit 10
 set local-preference 200  ! Higher = preferred

route-map RM-FROM-AWS-BACKUP permit 10
 set local-preference 100  ! Lower = backup

Failover with Site-to-Site VPN

Direct Connect is not inherently redundant — a single connection is a single point of failure. AWS recommends one of three resiliency models:

1. Maximum Resiliency: Two or more DX connections at two different DX locations, with connections to separate AWS devices at each location. Most expensive, highest availability.
2. High Resiliency: One or more DX connections at two different DX locations.
3. Development/Test: One DX connection with Site-to-Site VPN as backup. Suitable for non-critical workloads.

The most common cost-effective pattern for mid-market enterprises is Direct Connect primary + Site-to-Site VPN backup. When DX is healthy, all traffic routes over DX. If DX fails, BGP withdraws the routes and the VPN automatically takes over.

# Terraform: VPN as Direct Connect failover
resource "aws_vpn_gateway" "main" {
  vpc_id          = var.vpc_id
  amazon_side_asn = 64512

  tags = {
    Name = "prod-vgw"
  }
}

resource "aws_customer_gateway" "on_prem" {
  bgp_asn    = 65000
  ip_address = var.on_prem_public_ip  # Your on-premises router's public IP
  type       = "ipsec.1"

  tags = {
    Name = "on-prem-cgw"
  }
}

resource "aws_vpn_connection" "backup" {
  vpn_gateway_id      = aws_vpn_gateway.main.id
  customer_gateway_id = aws_customer_gateway.on_prem.id
  type                = "ipsec.1"
  static_routes_only  = false  # Use BGP (dynamic routing)

  # Tunnel options for IKEv2 (more secure)
  tunnel1_ike_versions = ["ikev2"]
  tunnel2_ike_versions = ["ikev2"]

  tunnel1_phase1_encryption_algorithms = ["AES256"]
  tunnel1_phase1_integrity_algorithms  = ["SHA2-256"]
  tunnel1_phase2_encryption_algorithms = ["AES256"]
  tunnel1_phase2_integrity_algorithms  = ["SHA2-256"]

  tags = {
    Name        = "prod-vpn-backup"
    Environment = "Production"
  }
}

# Route propagation: VGW will propagate routes learned via BGP to route tables
resource "aws_vpn_gateway_route_propagation" "private" {
  for_each       = toset(var.private_route_table_ids)
  vpn_gateway_id = aws_vpn_gateway.main.id
  route_table_id = each.value
}

For the failover to work automatically with BGP, configure your on-premises router to advertise your prefixes over both the DX Private VIF and the VPN BGP session. Use local preference to prefer DX routes when both are up. When DX goes down, BGP converges and VPN routes take over — typically within 30—90 seconds depending on BGP hold timers.

Pricing and Cost Optimization

Direct Connect pricing has two main components: port hours and data transfer out. Understanding both is essential for cost modeling.

Port Hours

You pay an hourly rate for each dedicated connection port, regardless of utilization:

• 1 Gbps port: ~$0.30/hr ($216/month)
• 10 Gbps port: ~$1.46/hr ($1,051/month)
• 100 Gbps port: ~$14.40/hr ($10,368/month)

Hosted connection pricing varies by partner and is negotiated separately. The partner bundles their circuit cost with a margin — typically 10—30% more than dedicated port-hour cost but with no physical infrastructure requirement on your side.

Data Transfer Out (DTO)

Data transfer from AWS to your on-premises network via Direct Connect is significantly cheaper than internet egress:

• Internet egress: $0.09/GB (first 10 TB/month in us-east-1)
• DX egress (us-east-1): $0.02/GB (typical, varies by location)
• Savings: ~78% reduction in DTO costs

Data transfer IN (from on-premises to AWS) over Direct Connect is free (same as internet inbound).

Cost Break-Even Analysis

A 1 Gbps dedicated connection costs ~$216/month in port hours. Add circuit costs from your provider (typically $500—$2,000/month depending on distance and provider). At $0.07/GB savings over internet egress, you need to transfer about 10—30 TB/month just to break even on data transfer costs. Add reliability and compliance value, and the calculation shifts significantly in Direct Connect's favor for serious production workloads.

Direct Connect vs VPN: When to Use Which

Choose Direct Connect when: you transfer more than 10 TB/month out of AWS, you need predictable sub-10ms latency, you have compliance requirements that prohibit public internet, or you are running real-time applications where jitter is unacceptable.

Choose VPN when: you need connectivity within hours, you have light workloads that don't justify DX costs, you're connecting branch offices or remote sites, or you need encrypted connectivity as a backup to Direct Connect.

Step-by-Step Setup Walkthrough

Here is the complete workflow for provisioning a dedicated Direct Connect connection and creating a Private VIF to a single VPC.

## STEP 1: Request a dedicated connection via AWS Console or CLI
aws directconnect create-connection \
  --bandwidth 10Gbps \
  --connection-name "corp-hq-to-aws" \
  --location "EqDC2" \
  --tags '[{"key":"Environment","value":"Production"},{"key":"Owner","value":"networking-team"}]'

# Note the connection ID (e.g., dxcon-abc12345)
# AWS will provide a Letter of Authorization (LOA-CFA) within 72 hours
# Give the LOA to your colocation provider to complete the cross-connect

## STEP 2: Check connection state (wait for 'available')
aws directconnect describe-connections \
  --connection-id dxcon-abc12345 \
  --query 'connections[0].{State:connectionState,Bandwidth:bandwidth}'

## STEP 3: Create a Virtual Private Gateway (if not already existing)
aws ec2 create-vpn-gateway \
  --type ipsec.1 \
  --amazon-side-asn 64512 \
  --tag-specifications 'ResourceType=vpn-gateway,Tags=[{Key=Name,Value=prod-vgw}]'

# Attach VGW to your VPC
aws ec2 attach-vpn-gateway \
  --vpn-gateway-id vgw-0a1b2c3d4e5f \
  --vpc-id vpc-0123456789abcdef0

## STEP 4: Enable route propagation on your private route tables
aws ec2 enable-vgw-route-propagation \
  --gateway-id vgw-0a1b2c3d4e5f \
  --route-table-id rtb-private-az-a

aws ec2 enable-vgw-route-propagation \
  --gateway-id vgw-0a1b2c3d4e5f \
  --route-table-id rtb-private-az-b

## STEP 5: Create the Private VIF
aws directconnect create-private-virtual-interface \
  --connection-id dxcon-abc12345 \
  --new-private-virtual-interface '{
    "virtualInterfaceName": "corp-hq-prod-vif",
    "vlan": 100,
    "asn": 65000,
    "authKey": "MyBGPSecretKey!",
    "amazonAddress": "169.254.0.1/30",
    "customerAddress": "169.254.0.2/30",
    "addressFamily": "ipv4",
    "virtualGatewayId": "vgw-0a1b2c3d4e5f",
    "enableSiteLink": false,
    "mtu": 9001
  }'

## STEP 6: Configure your on-premises router with the BGP details
# AWS provides: BGP peer IP (169.254.0.1), your BGP IP (169.254.0.2),
# AWS ASN (64512), your ASN (65000), auth key
# Configure your router per its documentation (Cisco, Juniper, Palo Alto, etc.)

## STEP 7: Verify BGP session comes up
aws directconnect describe-virtual-interfaces \
  --virtual-interface-id dxvif-xyz98765 \
  --query 'virtualInterfaces[0].{State:virtualInterfaceState,BGPPeers:bgpPeers}'

# Expected bgpPeers[].bgpStatus: "up"
# Expected virtualInterfaceState: "available"

Frequently Asked Questions

How long does it take to get a Direct Connect connection?

For dedicated connections, plan for 4—12 weeks. AWS processes the request within 72 hours and provides the Letter of Authorization. The remaining time depends on your colocation provider's cross-connect queue. Hosted connections from DX Partners can be provisioned in days to 2 weeks since the physical infrastructure already exists.

Does Direct Connect provide 99.99% availability?

A single Direct Connect connection does not have a 99.99% SLA. To achieve 99.99% availability, you need two or more dedicated connections at two separate DX locations. AWS provides the Direct Connect Resiliency Toolkit in the console to verify your architecture meets the target resiliency level.

Can I use Direct Connect to connect to multiple AWS accounts?

Yes. A Direct Connect Gateway can be shared across multiple AWS accounts using Resource Access Manager (RAM). A DX connection in one account can serve VPCs in other accounts through a shared DXGW. This is the standard enterprise pattern — a central networking account owns the DX connections and shares access to other business unit accounts.

What is MACsec and when do I need it?

MACsec (IEEE 802.1AE) provides Layer 2 encryption on the physical link between your router and the AWS DX device. It encrypts all traffic before it enters the AWS network fabric. MACsec is available on dedicated 10 Gbps and 100 Gbps connections at supported locations. Use it when your compliance requirements mandate encryption at the physical/link layer, not just at the application layer.

How does Direct Connect pricing compare to Transit Gateway charges?

If you use a Transit VIF with Direct Connect Gateway and Transit Gateway, you pay: DX port hours + DX data transfer rates + TGW attachment fee (~$0.05/hr per attachment) + TGW data processing ($0.02/GB). For a large enterprise with many VPCs, this model still saves significantly over internet data transfer costs, and the operational simplicity of a single VIF serving all VPCs justifies the TGW overhead.