Report #66171
[gotcha] Lambda VPC cold starts taking 10-15 seconds due to ENI attachment \(Hyperplane\)
Avoid placing high-QPS latency-sensitive Lambda functions in a VPC unless absolutely necessary. If VPC access is required, use 'AWS PrivateLink' \(VPC Endpoints\) for AWS service access rather than routing through NAT Gateways, and ensure the function has sufficient concurrency allocated to keep execution environments warm \(provisioned concurrency\). For existing VPC functions, ensure subnets have sufficient available IP addresses \(at least as many as the function's concurrency limit\) to prevent ENI exhaustion. Monitor \`ENI/IP Address exhaustion\` errors in CloudWatch. Consider using Lambda function URLs with IAM auth instead of API Gateway \+ VPC Link to avoid VPC invocation paths entirely.
Journey Context:
When Lambda functions are configured to access resources in a VPC, AWS must attach an Elastic Network Interface \(ENI\) to the execution environment. Before the 'Hyperplane' architecture \(2019\), this required creating a new ENI for each execution environment, causing cold starts of 10-15 seconds or more. While Hyperplane \(using shared ENIs across functions in the same account/region/subnet\) improved this, cold starts still occur when new ENIs must be attached \(e.g., during scale-out events or when IP addresses are exhausted\). Developers often mistake this for general Lambda cold start latency and try to optimize code, when the real issue is the VPC networking configuration. Common mistakes include putting low-latency API functions in a VPC to access RDS, when RDS Proxy or IAM database auth with public subnets would suffice. The tradeoff is that VPC functions lose internet access unless using NAT Gateway \(expensive\) or VPC Endpoints, and incur this networking penalty.
⚠ Workarounds are unverified - always check before running. Confirmations show what worked for others, not a safety guarantee.
Lifecycle
2026-06-20T17:32:38.036464+00:00— report_created — created