Direct Connect Failover That Never Triggers

The most likely cause is that the Direct Connect path was still considered valid at the AWS routing layer, or that the VPN was not actually a viable alternate for the affected prefixes.

Checks

1. Did the BGP session actually go down? Confirm on the on-premises router and in the Direct Connect virtual interface BGP status. A 12-minute drop should show in logs; if the session stayed up, AWS keeps preferring Direct Connect and traffic blackholes at the physical layer.
2. Are the VPN-advertised prefixes the same? If the VPN advertises 10.0.0.0/8 but the Direct Connect gateway propagates more-specific prefixes (for example 10.1.0.0/16), AWS prefers the more-specific route regardless of MED. The VPN must advertise prefixes at least as specific as those used over Direct Connect.
3. MED and AS-path comparison. MED is compared only among paths from the same neighboring AS. If the VPN and Direct Connect paths come from different ASNs, MED is not the deciding attribute; AS-path length and other attributes are. Verify with the Transit Gateway route table's path attributes.
4. Transit Gateway propagation. Ensure the VPN attachment's routes are actually propagated into the same Transit Gateway route table as the Direct Connect attachment. A static route or a separate route table association can prevent failover.
5. Return path. Confirm the on-premises router prefers the VPN for return traffic; otherwise AWS sends via VPN and on-premises replies via Direct Connect, which is down.

Changes

• Make the VPN advertise the same or more-specific prefixes as Direct Connect, and set BGP attributes so the VPN is a clear but lower-priority backup (for example, longer AS-path prepend on the VPN).
• Shorten BGP keepalive/hold timers on the Direct Connect session to detect failure faster, and confirm the on-premises device tears down the session promptly.
• Add a health-check-driven route or use Transit Gateway route table failover with a blackhole route to force the VPN path when Direct Connect is unhealthy.
• Test failover in a controlled window and verify with flow logs and traceroute that traffic moves to the VPN within the intended recovery time.

Define the objective in terms of detection plus convergence, then instrument each stage.

Proposed objectives

• Detection: Direct Connect BGP session failure detected within 60 seconds (requires non-default BGP timers, for example keepalive 10 / hold 30, coordinated with the on-premises router).
• Convergence: Traffic shifted to the VPN within 3 minutes of the physical failure, verified by successful application transactions.
• Data-plane verification: Synthetic probes to on-premises endpoints succeed within the convergence window.
• Capacity: The VPN must carry the failover load; document the expected throughput and accept reduced performance during failover.

Monitoring and evidence

• CloudWatch metrics for Direct Connect virtual interface BGP state, bit rate, and packet drop count; alarms on BGP down and on zero throughput.
• VPN tunnel metrics (tunnel state, bytes in/out) with alarms when a tunnel is down or when traffic does not appear on the VPN during a Direct Connect outage.
• Transit Gateway route table monitoring and flow logs to show path selection before and after failover.
• Synthetic canary transactions from an AWS workload to an on-premises service, with success rate and latency dashboards.
• A documented failover runbook with a scheduled quarterly test; record actual detection and convergence times as compliance evidence.

Governance

Tie the objectives to a service-level objective, assign an owner, and require review after any BGP, route table, or Direct Connect change. If measured convergence exceeds the objective, revisit timers and route specificity rather than assuming the VPN is broken.