ENILimitReachedException
AWS ENILimitReachedException means Lambda could not create an elastic network interface because ENI limits were reached during VPC setup (HTTP 502).
Last reviewed: May 4, 2026|Source-backed guidance under our editorial policy
Start Here
Use the closest compare guide, playbook, or adjacent error page to narrow the decision faster before you start changing production systems.
This page is part of the Error Reference library. Learn more about the project or report a correction.
What Does ENI Limit Reached Exception Mean?
Lambda cannot allocate additional ENIs for VPC-connected execution, so scaling and cold starts fail until network interface capacity pressure is reduced.
Common Causes
- -VPC-enabled Lambda functions exhausted ENI quota in account/VPC context.
- -Concurrency spikes require more ENIs than allowed by current limits.
- -Multiple functions share constrained subnets/security groups, increasing ENI contention.
- -ENI cleanup lag plus burst scaling creates temporary exhaustion windows.
How to Fix ENI Limit Reached Exception
- 1Reduce burst concurrency or limit invocations while ENI pressure is high.
- 2Distribute functions across additional subnets/AZs and rebalance networking.
- 3Request relevant quota increases where applicable and validated.
- 4Retry with bounded backoff after ENI capacity recovers.
Step-by-Step Diagnosis for ENI Limit Reached Exception
- 1Inspect Lambda concurrency and ENI utilization metrics for affected functions.
- 2Review subnet/security-group assignments across all VPC-enabled Lambda workloads.
- 3Correlate ENI-limit errors with deploy bursts and scale events.
- 4Validate idle ENI cleanup and networking behavior in the target VPC.
ENI Capacity and Quota Analysis
- -Measure ENI consumption versus service quotas in affected VPC/subnets (example: burst scaling consumes available ENI slots faster than release cycle).
- -Correlate Lambda concurrency spikes with ENI allocation failures (example: sudden SQS fan-out drives VPC function cold starts beyond ENI headroom).
Subnet/IP and Concurrency Shaping
- -Audit subnet CIDR/IP capacity and distribution across functions (example: small /28 subnet exhausts assignable IPs during traffic burst).
- -Apply reserved concurrency and paced event-source scaling (example: cap function concurrency to keep ENI demand below safe ceiling).
Decision Shortcut: ENI Quota vs Subnet IPs vs EC2 Permission
- -If ENI count is at quota and subnets still have free IPs, treat this as ENI quota or Lambda VPC scaling pressure.
- -If subnet available IPs are near zero, fix subnet sizing or distribution before requesting an ENI quota increase.
- -If the error is
EC2AccessDeniedException, investigate Lambda execution role permissions instead of capacity.
Wrong Fix to Avoid
- -Do not raise Lambda concurrency during an ENI allocation incident; it increases the same network-interface demand that is failing.
- -Do not move every function into one larger subnet without modeling combined peak demand and AZ resilience.
- -Do not rely on retries alone for asynchronous sources; repeated retries can keep concurrency high and delay ENI recovery.
Implementation Examples
aws cloudwatch get-metric-statistics \
--namespace AWS/Lambda \
--metric-name ConcurrentExecutions \
--dimensions Name=FunctionName,Value=orders-vpc-worker \
--statistics Maximum \
--period 60 \
--start-time 2026-05-04T06:30:00Z \
--end-time 2026-05-04T07:30:00Z
aws ec2 describe-subnets \
--subnet-ids subnet-0123456789abcdef0 subnet-0fedcba9876543210 \
--query 'Subnets[].{subnet:SubnetId,az:AvailabilityZone,availableIps:AvailableIpAddressCount,cidr:CidrBlock}' \
--output tableaws lambda put-function-concurrency \
--function-name orders-vpc-worker \
--reserved-concurrent-executions 50
# Remove or raise this cap after subnet/ENI headroom and burst tests are healthy.Incident Timeline
06:45 UTC
Event source fans out into VPC-enabled Lambda concurrency
Signal: SQS, stream, or API traffic increases concurrent cold starts for functions attached to the same VPC subnet and security group set.
Why it matters: The first signal is often a concurrency surge, not an explicit network quota dashboard alert.
06:47 UTC
Lambda cannot allocate another ENI
Signal: Invoke failures show ENILimitReachedException, while application logs may only show timeout, 502, or initialization failures.
Why it matters: Correlate Lambda errors with ENI count, subnet available IP addresses, and function concurrency before changing code.
06:55 UTC
Traffic is shaped while capacity is repaired
Signal: Reserved concurrency, event-source batch/concurrency limits, or upstream throttles reduce fresh ENI demand.
Why it matters: Stabilizing concurrency buys time for cleanup, subnet redistribution, or quota increase without amplifying the failure.
07:20 UTC
Headroom is restored and burst test passes
Signal: Invocations succeed under a controlled burst and ENI/subnet metrics remain below alert thresholds.
Why it matters: The durable fix is a headroom model tied to expected concurrency, not a single successful retry after traffic calms.
Seen in Production
Lambda VPC concurrency surge exhausts ENI capacity
Frequency: common
Example: Burst traffic to VPC-enabled functions drives ENI allocation beyond available quota.
Fix: Reduce burst concurrency, rebalance subnet usage, and increase relevant quotas where appropriate.
Multiple VPC-enabled functions contend for limited networking capacity
Frequency: rare
Example: Independent workloads share subnets/security groups and collide on ENI availability.
Fix: Separate high-concurrency workloads and size VPC networking for combined peak demand.
Wrong Fix vs Better Fix
More retries vs concurrency shaping
Wrong fix: Increase retry attempts for failed invokes while leaving the event source free to keep scaling.
Better fix: Cap concurrency or event-source parallelism until ENI and subnet headroom are restored.
Why this is better: Capacity failures recover when demand is reduced; uncontrolled retries keep pressure on the same constrained resource.
Single-subnet expansion vs distributed subnet plan
Wrong fix: Move all VPC-enabled functions into one larger subnet and call the incident fixed.
Better fix: Distribute high-concurrency functions across suitable subnets and AZs with modeled IP and ENI headroom.
Why this is better: The design keeps scaling capacity and availability balanced instead of creating a new single-subnet bottleneck.
Debugging Tools
- -Lambda concurrency metrics
- -VPC ENI utilization checks
- -Subnet/security-group allocation review
- -CloudTrail and function error correlation
How to Verify the Fix
- -Confirm Lambda VPC invokes succeed without ENI allocation failures.
- -Validate ENI utilization and concurrency headroom stay within safe operating range.
- -Re-run burst tests to ensure scaling no longer exhausts ENI capacity.
How to Prevent Recurrence
- -Set account/VPC ENI capacity alerts tied to Lambda concurrency growth.
- -Distribute high-concurrency functions across multiple subnets and AZs.
- -Load-test VPC-enabled Lambda scaling behavior before major traffic launches.
Pro Tip
- -maintain per-function ENI headroom budgets and block traffic ramp plans that would exceed modeled ENI demand in the target subnet set.
Official References
Provider Context
This guidance is specific to AWS services. Always validate implementation details against official provider documentation before deploying to production.