VPC内Lambda函数无法访问公网，请求排查原因

Let’s walk through the key checks you need to run to fix this timeout issue—since you’ve already ruled out basics like security group outbound rules and Flow Log rejects, we can focus on the less obvious culprits:

1. Confirm Your NAT Gateway is Deployed in a Public Subnet #

First off, NAT gateways need to live in a public subnet to function properly. That means the subnet your NAT gateway is in must have a route table with a default route (0.0.0.0/0) pointing to an internet gateway (IGW), not another NAT gateway.

Here’s how to verify:

• Head to the VPC Console → NAT Gateways, find your gateway, and note its associated subnet.
• Click into that subnet’s route table, and check for a route like 0.0.0.0/0 → igw-xxxxxxxx. If this is missing, your NAT gateway can’t reach the internet itself, so your Lambda can’t either.

2. Double-Check Lambda Subnet Route Table for NAT Gateway Entry #

You mentioned all four Lambda subnets are tied to the same route table (rtb-xxxxxxxx). This route table must have a default route pointing to your NAT gateway (0.0.0.0/0 → nat-xxxxxxxx).

If this route is missing, your Lambda’s outbound traffic has nowhere to go—this would explain the timeout and the NODATA entries in your Flow Logs (traffic never leaves the subnet). Even if you have a NAT gateway, without this route, Lambda doesn’t know to use it.

3. Verify the NAT Gateway is Healthy #

Take a quick look at your NAT gateway’s status in the VPC Console:

• It should show Available (not Failed or Pending).
• Make sure it’s associated with an Elastic IP that’s in a healthy state.

A broken or pending NAT gateway can’t forward traffic, which will lead to silent timeouts.

4. Check Security Groups for the NAT Gateway Subnet #

While your Lambda’s security group allows outbound traffic, the security group attached to the NAT gateway’s subnet needs to:

• Allow inbound traffic from your Lambda subnets (for the ports you’re using—usually 443 for HTTPS or 80 for HTTP).
• Allow outbound traffic to the internet on those same ports.

If this security group is blocking traffic, your Lambda’s requests will never make it past the NAT gateway.

5. Validate VPC DNS Settings #

Lambda relies on your VPC’s DNS configuration to resolve third-party domain names. If DNS is broken, your requests will timeout even if all routing is correct.

Check your VPC’s properties in the console:

• Ensure DNS resolution is set to Enabled
• Ensure DNS hostnames is set to Enabled

If either is disabled, Lambda can’t turn the third-party service’s domain into an IP address, leading to timeouts that won’t show up as rejects in Flow Logs.

6. Test with a Minimal Lambda Function #

To rule out code-specific issues, create a super simple Lambda function that only sends a GET request to a reliable public endpoint like https://example.com. Deploy it to the same VPC, subnets, and security groups as your problematic function.

If this test function times out too, you know the issue is definitely in your VPC/network config. If it works, the problem might be with your original function’s code or the third-party service itself.

内容的提问来源于stack exchange，提问作者Pat Needham