AWS Direct Connect Gateway: 7 things you need to know about

Summary:

• AWS Direct Connect Gateway enables private connectivity from on-premises networks to multiple VPCs across regions and accounts through a single connection. The quotas support up to 20 virtual private gateways (VGWs) and up to 6 transit gateways (TGWs) per Direct Connect Gateway.
• Understanding the architectural differences between VGW-based, TGW-based, and Cloud WAN association models determines scalability, cost efficiency, and failure resilience for enterprise hybrid cloud deployments.
• Virtual interface selection (private VIF vs. transit VIF) directly impacts routing flexibility, prefix limits, and cross-region traffic patterns. This choice is critical for large-scale implementations.
• SiteLink, high availability design patterns, and BGP best practices represent advanced considerations that separate production-grade architectures from basic connectivity setups.

When enterprises move beyond simple VPN tunnels and demand predictable latency with dedicated bandwidth to AWS, the Direct Connect Gateway becomes the architectural linchpin that determines whether your hybrid cloud strategy scales gracefully or collapses under its own complexity. This centralized routing construct allows a single physical Direct Connect connection to reach VPCs across multiple AWS regions and accounts. It eliminates the need for redundant circuits in every geography where your workloads operate.

Most engineering teams underestimate the nuanced quota limits, virtual interface trade-offs, and association models that govern how traffic actually flows through this gateway. The following guide distills seven critical knowledge areas that separate superficial implementations from production-hardened architectures capable of supporting global enterprise workloads.

Understanding Direct Connect Gateway quotas and limits

Before designing any hybrid architecture, engineers must internalize the hard boundaries that AWS imposes on Direct Connect Gateway resources. These quotas determine how many VPCs you can reach, how many routes you can advertise, and ultimately whether your design will hit scaling walls during production growth. The official AWS Direct Connect quotas documentation provides the authoritative reference. Contextualizing these numbers against real deployment scenarios reveals their practical implications.

The quota structure establishes the following critical limits:

• Virtual Private Gateways per Direct Connect Gateway: 20 VGWs maximum.
• Transit Gateways per Direct Connect Gateway: 6 TGWs maximum.
• Transit virtual interfaces per Direct Connect dedicated connection: 4 transit VIFs (counted within 51 total VIF limit).
• Routes per BGP session (private or transit VIF) from on‑premises to AWS: 100 prefixes per IPv4 and 100 per IPv6.
• Virtual interfaces (private or transit) per Direct Connect Gateway: 30 total.
• Number of prefixes per Transit Gateway from AWS to on‑premises on a transit VIF: 200 combined total (IPv4 + IPv6).

Senior engineers should recognize that these quotas create architectural forcing functions. An organization with 25 VPCs across 8 regions cannot simply attach all of them via VGW associations to a single Direct Connect Gateway. Instead, the design must incorporate Transit Gateways as aggregation points. This trades the simplicity of direct VGW attachment for the scalability of TGW-based routing.

This quota-driven architecture decision cascades into cost implications, operational complexity, and failure domain considerations that junior engineers often overlook.

Quota increase requests and soft limits

While most Direct Connect Gateway quotas are hard limits that cannot be increased, AWS does allow quota increase requests for certain parameters through the Service Quotas console. The VGW-per-DXGW limit of 20 and TGW-per-DXGW limit of 6 are generally firm. However, prefix limits on specific BGP sessions may be adjustable based on your support plan and use case justification. Always validate current adjustability through your AWS account team before committing to an architecture that assumes increased limits.

Architectural models comparing VGW, Transit Gateway, and Cloud WAN

The choice between Virtual Private Gateway, Transit Gateway, and Cloud WAN association models represents the most consequential architectural decision when deploying Direct Connect Gateway. Each model offers distinct trade-offs in scalability, routing flexibility, cost structure, and operational complexity. Understanding these differences prevents costly re-architecture efforts when your initial design fails to accommodate growth.

Consider the following comparison of association models and their characteristics:

The following diagram illustrates how traffic flows differ across these three architectural models. It highlights the routing boundaries and data processing points that impact both performance and cost.

Cloud WAN integration considerations

AWS Cloud WAN represents the newest association option for Direct Connect Gateway. It enables integration with a global core network that provides policy-based routing and segment isolation. This model suits organizations replacing traditional MPLS or SD-WAN infrastructure with AWS-native global networking.

Cloud WAN introduces additional complexity through segment policies, attachment acceptance workflows, and core network edge locations that must align with your Direct Connect points of presence. Most enterprises should validate their Cloud WAN requirements thoroughly before choosing this path over the more established TGW model.

Virtual interface types and the differences between private VIF and transit VIF

Virtual interfaces serve as the logical connections that carry traffic between your on-premises router and AWS services over a Direct Connect circuit. The distinction between private VIF and transit VIF fundamentally shapes your routing architecture, prefix capacity, and which AWS resources you can reach. Misunderstanding these differences leads to designs that either waste resources or fail to meet connectivity requirements.

Private virtual interfaces connect directly to a Virtual Private Gateway attached to a single VPC, or to a Direct Connect Gateway that then associates with multiple VGWs. This interface type supports up to 1,000 advertised prefixes from on-premises and provides the most straightforward path to VPC resources. Transit virtual interfaces connect to a Direct Connect Gateway that associates with Transit Gateways. This enables access to thousands of VPCs through TGW attachments while accepting only 100 prefixes from on-premises.

Choosing between private and transit VIFs

The decision framework for VIF selection should consider three primary factors. First, evaluate your on-premises route table size against the 100-prefix transit VIF limit versus the 1,000-prefix private VIF limit. Second, assess whether your VPC count and growth trajectory justifies the Transit Gateway model that transit VIFs enable.

Third, calculate the total cost of ownership including TGW data processing charges that apply only to transit VIF architectures. Organizations with complex on-premises routing but modest AWS footprints often find private VIFs with multiple VGW associations more economical than the transit VIF approach.

Multi-account and cross-region deployment patterns

Enterprise AWS deployments rarely exist within a single account or region. This makes multi-account Direct Connect Gateway architectures essential for production environments. The gateway itself lives in one AWS account but can associate with VGWs and TGWs owned by different accounts. This enables centralized connectivity management while preserving account-level isolation. This capability requires careful attention to resource sharing permissions, CIDR overlap prevention, and cross-account association workflows.

The association process for cross-account resources follows a proposal-acceptance model:

1. Gateway owner initiates: The account owning the Direct Connect Gateway creates an association proposal specifying the target VGW or TGW and allowed prefixes
2. Resource owner reviews: The account owning the VGW or TGW receives the proposal and validates the prefix configuration
3. Acceptance completes association: Upon acceptance, BGP sessions establish and route propagation begins within minutes
4. Ongoing management: Either party can delete the association, immediately terminating connectivity

Handling overlapping CIDR blocks

One of the most challenging aspects of multi-account Direct Connect Gateway deployments involves preventing CIDR conflicts between associated VPCs. The gateway does not perform NAT or provide any address translation. Overlapping IP ranges between two VGW-associated VPCs create routing ambiguity that AWS resolves unpredictably.

Senior engineers must implement CIDR governance through AWS Organizations service control policies, IPAM (IP Address Manager), or custom automation that validates address space before association approval. The allowed prefixes configuration on each association provides a final safeguard. It enables administrators to restrict which routes propagate even when VPC CIDRs technically overlap.

High availability design and BGP best practices

Production Direct Connect Gateway deployments demand resilience against circuit failures, device failures, and even entire Direct Connect location outages. AWS recommends a minimum of two physical connections at geographically diverse locations, each with redundant virtual interfaces, to achieve the 99.99% availability SLA. The BGP configuration across these connections determines failover behavior, convergence time, and traffic distribution during both normal operations and failure scenarios.

Essential BGP configuration practices for Direct Connect Gateway include:

• AS path prepending: Influence inbound traffic by artificially lengthening the AS path on backup connections
• Local preference: Control outbound traffic from AWS by setting higher local preference on primary paths
• BFD enablement: Bidirectional Forwarding Detection reduces failover time from 90 seconds (default BGP hold timer) to sub-second
• MD5 authentication: Protect BGP sessions against spoofing attacks, required for compliance in regulated industries
• Prefix filtering: Implement strict prefix lists to prevent route leaks between on-premises and AWS

Resiliency testing and chaos engineering

Designing for high availability means nothing without validation through controlled failure injection. Schedule quarterly resiliency tests that disable primary connections, simulate BGP session failures, and verify that monitoring systems detect and alert on degraded states. Document the expected failover time, actual observed failover time, and any application impact during each test. This practice builds organizational confidence in the Direct Connect architecture and identifies configuration drift before it causes production incidents.

SiteLink for global backbone connectivity

SiteLink transforms Direct Connect from a simple on-premises-to-AWS connectivity service into a global private backbone that connects your data centers to each other through the AWS network. When enabled on virtual interfaces, SiteLink allows traffic to flow between Direct Connect locations without traversing the public internet or requiring VPC resources in the path. This capability proves particularly valuable for organizations with multiple data centers that need low-latency, high-bandwidth connectivity without investing in dedicated MPLS circuits.

The traffic flow with SiteLink enabled follows a distinct pattern. Data enters the AWS network at one Direct Connect location, routes through the AWS global backbone to another Direct Connect location, and exits to the destination on-premises network. The Direct Connect Gateway facilitates this routing by maintaining BGP sessions with both locations and advertising the appropriate prefixes. Latency typically improves compared to internet-based connectivity because AWS backbone paths are optimized and avoid the congestion common on public peering points.

Cost optimization strategies for Direct Connect Gateway

Direct Connect Gateway itself carries no additional charges beyond the underlying Direct Connect port fees and data transfer costs. However, the architectural choices enabled by the gateway, particularly Transit Gateway associations, introduce significant cost variables that compound at scale. Understanding these cost drivers enables informed trade-offs between operational simplicity and monthly AWS bills.

The primary cost components in a Direct Connect Gateway architecture include:

• Port hours: Charged based on connection speed (1 Gbps, 10 Gbps, 100 Gbps) regardless of utilization
• Data transfer out: Egress from AWS to on-premises, varying by Direct Connect location ($0.02-0.03 per GB typically)
• Transit Gateway processing: $0.02-0.05 per GB for all data traversing TGW attachments
• SiteLink transfer: Additional $0.028–$0.032 per GB fees for traffic between Direct Connect locations.

For a concrete example, consider an enterprise transferring 50 TB monthly through a Transit Gateway-based Direct Connect architecture. The TGW processing charges alone reach $1,000-2,500 per month before accounting for port fees or standard data transfer. The same traffic through a VGW-based architecture eliminates this processing charge entirely, potentially saving $12,000-30,000 annually. This cost difference often justifies the additional operational complexity of managing multiple VGW associations rather than consolidating through Transit Gateway.

Conclusion

AWS Direct Connect Gateway serves as the architectural foundation for enterprise hybrid connectivity. Its effectiveness depends entirely on understanding the quotas, association models, and virtual interface types that govern its behavior. The limits of 20 VGWs and 6 TGWs per gateway, combined with the 100-prefix constraint on transit VIFs, create design boundaries that must inform your architecture from the earliest planning stages. Choosing between VGW-based simplicity and TGW-based scalability represents a decision with multi-year cost and operational implications that warrant careful analysis rather than defaulting to the newest option.

High availability through geographically diverse connections, properly tuned BGP configurations with BFD enabled, and regular resiliency testing transform Direct Connect Gateway from a single point of failure into a production-grade connectivity platform. SiteLink extends this platform into a global backbone capability that can replace or augment traditional MPLS services. However, the cost implications require evaluation against your specific traffic patterns. As AWS continues expanding Direct Connect locations and enhancing Cloud WAN integration, the Direct Connect Gateway will remain central to hybrid architectures. Mastery of these seven knowledge areas is essential for any engineer designing enterprise AWS connectivity.