SubnetIPAddressLimitReachedException
AWS SubnetIPAddressLimitReachedException means Lambda could not set up VPC access because one or more configured subnets had no available IP addresses (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 Subnet IP Address Limit Reached Exception Mean?
Lambda cannot provision VPC networking because selected subnets are out of usable private IPs, so scale-out and cold starts fail until subnet capacity recovers.
Common Causes
- -Configured Lambda subnets have no available private IP addresses.
- -Concurrency bursts consume subnet IP pools faster than expected.
- -Subnet CIDR allocation is undersized for VPC-enabled Lambda traffic.
- -Other workloads in the same subnets are exhausting address space.
How to Fix Subnet IP Address Limit Reached Exception
- 1Attach Lambda to subnets with sufficient free IP capacity.
- 2Reduce concurrency bursts while subnet capacity is expanded.
- 3Add additional subnets/AZs and rebalance function networking.
- 4Retry after free-IP capacity is restored.
Step-by-Step Diagnosis for Subnet IP Address Limit Reached Exception
- 1Measure free IP counts in each configured subnet.
- 2Correlate invoke/concurrency spikes with subnet address exhaustion.
- 3Audit co-located workloads consuming addresses in the same subnets.
- 4Validate subnet selection strategy and fallback behavior in function config.
Subnet Capacity and IP Exhaustion Analysis
- -Track available IP addresses per configured subnet during peak periods (example: /28 subnet reaches zero free IPs under burst traffic).
- -Correlate Lambda concurrency with subnet depletion windows (example: event-source spike consumes IPs faster than cleanup/reuse).
Subnet Selection and Concurrency Controls
- -Audit subnet assignment strategy across functions (example: all high-concurrency functions pinned to the same two small subnets).
- -Apply reserved concurrency and paced scaling to reduce abrupt IP demand (example: uncapped queue consumer floods cold starts and exhausts subnet pool).
Decision Shortcut: Subnet IP Exhaustion vs ENI Quota
- -If
AvailableIpAddressCountis near zero for the configured subnets, expand or rebalance subnet capacity before chasing Lambda code issues. - -If subnet IPs are healthy but ENI allocation still fails, compare against ENI quota and Lambda VPC scaling pressure.
- -If failures follow a queue or stream burst, cap event-source concurrency while you add durable subnet headroom.
Wrong Fix to Avoid
- -Do not increase reserved concurrency while selected subnets are already out of addresses; it increases the same IP demand.
- -Do not move all functions into a single larger subnet without preserving AZ spread and modeled peak address usage.
- -Do not assume retrying will solve address exhaustion; retries can keep cold-start pressure high while the subnet remains depleted.
Implementation Examples
aws lambda get-function-configuration \
--function-name payments-vpc-worker \
--query 'VpcConfig.SubnetIds' \
--output text
aws ec2 describe-subnets \
--subnet-ids subnet-0123456789abcdef0 subnet-0fedcba9876543210 \
--query 'Subnets[].{subnet:SubnetId,az:AvailabilityZone,cidr:CidrBlock,availableIps:AvailableIpAddressCount}' \
--output tableaws lambda put-function-concurrency \
--function-name payments-vpc-worker \
--reserved-concurrent-executions 25
# Restore this only after subnet free-IP headroom and burst tests are healthy.Incident Timeline
11:05 UTC
Traffic burst drives VPC Lambda scale-out
Signal: Function concurrency rises quickly after an SQS backlog, stream shard catch-up, or API traffic shift.
Why it matters: The workload is asking Lambda to attach more VPC networking capacity at the same time subnet address space is finite.
11:07 UTC
Configured subnet reaches zero usable IPs
Signal: describe-subnets shows low or zero AvailableIpAddressCount for one or more function subnets.
Why it matters: This confirms the bottleneck is subnet address capacity, not request syntax, IAM, or application code.
11:12 UTC
Concurrency is shaped to stop the cascade
Signal: Reserved concurrency or event-source max concurrency reduces new cold-start demand while subnet changes are prepared.
Why it matters: Stabilization comes from lowering fresh IP demand before attempting a durable network layout fix.
11:40 UTC
Function moves to healthier subnet capacity
Signal: After adding or selecting subnets with enough free IPs, invokes succeed and free-IP metrics remain above thresholds.
Why it matters: The permanent control is subnet headroom monitoring tied to expected concurrency, not one successful retry after traffic drops.
Seen in Production
Configured Lambda subnets run out of private IP addresses
Frequency: common
Example: Function scale-out fails because selected subnet CIDR blocks are exhausted.
Fix: Add larger/extra subnets, rebalance function networking, and reduce burst concurrency.
Shared subnet consumption by multiple services depletes address space
Frequency: rare
Example: Lambda and other workloads compete for the same subnet IP pool during peak windows.
Fix: Isolate high-churn workloads and monitor free-IP capacity continuously.
Wrong Fix vs Better Fix
Retry-only recovery vs capacity restoration
Wrong fix: Keep retrying failed invokes and wait for IP addresses to free up naturally.
Better fix: Reduce concurrency pressure, add or select larger subnets, and verify free IP counts before restoring traffic.
Why this is better: Retries alone do not create address space. Capacity restoration fixes the limiting resource directly.
Small shared subnet vs workload-specific subnet budget
Wrong fix: Place all VPC-enabled Lambda functions into the same small shared subnets because the config is convenient.
Better fix: Allocate subnet capacity according to combined peak concurrency and isolate high-churn workloads where needed.
Why this is better: The subnet plan matches real scaling behavior and prevents unrelated workloads from exhausting each other.
Debugging Tools
- -Subnet free-IP metrics
- -Lambda concurrency traces
- -VPC network allocation audits
- -CloudTrail and function error correlation
How to Verify the Fix
- -Confirm Lambda operations succeed once subnet IP capacity is restored.
- -Validate free-IP trends remain healthy under peak concurrency.
- -Ensure VPC setup failures stop recurring in affected functions.
How to Prevent Recurrence
- -Plan subnet CIDR capacity for projected Lambda concurrency growth.
- -Monitor free IP thresholds and alert before exhaustion.
- -Distribute VPC-enabled workloads across additional subnets and AZs.
Pro Tip
- -precompute IP consumption budgets per function-concurrency tier and enforce deployment checks that block configs with insufficient subnet headroom.
Official References
Provider Context
This guidance is specific to AWS services. Always validate implementation details against official provider documentation before deploying to production.