AWS Subnets with Amazon ASN not accepted in Private Peering...

The issue you're experiencing is likely related to AWS's BGP loop prevention mechanisms, even though you're using private peering. AWS implements strict controls to prevent routing loops and protect the integrity of its network, which can sometimes affect the propagation of routes that include AWS public ASNs.

In your case, the route for 52.129.106.0/24 is being advertised with ASNs 7224 and 16509, which are indeed Amazon's public ASNs. Even in a private peering scenario, AWS may be filtering these routes to prevent potential conflicts or loops within its global network.

To resolve this issue, you might need to consider the following approaches:

1. Work with your partner to see if they can remove the Amazon ASNs (7224 and 16509) from the BGP path before advertising the routes to your AWS Direct Connect private peering. This may involve configuring BGP route manipulation on their end.

2. Contact AWS support to discuss your specific use case. They may be able to provide guidance on how to properly advertise these routes or potentially make exceptions to allow the advertisement of these specific prefixes.

3. If possible, consider using AWS Transit Gateway to connect your VPCs across different regions. This might provide a more seamless way to route traffic between your APAC region and the Genesys public subnets in AWS Europe.

4. Explore the possibility of using AWS Global Accelerator or other AWS networking services that can help you reach resources across different AWS regions without running into BGP loop prevention issues.

Remember that AWS networking configurations can be complex, especially when dealing with cross-region routing and third-party services. It's often beneficial to engage with AWS support or a certified AWS networking specialist to design the most appropriate solution for your specific needs.
Sources
AWS Direct Connect | FAQ | Amazon Web Services (AWS)
Troubleshooting AWS Direct Connect - AWS Direct Connect

Hello,

You are not receiving the Genesys Public subnets (AWS-Europe) routes on your VPG BGP routing table in the APAC region, despite your partner advertising them through the AWS Direct Connect Private peering. This is because AWS Direct Connect Private peering is designed to route traffic within the same region only, and it does not allow routing of public internet traffic or cross-region traffic by default.

Try to do:

To receive the Genesys Public subnets (AWS-Europe) routes in your APAC region, you need to establish a separate connectivity solution for cross-region traffic. The recommended options are:

• Set up a new AWS Direct Connect Private peering connection in the Europe region.
• Use AWS Site-to-Site VPN or AWS Transit Gateway between your on-premises network and the AWS Europe region.

Alternatively, you can consult with AWS Support to explore potential workarounds or configurations, but routing public internet traffic or cross-region traffic through AWS Direct Connect Private peering is generally not recommended due to security and performance concerns.

1. how can we enable just a default route on VPG to send all traffic directly to Direct Connect connection?

1. Create a Virtual Private Gateway Endpoint for your Direct Connect connection:

• Go to the Virtual Private Gateway Endpoints console in your AWS region.
• Click "Create Virtual Private Gateway Endpoint".
• Select your existing Virtual Private Gateway (VPG) and your Direct Connect Gateway.
• Click "Create Virtual Private Gateway Endpoint" to create the endpoint.

2. Propagate the Direct Connect routes to your VPG route table:

• After creating the Virtual Private Gateway Endpoint, the routes from your Direct Connect connection should automatically propagate to your VPG route table.

3.Create a static default route in your VPG route table:

• Go to the Virtual Private Gateways console and select your VPG.
• In the "Route Tables" section, select the route table associated with your VPG.
• Click "Create Static Route".
• Enter the destination CIDR block as "0.0.0.0/0" (default route) and select the Virtual Private Gateway Endpoint you created in step 1 as the target.
• Click "Create Static Route" to add the default route.

4. Associate your VPCs with the VPG:

• Go to the VPC console in your AWS region.
• Select each VPC you want to associate with the VPG.
• Click "Actions" > "Attach to Virtual Private Gateway" and select your VPG.
• Click "Attach" to associate the VPC with the VPG.

After completing these steps, your VPCs will receive the default route (0.0.0.0/0) from your VPG route table, which points to your Direct Connect connection through the Virtual Private Gateway Endpoint. This means all traffic from your VPCs will be sent directly to the Direct Connect connection, bypassing any existing Site-to-Site VPN connections or internet gateways.

Note that this setup will override any existing Site-to-Site VPN connections or internet gateways for traffic destined to the Direct Connect connection, as the default route will take precedence. If you need to maintain these connections for specific traffic, you may need to adjust the route propagation or use more specific routes.

AWS Direct Connect has concepts of VIFs, I would like to gain some more insights on how you are advertising the routes from on-prem via your partner to AWS Direct Connect.

If you are using Public VIF, Private VIF or a Transit VIF. Can you expand a bit more on your connectivity design.