Direct Connect: Virtual Interfaces, Gateways, and Prefixes

Direct Connect has more objects than it looks like it has, and several of its limits are counted at a different level from the one you configure them on. This sheet is the map.

Virtual interface types#

A VIF is one 802.1Q VLAN carrying its own BGP session, and you can run one session per address family on it. The type decides which gateway it may terminate on, which in turn decides what it can reach.

Type	Terminates on	Reaches	SiteLink
private	A virtual private gateway directly, or a Direct Connect gateway	Private addresses in attached VPCs	Only when on a DX gateway
transit	A Direct Connect gateway, which associates to Transit Gateways	Everything behind those Transit Gateways	Supported
public	Nothing — no gateway is involved	AWS public service endpoints, over BGP	Not supported

A transit VIF works on a dedicated or hosted connection of any speed, and can terminate on a Cloud WAN core network as well as a Transit Gateway.

Where each object sits#

The scopes do not line up, and that is the source of most confusion here. A Direct Connect gateway is a global object. An association from it is to one regional gateway. Two different prefix limits are enforced at two different levels.

Direct Connect connectionOne locationThe physical port. Dedicated or hosted.

counted here: 50 private/public VIFs on dedicated, plus 4 transit. Exactly 1 VIF on hosted.

Virtual interfaceOne VLANOne BGP session per address family.

counted here: inbound prefixes from on-prem: 100 per family by default, raisable to 1,000

Direct Connect gatewayGlobalNot in any Region. VIFs in different locations can terminate on the same one.

counted here: a 10,000 prefix pool shared across every attached VIF, and 30 VIF attachments

Association to a virtual private gatewayOne Region

counted here: allowed prefixes, acting as a filter

Association to a Transit GatewayOne Region

counted here: allowed prefixes, acting as static origination — 200 prefixes, IPv4 and IPv6 combined

Inbound limits are counted per VIF. Allowed prefixes are counted per association. Checking headroom on one tells you nothing about the other.

Allowed prefixes mean opposite things#

Same field name, same console screen, opposite semantics depending on the gateway type at the far end of the association. This is the single most useful thing on this sheet.

	Virtual private gateway	Transit Gateway
Behaves as	A filter on what AWS would otherwise advertise	Static origination of routes that did not exist
You receive	The actual VPC CIDR, if permitted	The allowed prefix itself
Entry must be	The same as, or wider than, the VPC CIDR	Anything at all
Advertised from	The VPC	The DX gateway's ASN

Worked from the same starting point in both columns — a VPC with CIDR 10.0.0.0/16:

Allowed prefixes set to	Over a VGW association you receive	Over a TGW association you receive
22.0.0.0/24	Nothing. Not the same as or wider than the VPC CIDR	22.0.0.0/24
10.0.0.0/24	Nothing. Narrower than the VPC CIDR	10.0.0.0/24
10.0.0.0/15	10.0.0.0/16 — the VPC CIDR, not the /15	10.0.0.0/15
10.0.0.0/8	10.0.0.0/16	10.0.0.0/8

On a Transit Gateway association you can advertise a prefix with no relationship to anything attached — 8.8.8.8/32 is accepted — because AWS provisions exactly what the list says rather than filtering what exists. Two consequences worth holding onto: overlaps are rejected when multiple Transit Gateways associate to one DX gateway, so you cannot set 0.0.0.0/0 on a second association while a first holds 10.1.0.0/16; and editing the list does not drop the BGP session. The association moves from associated to updating, and only traffic using the prefix you touched is affected.

IPv6 fails closed where IPv4 fails open#

Omitting the list is not a neutral act, and the two families disagree about what it means. On IPv4 no filter is equivalent to 0.0.0.0/0 — everything is advertised. On IPv6, per the IPv6 on AWS whitepaper, specifying no value blocks all advertisements. An IPv6 allowed prefix must also be /64 or less specific, and ::/0 is not accepted.

So a dual-stack association with an empty allowed-prefixes list has working IPv4 and silently dead IPv6.

Inbound prefix budgets#

The other direction, from on-premises into AWS. Covered properly in the hybrid connectivity guide — the short version is that exceeding your allocation takes the BGP session to idle rather than dropping the excess prefixes.

Scope	Limit
Per BGP session, private or transit VIF	100 per address family, raisable to 1,000
Per BGP session, public VIF	1,000
Per DX gateway	10,000 across all attached VIFs, and 30 VIF attachments
Consumed by an AWS Interconnect connection	2,000 of that 10,000

MTU#

Path	Values
DX link layer Ethernet frame	1522 or 9023 bytes
Private VIF	1500 or 9001
Transit VIF	1500 or 8500
Transit Gateway jumbo support	8500 only

Two behaviours that are easy to be caught by. If two private VIFs advertise the same route with different MTU values, or a Site-to-Site VPN advertises that route as well, 1500 is used — the lower value wins and your jumbo configuration is quietly inactive. And raising a VIF to jumbo can trigger an update to the underlying physical connection, which disrupts every VIF on that connection for up to 30 seconds. That is a change-window operation, not a safe tweak.

Jumbo frames apply only to propagated routes over Direct Connect and static routes via Transit Gateway. Every current EC2 instance type supports them except C1, CC1, T1, and M1.

Quotas that shape the design#

Quota	Value	Adjustable
VIFs per hosted connection	1, of any type	No
Private or public VIFs per dedicated connection	50	No
Transit VIFs per dedicated connection	4	No
Members per LAG	4	No
Transit Gateways per DX gateway	6	No
DX gateways per Transit Gateway	20	No
VIFs per DX gateway	30	No
Active connections per location, per Region, per account	10	Contact AWS

The hosted-connection row is the one that changes architectures. A hosted connection carries exactly one virtual interface, full stop, so "we will add a transit VIF alongside the private one later" is not available on it. That decision is made when the connection is ordered, not afterwards.

ASN collisions#

The Amazon-side ASN depends on where the VIF terminates, which catches people who move a private VIF onto a DX gateway and keep their BGP config:

• Private VIF straight onto a virtual private gateway → the Amazon side uses the VGW's ASN.
• Private VIF onto a DX gateway → the Amazon side uses the DX gateway's ASN.

Two rules follow. You cannot use the same ASN on both ends of a VIF. And associating a Transit Gateway with a DX gateway requires the two to have different ASNs — since 64512 is the default for both, a pair of defaults fails the association outright.

Also worth knowing before you debug a missing route: a point-to-point /30 used for BGP peering, such as 192.168.0.0/30, does not propagate to a Transit Gateway. And a DX gateway already associated with a VGW or attached to a private VIF cannot then be attached to a Transit Gateway.

SiteLink changes path selection#

SiteLink connects two Direct Connect points of presence over the AWS backbone without the traffic transiting a Region. Private and transit VIFs only, never public, and never a private VIF attached directly to a virtual private gateway — it needs a DX gateway. Not available in GovCloud (US) or the China Regions, and separately billed.

The part that matters operationally is that enabling it changes how AWS picks an egress location:

• SiteLink off. Traffic from a virtual or Transit Gateway prefers a DX location associated with that Region, even when a location associated with a different Region advertises a shorter AS path.
• SiteLink on. Traffic prefers the lower AS path length regardless of which Region the location is associated with.

That first bullet is the mechanism behind the AS-path-prepending-does-nothing trap in the hybrid connectivity guide. Turning SiteLink on changes the answer.

One more: SiteLink does not work if your on-premises router advertises the same route to AWS on multiple virtual interfaces.