Question

Difficulty: HardAWS VPN, Direct Connect, and Transit Gateway Management

A SysOps Administrator is troubleshooting a routing issue in a hybrid network environment. Traffic from resources in a private VPC subnet destined for an on-premises data center network (172.16.0.0/16172.16.0.0/16) is routing through a backup Site-to-Site VPN connection instead of a primary 10 Gbps10\text{ Gbps} AWS Direct Connect connection. Both the Direct Connect connection (via a Transit Gateway attachment) and the VPN connection terminate on a single AWS Transit Gateway.

The administrator verifies the following configuration details:
- Both connections are actively establishing BGP sessions and advertising the identical 172.16.0.0/16172.16.0.0/16 prefix.
- The Transit Gateway route table associated with the VPC attachment shows active route propagation from both the Direct Connect gateway attachment and the VPN attachment.
- The Transit Gateway route table contains a static route for 172.16.0.0/16172.16.0.0/16 with the VPN attachment as the target.

Which action should the administrator take to ensure that traffic is routed over the Direct Connect connection as the primary path?

  1. Delete the static route for 172.16.0.0/16172.16.0.0/16 pointing to the VPN attachment from the Transit Gateway route table.Answer
  2. B
    Modify the Route 53 private hosted zone routing policy for the on-premises domain to use failover routing with the Direct Connect path as primary.
  3. C
    Add a static route for 172.16.0.0/16172.16.0.0/16 in the VPC subnet route tables pointing to the Internet Gateway (IGW) to bypass the Transit Gateway.
  4. D
    Create a VPC Gateway Endpoint for the on-premises network and associate it with the private subnet route tables.

Answer

Delete the static route for 172.16.0.0/16172.16.0.0/16 pointing to the VPN attachment from the Transit Gateway route table.
Deleting the static route targeting the VPN attachment is the correct action. AWS Transit Gateway routes traffic by prioritizing longest prefix match first, followed by static routes, and then dynamically propagated routes. Since both the Direct Connect and VPN connections advertise the identical 172.16.0.0/16172.16.0.0/16 range, the static route pointing to the VPN attachment wins and forces all traffic through the VPN. Removing the static route allows Transit Gateway to evaluate the dynamically propagated routes. For propagated routes, the Transit Gateway automatically prioritizes Direct Connect gateway attachments over Site-to-Site VPN attachments.

Step-by-Step Solution

1
Analyze Transit Gateway route evaluation order.
Identify that AWS Transit Gateway evaluates routing in the following order: (1) Longest Prefix Match (LPM), (2) Static routes, (3) Propagated routes.
Understanding the hierarchy of route evaluation is necessary to find why the VPN path is preferred.
2
Determine why the VPN is currently preferred.
Since both connections advertise the identical prefix 172.16.0.0/16172.16.0.0/16, LPM is a tie. The next criteria is static vs. propagated. The existing static route targeting the VPN attachment overrides all dynamically propagated routes, including the one from Direct Connect.
This explains the root cause of the incorrect routing path.
3
Select the remediation action.
Delete the static route targeting the VPN attachment. This falls back to propagated route evaluation, where the Transit Gateway will compare the propagated routes and select the Direct Connect gateway attachment because it has a higher default preference than the VPN attachment.
This restores correct traffic prioritization over the primary Direct Connect connection.

Key Concept

AWS Transit Gateway Route Evaluation and Precedence
Rate this question