A transit-authority analytics VPC routes all private-subnet egress through a single undersized NAT instance that saturates during evening GTFS feed pulls, throttling job completion. Which network-path remediation best improves throughput?
Select an answer to reveal the explanation.
Short Explanation
One skinny doorway for every evening feed download is a classic traffic jam. Upsize and spread the NAT egress path so the buses of data are not stuck behind one turnstile.
Full Explanation
A transit-authority analytics VPC that routes all private-subnet egress through a single undersized NAT instance saturates during evening GTFS feed pulls and throttles job completion. Replacing that path with appropriately sized NAT Gateway capacity—or a scaled NAT design—and multi-AZ egress removes the single bottleneck host so concurrent feed downloads proceed. That network-path remediation improves throughput because egress capacity and AZ independence become first-class for analytics pull jobs. Moving all analytics workers into the public subnet with open 0.0.0.0/0 security groups fails security posture to chase bandwidth. Disabling VPC Flow Logs to increase NAT instance bandwidth fails conceptually—Flow Logs are not the saturation root cause and losing them harms forensics. Forcing GTFS pulls through a single-threaded on-premises HTTP proxy that already times out fails by adding another known bottleneck. Exam caveat: NAT Gateway helps internet egress; also consider VPC endpoints for AWS API traffic so feed jobs do not compete with S3/API hairpins on the NAT meter. Operational check: deploy NAT Gateway per AZ for the analytics VPC, move routes off the NAT instance, run concurrent GTFS pulls, compare completion time and NAT bytes metrics, and decommission the undersized instance.