Help us improve the AWS re:Post Knowledge Center by sharing your feedback in a brief survey. Your input can influence how we create and update our content to better support your AWS journey.
How do I manage asymmetric routing with Direct Connect?
I want to use AWS Direct Connect with public, private, and transit virtual interfaces to manage asymmetric routing between my on-premises network and AWS resources.
Resolution
The following resolution explains how to manage outbound traffic flow from AWS to your on-premises network. For inbound traffic flow from your on-premises network to AWS, you must use preferred routing options to set the preference to a particular path.
To manage asymmetric routing with Direct Connect, use prefix length and Border Gateway Protocol (BGP) attributes to determine path selection for different types of virtual interfaces.
Note: For public virtual interfaces, AWS uses AS_PATH and the longest prefix match to determine the routing path.
Use specific prefixes to prefer Direct Connect over the internet
If you advertise the same prefix from both the internet and a public virtual interface, then use more specific routes on the public virtual interface. The traffic then prefers Direct Connect.
For example, you advertise the prefix 80.80.80./24 on both the internet and your public virtual interface. To allow traffic to prefer the public virtual interface, change your virtual interface prefix to a more specific one, such as 80.80.80.0/25 or 80.80.80.128/25.
Route traffic from the home and remote Region with identical BGP attributes and prefix lengths
AWS prioritizes the home AWS Region for outbound traffic in the following scenario:
You advertise the same prefixes on public virtual interfaces in the home Region and remote Region with identical BGP attributes and prefix lengths.
To route between Regions, advertise your prefix on the public virtual interfaces in both the home Region and remote Region. This configuration allows traffic to prefer the virtual interface that's in the same Region as the VPC.
Route traffic from the home and remote Region with identical prefix lengths
AWS prioritizes the link with the shorter AS_PATH in the following scenario:
You advertise the same prefixes on public virtual interfaces in the home Region and remote Region with identical prefix lengths.
To route traffic between multiple Regions, advertise your prefix on the virtual interfaces in both the home Region and remote Region. Then, advertise your prefix on the virtual interface in your home Region with a longer AS_PATH. This configuration allows traffic from the VPC in your home Region to prefer the virtual interface in the remote Region.
Route traffic from two remote Regions with identical prefix lengths
AWS prioritizes the link with the shorter AS_PATH in the following scenario:
You advertise the same prefixes from public virtual interfaces from two remote Regions with identical prefix lengths.
To route traffic between multiple Regions, advertise your prefix on the public virtual interfaces in the remote Regions. Then, advertise your prefix on one of the remote public virtual interfaces with a longer AS_PATH. This configuration allows traffic from the VPC in the home Region to prefer the remote virtual interface that doesn't have the longer AS_PATH.
Route traffic from multiple Regions with public ASN and private ASN
Note: Prepending works with a public Autonomous System Number (ASN), and your prepended ASN is visible to other networks. If you use prepending with a private ASN, then AWS replaces your private ASN with the 7224 ASN. When you use a private ASN on a public virtual interface, ASN prepending doesn't determine routing decisions outside AWS.
AWS prioritizes the link with the shorter AS_PATH in the following scenario:
You advertise the same prefixes from public virtual interfaces from two Regions with identical prefix lengths.
To route traffic between multiple Regions when you use public and private ASNs, advertise your prefix on the virtual interfaces in each remote Region. In one remote Region, advertise your prefix with a longer private ASN AS_PATH. In the other remote Region, advertise your prefix with a shorter public ASN AS_PATH. This configuration allows traffic from the VPC in the home Region to prefer the virtual interface with the longer private ASN AS_PATH.
Note: Direct Connect replaces the ASNs with the public ASNs of your Direct Connect gateway or the Region's ASN. In the AWS network, Direct Connect sees "[your prefix], as_path [YOUR_PUBLIC_ASN]" from the virtual interface with the longer private ASN AS_PATH. From the virtual interface with the shorter public ASN AS_PATH, it sees "[your prefix], as_path [YOUR_PUBLIC_ASN] 1111 1111".
Load share from multiple connections in the same Region
To modify outbound traffic load sharing across multiple Direct Connect connections, advertise prefixes with the same path attributes.
Note: You can load share virtual interfaces only in the same Region.
To load share from multiple connections, advertise your prefix with the same prefix length on all the public virtual interfaces that are in the same Region as your VPC.
Use local preferences to choose a network path for private and transit virtual interfaces
Use BGP communities to modify local preference. A higher local preference is preferred.
To set the local preference, use one of the following BGP community tags:
- 7224:7100 (low preference)
- 7224:7200 (medium preference)
- 7224:7300 (high preference)
The following example scenarios demonstrate how to use local preferences to choose a network path for private and transit virtual interfaces. The scenarios assume that you attached your transit virtual interfaces to a single Direct Connect gateway.
Note: It's a best practice to use the local preference BGP attribute with routing paths for active and passive connections and when you advertise the same prefix lengths. You must set the value for local preference for each Region to prefer Direct Connect locations that have the same associated Region. Set the value to 7224:7200 (medium preference). If you didn't associate the local Region with the Direct Connect location, then set local preference to a lower value. This applies only when you don't assign local preference community tags.
Two virtual interfaces in the same Region
When two virtual interfaces are in the same Region, add a community tag to your primary virtual interface. Don't add a community tag to your secondary virtual interface. Then, advertise your prefix on both virtual interfaces. This configuration allows traffic from the VPC in the same Region to prefer the virtual interface with the community tag.
Note: The default value of the BGP local preference is 7224:7200 (medium preference).
One virtual interface in a different Region
You have one virtual interface in the same Region as your VPC and one in a remote Region. Don't add a community tag to either the home virtual interface or the remote virtual interface. Then, advertise your prefix on both virtual interfaces. This configuration allows traffic to prefer the virtual interface that's in the same Region as your VPC.
Note: The default value of the BGP local preference is 7224:7200 (medium preference).
Virtual interfaces in a different Region than your VPC
Both virtual interfaces are in a different Region than your VPC. Don't add a community tag to either of the remote virtual interfaces, and then advertise your prefix on both virtual interfaces. This configuration allows traffic from the VPC to load balance across both of the remote virtual interfaces.
Use the AS_PATH attribute to choose a network path
If the local preference option isn't available, then use the AS_PATH attribute to choose a network path. You must advertise prefixes with different AS_PATH lengths to direct traffic but only when your prefixes have the same local preference. It's a best practice to use a shorter AS_PATH.
The following example scenarios demonstrate how to use the AS_PATH attribute to choose a network path for private and transit virtual interfaces.
Note: The following scenarios assume that you attached your transit virtual interfaces to a single Direct Connect gateway.
Two virtual interfaces in the same Region
You have two virtual interfaces in the same Region. Don't add community tags to the virtual interfaces. Advertise your prefix on both virtual interfaces, and then apply a longer AS_PATH to one of the virtual interfaces. This configuration allows traffic from the VPC to prefer the virtual interface that doesn't have the longer AS_PATH.
Note: The default value of the BGP local preference is 7224:7200 (medium preference).
One virtual interface in a different Region
You have one virtual interface in the same Region as your VPC and one in a different Region. Don't add community tags to either the virtual interface in the home Region or the remote virtual interface. Advertise your prefix on both virtual interfaces, and then choose a combination of AS_PATH preferences. This configuration allows traffic to prefer the virtual interface that's in the same Region as the VPC.
Note: The default value of the BGP local preference for the home Region is 7224:7200 (medium preference). You can't use the AS_PATH attribute to change the preference to "Home region: 7224:7200 Medium preference". Local preference overrides any AS_PATH preference.
Virtual interfaces in a different Region than your VPC
Both virtual interfaces are in a different Region than your VPC. Don't add community tags to any of your virtual interfaces. Advertise your prefix on both virtual interfaces with the same AS_PATH preference. Then, apply a longer AS_PATH on one of the virtual interfaces. This configuration allows traffic from the VPC to prefer the virtual interface that doesn't have the longer AS_PATH.
Note: The default value of the BGP local preference for the remote Regions is 7224:7100 (low preference).
Follow best practices to manage asymmetric routing
Implement the following best practices:
- For public virtual interfaces, use more specific routes on Direct Connect when possible so that your traffic prefers the dedicated connection over the internet.
- Regularly monitor your BGP routes and traffic patterns to make sure that your routing configuration works.
- If you use multiple virtual interfaces for redundancy, then configure your on-premises network to handle potential asymmetric routing scenarios.
- Test your routing configurations before you implement them in production environments.
Related information
- Language
- English

Relevant content
- asked 2 years ago
- asked 7 months ago
- asked a year ago
AWS OFFICIALUpdated 3 years ago
AWS OFFICIALUpdated 3 years ago