AWS Certified Solutions Architect Professional SAP-C02 Practice Question

The optimal solution is to deploy an AWS Transit Gateway in each region and use inter-region peering to connect them. A central inspection VPC should be created in each region, containing a Gateway Load Balancer (GWLB) with a fleet of security appliances behind it. Transit Gateway route tables will be configured to direct all inter-VPC and egress traffic to the GWLB endpoint in the inspection VPC. This design creates a scalable, manageable hub-and-spoke network. The Transit Gateway acts as a cloud router, simplifying connectivity and eliminating the need for complex VPC peering meshes. Using a Gateway Load Balancer is the correct approach for deploying, scaling, and managing third-party virtual security appliances transparently within the network traffic path. This architecture centralizes traffic inspection without requiring security appliances to be deployed in each spoke VPC.

A full-mesh VPC peering configuration is incorrect because it is not scalable. Managing peering connections for hundreds of VPCs (which would require thousands of connections) is operationally complex and error-prone. Furthermore, VPC peering does not support transitive routing, so it cannot be used to route traffic from a spoke VPC through a central VPC to an on-premises network.

The legacy 'Transit VPC' model using EC2-based VPN appliances is also incorrect. While it provides transitive routing, it is a self-managed solution that has been largely superseded by the fully managed, more scalable, and highly available AWS Transit Gateway service.

Using AWS PrivateLink is not suitable for this scenario. PrivateLink is designed to provide secure, private connectivity from a VPC to specific services, not for routing all network traffic. It cannot be used to inspect general inter-VPC or egress traffic.