AWS Direct Connect: Transit VIF MTU and Least Overhead Architecture?
A company has a highly available application that is hosted in multiple VPCs and in two on-premises data centers. All the VPCs reside in the same AWS Region. All the VPCs require access to each other and to the on-premises data centers for the transfer of files that are multiple gigabytes in size. A network engineer is designing an AWS Direct Connect solution to connect the on-premises data centers to each VPC. Which architecture will meet the company's requirements with the LEAST operational overhead?
Community Votes
100% of anonymous learners picked answer D. Votes are pick records left by other test-takers — they are not the verified answer.
Community Insight
The exam is testing both architectural pattern (Transit Gateway vs VIF-per-VPC) and the MTU limit for transit virtual interfaces: transit VIFs support 1500 or 8500, not 9001.
This ANS-C01 question tests the most operationally efficient Direct Connect design for connecting multiple VPCs to on-premises data centers. The community agrees D is correct because it uses a transit gateway with transit VIFs and the correct 8500-byte MTU.
Choosing C, which uses the correct Transit Gateway architecture but incorrectly sets the transit VIF MTU to 9001; transit VIFs only support up to 8500-byte jumbo frames, while 9001 is for private VIFs.
Community Discussion (5 comments)
Comments & Corrections
No comments yet — spotted an error or have a note? Share it below.
Expert Analysis
Why the Answer Is Correct
Option D uses a transit gateway in the same Region, attaches all VPCs, and associates a Direct Connect gateway with the transit gateway. This is the least operational overhead architecture because a single transit gateway provides centralised routing between VPCs and on-premises via Direct Connect, avoiding per-VPC private VIFs and VPC peering. A transit VIF is the correct VIF type for connecting Direct Connect to a transit gateway, and its MTU must be either 1500 or 8500. The community comments confirm "The MTU of a transit virtual interface can be either 1500 or 8500 (jumbo frames)" and that jumbo frames on transit gateways support only 8500 bytes.
Why the Other Options Are Wrong
Options A and B use a virtual private gateway plus a private VIF in each VPC and VPC peering; this creates more operational overhead because every VPC needs its own VIF and static routing is required for inter-VPC traffic. Option C uses the correct transit gateway+DGW architecture but incorrectly sets the transit VIF MTU to 9001. As the comments note, jumbo frames on transit gateways support only 8500 bytes, so 9001 is only valid for private VIFs, not transit VIFs. Option D fixes this with the correct MTU.
Community Comment Notes
Vote distribution is 100% D, and the comments consistently focus on the transit VIF MTU limit. One commenter linked AWS docs "set-jumbo-frames-vif" to show that transit VIF supports 8500. Another emphasised that "Jumbo frames will apply only to propagated routes via AWS Direct Connect and static routes via transit gateways." These comments reinforce that the primary trap is confusing private VIF MTU (9001) with transit VIF MTU (8500), rather than selecting the overall architecture.
Official Reference
Exam Strategy
Remember that transit VIFs support 1500 or 8500 MTU, while private VIFs support 1500 or 9001. When you see a Direct Connect design with a transit gateway, eliminate any option using 9001 on the transit VIF and choose the architecture with centralized routing and route propagation.
Related Analysis
Practice All ANS-C01 Questions
Access 137 questions with complete answers and detailed explanations.
View Full ANS-C01 Practice Test →