Soru

Zorluk: Çok zorHybrid and Multi-Account Network Connectivity Design

An enterprise is designing a highly available, multi-Region hybrid network architecture for its AWS Organizations environment. Spoke VPCs in the `euwest1eu-west-1` (Ireland) and `eucentral1eu-central-1` (Frankfurt) Regions are connected via local regional AWS Transit Gateways (TGWs) that are peered with one another. The on-premises network spans two main hubs: London (primary for `euwest1eu-west-1`) and Frankfurt (primary for `eucentral1eu-central-1`), utilizing the aggregated corporate network range of `10.0.0.0/810.0.0.0/8`. The London data center connects to the `euwest1eu-west-1` TGW using a `1010 Gbps AWS Direct Connect (DX) connection via a shared DX Gateway, and has a backup Site-to-Site VPN attachment directly on the `euwest1eu-west-1` TGW. The Frankfurt data center is configured similarly with a DX and VPN connection to the `eucentral1eu-central-1` TGW. The network design requires that outbound traffic from `euwest1eu-west-1` to `10.0.0.0/810.0.0.0/8` prefers the London DX as the primary path, fails over to the local London VPN as the secondary path, and only routes over the peered TGW connection to egress via the Frankfurt data center paths if both London connections are offline. Which routing configuration achieves this design while preventing sub-optimal routing under normal conditions?

  1. A
    Advertise the summary prefix `10.0.0.0/810.0.0.0/8` from the London data center over both the local Direct Connect (DX) and VPN connections. In the `euwest1eu-west-1` Transit Gateway (TGW) route table, enable propagation for the DX Gateway and VPN attachments. Add a static route for `10.0.0.0/810.0.0.0/8` pointing to the TGW peering attachment, configuring it with a higher administrative weight or metric to act as a fallback.
  2. B
    Advertise the summary prefix `10.0.0.0/810.0.0.0/8` from both the London and Frankfurt data centers. Configure dynamic BGP peering over the Transit Gateway (TGW) peering attachment. In the `euwest1eu-west-1` TGW route table, configure BGP local preference to prioritize the local Direct Connect Gateway and VPN routes over the routes learned via the peering attachment.
  3. Advertise the more specific prefixes `10.0.0.0/910.0.0.0/9` and `10.128.0.0/910.128.0.0/9` from the London data center over the local Direct Connect (DX) and VPN connections, using BGP AS-path prepending on the VPN. Enable route propagation from the Direct Connect Gateway (DXGW) and VPN attachments to the `euwest1eu-west-1` Transit Gateway (TGW) route table, and add a static route for `10.0.0.0/810.0.0.0/8` pointing to the TGW peering attachment.Cevap
  4. D
    Deploy a single NAT Gateway in a centralized egress VPC in each region to handle hybrid outbound routing. Associate a Route 53 Private Hosted Zone (PHZ) for the on-premises domain with all VPCs across both regions, and configure Route 53 Resolver endpoints to forward traffic over the peering link as a backup when the local Direct Connect fails.

Cevap

Advertise the more specific prefixes `10.0.0.0/910.0.0.0/9` and `10.128.0.0/910.128.0.0/9` from the local data center over Direct Connect and VPN, use AS-path prepending on the VPN, and configure a static route for `10.0.0.0/810.0.0.0/8` pointing to the Transit Gateway peering attachment.
The correct architecture leverages the longest prefix match rule of AWS Transit Gateway. By advertising more specific prefixes (`10.0.0.0/910.0.0.0/9` and `10.128.0.0/910.128.0.0/9`) from the local data center over both the local Direct Connect (DX) and Site-to-Site VPN, workloads in the local region will prefer the local paths over the peered static route of `10.0.0.0/810.0.0.0/8`. BGP AS-path prepending on the VPN ensures the DX path is preferred over the VPN under normal conditions. If both local paths fail, the specific prefixes are withdrawn, and traffic falls back to the static `10.0.0.0/810.0.0.0/8` route pointing to the Transit Gateway peering attachment, sending traffic to the peered region.

Adım Adım Çözüm

1
Analyze Transit Gateway route table precedence rules.
Static routes always take precedence over propagated routes for identical prefix lengths.
Determines that a static route for `10.0.0.0/810.0.0.0/8` pointing to the peering attachment would override propagated `10.0.0.0/810.0.0.0/8` routes from local DX and VPN, requiring a longest-prefix match strategy.
2
Design on-premises BGP advertisement strategy.
Advertise more specific prefixes (`10.0.0.0/910.0.0.0/9` and `10.128.0.0/910.128.0.0/9`) from the local data center.
Ensures the Transit Gateway prefers local paths due to longest prefix match, bypassing the `10.0.0.0/810.0.0.0/8` static peering route under normal operations.
3
Establish path preference between local Direct Connect and VPN.
Prepend BGP AS-path on the local VPN connection.
Forces the Transit Gateway to select the local Direct Connect connection as the primary path and the VPN as the local backup.
4
Configure the backup route to the peered region.
Add a static route for the summary prefix `10.0.0.0/810.0.0.0/8` pointing to the peering attachment.
Ensures that when both local specific routes fail and are withdrawn, traffic falls back to the peered region's TGW.

Anahtar Kavram

AWS Transit Gateway route evaluation order prioritizing static routes over propagated routes for identical prefixes, and utilizing the longest prefix match to implement fallback routing over peering attachments.
Bu soruyu puanla