A marketing firm uses a hybrid network with AWS Direct Connect and an SD-WAN overlay to link branch offices. Several VPCs connect to a third-party SD-WAN appliance transit VPC in the same AWS account using AWS Site-to-Site VPNs. The company plans to attach more VPCs to that SD-WAN appliance transit VPC but is running into scalability limits, route table constraints, and rising costs with the current design. A network engineer must propose a solution that resolves these problems and eliminates dependencies while requiring the LEAST operational overhead. Which approach satisfies these requirements?

The correct solution uses AWS Transit Gateway with a Transit Gateway Connect attachment. This approach centralizes connectivity, resolving scalability limits and route table constraints by allowing many VPCs to connect to a single Transit Gateway. Transit Gateway Connect attachments are specifically designed for native integration with SD-WAN virtual hubs, offering higher bandwidth and dynamic routing (BGP) compared to Site-to-Site VPNs, which reduces operational overhead and cost. Incorrect options: Configuring a Site-to-Site VPN between Transit Gateway and the SD-WAN appliance transit VPC would still incur the overhead and limitations of VPNs, rather than leveraging the advanced capabilities of Transit Gateway Connect for SD-WAN integration. Using VPC peering between all VPCs and the SD-WAN appliance transit VPC creates a mesh network that quickly hits scalability limits, becomes complex to manage, and does not address route table constraints. It also lacks the native SD-WAN integration benefits. The last option incorrectly combines VPC peering with Transit Gateway Connect. VPC peering does not integrate with Transit Gateway Connect, and this approach would still lead to the scalability and management issues of extensive peering.