An enterprise is designing a highly resilient hybrid network for its AWS environment in th… — AWS Certified Solutions Architect - Professional

An enterprise is designing a highly resilient hybrid network for its AWS environment in the `us-east-1` Region, which consists of $80$ spoke VPCs across multiple AWS accounts. The enterprise has a primary on-premises data center in Chicago and a secondary backup data center in Dallas.

The design must satisfy the following technical requirements:
* Scalability: The solution must support routing to all $80$ spoke VPCs without exceeding default AWS service quotas or resource association limits.
* Primary Path: All traffic between the Chicago data center and the AWS VPCs must use a dedicated $10$ Gbps AWS Direct Connect (DX) connection.
* Secondary Path: The Dallas data center must connect to AWS via an IPsec VPN over the public internet, which should act as the primary path for Dallas and a standby path for Chicago traffic if the Chicago DX link fails.
* Routing Failover: Failover from the Chicago DX connection to the Dallas VPN must be fully dynamic and automated using BGP.
* Administrative Overhead: The solution must avoid configuring individual VPN connections or virtual private gateways (VGWs) for each of the $80$ VPCs.
* Transit Prevention: The Chicago and Dallas data centers must not be able to route traffic to each other through the AWS network.

Which routing configuration and architecture pattern best meets these requirements?

A
Create a Direct Connect Gateway (DXGW) and a Virtual Private Gateway (VGW) in each of the $80$ spoke VPCs. Associate all $80$ VGWs directly with the DXGW. Establish a Private Virtual Interface (VIF) on the Chicago DX connection to the DXGW. Deploy an AWS Site-to-Site VPN from Dallas to a centralized Virtual Private Gateway, and configure VPC Peering in a full mesh among all $80$ spoke VPCs to allow transitive routing from the VPN to all spokes. Configure BGP on the customer gateways to advertise the respective CIDRs.
Deploy an AWS Transit Gateway (TGW) and attach all $80$ spoke VPCs to it. Create a Direct Connect Gateway (DXGW) and associate it with the TGW. Establish a Transit Virtual Interface (VIF) on the Chicago DX connection to the DXGW. Deploy an AWS Site-to-Site VPN from Dallas to the TGW. Configure BGP on the customer gateways, advertising the Chicago CIDR over both the DX connection and the Dallas VPN connection. Create two TGW route tables: a Spoke Route Table associated with the VPC attachments that propagates routes from the DXGW and VPN attachments, and a Hybrid Route Table associated with the DXGW and VPN attachments that propagates routes only from the VPC attachments.Answer
C
Deploy an AWS Transit Gateway (TGW) and attach all $80$ spoke VPCs to it. Create a Direct Connect Gateway (DXGW) and associate it with the TGW. Establish a Transit Virtual Interface (VIF) on the Chicago DX connection to the DXGW. Deploy an AWS Site-to-Site VPN from Dallas to the TGW. Create a single TGW route table associated with all VPC, DXGW, and VPN attachments, with route propagation enabled for all attachments. Configure BGP on the Dallas customer gateway to advertise both the Dallas CIDR and the Chicago CIDR, using BGP communities to filter routes and prevent traffic from routing between Chicago and Dallas.
D
Deploy an AWS Transit Gateway (TGW) and attach all $80$ spoke VPCs to it. Create a Direct Connect Gateway (DXGW) and associate it with the TGW. Establish a Transit Virtual Interface (VIF) on the Chicago DX connection to the DXGW. Deploy an AWS Site-to-Site VPN from Dallas to the TGW. Create two TGW route tables: one for the VPCs and one for the hybrid connections. To share a private DNS zone hosted in a central Shared Services VPC with all $80$ spoke VPCs, configure Route 53 Private Hosted Zones in the central VPC and rely on TGW routing to forward DNS queries from the spokes without associating the PHZ to the other VPCs. Deploy a single NAT Gateway in the central VPC to handle all outbound internet traffic for the $80$ spoke VPCs.

Answer

Deploying an AWS Transit Gateway with two distinct route tables to segment traffic, using a Direct Connect Gateway for the primary connection, a Site-to-Site VPN for backup, and configuring BGP to advertise the Chicago prefix over both paths.

The correct configuration uses an AWS Transit Gateway to aggregate the

80

spoke VPCs, avoiding direct association limits on the Direct Connect Gateway. It employs two TGW route tables to separate the routing domains: VPC attachments route to both hybrid paths, while hybrid attachments (DXGW and VPN) only propagate routes from VPCs, preventing Chicago and Dallas from communicating through AWS. For failover, because TGW naturally prefers DXGW over VPN for the same prefix length, advertising the Chicago CIDR on both paths ensures the VPN remains a standby path until a DX link failure occurs.

Step-by-Step Solution

Evaluate scale and resource limitations.

Recognize that with

80

spoke VPCs, associating Virtual Private Gateways directly to a Direct Connect Gateway is blocked by the default limit of

10

VGWs per DXGW. Therefore, AWS Transit Gateway (TGW) must be utilized as the central hub.

Ensures that the design respects AWS service limits and reduces administrative complexity.

Establish the hybrid connectivity paths.

Deploy an AWS Transit Gateway. Connect the

80

VPCs as attachments. Create a DXGW and associate it with the TGW. Terminate the Chicago connection on a Transit VIF to the DXGW, and deploy a Site-to-Site VPN from Dallas terminating on the TGW.

Configures the required hybrid physical and logical paths into the TGW.

Design routing isolation for transit prevention.

Create a 'Spoke Route Table' and a 'Hybrid Route Table'. Associate the Spoke Route Table with the VPC attachments and propagate routes from DXGW and VPN. Associate the Hybrid Route Table with the DXGW and VPN attachments and propagate routes only from the VPC attachments.

Since the Hybrid Route Table has no route propagation from the DXGW and VPN attachments, TGW will drop any traffic sent between Chicago and Dallas, preventing transit routing between them.

Configure dynamic failover routing.

Configure the customer gateway in Dallas to advertise Chicago's prefix (`

10.1.0.0/16

`) via BGP over the VPN. Configure Chicago to advertise it over the DX connection. When the DX connection is healthy, TGW automatically prefers the DXGW route over the VPN route for the same prefix. If the DX fails, the route is withdrawn, and traffic dynamically routes over the VPN to Dallas.

Leverages the default path preference of AWS Transit Gateway (DXGW preferred over VPN for identical prefixes) to implement dynamic active/passive failover.

Key Concept

Transit Gateway Route Tables (Route Domains) and Route Preference Evaluation

Estimated Time:3m 0s

Question

Answer

Step-by-Step Solution

Key Concept

Common Mistakes

Topics

More questions from this topic