Skip to content

Direct Connect gateway implementation guide

Moving from one Direct Connect connection and one virtual interface to a redundant pair behind a Direct Connect gateway, so that VPCs in several Regions can be reached from the same on-premises network.

The migration involves deleting and recreating the existing private virtual interface, so it needs a maintenance window and a fallback path.

  • One 1 Gbps Direct Connect connection
  • One private virtual interface
  • One VPC
  • No cross-Region reach
  • Two 1 Gbps connections at different Direct Connect locations
  • A Direct Connect gateway
  • One private virtual interface per connection, both associated with the gateway
  • VPCs in more than one Region reachable from the same circuits
  1. Access to the Direct Connect console.
  2. Network administrator access to the on-premises routers.
  3. A BGP ASN for the Direct Connect gateway — AWS uses 64512 by default.
  4. VLAN IDs for the new virtual interfaces.
  5. IP address ranges for the BGP peerings.
  6. A maintenance window, and preferably a Site-to-Site VPN as a fallback path during the cutover.

Record the current configuration before changing anything: the private virtual interface settings, BGP configuration, route tables, VLAN IDs and peering addresses. Deleting a virtual interface discards them.

Order the second connection:

  • Same speed as the existing one.
  • At a different Direct Connect location. A second circuit into the same location protects against a circuit failure but not against the loss of that location.
  • Confirm the Letter of Authorization and Connecting Facility Assignment (LOA-CFA) has been received and the cross-connect installed.

Prepare the on-premises side: an additional physical port, BGP capability confirmed on the second router, and a routing policy review — decide now whether the two paths will be active/active or active/standby.

Phase 2: create the Direct Connect gateway

Section titled “Phase 2: create the Direct Connect gateway”
Terminal window
aws directconnect create-direct-connect-gateway \
--direct-connect-gateway-name "global-dxgw" \
--amazon-side-asn 64512

Associate it with the existing VPC’s virtual private gateway:

Terminal window
aws directconnect create-direct-connect-gateway-association \
--direct-connect-gateway-id "dxgw-xxxxxx" \
--virtual-gateway-id "vgw-xxxxxx"

The gateway can be created and associated before any virtual interface points at it, which keeps this phase non-disruptive.

A private virtual interface can be associated with a virtual private gateway or a Direct Connect gateway, never both, and it cannot be moved. The existing one has to be deleted and recreated.

  1. Confirm the fallback path is carrying traffic.
  2. Delete the existing private virtual interface.
  3. Create a virtual interface on each connection, each with its own VLAN ID and BGP settings, associated with the Direct Connect gateway:
Terminal window
aws directconnect create-private-virtual-interface \
--connection-id "dxcon-xxxxxx" \
--new-private-virtual-interface \
virtualInterfaceName=primary-vif,vlan=100,asn=65001,directConnectGatewayId=dxgw-xxxxxx

Repeat for the second connection with a different VLAN ID.

BGP. Confirm both sessions establish, that routes are propagating in both directions, and that the prefixes advertised are the ones you expect and no more.

Connectivity. Reach resources in the VPC over each path. Then fail each path deliberately — shut the BGP session, not the physical port — and confirm traffic moves to the other within the expected convergence time.

Monitoring. Configure CloudWatch metrics on the connections and virtual interfaces, and alarm on ConnectionState and on BGP session state. A failed circuit that nobody notices is a single point of failure you are paying twice for.

Terminal window
aws directconnect create-direct-connect-gateway-association \
--direct-connect-gateway-id "dxgw-xxxxxx" \
--virtual-gateway-id "vgw-yyyyyy"

Then add routes in each Region’s VPC route tables and test cross-Region connectivity.

A Direct Connect gateway associates with up to 20 virtual private gateways or up to 6 transit gateways; neither quota can be increased. Note also that it does not route between the associated VPCs — for that, attach a transit gateway. See transit gateway or Direct Connect gateway.

graph TB subgraph OnPrem["On-Premises Network"] CR[Customer Router] DC[Data Center] DC --> CR end subgraph DXLoc["AWS Direct Connect Locations"] subgraph CustCage["Customer Cage"] CageR1["Customer<br/>DX router 1"] CageR2["Customer<br/>DX router 2"] CR --"Primary connection"--> CageR1 CR --"Secondary connection"--> CageR2 end subgraph AWSCage["AWS Cage"] DX1["Direct Connect 1<br/>1 Gbps"] DX2["Direct Connect 2<br/>1 Gbps"] DXR1[AWS DX router 1] DXR2[AWS DX router 2] CageR1 --> DXR1 CageR2 --> DXR2 DXR1 --> DX1 DXR2 --> DX2 end subgraph VIFs["Private Virtual Interfaces"] VIF1["Private VIF 1<br/>VLAN 100"] VIF2["Private VIF 2<br/>VLAN 200"] end DXGW["Direct Connect Gateway<br/>ASN 64512"] DX1 --> VIF1 DX2 --> VIF2 end subgraph R1["Region: eu-west-2"] VPC1["Primary VPC<br/>10.0.0.0/16"] VGW1[Virtual Private Gateway] end subgraph R2["Region: eu-west-1"] VPC2["Secondary VPC<br/>172.16.0.0/16"] VGW2[Virtual Private Gateway] end VIF1 & VIF2 --"BGP session"--> DXGW DXGW --> VGW1 & VGW2 VGW1 --> VPC1 VGW2 --> VPC2 classDef aws fill:#FF9900,stroke:#232F3E,stroke-width:2px,color:white; classDef corporate fill:#00A4EF,stroke:#232F3E,stroke-width:2px,color:white; class VPC1,VPC2,DXGW,DX1,DX2,VGW1,VGW2,VIF1,VIF2,DXR1,DXR2 aws; class DC,CR,CageR1,CageR2 corporate;