A financial services company is designing a multi-account hub-and-spoke network architectu… — AWS Certified Solutions Architect - Professional

A financial services company is designing a multi-account hub-and-spoke network architecture in a single AWS Region using an AWS Transit Gateway (TGW). The architecture consists of $50$ spoke VPCs (IP ranges within $10.0.0.0/16$ to $10.49.0.0/16$ ) and a Centralized Inspection VPC. The Centralized Inspection VPC hosts a fleet of third-party firewalls behind a Gateway Load Balancer (GWLB) and NAT Gateways. The company's on-premises datacenters use a primary AWS Direct Connect (DX) connection with a Transit VIF terminated on a Direct Connect Gateway (DXGW), and a backup IPsec Site-to-Site VPN connection terminated directly on the TGW. The design must meet the following requirements: all traffic between spoke VPCs, traffic between spokes and the on-premises network, and internet-bound egress traffic from the spokes must be inspected by the firewalls in the Centralized Inspection VPC; if the primary DX connection fails, traffic must fail over automatically to the Site-to-Site VPN, preferring the DX connection when it is healthy; and administrative overhead must be minimized while preventing routing loops. Which configuration will meet these requirements?

A
Configure a single TGW route table named `Transit-RT` associated with all spoke VPC, Centralized Inspection VPC, DXGW, and VPN attachments. Enable route propagation for all attachments in `Transit-RT`. In the spoke VPC route tables, point ` $0.0.0.0/0$ ` and the on-premises ranges to the TGW. In `Transit-RT`, add a static route for ` $0.0.0.0/0$ ` pointing to the Centralized Inspection VPC attachment to direct all traffic to the firewall fleet.
B
Configure three TGW route tables: `Spoke-RT`, `OnPrem-RT`, and `Inspection-RT` with the required associations and static routes. To enable domain name resolution across the environment, create a Route 53 Private Hosted Zone (PHZ) in a shared services account and associate it only with the Centralized Inspection VPC. Configure on-premises and spoke VPC DNS clients to resolve internal domains transitively through the Centralized Inspection VPC's Route 53 Resolver.
Configure three TGW route tables: `Spoke-RT`, `OnPrem-RT`, and `Inspection-RT`. Associate `Spoke-RT` with all spoke VPC attachments and add a static route for ` $0.0.0.0/0$ ` pointing to the Centralized Inspection VPC attachment. Associate `OnPrem-RT` with the DXGW and VPN attachments and add a static route for ` $10.0.0.0/8$ ` pointing to the Centralized Inspection VPC attachment. Associate `Inspection-RT` with the Centralized Inspection VPC attachment and enable route propagation from the spoke VPC, DXGW, and VPN attachments. Configure BGP on the customer gateways to advertise on-premises prefixes with a shorter AS path over the DX connection than over the VPN.Answer
D
Configure two TGW route tables: `Spoke-RT` and `Inspection-RT`. Associate `Spoke-RT` with all spoke VPC, DXGW, and VPN attachments, and add a static route for ` $0.0.0.0/0$ ` pointing to the Centralized Inspection VPC. Associate `Inspection-RT` with the Centralized Inspection VPC. Deploy a single NAT Gateway in a single Availability Zone in the Centralized Inspection VPC to handle all egress traffic. Configure the TGW attachment subnets in the Centralized Inspection VPC to route all incoming traffic directly to this NAT Gateway, bypassing the GWLB.

Answer

Configure three separate Transit Gateway route tables to isolate the routing domains, using static routes in the spoke and on-premises route tables to forward traffic to the Centralized Inspection VPC, and route propagation in the inspection route table to return traffic to its destination. Use BGP AS path prepending on the customer gateway to prefer the Direct Connect connection over the VPN.

The correct configuration implements three separate Transit Gateway route tables. The spoke route table directs all non-local traffic to the inspection VPC. The on-premises route table directs all incoming hybrid traffic to the inspection VPC. The inspection route table uses propagated routes to safely deliver inspected traffic to its final destination without loops. BGP routing configuration on the customer gateways ensures that the Direct Connect path is preferred while allowing automatic failover to the VPN.

Step-by-Step Solution

Isolate routing domains by creating three Transit Gateway route tables: `Spoke-RT`, `OnPrem-RT`, and `Inspection-RT`.

Prevents routing loops and allows fine-grained control over pre-inspection and post-inspection traffic flows.

A single route table cannot handle both forwarding traffic to the inspection VPC and routing it to the final destination without causing loops or bypassing the firewall.

Associate `Spoke-RT` with the spoke VPC attachments and add a static route for `

0.0.0.0/0

` pointing to the Centralized Inspection VPC attachment.

Forces all outbound, inter-spoke, and spoke-to-on-premises traffic from the spokes to be sent to the Centralized Inspection VPC.

Ensures that all traffic originating from application workloads undergoes firewall inspection before going to the internet, other spokes, or on-premises.

Associate `OnPrem-RT` with the DXGW and VPN attachments and add a static route for `

10.0.0.0/8

` pointing to the Centralized Inspection VPC attachment.

Ensures that any incoming traffic from on-premises to the AWS spoke networks is redirected to the Centralized Inspection VPC.

Meets the security requirement to inspect all traffic between the on-premises network and the AWS spokes.

Associate `Inspection-RT` with the Centralized Inspection VPC attachment, and enable route propagation from the spokes, DXGW, and VPN attachments.

Populates the route table with the exact prefixes for the spokes and on-premises networks.

Allows the Transit Gateway to correctly route traffic to its final destination after it has been inspected and returned by the firewall fleet.

Configure the customer gateways to advertise on-premises networks via BGP over both paths, prepending the AS path on the VPN connection.

AWS TGW prefers the shorter AS path on the DX connection, only failing over to the VPN if the DX connection becomes unavailable.

Provides automatic failover while maintaining a deterministic preference for the higher-bandwidth Direct Connect link.

Key Concept

Multi-table Transit Gateway routing for centralized security inspection and hybrid failover

Estimated Time:3m 0s

Question

Answer

Step-by-Step Solution

Key Concept

Common Mistakes

Topics

More questions from this topic