PacketSensei

AWS `Lambda in a VPC cannot reach the internet`: What It Means and How to Fix It

PacketSensei

Lambda in a VPC cannot reach the internet is the most predictable Lambda failure there is: attaching a function to a VPC removes its internet access. It comes from Lambda, and the message reads:

connect ETIMEDOUT / EndpointConnectionError after adding VPC config

If you are here mid-incident, skip to how to tell which cause you have — the command there narrows it down faster than reading the list.

Quick reference
Error Lambda in a VPC cannot reach the internet
Service Lambda
Message connect ETIMEDOUT / EndpointConnectionError after adding VPC config
Most common cause The function is in public subnets

What it actually means

A Lambda function outside a VPC runs on AWS-managed networking with full outbound internet access. The moment you attach it to a VPC, it uses your networking, and it gets exactly the connectivity your subnets provide.

There is no “public subnet” fix here. A Lambda ENI never gets a public IP, so placing the function in a public subnet gives it no internet access at all — only a NAT gateway in a different subnet does. This is counter-intuitive enough that it is the single most repeated VPC-Lambda mistake.

Why it happens

Ranked by how often each one turns out to be the answer.

# Cause Fix
1 The function is in public subnets Lambda ENIs have no public IP, so an internet gateway route does nothing for them. Move the function to private subnets whose route table points 0.0.0.0/0 at a NAT gateway.
2 Private subnets with no NAT gateway Add one, or add VPC endpoints for the specific AWS services the function calls — which is cheaper and often sufficient.
3 The security group has no egress rule A group with all outbound removed blocks everything. Lambda needs egress.
4 Calling an AWS service with no endpoint and no NAT Even sts:AssumeRole or secretsmanager:GetSecretValue needs a path. Interface endpoints for the services the function uses avoid the NAT gateway entirely.
5 The function did not need a VPC in the first place VPC attachment is only required to reach private resources — an RDS instance, an ElastiCache cluster, a private API. Calling public AWS APIs does not require it, and attaching for no reason imports this whole problem.

How to tell which one you have

# Which subnets and security groups?
aws lambda get-function-configuration --function-name my-function \
  --query 'VpcConfig.[SubnetIds,SecurityGroupIds]'

# Do those subnets route to a NAT gateway?
aws ec2 describe-route-tables \
  --filters Name=association.subnet-id,Values=subnet-0123456789abcdef0 \
  --query 'RouteTables[].Routes[?DestinationCidrBlock==`0.0.0.0/0`]'

# Does the security group allow egress?
aws ec2 describe-security-groups --group-ids sg-0123456789abcdef0 \
  --query 'SecurityGroups[].IpPermissionsEgress'

A route pointing at igw-... rather than nat-... is the tell.

Preventing it

Attach a function to a VPC only when it genuinely needs to reach something private. It is not a security control in itself — IAM is — and it adds cold-start cost, an ENI dependency, and this entire failure mode.

When a VPC is required, put the function in private subnets and add interface endpoints for the AWS services it calls. That is cheaper than a NAT gateway for low-volume functions and keeps the traffic off the public internet.

Quota codes, limits and behaviour on this page were last checked against AWS documentation on 2026-08-22. AWS changes these; if something here does not match what you are seeing, trust the console and tell us.