First off, let's get the core question out of the way: you absolutely do NOT need a NAT gateway for this setup. Your Lambda and Application Load Balancer (ELB) are in the same VPC, and even public-facing ELBs have private IP addresses within your VPC. Lambda can reach the ELB directly over the VPC's internal network—no public internet traversal required, so NAT gateways (and their associated costs) are totally unnecessary here.

Now, why can't your Lambda access the ELB right now? Based on your configuration details, the most likely culprit is how you're trying to reach the ELB. Let's walk through the fixes and checks:

1. Use the ELB's private DNS name instead of the public one #

Public Application Load Balancers have two distinct DNS records:

• Public DNS: Looks like meteor-app-xxxx.elb.amazonaws.com — resolves to public IPs, which your Lambda can't reach without a NAT gateway (since it's stuck in the VPC with no public egress)
• Private DNS: Looks like meteor-app-xxxx.internal.elb.amazonaws.com — resolves to the ELB's private VPC IPs. When you use this, all traffic stays inside your VPC, so no NAT is needed, and your existing security group rules will work.

This is almost certainly the main issue. Swap out the public DNS for the private one in your Lambda code, and you should see immediate progress.

2. Double-check your security group rules (they look good, but let's confirm) #

Your current security group setup should work, but it's worth verifying:

• Lambda's security group (sg-0c53aa67) has an outbound rule allowing TCP 443 traffic to the ELB's security group (sg-6141c009) — that's perfect, it explicitly allows Lambda to initiate HTTPS connections to the ELB.
• The ELB's security group (sg-6141c009) allows inbound HTTPS (TCP 443) from any source — this includes traffic from your Lambda's private IP within the VPC, so that rule is valid.

No changes needed here unless you accidentally misconfigured the security group IDs, but based on your description, this part is solid.

3. If it still doesn't work: Additional troubleshooting steps #

If switching to the private DNS doesn't fix it, run through these checks:

• Confirm that your Lambda's subnets and the ELB's subnets are in the same VPC, and that their route tables allow internal VPC traffic (default VPC route tables do this automatically; custom VPCs need to have routes that permit communication between subnets).
• Check the ELB's health status in the AWS Console — if the ELB itself is unhealthy (e.g., target instances are down), Lambda won't be able to reach it regardless of network config.
• Add logging to your Lambda function to print the IP address resolved from the ELB DNS name. If it's a public IP (not in the private ranges like 10.x.x.x, 172.16-31.x.x, or 192.168.x.x), you're still using the public DNS by mistake.

To recap: Skip the expensive NAT gateway, use the ELB's private internal DNS, and your Lambda will be able to reach both the database (already working via VPC) and the ELB's API without any extra cost.

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