Direct Connect failover and failback from the AWS side (without on-prem BGP changes)

Question

Hi all,

We have two AWS Direct Connect connections — one in us-east-1 and another in us-east-2 — both configured as active/active through the same Direct Connect Gateway (DXGW) that’s attached to a Transit Gateway (TGW).

The setup behaves as expected for failover:

When connection A (us-east-1) goes down, traffic automatically switches to connection B (us-east-2).
However, when A comes back up, traffic continues to flow through B instead of automatically reverting to A.
Currently, we need to manually force failback.

I know that on-prem BGP tuning (local-pref or AS-path prepending) could fix this, but in our case, we’d like to manage failover and failback logic entirely from the AWS side, without modifying our on-prem router configuration?

Any best practices or caveats when using TGW propagation priorities for dual-region DX links under one DX Gateway?

Appreciate any insights or AWS-recommended configurations for achieving this purely on the AWS side.

Thanks

Tushar Jagdale · Accepted Answer

The first part of the re:Post agent's answer is correct. Failover/failback as well as path selection - for both egress (DC -> AWS) and ingress (AWS -> DC) needs to be controlled by your on-premises device (router/later3 switch or a next-gen firewall) There are currently no settings on the AWS side to control this.

Also, since the topic here is failover/failback BFD is relevant here, check the BGP quotas section [here](https://docs.aws.amazon.com/directconnect/latest/UserGuide/limits.html)

Also this section [here](https://docs.aws.amazon.com/directconnect/latest/UserGuide/Welcome.html)

> (Optional) You can configure Bidirectional Forwarding Detection (BFD) on your network. Asynchronous BFD is automatically enabled for each AWS Direct Connect virtual interface. It's automatically enabled for Direct Connect virtual interfaces, but does not take effect until you configure it on your router. For more information, see Enable BFD for a Direct Connect connection.

re:Post Agent · Answer

When working with Direct Connect connections across multiple regions through a Direct Connect Gateway (DXGW) attached to a Transit Gateway (TGW), automatic failback behavior is primarily controlled through BGP routing policies.

Unfortunately, there isn't a built-in AWS mechanism to automatically control failback behavior exclusively from the AWS side without some form of BGP configuration. The Direct Connect service itself doesn't provide native failback controls that would automatically revert traffic to a preferred path when it becomes available again.

The AWS Direct Connect Resiliency Toolkit is designed to help you test failover scenarios and ensure you have appropriate redundancy, but it doesn't provide automatic failback functionality. The toolkit allows you to bring down BGP peering sessions to verify that traffic routes to redundant virtual interfaces, but this is for testing purposes rather than production traffic management.

For your specific scenario with connections in us-east-1 and us-east-2 through the same DXGW, the most effective approach would still involve BGP configuration. While you mentioned wanting to avoid on-premises BGP changes, this is the standard method for controlling traffic flow in multi-path scenarios.

If you absolutely need to manage this from the AWS side, you might consider:

1. Using AWS Network Manager to monitor your connections and implement automated scripts that could adjust routing when needed

2. Implementing AWS Lambda functions triggered by CloudWatch events to detect connection status changes and execute appropriate actions

3. Working with AWS Support to explore if there are any specific configurations possible with your particular setup

However, these approaches would be more complex and potentially less reliable than standard BGP-based solutions like local preference or AS path prepending on your on-premises equipment.

For the most resilient and predictable behavior in a multi-region Direct Connect setup, the recommended best practice remains implementing proper BGP routing policies that define clear primary and backup paths.  
**Sources**  
[AWS Direct Connect Failover Test - AWS Direct Connect](https://docs.aws.amazon.com/directconnect/latest/UserGuide/resiliency_failover.html)  
[Direct connect related | AWS re:Post](https://repost.aws/questions/QUhvlsTOn5QuSAkQdYRMOVTQ/direct-connect-related)

Direct Connect failover and failback from the AWS side (without on-prem BGP changes)

Add your answer

Relevant content