An enterprise manages a multi-account AWS environment with spoke VPCs in a single AWS Region. The spokes are split equally: Production VPCs and Development VPCs. The enterprise is designing a centralized egress architecture using AWS Transit Gateway and a centralized Services VPC.
The architecture must satisfy the following requirements:
- All outbound internet traffic from all spoke VPCs must be inspected by a cluster of virtual security appliances in the Services VPC before exiting to the internet.
- High availability must be maintained across all traffic paths, with no single points of failure.
- Production VPCs must be able to communicate with each other.
- Development VPCs must be isolated from each other and must not be able to communicate with Production VPCs.
- Spoke VPCs must not contain local NAT Gateways to minimize operational costs.
Which Transit Gateway routing and network architecture meets these requirements with the least administrative overhead?
- ACreate a single Transit Gateway route table associated with all VPC attachments. Enable route propagation for all spoke and Services VPC attachments. In the Services VPC, deploy the security appliances and a NAT Gateway in a public subnet in each Availability Zone. Define policy rules within the virtual security appliances to drop traffic between Development VPC CIDR blocks and between Development and Production CIDR blocks, while allowing egress traffic to the internet.
- Create three Transit Gateway route tables: a Production Route Table, a Development Route Table, and a Services Route Table. Associate the Production VPCs with the Production Route Table, enable route propagation from the Production VPCs, and add a static default route () pointing to the Services VPC attachment. Associate the Development VPCs with the Development Route Table, disable route propagation, and add a static default route () pointing to the Services VPC attachment. Associate the Services VPC with the Services Route Table and enable route propagation from all spoke VPCs. In the Services VPC, deploy the security appliances and a NAT Gateway in a public subnet in each Availability Zone, and configure subnet route tables to route outbound traffic to the local NAT Gateway.Cevap
- CCreate two Transit Gateway route tables: a Spoke Route Table and a Services Route Table. Associate all Production and Development VPCs with the Spoke Route Table, enable route propagation for all spoke VPCs, and add a static default route () pointing to the Services VPC attachment. Use security groups in the spoke VPCs to restrict Development-to-Development and Development-to-Production traffic. In the Services VPC, deploy the security appliances across both Availability Zones and route all egress traffic through a single NAT Gateway deployed in a single public subnet to minimize NAT Gateway hourly charges.
- DCreate three Transit Gateway route tables: a Production Route Table, a Development Route Table, and a Services Route Table with the correct associations. For name resolution of internal resources, associate a Route 53 Private Hosted Zone (PHZ) created in the Services account only with the Services VPC, and configure the spoke VPCs to forward all DNS queries to the Transit Gateway. Deploy a single NAT Gateway in the Services VPC to route all outbound traffic to the internet.
Cevap
Create three Transit Gateway route tables: a Production Route Table, a Development Route Table, and a Services Route Table. Associate the Production VPCs with the Production Route Table, enable route propagation from the Production VPCs, and add a static default route pointing to the Services VPC. Associate the Development VPCs with the Development Route Table, disable route propagation, and add a static default route pointing to the Services VPC. Associate the Services VPC with the Services Route Table and enable route propagation from all spoke VPCs. In the Services VPC, deploy the security appliances and a NAT Gateway in a public subnet in each Availability Zone, routing outbound traffic to the local NAT Gateway.
The correct architecture uses three Transit Gateway route tables to segment routing domains at the network layer. Production VPCs propagate their CIDRs to the Production Route Table, allowing them to route to each other, while a default route directs internet traffic to the Services VPC. Development VPCs associate with a table that has no propagations, ensuring they cannot route to each other or to Production VPCs, while their default route also points to the Services VPC. In the Services VPC, deploying NAT Gateways and appliances across multiple Availability Zones ensures there is no single point of failure.
Adım Adım Çözüm
Anahtar Kavram
AWS Transit Gateway supports multiple route tables to enforce network isolation at scale. By controlling route associations and propagations, you can allow inter-VPC communication for some environments (Production) while completely isolating others (Development) without managing complex security groups or firewall rules for local routing. Furthermore, centralized egress filtering must employ multi-AZ NAT Gateways to maintain high availability.