Direct
Connect.

The Direct Connect Gateway (DXGW) is a globally distributed routing appliance that acts as an intermediary between your Direct Connect VIFs and your Virtual Private Clouds (VPCs). Unlike a Virtual Private Gateway (VGW) which is region-scoped, the DXGW can associate VPCs across multiple AWS Regions, enabling a single physical Direct Connect connection to provide private connectivity to VPCs in any region (excluding China and GovCloud).

The routing architecture of the DXGW follows a hub-and-spoke model: the on-premises router establishes a single eBGP session to the DXGW over a Private VIF, and the DXGW propagates learned prefixes into all associated VPC route tables. This reduces BGP session count from N (one per VPC) to 1 (one per DXGW), which is critical when managing hundreds or thousands of VPCs. The DXGW supports both IPv4 and IPv6 unicast address families, and prefix propagation uses a two-step process: prefixes received from the on-premises router are first validated against the DXGW's allowed prefix list, then injected into each associated VPC's route table as static routes with the VGW as the next hop.

The scaling limits of DXGW are well-defined and frequently encountered in large-scale deployments. Each DXGW supports a maximum of 100 Virtual Interface (VIF) associations, 300 VPC associations per DXGW (with a regional distribution of up to 10 VPCs per region for non-allocated DXGWs, and up to 300 VPCs across regions for allocated DXGWs), and a maximum of 1,000 propagated routes per BGP session. The route limit is particularly constraining — if an enterprise data center advertises more than 1,000 prefixes (which is common in large environments with per-application VLANs), the DXGW will silently drop excess prefixes, causing reachability gaps for applications whose prefixes are not propagated. The solution is either route summarization at the on-premises router (aggregating /24s into /16s) or multi-VIF designs where different prefix sets are advertised on different Private VIFs to different DXGWs.

BGP path selection over the DXGW follows standard eBGP rules with AWS-specific modifications. When a VPC receives the same prefix from multiple DXGWs (or from a DXGW and a VGW), it selects the path with the shortest AS_PATH. AWS does not support BGP Multi-Exit Discriminator (MED) on DXGW — instead, path selection is controlled entirely through AS_PATH prepending on the on-premises router or through BGP communities (7224:9100 for local region preference, 7224:9200 for continent preference, 7224:9300 for global preference). The BGP community mechanism is particularly powerful for traffic engineering: applying 7224:9100 to a prefix causes AWS to advertise it with a shorter AS_PATH to VPCs in the local region compared to other regions, effectively steering cross-region traffic to the geographically nearest Direct Connect location.

Route propagation timing through the DXGW is not instantaneous. When a new prefix is advertised over the Private VIF, it takes approximately 30-60 seconds for the route to appear in all associated VPC route tables. This delay is caused by the propagation pipeline: the on-premises BGP update must be received by the DXGW, validated, transformed into a VPC route table entry, and propagated through the AWS Regional API layer to each VPC. During large-scale routing events (such as a data center failover where hundreds of prefixes are withdrawn and readvertised), this propagation delay can compound, resulting in a 2-5 minute window of inconsistent routing. BFD on the Private VIF can reduce the detection portion of the failover, but the DXGW propagation delay remains a hard physical limit determined by the API propagation path.

AWS Direct Connect supports Link Aggregation Groups (LAG) as defined by IEEE 802.3ad, allowing up to 4 physical connections (1G, 10G, or 100G each) to be aggregated into a single logical interface. LAG provides both increased aggregate bandwidth (up to 400G with four 100G connections) and link-level redundancy — if one physical member fails, traffic is redistributed across the surviving members without requiring BGP reconvergence. However, LAG introduces subtle performance characteristics that differ fundamentally from ECMP (Equal-Cost Multi-Path) routing.

The key difference between LAG and ECMP lies in the load-balancing algorithm. ECMP operates at Layer 3, distributing packets across multiple BGP next hops based on a hash of the IP header fields (source IP, destination IP, protocol, and optionally source/destination ports). LAG operates at Layer 2, distributing frames across physical member links based on a hash of the Ethernet header (source MAC, destination MAC, and VLAN tag for L2 LAG; plus IP and port fields for L3 LAG). The LAG hash algorithm in AWS Direct Connect uses a 7-tuple hash: source MAC, destination MAC, source IP, destination IP, IP protocol, source port, and destination port. The hash output is reduced to a 2-bit value (for 4-member LAG) or a 1-bit value (for 2-member LAG), determining which physical link carries the frame.

The critical performance characteristic of LAG is that all packets in a single flow use the same physical link, because the hash input fields are identical for all packets in the flow. This means that aggregate throughput is limited by the hash distribution across flows, not by the number of member links. If a single flow (such as a large S3 multipart upload or a database replication stream) consumes 50 Gbps of bandwidth, and the LAG has four 10G members (40 Gbps total), the flow will hash to a single 10G link and experience congestion, even though three member links are idle. This phenomenon, known as "flow collision" or "hash polarization," becomes increasingly severe as the number of member links increases — the probability of flow collision for a 4-link LAG with 100 flows is approximately 23% (based on the birthday problem: P(at least one collision) = 1 - (4! / (4^100 * (4-100)!)) ).

AWS Direct Connect LAG supports two hash algorithms: the standard 7-tuple hash and the adaptive hash (using Flowlet switching). Flowlet switching improves load distribution by detecting idle gaps between bursts of packets — if a flow's inter-packet gap exceeds a threshold (typically 50-100 microseconds), the next burst can be hashed to a different member link, effectively allowing single flows to use the aggregate bandwidth. Flowlet switching requires hardware support on both the AWS Direct Connect router and the on-premises router, and is supported on AWS Direct Connect only for 100G interfaces. When Flowlet switching is enabled, aggregate throughput for a single TCP connection can reach up to 70% of the LAG's total capacity (compared to 25% for a 4-link LAG without Flowlet switching), significantly improving utilization for high-bandwidth workloads such as machine learning training data transfers.

LAG member links in AWS Direct Connect are not required to be symmetric — you can aggregate a 10G link and a 100G link into a single LAG, although the bandwidth contribution of each member is proportional to its speed. In this case, the 100G link carries 10/11 of the traffic, and the 10G link carries 1/11. However, the hash distribution applies the same probability to both links, so the 10G link is equally likely to receive a specific flow as the 100G link, causing oversubscription on the 10G link for any flow that hashes to it. AWS strongly recommends symmetric LAG member speeds. Additionally, LAG does not support BFD — link failure detection relies on LACP timeouts, which default to "short timeout" mode (3 seconds detection) but can drift to "long timeout" mode (90 seconds) in degraded optical conditions.