AWS Lambda Error – Connection timed out (VPC misconfig)

#aws#lambda#devops#cloud

Connection timeouts occur when a Lambda runs inside a VPC but cannot reach its target endpoint because the VPC’s networking path is incomplete, blocked, or misconfigured.

Problem

Your Lambda runs inside a VPC and attempts to call an external API, AWS service, or database, but it never receives a response. CloudWatch logs show:

Task timed out after X seconds

Or your function reports:

socket hang up
ETIMEDOUT
Error: connect TIMEDOUT

This happens when the Lambda container cannot establish an outbound network path. Common causes include misconfigured subnets, missing NAT gateways, or security groups without outbound rules.

---

Clarifying the Issue

A timeout inside a VPC Lambda almost always means no route to the destination. Lambda ENIs in private subnets cannot reach the internet unless routing, NAT, and security groups are configured correctly.

This occurs when:

• Private subnet has no NAT gateway
• Route table lacks 0.0.0.0/0
• Security group blocks outbound traffic
• Missing VPC endpoints for AWS APIs
• DNS resolution fails or returns stale records

---

Why It Matters

Timeouts catastrophically impact production systems:

• Break ingestion pipelines
• Cause retries and duplicate writes
• Slow entire systems due to retry storms

They are silent at first, but when traffic increases, failures cascade.

---

Key Terms

• ENI – Elastic Network Interface created for Lambda when running inside your VPC
• Private Subnet – Subnet with no direct route to an Internet Gateway
• NAT Gateway – Provides outbound internet access for private subnets
• VPC Endpoint – Private network bridge for AWS services such as S3 and DynamoDB

---

Steps at a Glance

1. Confirm the timeout in CloudWatch
2. Determine whether the function runs inside a VPC
3. Test outbound connectivity
4. Verify route tables and VPC endpoints
5. Validate NAT gateway placement
6. Check security groups
7. Re-test the function

---

Detailed Steps

Step 1: Confirm the timeout in CloudWatch logs

Run:

aws logs tail /aws/lambda/my-function --since 5m

You should see a timeout event such as:

Task timed out after 30.00 seconds

This confirms the networking path failed.

Move on to checking the VPC configuration.

---

Step 2: Determine whether the function runs inside a VPC

Inspect the runtime settings:

aws lambda get-function-configuration \
  --function-name my-function \
  --query 'VpcConfig'

If subnets and security groups appear, the function is running inside a VPC.
Private subnets without NAT access will time out every time.

Next, validate connectivity.

---

Step 3: Test outbound connectivity from the runtime

Add a temporary connectivity test to your handler.

Node.js:

const https = require("https");
exports.handler = async () => {
  return new Promise(resolve => {
    https.get("https://example.com", res => resolve({ status: res.statusCode }));
  });
};

Python:

import requests

def handler(event, context):
    r = requests.get("https://example.com")
    return r.status_code

If this fails, your network path is broken.

Next, verify routing.

---

Step 4: Verify route tables and VPC endpoints

Run:

aws ec2 describe-route-tables \
  --filters Name=vpc-id,Values=vpc-123456

Check your private subnet’s route table:

• Should include 0.0.0.0/0 → nat-gateway-id
• Should not point directly to an Internet Gateway
• Should include VPC endpoints if your function calls AWS APIs

If you use AWS services like S3 or DynamoDB, confirm VPC endpoints exist:

aws ec2 describe-vpc-endpoints --filters Name=vpc-id,Values=vpc-123456

Why VPC endpoints matter: They keep S3/DynamoDB traffic inside the AWS network, avoiding the public internet entirely and eliminating NAT dependency, latency, and timeouts.

Now check the NAT gateway itself.

---

Step 5: Validate NAT gateway placement

Your NAT gateway must be:

• In a public subnet
• In a subnet that routes 0.0.0.0/0 to an Internet Gateway

If the NAT is in the wrong subnet, all Lambda traffic will fail.

Now ensure the SG isn’t blocking traffic.

---

Step 6: Check the Lambda security group

Run:

aws ec2 describe-security-groups \
  --group-ids sg-123456

Confirm that:

• Outbound rules allow all traffic (0.0.0.0/0)
• Inbound rules allow return traffic if needed

Outbound blocks are a top cause of timeouts.

Proceed to re-testing.

---

Step 7: Re-test your function

Run:

aws lambda invoke \
  --function-name my-function \
  --payload '{}' \
  out.json

If routing and security rules are correct, the function should now reach its destination.

---

Pro Tips

• Prefer VPC endpoints over NAT whenever using AWS APIs
• Keep Lambdas out of VPC unless absolutely required
• Put Lambdas in private subnets, not public ones
• Use separate NAT gateways for very high-throughput workloads

---

Conclusion

Connection timeouts occur when a Lambda inside a VPC cannot reach its destination. By validating routes, NAT placement, subnets, security groups, and VPC endpoints, you can restore outbound connectivity and stabilize your workloads.

---

Aaron Rose is a software engineer and technology writer at tech-reader.blog and the author of Think Like a Genius.