Lesson 269 · AWS Learning Path

AWS 269: Direct Connect Gateway and virtual interfaces

Anil Jalela · Published Mar 21, 2026 · 15 min read

Why this lesson matters

A Direct Connect port is only physical capacity. A virtual interface (VIF) creates a logical 802.1Q/BGP path on that port, and its type determines what it can reach. A Direct Connect gateway (DXGW) connects eligible VIFs to virtual private gateways (VGWs), Transit Gateways (TGWs), or supported Cloud WAN designs across approved accounts and Regions. Choosing the wrong VIF or gateway combination can leave a perfectly healthy port with no valid route.

The difficult parts are not the names. Architects must understand where each BGP session terminates, which ASN appears, who owns and accepts cross-account proposals, what prefixes AWS originates or filters, where transit is prohibited, how route preference works, and what a green available or up state does not prove.

This lesson builds those contracts in detail. It does not create, accept, associate, update, test, or delete anything. You will inspect explicitly owned evidence and design a multi-account, multi-Region routing model locally.

Outcomes

By the end, you can:

• select public, private, or transit VIF from destination and routing requirements;
• distinguish a direct private-VIF-to-VGW design from a DXGW/VGW or DXGW/TGW design;
• explain why a public VIF does not attach to a DXGW and is not general internet transit;
• inventory VLAN, BGP peer addresses, address families, ASNs, authentication, MTU, SiteLink, owner, and gateway fields;
• explain DXGW scope, ASN, association restrictions, quotas, and non-transitive behavior;
• execute the reasoning for same-account and cross-account association proposals;
• calculate allowed-prefix behavior separately for VGW and TGW associations;
• design IPv4/IPv6, route filters, prefix controls, BGP communities, active/active, and active/passive paths;
• interpret VIF, BGP peer, association, route, metric, and failover-test states;
• diagnose failures without modifying production routing; and
• produce a reviewable eight-VPC hybrid-routing dossier.

Start with the destination, not the port

One dedicated connection can host many private/public VIFs within current quotas. A hosted connection supports one VIF. The VIF is therefore both a routing boundary and a capacity/blast-radius decision.

The three principal data paths

Direct private VIF to VGW

customer router == VLAN/BGP private VIF == VGW == one VPC

This is the simplest private design for one VPC in the relevant Region. The Amazon-side BGP ASN comes from the VGW. It does not provide the DXGW's multi-Region/multi-association abstraction.

Private VIF through DXGW to VGWs

customer router == private VIF == DXGW
                                  |-- VGW/VPC A
                                  |-- VGW/VPC B in another account/Region

The private VIF terminates logically on the DXGW, whose ASN appears toward on-premises. Each VGW association contributes approved VPC reachability. Associated VPC CIDRs cannot overlap. The DXGW normally does not become a VPC-to-VPC transit router; associated gateways do not automatically communicate through it.

Transit VIF through DXGW to TGW

customer router == transit VIF == DXGW == TGW == selected attachments/routes

This centralizes many VPC/VPN attachments behind TGW routing domains. The TGW owner still controls attachment associations, propagations, static/blackhole routes, and segmentation. The DXGW allowed-prefix list and TGW route table must both be correct; neither replaces the other.

What a Direct Connect gateway is and is not

A DXGW is a globally available Direct Connect resource within an AWS partition. It lets eligible VIFs reach associated gateways beyond one VPC/account/Region. It is designed outside the data path as a scalable association abstraction rather than a customer-managed appliance. Creating multiple DXGWs does not by itself make a physical connection resilient.

The DXGW has an Amazon-side ASN selected at creation. Plan it before creation because the ASN is not a casual routing detail and must differ from the customer ASN on the VIF. On-premises sees the DXGW ASN in relevant advertisements; a VGW ASN behind the DXGW is not exposed in the same way as a private VIF attached directly to that VGW.

Important combination rules:

• A DXGW used with VGWs/private VIFs cannot simultaneously be repurposed as the same gateway for TGW/transit-VIF associations.
• A DXGW already associated with VGWs or attached private VIFs cannot be associated with TGW.
• A DXGW already associated with TGW cannot be associated with VGW.
• A public VIF does not attach to DXGW.
• One VGW cannot be associated with multiple DXGWs, and one private VIF cannot attach to multiple DXGWs.
• The VGW must be attached to a VPC; detaching it also affects the DXGW association.
• Overlapping CIDRs among VPCs associated through VGWs are not supported.
• Quotas constrain DXGWs, VIFs, VGW/TGW associations, and prefixes; verify current values before design.

VIF fields, from Layer 2 through BGP

For IPv6 BGP peers, AWS allocates supported peer addressing; IPv4 public VIF peer addresses must meet public-ownership requirements. Private/transit peer addresses can use valid dedicated point-to-point space under documented rules but must not be advertised as workload routes or reused ambiguously. Do not use EIP/BYOIP pool addresses in unsupported peer configurations.

AWS enables BGP MD5 authentication; protect the generated or supplied key. MD5 authenticates BGP messages, not application traffic. Direct Connect supports single-hop BGP, so multihop assumptions and TTL changes are invalid. BGP/BFD timers must be engineered with device capacity and convergence tests; combining graceful restart and BFD without understanding stale-route behavior can prolong blackholes.

VIF and BGP states

bgpStatus=up means the peer is established, not that correct routes are accepted, advertised, selected, or usable. Inspect route visibility, prefix counts, customer RIB/FIB, gateway routes, and application probes.

Public VIF: public AWS services, not the internet

A public VIF exchanges customer-owned validated public prefixes and Amazon public prefixes. AWS uses ASN 7224 on its side. The customer must advertise at least one approved public prefix, and AWS performs ownership/registry and routing-policy checks. A private ASN can be used under documented conditions, but public-AS behavior such as useful AS-path prepending differs.

AWS public service reachability includes public endpoints/prefixes according to current advertisements; it does not provide transit to non-AWS internet destinations. Source validation applies. Protect the customer router with explicit route filters rather than accepting/redistributing every learned Amazon route into internal tables blindly.

Scope communities on routes from AWS can control how broadly Amazon prefixes are received. Region/continent communities on customer routes can affect advertisement scope, and public routing requires careful ownership and asymmetric-return analysis. Do not advertise 0.0.0.0/0 or an unowned aggregate as a shortcut.

If private workloads need S3 without public IP addresses, evaluate gateway/interface endpoints or private connectivity patterns. A public VIF reaches public service addresses; “public VIF” does not mean the packets must traverse the public internet, but it does mean public addressing/routing policy is involved.

Private and transit VIF routing policy

Private/transit VIFs advertise on-premises prefixes toward AWS and receive AWS-side prefixes according to the gateway associations. Longest prefix match dominates. For equal prefixes, AWS Region/location preference, local-preference communities, AS path, and ECMP behavior matter according to topology.

Direct Connect accepts local-preference communities from customer advertisements:

Use equal communities for intended active/active equal preference and different communities for active/passive. AS-path prepending can influence other comparisons, but community and Region preference interactions must be tested. These controls influence AWS-to-on-premises routing; customer local preference controls on-premises-to-AWS selection. Design both directions.

Current prefix controls can allocate higher private/transit inbound route capacity than the default, up to supported limits. If the customer advertises beyond its allocation, BGP can be driven down. Aggregate responsibly, reserve headroom for growth/failover, set customer maximum-prefix thresholds, and alarm on accepted/advertised counts.

Allowed prefixes: VGW and TGW behavior is different

This distinction is certification-important and operationally critical.

DXGW association to VGW

The allowed-prefix list is a filter. The VGW still advertises the associated VPC's actual CIDR. The configured allowed range must be the same as or wider than that VPC CIDR.

For VPC 10.0.0.0/16:

The /15 is not advertised merely because it appears in the filter. Only the actual associated VPC CIDR is advertised.

DXGW association to TGW

The allowed-prefix list is originated by the DXGW toward on-premises. The listed aggregate or specific prefix is what BGP receives, even if it does not exactly mirror one attached VPC CIDR. TGW route tables still need routes that can deliver traffic covered by that advertisement. An overly broad allowed prefix can attract traffic into a TGW that has nowhere safe to send it.

When one DXGW associates with multiple TGWs, their allowed prefixes cannot overlap. A 0.0.0.0/0 association collides with every IPv4 prefix and is therefore incompatible with other TGW allowed ranges on that DXGW. Use deliberate non-overlapping allocation and ownership.

Updating allowed prefixes can transiently affect traffic using changed prefixes while the association is updating. Treat it as a routed production change with before/after advertisements, reachability, and rollback, not a documentation edit.

Cross-account associations and proposals

Multi-account connectivity requires mutual control:

1. the VGW/TGW owner identifies the DXGW ID and owner and creates an association proposal with requested prefixes;
2. the DXGW owner verifies the requesting account, gateway, VIF owner where required, prefixes, ASN/IP plan, route intent, cost, and ticket;
3. the DXGW owner accepts, rejects, or overrides approved prefixes;
4. both owners verify association state, BGP advertisements, route tables, positive paths, negative segmentation paths, monitoring, and rollback;
5. proposal/association changes are audited and periodically reconciled.

VGW proposals have expiration/visibility lifecycle, so stale proposals should not be treated as durable configuration. An association does not grant IAM access to workloads; it creates network reachability that security groups, NACLs, firewalls, identity, and application policy must still constrain.

Maintain a contract with fields for both account owners, gateway/VIF IDs, Regions, prefixes, allowed direction/use, environment/data class, route owner, security owner, monitoring, cost allocation, incident contacts, change authority, expiry/review, and decommission dependency.

Transit and isolation boundaries

A DXGW is not a general route-reflector/transit service among all attachments. With VGW associations, direct VPC-to-VPC communication through the same DXGW is generally unsupported, as are direct VIF-to-VIF paths and VIF-to-VPN hairpins. A documented supernet exception can allow associated VPC communication via the Direct Connect endpoint under narrow conditions; do not use that side effect as a segmentation architecture.

For controlled VPC-to-VPC, VPN-to-VPC, or inspection transit, use TGW route tables, Cloud WAN policy, VPC peering, or another intentional service. Verify return paths and stateful appliance symmetry. A transit VIF plus DXGW only gets routes to TGW; TGW association/propagation and VPC subnet routes decide actual forwarding.

SiteLink can connect eligible VIFs at DX locations over the AWS network. It is supported for transit VIF and specific private-VIF/DXGW combinations, not public VIF or private VIF directly attached to VGW. It fails if the same route is advertised in an unsupported way across multiple SiteLink VIFs. Treat SiteLink as a WAN route and cost domain with explicit branch-to-branch security.

Redundancy without route ambiguity

One VIF on one connection is one logical failure path. Resilient designs normally create VIFs over physically diverse Direct Connect connections/locations and establish separate BGP peers. A VIF cannot span two connections. LAG member redundancy at one endpoint does not replace diverse VIFs.

For each prefix, document:

• normal customer-to-AWS path and AWS-to-customer path;
• equal/unequal local preference communities;
• customer local preference and AS path policy;
• more-specific route effects;
• BFD/BGP timer and failure detection;
• backup VPN's advertised prefixes and route priority;
• failed-path capacity and MTU; and
• whether stateful middleboxes support resulting asymmetry.

A route backup is not usable until its VIF/BGP/gateway/security/application path passes a controlled failover test.

Read-only console and CLI investigation

In the Direct Connect console inspect VIF details, BGP peers/routes, connection parent, VIF owner, SiteLink, MTU, gateway, associations, proposals, and prefix lists. Inspect CloudWatch VirtualInterfaceBgpStatus, accepted/advertised prefix counts, bps and pps. Do not click Accept, Associate, Edit, Start failover test, or Delete.

export AWS_DEFAULT_REGION="ap-south-1"
aws sts get-caller-identity --query Arn --output text

aws directconnect describe-virtual-interfaces \
  --query 'virtualInterfaces[].{Name:virtualInterfaceName,Id:virtualInterfaceId,Owner:ownerAccount,Connection:connectionId,Type:virtualInterfaceType,State:virtualInterfaceState,Vlan:vlan,CustomerAsn:asn,AmazonAsn:amazonSideAsn,Family:addressFamily,Bgp:bgpStatus,Mtu:mtu,SiteLink:siteLinkEnabled,Vgw:virtualGatewayId,Dxgw:directConnectGatewayId}' \
  --output json

aws directconnect describe-direct-connect-gateways \
  --query 'directConnectGateways[].{Name:directConnectGatewayName,Id:directConnectGatewayId,Owner:ownerAccount,State:directConnectGatewayState,Asn:amazonSideAsn}' \
  --output table

aws directconnect describe-direct-connect-gateway-associations --output json
aws directconnect describe-direct-connect-gateway-association-proposals --output json
aws cloudwatch list-metrics --namespace AWS/DX --output json

Redact account IDs, peer IPs, public/private prefixes, VLANs where topology-sensitive, BGP keys, route policies, locations, and resource IDs before sharing. Paginate results. Query each owner account because one account's view cannot prove another account's route table, security policy, or acceptance intent.

Evidence-led troubleshooting

Do not recreate a VIF to fix a route filter. VLAN and peer changes can require disruptive replacement, and deletion can remove the evidence needed for AWS/provider support. Capture state, peer/routes, metrics, associations, changes, and packet behavior first.

Eight-VPC architecture exercise

Northwind has one dedicated connection at each of two diverse locations, eight VPCs across ap-south-1 and eu-west-1, production and non-production TGWs in separate network accounts, public S3/API endpoint requirements, IPv4 now and IPv6 migration, on-premises ASN 65020, and a VPN backup. Production and non-production must not transit each other. Two acquisition VPCs use overlapping RFC1918 space.

Produce:

1. requirement-to-VIF decision matrix for private/public/transit and alternatives such as endpoints;
2. account/Region ownership map for connections, VIFs, DXGWs, TGWs/VGWs, proposals, and bills;
3. VLAN, IPv4/IPv6 peer, ASN, BGP key owner, MTU, SiteLink, and parent-connection register;
4. separate production/non-production DXGW/TGW association model respecting type and overlap restrictions;
5. allowed-prefix calculations showing VGW-filter versus TGW-originated behavior;
6. TGW association/propagation/static/blackhole routes and VPC subnet routes;
7. public-prefix ownership/validation and public-VIF route-filter plan, or a justified endpoint alternative;
8. active/active or active/passive community/local-preference/AS-path policy in both directions;
9. overlap resolution for acquisition networks without pretending DXGW performs NAT;
10. normal, one-VIF, one-port, one-location, and VPN-only route/capacity/MTU tests;
11. positive connectivity and negative segmentation test matrix; and
12. RACI, monitoring, rollback, cost allocation, exception expiry, and decommission plan.

Reject the design if it attaches a private VIF to TGW, attaches a public VIF to DXGW, mixes VGW and TGW association modes on one DXGW, uses overlapping TGW allowed prefixes, assumes DXGW is unrestricted transit, or lacks a separately tested return path.

Cost and no-change evidence

DXGW itself is not a replacement for pricing every path. Include underlying connection/hosted charges, DTO or billing tier, SiteLink transfer, TGW attachment/data processing, Cloud WAN where used, public IPv4, VPN backup, monitoring/logging, partner/carrier costs, and idle resilience capacity. Cross-account designs need an agreed cost owner for each service and transfer direction.

This lesson's cleanup is an unchanged inventory. Do not accept/reject a VIF, create/update/delete a peer, change MTU/SiteLink, accept a gateway proposal, edit allowed prefixes, or start a failover test. For approved teardown, sequence traffic drain, route withdrawal, association/proposal removal, VIF deletion, key retirement, port/circuit cancellation, alarm removal, cost verification, and evidence retention across all owners.

Knowledge check

1. Which VIF reaches TGW?

A transit VIF attached to DXGW, which is associated with TGW.

1. Does a public VIF attach to DXGW?

No. It peers for AWS public prefixes and is not general internet transit.

1. How do VGW and TGW allowed prefixes differ?

VGW entries filter actual VPC CIDRs; TGW entries are originated by DXGW toward on-premises.

1. Does bgpStatus=up prove application reachability?

No. Correct prefixes, route selection, gateway/VPC routes, security, DNS, return path, and workload must also pass.

1. Can a DXGW associated with VGWs also associate with TGW?

No; use a separate compatible gateway design.

1. What creates cross-account consent?

The resource-gateway owner proposes and the DXGW owner validates/accepts the association and approved prefixes.

Lesson acceptance

The lesson is complete only when the learner can:

• derive the correct VIF/gateway path from each destination requirement;
• explain every VIF field and state from VLAN through BGP and routing;
• apply DXGW combination, overlap, association, ASN, quota, and transit rules;
• calculate VGW and TGW allowed prefixes correctly without conflating them;
• design and audit cross-account association proposals and ownership contracts;
• prove both address families, route directions, preference, segmentation, failover, capacity, and MTU;
• interpret route visibility, prefix metrics, VIF/BGP/association states, and application tests;
• diagnose every supplied failure from evidence before mutation;
• complete and defend the eight-VPC dossier; and
• attest that no VIF, peer, DXGW, association, route, prefix, SiteLink setting, or AWS resource was changed.

Official sources

• Direct Connect virtual interfaces
• Direct Connect gateways
• Virtual private gateway associations
• Transit Gateway associations
• Cross-account VGW association
• Cross-account TGW association proposal
• Allowed-prefix interactions
• Routing policies and BGP communities
• BGP-specific settings
• Direct Connect quotas
• CloudWatch Direct Connect metrics