Free — no signup required

Direct Connect (DX): The Physical Layer

5 min read

What Direct Connect Actually Is

Imagine you rent office space in a building that also houses your bank's vault. Instead of driving across town every time you need cash, you negotiate a private hallway directly between your office and the vault. No traffic, no weather, no shared roads. That private hallway is Direct Connect.

AWS Direct Connect (DX) is a physical fiber-optic cable that connects your router to an AWS router inside a colocation facility — a neutral data center like Equinix or CoreSite that both you and AWS have equipment in. The connection bypasses the public internet entirely. This means lower and more consistent latency, higher throughput, and a path that is not subject to internet congestion or BGP route hijacking.

There are two flavors:

  • Dedicated Connection: A physical port — 1 Gbps, 10 Gbps, or 100 Gbps — that AWS provisions exclusively for you. You own the full capacity.
  • Hosted Connection: A sub-rate slice of a port (e.g., 50 Mbps, 500 Mbps, 10 Gbps) provisioned by an AWS Direct Connect Partner such as Megaport, Verizon, or Zayo. You share the physical infrastructure but get a guaranteed bandwidth slice. This is the faster path to getting started because the partner already has the physical cross-connect in place.

The physical cross-connect itself — the actual fiber patch cable between your cage and the AWS cage in the colocation facility — is called a Letter of Authorization / Connecting Facility Assignment (LOA-CFA). AWS gives you this document, and you hand it to the colocation facility to physically install the cable.

Link Aggregation Groups (LAG): Redundancy and Scale

A single 100 Gbps connection is impressive, but it is also a single point of failure. If that cable is accidentally cut during facility maintenance, your entire Direct Connect path goes dark.

Link Aggregation Group (LAG) solves both the capacity and redundancy problems simultaneously. You bundle up to 4 physical Direct Connect connections into a single logical interface. The protocol that coordinates this is LACP (Link Aggregation Control Protocol), an IEEE 802.3ad standard.

Key properties of a LAG:

  • Active/Active load balancing: Traffic is distributed across all member links simultaneously. You get the aggregate bandwidth of all links.
  • Automatic failover: If one physical link fails, LACP detects it within seconds and redistributes traffic across the surviving links — no manual intervention required.
  • Minimum links: You can configure a minimum number of active links. If the LAG drops below that threshold (e.g., 2 of 4 links fail), the entire LAG goes down rather than operating in a degraded state. This is useful when your application requires a minimum bandwidth guarantee.
  • Same location requirement: All connections in a LAG must terminate at the same Direct Connect location.

For true geographic redundancy, you need separate LAGs at separate Direct Connect locations — not just multiple cables at the same facility.

Virtual Interfaces (VIFs): Logical Lanes on the Physical Road

The physical cable is the road. To carry different types of traffic — some destined for private VPCs, some for public AWS services — you need logical lanes. In Direct Connect, these lanes are implemented as VLANs (Virtual Local Area Networks), and AWS exposes them as Virtual Interfaces (VIFs).

There are three types:

1. Private VIF
Connects your on-premises network to a specific VPC using private RFC 1918 IP addresses. You associate a Private VIF with a Virtual Private Gateway (VGW) attached to your VPC. Traffic flows as if your data center is another subnet of that VPC.

  • Example: Your on-premises Oracle database at 10.0.1.50 queries an EC2 application server at 172.16.5.20 in VPC-A.
  • Limitation: One Private VIF connects to one VPC. If you have 50 VPCs, you need 50 Private VIFs — or you use a Transit VIF.

2. Public VIF
Connects your on-premises network to AWS public service endpoints (S3, DynamoDB, SQS, etc.) using their public IP addresses — but the traffic never touches the public internet. It travels over your dedicated fiber to AWS's backbone network.

  • Example: Your on-premises backup server uploads 10 TB/day to S3 without consuming internet bandwidth or paying internet data transfer rates.
  • Important: A Public VIF does NOT give you access to your VPCs. It only reaches public AWS service endpoints.

3. Transit VIF
The scalable solution. A Transit VIF connects your Direct Connect to a Transit Gateway (TGW). The TGW then routes to any number of VPCs attached to it — potentially thousands.

  • Example: One 10 Gbps Direct Connect with one Transit VIF provides connectivity to 500 VPCs across multiple AWS accounts via a centralized TGW.
  • This is the standard enterprise architecture for large AWS deployments.
Interview Tip

Interviewers frequently ask: "What is the difference between a Private VIF and a Transit VIF?" The key answer: a Private VIF connects to a single VPC via a Virtual Private Gateway. A Transit VIF connects to a Transit Gateway, which can route to thousands of VPCs. For any organization with more than a handful of VPCs, Transit VIF is the correct choice. A follow-up question is often: "Can you use a Public VIF to access your EC2 instances?" — the answer is no. Public VIFs only reach public AWS service endpoints, not private VPC resources.

Key Point — Direct Connect is not encrypted by default. The physical cable is private, but the data on it is not encrypted. For compliance requirements (PCI-DSS, HIPAA), you must run MACsec (Layer 2 encryption) on Dedicated Connections, or establish an IPsec VPN over the Direct Connect path. This is a common architectural oversight that causes compliance failures.

This is one of 18 chapters

Get every chapter — Kubernetes, Terraform, SRE, distributed systems, and more — with fast daily review built in.

See pricing