AWS Lambda Error: Task timed out after X seconds (VPC Egress Block)
.jpeg)
This is not a code failure. It is a VPC routing failure.
Problem
Your Lambda function runs inside a VPC, reaches the full configured timeout (for example, 30 seconds), and fails with:
Task timed out after 30.00 seconds
You may see little or no application logging. The function appears to hang anytime it calls an external service, including AWS APIs or public endpoints.
Clarifying the Issue
This is a network egress problem. A Lambda placed in a private subnet has no outbound path to the public internet unless a NAT Gateway is configured. It also cannot reach most AWS services unless the required VPC Endpoints are configured. As a result, outbound packets are silently dropped. The function waits, receives no response, and simply times out.
This is not a code failure. It is a VPC routing failure.
Why It Matters
A Lambda with a blocked egress path will:
- Consume the full timeout every time
- Perform zero useful work
- Produce misleading logs
- Cause API Gateway or Step Functions to fail unexpectedly
- Increase latency and cost
- Break downstream workflows
Restoring a proper outbound path eliminates the silent hang and restores predictable execution.
Key Terms
- Private Subnet: A subnet without a direct route to the internet.
- NAT Gateway: A resource in a public subnet that provides outbound internet access to private subnets.
- VPC Endpoint: A private access point for an AWS service from inside a VPC.
- Interface Endpoint: An endpoint using ENIs for services like Secrets Manager, SQS, or SNS.
- Gateway Endpoint: A route-table-based endpoint for S3 or DynamoDB.
Steps at a Glance
- Determine whether the function needs internet access or only AWS services.
- Verify that the function is attached to private subnets and check its security group.
- If internet access is required, confirm NAT Gateway connectivity.
- If AWS service access is required, verify appropriate VPC Endpoints.
- Test the network path with a simple connectivity call.
- Test your actual workload and confirm the timeout is resolved.
Step 1: Determine whether the function needs internet access or only AWS services
You need to decide which outbound path your Lambda requires:
- Public Internet: Third-party APIs, external databases. Requires a NAT Gateway.
- AWS Services: S3, DynamoDB, Secrets Manager, SQS, SNS, and others. Can use VPC Endpoints instead of NAT.
This distinction determines which path you must fix.
Step 2: Verify subnets and security group
Check that the Lambda is in private subnets. Lambdas in VPC mode should never be placed in public subnets.
Next, examine the security group attached to the function. A typical safe outbound rule is:
- Outbound: All traffic → 0.0.0.0/0
If outbound traffic is restricted too tightly, the Lambda will silently hang.
Step 3: If internet access is required, verify NAT Gateway configuration
A complete internet egress path requires three components to be aligned:
- The private subnet route table must route 0.0.0.0/0 to a NAT Gateway.
- The NAT Gateway must be deployed in a public subnet.
- The public subnet’s route table must route 0.0.0.0/0 to an Internet Gateway.
If any part of this chain is missing, all internet-bound packets are dropped.
Step 4: If the function only needs AWS services, verify correct VPC Endpoints
For AWS service access, use VPC Endpoints instead of NAT.
Gateway Endpoints for S3 and DynamoDB:
- Ensure the Gateway Endpoint is associated with the private subnet’s route table.
- Traffic to S3 and DynamoDB will follow the service prefix list, which overrides the NAT route.
Interface Endpoints for services like Secrets Manager, SNS, SQS:
- These deploy ENIs into your subnets.
- The endpoint’s security group must allow inbound port 443 from the Lambda’s security group only.
If these endpoints are missing or misconfigured, your function will hang on service calls.
Step 5: Test the network path with a simple connectivity call
Before testing your full application, validate the network path.
If internet access is required, run a small test inside your handler:
import requests
response = requests.get("http://checkip.amazonaws.com")
print(f"Egress successful: {response.text}")
Here’s what this does:
It sends a simple HTTP request to verify that outbound internet traffic is working.
Expected output:
An external IP address printed to logs.
If your function only uses AWS services, test a simple AWS call such as retrieving a secret or listing an S3 bucket.
Step 6: Test the actual workload
Invoke your actual function:
aws lambda invoke \
--function-name MyFunction \
response.json
cat response.json
Expected behavior:
Your handler executes normally and the Lambda Duration value in CloudWatch is realistic instead of maxed-out.
If the Duration still hits the full timeout, reevaluate the NAT path, endpoint configuration, or the function’s outbound security rules.
Pro Tips
- A Lambda that always times out at the full limit is a signature of a VPC egress block.
- Route specificity matters. Gateway Endpoint routes override the NAT route.
- Misconfigured security groups can block traffic just as effectively as bad routing.
- For Interface Endpoints, restrict inbound access to the Lambda’s own security group.
- Workloads that only access VPC resources (like RDS) do not need a NAT Gateway.
Conclusion
This timeout pattern occurs when Lambda is placed in a VPC without a functioning outbound connection. By restoring the correct NAT Gateway route or configuring the appropriate VPC Endpoints, the function regains its ability to communicate externally and stops timing out. Once the egress path is fixed, network-dependent workloads return to normal behavior.
Aaron Rose is a software engineer and technology writer at tech-reader.blog and the author of Think Like a Genius.
Comments
Post a Comment