A public-health department runs workloads in private subnets that must reach Amazon S3 and Amazon DynamoDB APIs without sending that traffic across the public internet or a NAT Gateway. Which design satisfies this requirement?
Select an answer to reveal the explanation.
Short Explanation
Private subnets still need groceries from S3 and DynamoDB—they just should not walk them through downtown (the internet). Gateway VPC endpoints put those AWS APIs on a private neighborhood path. NAT to the public endpoints works for many apps, but it is not what you want when the requirement is no public traversal for those APIs.
Full Explanation
Private-subnet workloads in a public-health department that must call Amazon S3 and Amazon DynamoDB without traversing the public internet or a NAT Gateway should use gateway VPC endpoints for those services. Gateway endpoints install prefix-list routes in the subnet route tables so API traffic to S3 and DynamoDB stays on the Amazon network path associated with the VPC. That design satisfies “no public internet / no NAT for these APIs” while keeping the workloads in private address space without assigning public IPs or attaching internet gateways to private subnets.
Attaching an internet gateway to every private subnet and using public IP addressing for S3 and DynamoDB contradicts the private-subnet model and forces public-path dependency the department rejected. Forcing all S3 and DynamoDB calls through a NAT Gateway to public service endpoints may work functionally, but NAT still sends that traffic toward public AWS endpoints via internet egress constructs—exactly what the requirement asked to avoid for these APIs. Disabling VPC networking and accessing S3 or DynamoDB only from developer laptops over home broadband is operationally irrelevant to production private-subnet workloads and fails every municipal control expectation.
Exam caveat: gateway endpoints exist for S3 and DynamoDB; most other AWS APIs use interface endpoints—do not invent a gateway endpoint for arbitrary services, and do not claim NAT equals “private access” when the stem forbids NAT. Operational check: confirm gateway endpoints exist in the VPC, verify private subnet route tables contain the S3 and DynamoDB prefix-list routes pointing to the endpoints, run an instance curl/SDK call without a NAT route present, and prove Flow Logs or packet paths do not show IGW/NAT for those destinations.