Private DNS from CloudShell vs Lambda

My understanding is a bit different from the former answer of the re:Post Agent. While the Agent's advice on VPC DNS attributes is generally good practice, a 404 Not Found error suggests that the connectivity (Layer 4) and DNS resolution are actually functioning. If DNS were failing, the Lambda would return a NameNotResolved or UnknownHostException, not a 404.

The discrepancy between CloudShell and Lambda in this specific scenario usually stems from Layer 7 (HTTP) configuration.

Host Header Mismatch (Most Likely):

When Private DNS is disabled, you are likely calling the regional VPC Endpoint DNS name (e.g., vpce-123.region.vpce.amazonaws.com).

In CloudShell: If you are using curl, it might be inheriting environment configurations or you might be explicitly setting a Host header.

In Lambda: If your code (Node.js fetch, Python requests) calls the VPCE URL directly, it sends that technical URL as the Host header. The Endpoint Service in Region B likely expects the service's friendly name (e.g., myservice.example.com). Without the correct Host header, the target returns a 404.

SNI (Server Name Indication): For HTTPS connections, the TLS handshake requires the correct SNI. If the Lambda doesn't send the SNI expected by the Network Load Balancer (NLB) or Service in Region B, the connection might drop or route to a default "404" target.

Endpoint Policy: Ensure the VPC Endpoint in Region A has an IAM Policy that explicitly allows the Lambda's Execution Role. CloudShell often runs with broader User permissions which might bypass restrictions that hit the Lambda.

Pathing: Double-check if the Lambda code is unintentionally appending or stripping parts of the URI path when switching from the friendly DNS name to the VPCE technical DNS name.

PS: As to my understanding, the Agent focused on enableDnsHostnames and enableDnsSupport. While these are required for Private DNS, their absence would cause a connection timeout or resolution error, not a successful (but "Not Found") response from the target service. So, I think instead of troubleshooting VPC DNS settings, you should try explicitly setting the Host Header in your Lambda code to match the expected service name, or simply enable Private DNS on the Interface Endpoint in Region A. This allows the Lambda to use the standard service URL, ensuring the Host header matches what the destination expects.

No, success from CloudShell does not necessarily indicate that success should be expected from Lambda, even when they share the same VPC, subnets, and security group configuration.

The key difference lies in how DNS resolution works for Lambda functions versus CloudShell. When private DNS is not enabled on the VPC endpoint (as in your case), you need to use the VPC endpoint-specific DNS name rather than the service's default regional DNS name.

For Lambda to successfully resolve and connect to your Region B VPC endpoint service, you should ensure that:

1. Your Lambda function is configured to use the correct DNS name for the VPC endpoint. Without private DNS enabled, this would be the endpoint-specific DNS name (format: vpce-xxxxx.service-id.region.vpce.amazonaws.com) rather than the standard service endpoint name.

2. The VPC's DNS settings are properly configured. Lambda requires that both enableDnsHostnames and enableDnsSupport attributes are set to true in your VPC for proper DNS resolution.

3. Your Lambda function maintains proper network connectivity. Lambda functions may behave differently than CloudShell in terms of connection persistence and DNS caching.

The 404 error from Lambda while CloudShell succeeds suggests that either the DNS resolution is working differently between the two services, or there may be differences in how the requests are being routed. Consider enabling private DNS on your VPC endpoint or explicitly using the endpoint-specific DNS name in your Lambda function to ensure consistent resolution behavior.
Sources
Connecting inbound interface VPC endpoints for Lambda - AWS Lambda
Access AWS services through AWS PrivateLink - Amazon Virtual Private Cloud