An application currently calls the Amazon Kinesis API using its standard public regional endpoint hostname. The team creates an interface VPC endpoint for Kinesis with private DNS enabled, expecting to avoid code changes while removing the need for internet or NAT gateway access. Does this work, and why?
- Yes, because enabling private DNS makes the standard public hostname resolve to the endpoint's private IP addresses inside the VPC
- No, the application must be rewritten to use the VPC-endpoint-specific DNS name
- Yes, but only if the VPC's internet gateway is also removed first
- No, interface endpoints only support services accessed by IP address, never by hostname
Correct answer: A. Yes, because enabling private DNS makes the standard public hostname resolve to the endpoint's private IP addresses inside the VPC
When private DNS is enabled on an interface endpoint, AWS overrides resolution of the service's standard public regional DNS name within the VPC, using a private hosted zone, so that it resolves to the endpoint's private IP addresses instead of the public service IPs. Existing application code that already calls the standard hostname keeps working unmodified, while traffic now flows privately through the endpoint's elastic network interfaces instead of over the internet or a NAT gateway. Option B describes the fallback needed only when private DNS is disabled or unsupported for a given service, which is unnecessary here since private DNS is enabled and Kinesis supports it. Option C is false because DNS resolution and endpoint routing are independent of whether an internet gateway exists elsewhere in the VPC; the gateway's presence does not interfere with a private DNS override. Option D is incorrect because interface endpoints are addressed by hostname exactly like any other AWS service endpoint, not only by raw IP address.
Source: AWS PrivateLink docs: Interface VPC endpoints — private DNS names