A network engineer is designing a hybrid network using AWS Transit Gateway with multiple VPCs and an on-premises data center connected via AWS Direct Connect. The VPCs need to communicate with each other and with on-premises, but must isolate development VPCs from production VPCs. What is the MOST scalable and cost-effective approach?
Separate route tables enforce isolation; shared table allows on-premises access.
Why this answer
A single Transit Gateway with separate route tables allows you to isolate development and production VPCs from each other while sharing a common route table for the Direct Connect attachment to reach on-premises. This design is highly scalable (no mesh of peering connections) and cost-effective (no per-VPN-tunnel charges), leveraging Transit Gateway’s native segmentation and centralized routing.
Exam trap
The trap here is that candidates assume a single Transit Gateway cannot isolate traffic, but AWS Transit Gateway supports multiple route tables per gateway, enabling logical segmentation without separate transit gateways or complex ACLs.
How to eliminate wrong answers
Option A is wrong because using a single route table for all attachments would allow traffic to flow between development and production VPCs, and network ACLs are stateless, cumbersome to manage at scale, and cannot provide the same isolation as separate route tables. Option B is wrong because VPC peering creates a full mesh that does not scale (O(n²) connections) and does not natively support transitive routing, requiring a Direct Connect gateway for on-premises but still lacking isolation between VPCs without complex route table manipulation. Option C is wrong because establishing a VPN from each VPC to on-premises over Direct Connect adds unnecessary cost and complexity (per-VPN tunnel charges, BGP configuration), and does not provide a mechanism for VPC-to-VPC communication without additional transit or peering.