Soru

Zorluk: ZorHybrid and Multi-Account Network Connectivity Design

A multinational retail corporation operates a multi-account AWS environment with 1515 spoke VPCs and a central Shared Services VPC in the `us-east-1` Region, all connected via an AWS Transit Gateway. The corporation recently acquired a logistics firm that has 1010 VPCs in the same Region and an on-premises warehouse network connected to AWS via a 10 Gbps10\text{ Gbps} AWS Direct Connect connection.

The solutions architect must design a hybrid network topology that satisfies the following requirements:
1. The logistics firm's VPCs must be able to access a shared inventory API hosted in the corporation's Shared Services VPC.
2. The logistics firm's VPCs must not have any network connectivity to the retail corporation's spoke VPCs.
3. Both the retail corporation's spoke VPCs and the logistics firm's VPCs must be able to communicate with the logistics firm's on-premises warehouse network.
4. Administrative overhead must be minimized, and no additional Direct Connect connections should be provisioned.

Which of the following network architectures meets these requirements?

  1. Share the retail corporation's Transit Gateway with the logistics firm's AWS account using AWS Resource Access Manager (RAM). Attach the logistics firm's VPCs to the shared Transit Gateway. Associate the Direct Connect Gateway with the Transit Gateway. Create three separate Transit Gateway route tables: one for the corporate spokes, one for the logistics spokes, and one for the Shared Services and Direct Connect Gateway attachments. Associate the corporate spoke attachments with the corporate route table and propagate the Shared Services VPC and Direct Connect Gateway. Associate the logistics spoke attachments with the logistics route table and propagate the Shared Services VPC and Direct Connect Gateway. Associate the Shared Services VPC and Direct Connect Gateway attachments with their dedicated route table and propagate the corporate and logistics spokes.Cevap
  2. B
    Establish VPC peering connections between all 1010 logistics VPCs and the corporate Shared Services VPC. Associate the Direct Connect Gateway directly with the Shared Services VPC using a Virtual Private Gateway (VGW), and configure a centralized software-defined WAN (SD-WAN) appliance cluster in the Shared Services VPC to route traffic between the logistics VPCs and the on-premises warehouse network.
  3. C
    Share the retail corporation's Transit Gateway with the logistics firm's AWS account using AWS Resource Access Manager (RAM). Attach all logistics VPCs to the shared Transit Gateway. Enable default route propagation and default route association on all attachments to use a single Transit Gateway route table. Use security groups and Network Access Control Lists (NACLs) in each VPC to block traffic between the corporate spokes and the logistics spokes, and associate the Direct Connect Gateway with a Virtual Private Gateway (VGW) in each of the 2525 spoke VPCs.
  4. D
    Deploy a new Transit Gateway in the logistics firm's AWS account and connect the logistics VPCs to it. Establish a Transit Gateway peering connection between the retail corporation's Transit Gateway and the logistics firm's Transit Gateway. Associate the Direct Connect Gateway with the retail corporation's Transit Gateway. In the logistics Transit Gateway route table, add a static route pointing to the Transit Gateway peering connection for all traffic destined for the corporate Shared Services VPC and the on-premises warehouse network.

Cevap

The network architecture using a shared Transit Gateway with three separate route tables (Corporate, Logistics, and Shared/DX) to isolate environments while allowing shared access to Shared Services and the on-premises network.
The correct design uses a single shared Transit Gateway (via AWS RAM) to consolidate connections, minimizing administrative overhead and DX connection costs. By creating three separate Transit Gateway route tables (Corporate, Logistics, and Shared/DX), we can precisely control routing. Corporate spokes are associated with the Corporate route table, and logistics spokes are associated with the Logistics route table. Both route tables have propagations from the Shared Services VPC and the Direct Connect Gateway, enabling outbound connectivity to those destinations. To allow return traffic, the Shared Services VPC and Direct Connect Gateway attachments are associated with the Shared/DX route table, which has route propagations from both corporate and logistics spokes. Since the Corporate route table does not propagate logistics spoke routes, and the Logistics route table does not propagate corporate spoke routes, the two spoke environments remain completely isolated.

Adım Adım Çözüm

1
Analyze the security isolation requirement between corporate spoke VPCs and logistics spoke VPCs.
Identify that separate Transit Gateway route tables are needed to prevent route propagation and direct VPC-to-VPC communication between the two sets of spokes.
A single default route table with full propagation would allow unwanted transitive routing between all attached VPCs.
2
Determine how to allow both environments to access the centralized Shared Services VPC and the on-premises warehouse network.
Propagate the Shared Services VPC attachment and the Direct Connect Gateway (DXGW) attachment into both the Corporate Route Table and the Logistics Route Table.
This populates both route tables with the destination CIDRs for Shared Services and on-premises, enabling outbound routing to these destinations.
3
Configure the routing for return traffic back from the Shared Services VPC and the on-premises network.
Associate both the Shared Services VPC and the DXGW attachments with a third route table (Shared/DX Route Table), and propagate the Corporate Spokes and Logistics Spokes into it.
This ensures the Transit Gateway knows how to route returning traffic back to the respective spokes without needing to route corporate traffic directly to logistics spokes.
4
Evaluate the option of using Transit Gateway peering for on-premises connectivity.
Recognize that Transit Gateway peering does not support transitive routing to a Direct Connect Gateway.
An architecture relying on TGW peering to access DXGW on a peered TGW is invalid, making separate TGWs with peering an incorrect design.

Anahtar Kavram

Transit Gateway route table isolation and propagation in a hybrid, multi-account setup
Bu soruyu puanla