An enterprise is designing a highly resilient hybrid network across two AWS Regions: `us-e… — AWS Certified Solutions Architect - Professional

An enterprise is designing a highly resilient hybrid network across two AWS Regions: `us-east-1` (Primary, with $30$ spoke VPCs) and `us-west-2` (Disaster Recovery, with $15$ spoke VPCs). The spoke VPCs in each region are connected to regional Transit Gateways (`TGW-East` and `TGW-West`), which are peered. The on-premises network uses the CIDR block ` $172.16.0.0/12$ `. The enterprise has a 10 Gbps AWS Direct Connect (DX) connection terminating in `us-east-1` via a Direct Connect Gateway (`DXGW`) associated with both Transit Gateways. For redundancy, they deploy AWS Site-to-Site VPN connections from the on-premises datacenter to both `TGW-East` (`VPN-East`) and `TGW-West` (`VPN-West`). The spoke VPC CIDR ranges are ` $10.100.0.0/16$ ` for `us-east-1` and ` $10.200.0.0/16$ ` for `us-west-2`.

The architecture must satisfy the following constraints:
1. Under normal operations, all hybrid traffic must use the DX connection.
2. If the DX connection fails, traffic to and from `us-east-1` must fail over to `VPN-East`, and traffic to and from `us-west-2` must fail over to `VPN-West`.
3. Cross-region routing over the TGW peering link must not be used for hybrid traffic during a DX failure unless the local region's VPN is also down.
4. Asymmetric routing must be avoided to maintain stateful firewall inspection on-premises.

Which configuration strategy will meet these requirements?

Enable route propagation from the DXGW and the local VPN attachment in the TGW route tables associated with the spoke VPCs in each region. For inter-VPC traffic, add a static route for the remote region's VPC CIDR pointing to the TGW peering attachment. For last-resort hybrid failover, add a static route for a supernet of the on-premises network (such as ` $172.0.0.0/8$ `) pointing to the TGW peering attachment. On the customer gateway, configure BGP local preference to prefer the DX connection, and configure inbound route maps to decrease the local preference of the ` $10.200.0.0/16$ ` route received via `VPN-East` and the ` $10.100.0.0/16$ ` route received via `VPN-West`.Answer
B
Enable route propagation from the DXGW and the local VPN attachment in the TGW route tables associated with the spoke VPCs in each region. Add a static route for the on-premises prefix ` $172.16.0.0/12$ ` pointing to the TGW peering attachment in both regions to enable cross-region backup routing. On the customer gateway, configure BGP local preference to prefer the DX connection, and configure the customer gateway to advertise more specific prefixes over the DX connection than over the VPN connections.
C
Enable route propagation from the DXGW, the local VPN attachment, and the TGW peering attachment in the TGW route tables associated with the spoke VPCs in each region. On the customer gateway, configure BGP local preference to prefer the DX connection over the VPN connections. Configure the TGW route tables to use ECMP across the local VPN and the TGW peering attachment to balance the failover load.
D
Associate the spoke VPCs in both regions directly with a Virtual Private Gateway (VGW) in each account, and connect them to the DXGW. Configure the Site-to-Site VPN connections to terminate on the VGWs. Use BGP AS-path prepending on the customer gateway to prefer the DX connection. On the customer gateway, configure static routes for the VPC CIDRs pointing to the respective VPN tunnels.

Answer

Enable route propagation from the DXGW and local VPN attachments. Use a static supernet route pointing to the TGW peering attachment for last-resort failover, and adjust the customer gateway's local preference for inbound routes to prevent asymmetric routing.

The correct strategy relies on route propagation for the primary paths and a less-specific static supernet route for the cross-region backup path. Under Transit Gateway routing logic, a propagated route from a local VPN (e.g., `

172.16.0.0/12

`) will be preferred over a static route of a shorter prefix length (e.g., `

172.0.0.0/8

`) due to Longest Prefix Match. This allows the local VPN to be preferred for failover while still maintaining the peered TGW path as a last-resort route. Adjusting BGP local preference on the customer gateway ensures symmetric routing by directing traffic to the respective local VPN tunnels.

Step-by-Step Solution

Evaluate the path preference for AWS-to-on-premises traffic under normal operations.

By default, Transit Gateway path selection evaluates attachment types in the following order: VPC, DXGW, Connect, VPN, Peering. Since both DXGW and the local VPN propagate the `

172.16.0.0/12

` route, the DXGW attachment is preferred, sending all outbound traffic over Direct Connect.

This satisfies the requirement to use the DX connection under normal operations.

Address the behavior during a DX failure and the constraint to avoid cross-region TGW peering unless necessary.

When the DX link fails, the DXGW route is withdrawn. The TGW must choose between the local VPN (propagated) and the TGW peering link. In Transit Gateway route tables, static routes are always preferred over propagated routes of the same prefix length. Therefore, adding a static route for `

172.16.0.0/12

` pointing to the peering attachment would override the propagated local VPN route, forcing traffic across regions. To prevent this, a less-specific route like `

172.0.0.0/8

` (a supernet) is defined for the peering attachment. Due to Longest Prefix Match (LPM), the TGW will prefer the local VPN's `

172.16.0.0/12

` route over the peering attachment's `

172.0.0.0/8

` route.

This guarantees that the local VPN is used for failover and the peering link acts strictly as a last-resort backup.

Prevent asymmetric routing for traffic originating from the on-premises datacenter.

On the customer gateway, the local preference must be set higher for routes received via the DX connection to ensure normal inbound traffic uses DX. To prevent asymmetric routing during a DX failure, the customer gateway must route `

10.100.0.0/16

` via `VPN-East` and `

10.200.0.0/16

` via `VPN-West`. This is accomplished by applying inbound route maps on the customer gateway that decrease the local preference of cross-region routes received over the VPN tunnels.

This ensures symmetric paths for stateful firewall inspection at the customer gateway.

Key Concept

Transit Gateway Route Selection Order and Longest Prefix Match Interaction

Estimated Time:3m 0s

Question

Answer

Step-by-Step Solution

Key Concept

Common Mistakes

Topics

More questions from this topic