AWS Transit Gateway backup VPN path behavior?
Hi, Ihac who has multiple VPN attachments to TGW and both advertising same route. VPN A attachment is static route and VPN B attachment is dynamic propagated route. Assuming VPN A route is installed in the TGW route table due to order of preference. Now if the VPN A goes down, the static route will be showing blackhole, in this scenario will the TGW route table install the second VPN B propagated route instead and forward to VPN B or will continue to blackhole the traffic? Appreciate any inputs.
- Language
- English
- Newest
- Most votes
- Most comments
The re:Post Agent is correct. According to official AWS documentation, when a static route and a propagated route share the exact same destination, the static route completely suppresses the propagated route, meaning the backup route is not even installed in the TGW route table.
What will happen:
-
When VPN A goes down, its static route changes to a blackhole state.
-
Because the propagated route from VPN B was never installed in the table, no automatic failover occurs, and traffic will continue to be dropped.
-
You would need to manually (or via API) delete the static route to allow the TGW to install the propagated route from VPN B.
Recommendation:
To get the automatic failover behavior you want, switch both attachments to dynamic routing (BGP).
The answers above are correct. A static route in the TGW route table will blackhole when the VPN attachment goes down and will NOT automatically failover to a propagated route from another attachment. I verified this behaviour in a test environment.
Recommended approach: Use BGP on both VPN attachments. When a BGP VPN tunnel goes down, the BGP session terminates and routes are automatically withdrawn from the TGW route table. The backup VPN's propagated route takes over without any manual intervention. Failover typically completes in 10-30 seconds.
If BGP is not an option, you can automate the failover using Lambda. This blog post covers setting up automated VPN monitoring using Lambda. You can trigger a Lambda function to delete the blackholed static route from the TGW route table, allowing the propagated route from VPN B to take over. When VPN A recovers, the Lambda re-adds the static route. This approach gives you approximately 60 seconds failover time (DPD timeout + event propagation + Lambda execution).
Summary:
| Approach | Failover Time | Complexity |
|---|---|---|
| BGP on both VPNs | 10-30s | Low |
| Static + Lambda automation | ~60s | Medium |
| Manual intervention | Minutes to hours | None |
References:
- Setting up AWS Site-to-Site VPN automated monitoring solution - https://aws.amazon.com/blogs/networking-and-content-delivery/setting-up-of-aws-site-to-site-vpn-automated-monitoring-solution/
- Transit Gateway route evaluation order - https://docs.aws.amazon.com/vpc/latest/tgw/how-transit-gateways-work.html#tgw-route-evaluation-overview
- Site-to-Site VPN routing options - https://docs.aws.amazon.com/vpn/latest/s2svpn/VPNRoutingTypes.html
When a VPN attachment goes down and its static route shows as blackhole in the Transit Gateway route table, the Transit Gateway will NOT automatically fail over to an alternative propagated route from another VPN attachment. The static route will remain in the route table with a blackhole state, and traffic matching that route will continue to be dropped.
This is because static routes in Transit Gateway route tables take precedence over propagated routes, and a blackholed static route does not get automatically removed or deprioritized. The static route continues to exist in the route table even when the attachment is unavailable.
To achieve automatic failover behavior between multiple VPN attachments advertising the same route, you should use dynamic routing with BGP on both VPN attachments rather than mixing static and dynamic routes. With dynamic routing, when a VPN connection goes down, the BGP session terminates and the routes are automatically withdrawn from the Transit Gateway route table. This allows the Transit Gateway to use the remaining available propagated routes from the other VPN attachment.
If you need to use static routes, you would need to manually delete the blackholed static route to allow traffic to fail over to the propagated route from the other VPN attachment. Alternatively, you could implement monitoring and automation to detect the blackhole state and programmatically remove the static route when needed.
Sources
AWS Transit Gateway + AWS Site-to-Site VPN - Amazon Virtual Private Cloud Connectivity Options
Transit gateway route tables in AWS Transit Gateway - Amazon VPC
Relevant content
- asked 3 years ago
- asked 6 months ago
Will wait for expert confirmation, finding mixed answers online.
Route evaluation order
Transit gateway routes are evaluated in the following order:
https://docs.aws.amazon.com/vpc/latest/tgw/how-transit-gateways-work.html#tgw-route-evaluation-overview