AWS Direct Connect
Key concepts
Dedicated vs hosted connections
Virtual interfaces (public/private)
Direct Connect Gateway
LAG for redundancy
MACsec encryption
Overview
AWS Direct Connect (DX) is a service that creates a dedicated, private network link between your on-premises data center, office, or colocation environment and AWS. Instead of sending traffic over the public internet, you connect through a Direct Connect location to a physical AWS router, giving you consistent bandwidth and lower, more predictable latency. The physical link is provisioned at one of many Direct Connect locations worldwide, and logical connections called virtual interfaces (VIFs) ride on top of it to reach either private VPC resources or public AWS services.
On the SAA-C03 exam, Direct Connect appears in "hybrid connectivity" and "high-performing network" scenarios. You should know when to choose Direct Connect over a Site-to-Site VPN, the difference between dedicated and hosted connections, the three virtual interface types, how a Direct Connect Gateway connects many VPCs across Regions, how a Link Aggregation Group (LAG) adds redundancy and bandwidth, and how MACsec encrypts traffic at the physical layer.
Private, Consistent Connectivity to AWS
Direct Connect gives you a private, dedicated link with consistent bandwidth and predictable latency. Use a private virtual interface to reach VPC resources, a public virtual interface to reach public AWS services over the private link, and a Direct Connect Gateway to reach many VPCs across multiple Regions. For high availability, combine multiple connections or a LAG, and pair Direct Connect with a backup VPN.
Direct Connect alone is a single point of failure and is not encrypted by default. For resilience, use two connections (ideally at two Direct Connect locations) or a LAG, and add a Site-to-Site VPN as backup. For encryption, run a VPN over a public VIF or enable MACsec on supported dedicated connections. Choose Direct Connect when you need consistent bandwidth and low latency; choose a VPN when you need quick setup and built-in encryption over the internet.
Key Concepts
Dedicated vs Hosted Connections
How You Buy the Physical Link
A dedicated connection is a physical Ethernet port (1 Gbps, 10 Gbps, or 100 Gbps) that AWS provisions for you at a Direct Connect location. You own the whole port and can create multiple virtual interfaces on it. A hosted connection is provisioned by an AWS Direct Connect Partner who already owns a port and carves out a slice of capacity for you, with speeds ranging from 50 Mbps up to 25 Gbps depending on the partner. Hosted connections are faster to obtain and good for lower or sub-1 Gbps bandwidth, while dedicated connections suit high, predictable throughput.
Dedicated vs Hosted Connections
| Dimension | Dedicated Connection | Hosted Connection |
|---|---|---|
| Provisioned by | AWS directly | Direct Connect Partner |
| Port ownership | Entire physical port is yours | Slice of a partner port |
| Speeds | 1, 10, or 100 Gbps | 50 Mbps up to 25 Gbps |
| Virtual interfaces | Multiple per port | Typically one per connection |
| Best for | High, steady throughput | Lower bandwidth, faster setup |
Virtual Interfaces (Public and Private)
Logical Connections on the Physical Link
A virtual interface (VIF) is a logical BGP (Border Gateway Protocol, the routing protocol that exchanges routes) session running over the physical connection. A private VIF reaches resources inside a VPC using private IP addresses (for example EC2 instances), attaching to a Virtual Private Gateway or a Direct Connect Gateway. A public VIF reaches public AWS services (for example Amazon S3 or DynamoDB) using their public IP addresses, but over the private Direct Connect link instead of the internet. A transit VIF connects to a Direct Connect Gateway that is associated with one or more AWS Transit Gateways, letting you reach many VPCs through a hub. Each dedicated connection can host many VIFs.
Virtual Interface Types
| VIF Type | Reaches | Addressing | Attaches To |
|---|---|---|---|
| Private VIF | VPC resources such as EC2 | Private IPs | Virtual Private Gateway or DX Gateway |
| Public VIF | Public AWS services such as S3 | Public IPs | AWS public endpoints |
| Transit VIF | Many VPCs via a hub | Private IPs | DX Gateway with Transit Gateway |
Direct Connect Gateway
Connecting Many VPCs Across Regions
A Direct Connect Gateway (DXGW) is a globally available resource that lets one Direct Connect connection reach VPCs in multiple AWS Regions, removing the need for a separate connection per Region. You associate the DXGW with Virtual Private Gateways (one per VPC) using a private VIF, or with a Transit Gateway using a transit VIF to fan out to many VPCs at once. A DXGW does not allow VPC-to-VPC routing through itself when using Virtual Private Gateways, so traffic flows between on-premises and each VPC rather than between attached VPCs.
Reaching VPCs with a DX Gateway
| Goal | Use This |
|---|---|
| One VPC, same Region | Private VIF to a Virtual Private Gateway |
| Several VPCs across Regions | Private VIF to a DX Gateway with multiple Virtual Private Gateways |
| Many VPCs through a hub | Transit VIF to a DX Gateway associated with a Transit Gateway |
| Public AWS services privately | Public VIF (no DX Gateway needed) |
LAG for Redundancy and Bandwidth
Bundling Connections with a LAG
A Link Aggregation Group (LAG) bundles multiple dedicated connections into a single logical, higher-bandwidth connection using the Link Aggregation Control Protocol (LACP). All connections in a LAG must use the same port speed and terminate at the same Direct Connect endpoint (same location and AWS device). A LAG can hold up to four connections when the port speed is below 100 Gbps, or up to two connections at 100 Gbps (or 400 Gbps), and you can set a minimum number of active connections so the LAG goes down if too few links are healthy. A LAG increases both aggregate bandwidth and resilience against a single link failure, though because all links land at one endpoint it does not protect against a full-location outage.
Resilience Options
| Approach | What It Protects Against | Notes |
|---|---|---|
| Single connection | Nothing extra | Single point of failure |
| LAG | One link failing | Up to 4 connections below 100 Gbps or 2 at 100 Gbps, same speed and endpoint |
| Two connections at two locations | A device or location failing | Highest resilience for DX alone |
| DX plus backup VPN | DX path failing entirely | VPN over internet as failover |
MACsec Encryption
Layer 2 Encryption on the Link
MAC Security (MACsec) is an IEEE 802.1AE standard that encrypts traffic at Layer 2 (the data link layer) directly on the physical connection. Direct Connect supports MACsec on high-speed dedicated connections (10 Gbps, 100 Gbps, and 400 Gbps) at selected Direct Connect locations, providing confidentiality and integrity between your edge router and the AWS device with near line-rate performance. MACsec is not available on hosted connections. Because Direct Connect traffic is private but unencrypted by default, MACsec is the native way to encrypt the link itself. An alternative is running an IPsec VPN over a public VIF, which encrypts at Layer 3 but adds tunnel overhead.
Encryption Options Over Direct Connect
| Option | Layer | Where It Runs | Note |
|---|---|---|---|
| MACsec | Layer 2 (802.1AE) | On high-speed dedicated links (10, 100, 400 Gbps) | Near line-rate, select locations |
| VPN over public VIF | Layer 3 (IPsec) | Tunnel across the public VIF | Adds tunnel overhead |
| No encryption | None | Default Direct Connect | Private but unencrypted |
Best Practices
1. Build redundancy from the start
├── Use two connections at two Direct Connect locations for high resilience
└── Add a Site-to-Site VPN as an automatic backup path
2. Match the VIF type to the destination
├── Private VIF for VPC resources by private IP
├── Public VIF for public AWS services over the private link
└── Transit VIF for many VPCs through a Transit Gateway
3. Use a Direct Connect Gateway for multi-Region reach
└── One connection serves VPCs in several Regions
4. Aggregate links with a LAG for more bandwidth
├── Keep all links at the same speed and location
└── Set a minimum active link count to fail predictably
5. Encrypt when data sensitivity requires it
├── Enable MACsec on supported high-speed dedicated links (10, 100, or 400 Gbps)
└── Or run an IPsec VPN over a public VIFCommon Pitfalls
Pitfall 1: Treating a Single Connection as Highly Available
Mistake: Provisioning one Direct Connect connection and assuming the link is resilient.
Why it fails: A single connection is a single point of failure; a fiber cut, device fault, or location issue takes the entire link down.
Correct Approach: Use two connections at two Direct Connect locations, or a LAG plus a backup Site-to-Site VPN, to meet availability targets.
Pitfall 2: Assuming Direct Connect Is Encrypted
Mistake: Believing the private link encrypts data in transit by default.
Why it fails: Direct Connect keeps traffic off the public internet, but it does not encrypt payloads on its own, which can violate compliance requirements.
Correct Approach: Enable MACsec on supported high-speed dedicated connections (10, 100, or 400 Gbps), or run an IPsec VPN over a public VIF, when encryption is required.
Pitfall 3: Using the Wrong Virtual Interface Type
Mistake: Creating a private VIF to reach Amazon S3, or a public VIF to reach EC2 by private IP.
Why it fails: A private VIF routes only to VPC private IP space, while a public VIF routes only to AWS public service endpoints, so the wrong choice cannot reach the target.
Correct Approach: Use a private VIF (or transit VIF) for VPC resources and a public VIF for public AWS services such as S3 and DynamoDB.
Pitfall 4: Expecting a LAG to Span Locations
Mistake: Trying to place LAG member connections at different Direct Connect locations for site redundancy.
Why it fails: All connections in a LAG must terminate at the same location and on the same AWS device, so a LAG does not protect against a location outage.
Correct Approach: Use a LAG for link-level redundancy and added bandwidth, and use separate connections at separate locations for location-level resilience.
Test Your Knowledge
A company runs a large data-replication job to Amazon S3 and currently uses the public internet, but throughput is inconsistent and latency varies. They want a private link with predictable bandwidth and need to reach S3 public endpoints. Which Direct Connect setup fits best?
An enterprise has VPCs in three AWS Regions and wants a single Direct Connect connection to reach private resources in all of them without provisioning a separate connection per Region. What should the architect use?
A financial services team must encrypt all traffic on their 10 Gbps dedicated Direct Connect link at near line-rate performance with minimal tunnel overhead. Which option meets the requirement?
Related Services
Quick Reference
Limits and Facts
Direct Connect Quick Facts
| Item | Value |
|---|---|
| Dedicated connection speeds | 1, 10, or 100 Gbps |
| Hosted connection speeds | 50 Mbps up to 25 Gbps |
| Connections per LAG | Up to 4 below 100 Gbps, or 2 at 100 Gbps |
| Virtual interface types | Private, Public, Transit |
| MACsec support | 10, 100, and 400 Gbps dedicated, select locations |
| Routing protocol | BGP over each virtual interface |
| Default encryption | None (private but unencrypted) |
Common CLI Commands
# List your Direct Connect connections
aws directconnect describe-connections
# Create a private virtual interface to a Direct Connect Gateway
aws directconnect create-private-virtual-interface \
--connection-id dxcon-abc123 \
--new-private-virtual-interface "virtualInterfaceName=prod-vif,vlan=101,asn=65000,directConnectGatewayId=dxgw-abc123"
# Create a public virtual interface for public AWS services
aws directconnect create-public-virtual-interface \
--connection-id dxcon-abc123 \
--new-public-virtual-interface "virtualInterfaceName=public-vif,vlan=102,asn=65000"
# Create a Direct Connect Gateway
aws directconnect create-direct-connect-gateway \
--direct-connect-gateway-name prod-dxgw --amazon-side-asn 64512
# Create a LAG from dedicated connections
aws directconnect create-lag \
--number-of-connections 2 --location EqDC2 \
--connections-bandwidth 10Gbps --lag-name prod-lag