AWS Networking: Active/Passive Routing Between Direct Connect Connections for AWS Public Endpoints

AWS Networking: Active/Passive Routing Between Direct Connect Connections for AWS Public Endpoints

Introduction

AWS Direct Connect (DX) provides a dedicated network connection between an on-premises environment and AWS, improving performance and reliability compared to traditional internet-based connections. When managing multiple Direct Connect connections with public Virtual Interfaces (VIFs), implementing an active/passive routing strategy ensures high availability and optimized traffic flow.

This article explains how to configure active/passive routing between Direct Connect connections for accessing AWS public endpoints including AS Path Prepending and More Specific Prefix Advertisement.

Real-World Context: Why This Matters?

Organizations use AWS public endpoints for services such as:

  • Amazon S3 – Secure and efficient storage for backups or web content.
  • Amazon API Gateway – Enabling APIs to interact with cloud services.
  • AWS Lambda – Serverless computing that requires API calls over Direct Connect.
  • Amazon CloudFront – Content delivery network (CDN) acceleration.

For enterprises needing a reliable and predictable network path to these AWS services, an active/passive Direct Connect setup ensures traffic flows over the preferred connection while seamlessly failing over to the backup link if needed.

We can think of the use case / example in this context: A network engineer is responsible for two AWS Direct Connect connections between an on-premises data center and AWS. Each connection has a public VIF and is configured with a private Autonomous System Number (ASN). The goal is to ensure that outbound traffic primarily uses one connection, with the secondary connection serving as a backup in case of failure. To achieve this, the engineer uses two key techniques:

  1. AS Path Prepending: To control outbound traffic and influence AWS’s routing decisions.
  2. More Specific Prefix Advertisement: To ensure traffic prefers one Direct Connect connection over the other.

Step 1: Using AS Path Prepending to Control Outbound Traffic

Concept

AS Path Prepending makes a route appear less preferred by artificially increasing its AS path length. AWS prefers shorter AS paths, meaning outbound traffic will flow through the connection with the shortest path unless a failure occurs.

Implementation Steps

  • Configure AS path prepending on the secondary Direct Connect connection.
  • Increase the number of times the ASN is added to the path on the secondary connection.
  • This makes AWS prefer the primary connection with a shorter AS path.

Example Configuration (Cisco Syntax)

router bgp <private_ASN>
  neighbor <AWS_IP> remote-as 7224
  neighbor <AWS_IP> route-map PREPEND_OUTBOUND out

route-map PREPEND_OUTBOUND permit 10
  set as-path prepend <private_ASN> <private_ASN> <private_ASN>        

📌 Key Takeaway: AWS prefers the route with the shorter AS path, ensuring outbound traffic uses the primary Direct Connect connection.


Step 2: Advertising More Specific Prefixes to Control Inbound Traffic

Concept

AWS follows longest-prefix matching when choosing routes. By advertising more specific prefixes on the primary Direct Connect connection, AWS will direct inbound traffic through it.

Implementation Steps

  • Advertise a /24 prefix on the primary Direct Connect connection.
  • Advertise a less specific /23 or /22 prefix on the secondary Direct Connect connection.
  • AWS will route traffic to the most specific match, ensuring the primary connection is used first.
  • If the primary connection fails, AWS will automatically route traffic to the secondary connection.

Example Prefix Advertisements

  • Primary Direct Connect: Advertise 203.0.113.0/24
  • Secondary Direct Connect: Advertise 203.0.113.0/23

📌 Key Takeaway: The more specific prefix (longer subnet mask) on the primary Direct Connect ensures AWS directs traffic through it first.

Step 3: AWS Side Considerations

BGP Peering with AWS

  • AWS requires BGP peering over Direct Connect public VIFs. The network engineer must configure BGP peering with AWS’s Autonomous System Number (ASN 7224).
  • AWS dynamically advertises public service prefixes over the public VIF, and organizations must accept those routes.

Involving Transit Gateway

Direct Connect public VIFs provide direct access to AWS public services without requiring an AWS Transit Gateway. You use TGW only for private routing so connecting to VPC resources - not in this context (accssing public AWS endpoints).

How AWS Advertises Prefixes?

AWS advertises public service prefixes over Direct Connect public VIFs. Customers should filter and accept only necessary routes to avoid excessive route propagation.

Traffic Flow Summary

  • Under normal conditions: AWS sends traffic to the primary Direct Connect connection (shorter AS path and more specific prefix).
  • If the primary Direct Connect connection fails: AWS automatically reroutes traffic to the secondary connection (less specific prefix).

This configuration achieves an active/passive routing setup, ensuring reliability and seamless failover for AWS public endpoints.

AWS Documentation and Additional Resources

For further details, refer to AWS’s official documentation and blog posts:

🔹 AWS Direct Connect Active/Passive Configuration Guide 👉 AWS Documentation

🔹 Creating Active/Passive BGP Connections Over AWS Direct Connect 👉 AWS Blog

Conclusion

By leveraging AS path prepending and more specific prefix advertisements, network engineers can effectively control traffic routing between AWS Direct Connect connections. This approach ensures that one connection is actively used, while the other remains on standby, improving redundancy and optimizing AWS public endpoint access.


SACHIN GAWANDE

Sr. Technical Account Manager | Cloud Networking & Security Specialist | 10+ Years in Optimizing AWS & On-Premises Solutions | Driving Cost-Efficient, Scalable, & Secure Architectures

2mo

This is super helpful! Managing traffic between Direct Connect links can be tricky, and your breakdown makes it much clearer. I’ve set up Active/Passive routing before, and getting failover right was a big learning experience.

To view or add a comment, sign in

More articles by Mariusz (Mario) Dworniczak, PMP

Insights from the community

Others also viewed

Explore topics