A city application in private subnets reads and writes one S3 bucket and must stop sending that traffic through the NAT gateway. The team also wants to avoid the hourly charge of an interface VPC endpoint. Which change keeps the S3 path on the AWS network?
Select an answer to reveal the explanation.
Short Explanation
You can keep S3 traffic on the AWS network without sending it through the NAT gateway by using a gateway endpoint and routing the S3 prefix list to it. VPC peering connects VPCs; it does not provide a way to peer directly with S3.
Full Explanation
A gateway VPC endpoint for S3 adds a prefix-list route to the subnet route table, keeping bucket traffic on the AWS network and off the NAT gateway. Gateway endpoints have no hourly charge, so this change also meets the cost constraint. Moving the NAT gateway into a private subnet does not work: the NAT gateway itself must be in a public subnet with a route to an internet gateway to reach the internet. VPC peering connects VPCs, and S3 is not a VPC that you can peer with. Assigning public IPs to the instances and routing their default traffic to an internet gateway sends them onto the public internet, abandoning the private design rather than providing the private S3 path. Exam caveat: the endpoint policy and bucket policy must still allow the instance role; otherwise, the route can be correct while the API returns access denied. Practical check: confirm the private route table sends the S3 prefix list to the gateway endpoint, then make a bucket API call and verify that the NAT gateway’s metrics no longer rise for that traffic.