AWS "There Are Not Enough Free Addresses in Subnet" (InsufficientFreeAddressesInSubnet): EC2, EKS "Failed to Assign an IP Address to Container", Lambda, Fargate, ALB, Glue and SageMaker, Fixed

"There are not enough free addresses in subnet" (error code InsufficientFreeAddressesInSubnet) means the subnet you picked has run out of private IP addresses, and whatever you were creating (an EC2 instance, an EKS Pod, a Lambda function, a Fargate task, a load balancer node, a Glue job) needs at least one. Every one of those things gets its own network interface with its own address, and a subnet only holds what its CIDR block allows, minus five addresses AWS keeps for itself: a /28 holds 11, a /24 holds 251. The fix is never to enlarge the subnet, because AWS has no way to resize a subnet once it exists; you give the workload more subnets, a bigger new subnet, or a secondary CIDR block on the VPC. Here is the part that surprises almost everyone running EKS: a subnet can show zero free addresses while half of them are doing nothing. The EKS networking plugin keeps a whole spare network interface full of addresses on every node by default, so ten small nodes can reserve two hundred addresses for Pods that do not exist yet. This page shows how to see who is holding the addresses, the exact message each service prints, and the fix for each: EC2, EKS (including "failed to assign an IP address to container"), Lambda, ECS and Fargate, Application Load Balancers, Glue and SageMaker.

Jake's phone repair shop runs its booking site on a small AWS setup that Ethan, his developer friend, built two years ago: a VPC, two subnets, a load balancer, a few containers. On the Monday of a big sale, Ethan scaled the service from four tasks to twelve to handle the traffic. Eight new tasks failed in under a minute with an error about free addresses, and the load balancer started returning errors of its own. Jake, watching over his shoulder, asked the question this page answers: "We pay for the cloud so it never runs out of room. How did we run out of addresses?"

New to VPCs and subnets? Our plain-English guide to Amazon VPC explains networks, subnets and CIDR blocks in about ten minutes. You can follow this page without it.

What "not enough free addresses in subnet" means

A subnet is a slice of your VPC's address range, pinned to one Availability Zone. Its size is written as a CIDR block such as 10.0.1.0/24: the number after the slash says how many addresses it holds. A /24 is 256 addresses, a /28 is 16, and each step down in the number doubles the size.

You never get all of them. AWS keeps five addresses in every subnet: the first four (the network address, the VPC router, the DNS server address, and one held for future use) and the last one (the broadcast address, which a VPC does not use but still reserves). So the usable count is always the total minus five:

Now the part that decides how fast a subnet fills: almost everything in a VPC talks to the network through a network interface (an ENI), and every network interface takes at least one address. An EC2 instance has one. Every EKS Pod gets its own address. Every Fargate task gets its own interface. A Lambda function connected to the VPC creates interfaces in each subnet you give it. A load balancer runs nodes with interfaces in each subnet. NAT gateways, VPC interface endpoints and RDS databases all hold addresses too. Add those up against "251 usable," and a /24 that looked generous on the day it was created becomes the bottleneck of a busy week.

The error comes from the moment of creation. It does not take anything down that is already running; it stops new things from starting. That is why it usually shows up during scale-out, a deployment, a cluster upgrade or a batch job, exactly when you need the new capacity most.

Jake: "So the subnet is like a car park, and every car needs its own space."

Ethan: "And five spaces are painted for the staff before you arrive. The car park can't be widened, either. We can only open another one next door."

See how many addresses are left, and who is holding them

The free count is one command. The AvailableIpAddressCount field is the number AWS uses when it refuses a request:

aws ec2 describe-subnets \
  --filters Name=vpc-id,Values=vpc-0123456789abcdef0 \
  --query 'Subnets[].{Subnet:SubnetId,AZ:AvailabilityZone,CIDR:CidrBlock,Free:AvailableIpAddressCount}' \
  --output table

On a fresh /28 in a test environment, that table shows 11 free; after nine instances land in it, it shows 2. In the console, the same number is the Available IPv4 addresses column on the Subnets page.

The useful question is the second one: who is holding the addresses. Every address in use belongs to a network interface, and the interface records which service created it:

aws ec2 describe-network-interfaces \
  --filters Name=subnet-id,Values=subnet-0123456789abcdef0 \
  --query 'NetworkInterfaces[].{Type:InterfaceType,Status:Status,IPs:length(PrivateIpAddresses),Desc:Description}' \
  --output table

Read three columns. Type tells you the kind: interface for instances, EKS nodes and Fargate tasks; lambda for Lambda; load_balancer or network_load_balancer; vpc_endpoint; natGateway; trunk and branch for ECS and EKS features that pack more interfaces onto a node. IPs is how many addresses that one interface holds, and on EKS nodes it is often 10, 15 or 30, which is the first clue to the warm-pool surprise below. Description names the owner: the load balancer's name, the EKS cluster, the ECS attachment, the Lambda function. An interface with Status available is attached to nothing and is still holding its address, which is worth chasing; our guide to leftover network interfaces that block a VPC delete shows how to trace and remove them safely.

To total the addresses by type in one go, which is how you find the biggest consumer:

aws ec2 describe-network-interfaces \
  --filters Name=subnet-id,Values=subnet-0123456789abcdef0 \
  --query 'NetworkInterfaces[].[InterfaceType, length(PrivateIpAddresses)]' --output text \
| awk '{n[$1]+=$2} END {for (t in n) print n[t], t}' | sort -rn

One more holder that surprises people: stopped EC2 instances keep their addresses. Addresses that belong to stopped instances count as unavailable, so a subnet full of stopped test servers is full, and you will hit the error even though nothing is running.

The message each service prints, and where to go

The same shortage wears a different message in every service. Find yours, then jump to its section:

Getting more addresses: you cannot resize a subnet

Before you reach the service-by-service fixes, here is the rule that shapes all of them. A subnet's CIDR block is fixed for its life. The only API that modifies a subnet changes its settings (public IP on launch, IPv6, DNS options) and has no field for its range. So "make the subnet bigger" is not on the menu. You have four real options, roughly in order of effort:

1. Free what is wasted. Terminate stopped instances you no longer need, delete available network interfaces that nothing uses, stop ECS tasks that never ended, and on EKS shrink the warm pool. This often buys back a surprising number of addresses in minutes.
2. Use more of the subnets you already have. Most services take a list of subnets: an Auto Scaling group, an ECS service, a Lambda function, an EKS node group, a Glue connection. If another subnet in the same VPC has room and the right routes, add it to the list.
3. Create a new, bigger subnet in unused space of the VPC's CIDR block, then point the service at it. Check the VPC's free space with aws ec2 describe-vpcs and the existing subnets' ranges first; subnets cannot overlap.
4. Add a secondary CIDR block to the VPC when the VPC itself is full, then create new subnets inside it. This is the standard fix for EKS clusters that outgrew their VPC.

Adding a secondary CIDR block is one command:

aws ec2 associate-vpc-cidr-block --vpc-id vpc-0123456789abcdef0 --cidr-block 100.64.0.0/16
aws ec2 create-subnet --vpc-id vpc-0123456789abcdef0 --cidr-block 100.64.0.0/19 --availability-zone us-east-1a

The association starts in the associating state and becomes usable within moments; a local route is added to every route table automatically. Which ranges you are allowed to add depends on your primary range. A VPC built on 10.0.0.0/8 cannot add a block from the other private ranges (172.16.0.0/12 or 192.168.0.0/16), but it can add more 10.x space that does not clash, or a block from 100.64.0.0/10, the shared address space that EKS teams use for Pods because it rarely collides with office networks or peered VPCs. Every added block must be between /16 and /28, and must not overlap anything the VPC is connected to through peering, a transit gateway or a VPN.

The new subnets need the same plumbing as the old ones: a route table with the NAT gateway or endpoints the workload needs, and network ACLs that allow its traffic. If the new subnet's workloads suddenly cannot reach the internet, our guide to private subnets without internet access covers the routing checks.

EC2 and Auto Scaling: InsufficientFreeAddressesInSubnet

For plain instances the error is literal: your launch asked for more addresses than the subnet has. Remember that an instance with extra network interfaces or secondary private IPs takes one address for each.

• Auto Scaling groups: give the group subnets in every Availability Zone you use, not one. When one subnet is full, the group launches in the others. Our page on public and private subnets covers which kind to use.
• Stopped instances: they hold their addresses. Terminate the ones you no longer need; an image or snapshot keeps their disk if you might want it back.
• Launch templates that set a fixed private IP fail differently ("address in use") but in the same subnets; check the template does not pin an address.

EKS Pods: "failed to assign an IP address to container" and the warm pool

This is the version with the most readers, and the one where the free-address count lies to you. On EKS with the default networking plugin (the Amazon VPC CNI), every Pod gets a real VPC address from the node's subnet. To start Pods quickly, the plugin keeps addresses ready on each node before any Pod asks for them, and the default setting is generous: WARM_ENI_TARGET=1, which means "always keep one whole spare network interface, and all of its addresses, attached to every node."

Take an m5.large node. It supports 3 network interfaces with 10 addresses each. As soon as a few Pods land on it and its first interface is no longer fully free, the plugin attaches a second interface to keep one spare. So a node running five Pods typically holds twenty addresses from the subnet. Ten such nodes hold two hundred addresses for fifty Pods. On a /24 with 251 usable, add the nodes' own addresses and the cluster's control-plane interfaces, and the subnet reads zero free while a quarter of its addresses wait for Pods that do not exist. The plugin's documentation gives the same pattern with a bigger instance: an m4.4xlarge launches with 1 interface and 30 addresses, and after 5 Pods it attaches more interfaces until a whole free one is available again.

When the subnet runs dry, new Pods stick in ContainerCreating and kubectl describe pod shows:

Failed create pod sandbox: rpc error: code = Unknown desc = NetworkPlugin cni failed to set up
pod network: add cmd: failed to assign an IP address to container

You will often see it during a rolling update, because the update briefly runs more Pods than usual: a deployment with maxSurge of 25% on 600 Pods needs 150 extra addresses for a few minutes. Also check the node itself: each instance type has a maximum Pod count, worked out as interfaces times (addresses per interface minus one) plus two, which is 29 for an m5.large; a node at that ceiling refuses Pods with the same symptom even when the subnet has room. Our EKS NotReady and Pending guide covers the "Too many pods" side of that.

Jake: "So the cluster is reserving spaces for cars that haven't arrived?"

Ethan: "Every node reserves a whole row, just in case. It's quick when the cars come. It's a disaster when the car park is small."

Fix 1: shrink the warm pool

Tell the plugin to keep a few spare addresses instead of a whole interface. Use MINIMUM_IP_TARGET for the floor you normally need and a small WARM_IP_TARGET for headroom. The plugin's own example: for about 30 Pods per node, WARM_IP_TARGET=30 alone ends up holding 60 addresses once the Pods arrive, while MINIMUM_IP_TARGET=30 with WARM_IP_TARGET=2 holds 32. On the managed add-on:

aws eks update-addon --cluster-name shop --addon-name vpc-cni \
  --configuration-values '{"env":{"MINIMUM_IP_TARGET":"10","WARM_IP_TARGET":"2"}}' \
  --resolve-conflicts PRESERVE

On a self-managed plugin, the same two variables go on the aws-node DaemonSet in kube-system. The trade-off is speed and API calls: with fewer spare addresses, the plugin asks EC2 for addresses more often, and the plugin's documentation warns against small WARM_IP_TARGET values on large clusters or clusters with heavy Pod churn, because the extra calls can be throttled. Pairing it with MINIMUM_IP_TARGET is what keeps the call count sane.

Fix 2: add subnets or a secondary range for Pods (custom networking)

With custom networking, the plugin places Pods' addresses in different subnets from the nodes, typically subnets carved from a secondary 100.64.0.0/10 block added as shown above. The nodes keep their original subnets; the Pods get room to grow. Two things to know: with custom networking, the node's primary interface is no longer used for Pods, so each node runs slightly fewer Pods than before; and it does not work with IPv6 clusters. If address exhaustion is your only reason, the EKS documentation points out that an IPv6 cluster removes the problem at the root, though that is a new cluster, not a switch on an old one.

EKS fix 3: prefix delegation, and the "InsufficientCidrBlocks" trap

With prefix delegation (VPC CNI 1.9.0 or newer, Nitro instances), the plugin assigns each interface a block of 16 addresses (a /28) at a time instead of one address at a time. Nodes run many more Pods, attach new capacity faster (a prefix attaches in under a second; a new interface can take up to 10), and in the worst case leave up to 15 addresses unused per node. It is turned on with ENABLE_PREFIX_DELEGATION=true, and the recommended way to switch is new node groups, not a rolling replacement of old ones, because a node holding both single addresses and prefixes can misreport its capacity.

The trap: a /28 prefix must be 16 contiguous free addresses, aligned to a /28 boundary. A busy subnet can have a hundred free addresses scattered between used ones and still not contain a single free /28, and the plugin's logs then show:

failed to allocate a private IP/Prefix address: InsufficientCidrBlocks: There are not enough free
cidr blocks in the specified subnet to satisfy the request.

The fix is to reserve space for prefixes so nothing else fragments it. A subnet CIDR reservation of type prefix sets aside a range that EC2 then uses only for prefix assignments:

aws ec2 create-subnet-cidr-reservation --subnet-id subnet-0123456789abcdef0 \
  --cidr 10.0.8.0/22 --reservation-type prefix --description "EKS pod prefixes"

A reservation can only cover space that is currently free, so on a badly fragmented subnet your cleaner route is a new subnet dedicated to Pods, with prefix delegation on from the start. A subnet used only by prefix-mode Pods does not need the reservation step at all.

EKS cluster creation and upgrades: the six-address rule

The EKS control plane places 2 to 4 network interfaces in the subnets you gave the cluster. Each of those subnets needs at least six free addresses for EKS, and 16 is the safer floor you should plan for. That sounds trivial until an upgrade: when you update the Kubernetes version, EKS deletes its interfaces and creates new ones, possibly in different subnets from the list. If every cluster subnet is full of Pods, the upgrade cannot place its interfaces.

Since late 2023 you can change the cluster's subnets without rebuilding it:

aws eks update-cluster-config --name shop \
  --resources-vpc-config subnetIds=subnet-aaa,subnet-bbb,subnet-ccc

The rule: the new list must cover the same set of Availability Zones the cluster was created with, all in the same VPC. A cluster created across three zones needs at least one subnet in each of those three. A good pattern for you is small dedicated subnets (a /28 per zone) just for the control-plane interfaces, so Pods can never crowd them out. If you add a secondary CIDR block for this, give it up to an hour before kubectl exec, logs and port-forward work for nodes in the new range; the control plane needs that long to recognize it.

Lambda: SubnetOutOfIPAddresses and Hyperplane interfaces

A Lambda function attached to a VPC does not get one interface per running copy, a common worry from older documentation. Lambda creates a Hyperplane interface for each combination of subnet and security group, shares it between every function in the account that uses the same combination, and each one carries up to 65,000 connections. So a function with three subnets and one security group usually needs three addresses, not three hundred.

The shortage shows up when Lambda cannot create those interfaces. A new function stays Pending and then Failed, or an update fails, and the function's configuration shows the reason code SubnetOutOfIPAddresses:

aws lambda get-function-configuration --function-name resize-photos \
  --query '{State:State,Reason:StateReason,Code:StateReasonCode,Update:LastUpdateStatusReasonCode}'

• The fix: give the function subnets that have free addresses, ideally the same subnets and security group your other functions use, so they share interfaces. Each new subnet-and-group combination is a new interface.
• Idle functions: after 14 days without invocations, Lambda reclaims the interfaces and marks the function Inactive; the next call fails while it recreates them. If the subnet filled up in those 14 days, the recreation is where you meet this error.
• Taking a function out of a VPC takes up to 20 minutes to release its interface, and only if no other function or published version still uses it.
• A different limit: ENILimitReachedException is the per-VPC network interface quota (3,000 by default), not the subnet; it is raised through Service Quotas.

Connecting a function to a VPC does not give it internet access, even in a public subnet; that is a separate problem our Lambda-in-a-VPC internet guide covers.

ECS and Fargate: one address per task

Every Fargate task gets its own network interface with a private address, and so does every ECS task on EC2 that uses the awsvpc network mode. Twelve tasks are twelve addresses, plus a short overlap during deployments while old and new tasks run together. That is how Jake's sale-day scale-out from four tasks to twelve failed: the two /27 subnets had 54 usable addresses between them, and the load balancer, a NAT gateway, two VPC endpoints and the existing tasks had used most of them.

• Spread the service: list subnets in several Availability Zones in the service's network configuration. ECS places tasks across them.
• Batch jobs that fan out: a Step Functions Map state that starts thirty Fargate tasks at once needs thirty addresses at once. Cap the Map's concurrency to what the subnets can hold, or give the job its own larger subnets.
• Tasks that never stopped: one widely read case traced the error to tasks from run-task that stayed around for months and kept their addresses. List the cluster's running tasks and stop the strays.
• ECS on EC2: with awsvpc, the instance's interface limit caps tasks per instance before the subnet does; the awsvpcTrunking account setting raises that limit on supported instance types (container agent 1.28.1 or later), but every task still takes a subnet address.

If the task fails before the container starts with a different network message (a registry timeout, a secrets fetch), that is not this error; our guides to ResourceInitializationError and CannotPullContainerError cover those.

Jake: "So each copy of our booking app is a car too."

Ethan: "Each copy, the load balancer's own cars, and the delivery vans. We just ran out on the busiest day of the year."

Load balancers: the 8-address rule and the silent scaling failure

An Application Load Balancer runs on nodes that AWS scales up and down behind the scenes, and each node needs an address in each of the load balancer's subnets. AWS's requirement: every subnet you give an ALB should be at least a /27 and have at least eight free addresses, so the load balancer can scale out when traffic rises. Creating one in a fuller subnet fails up front:

Not enough IP space available in subnet-0123456789abcdef0. ELB requires at least 8 free IP addresses
in each subnet. (Service: AmazonElasticLoadBalancing; Status Code: 400; Error Code: InvalidSubnet)

The worse case is the one where you get no error message at all. If an existing ALB's subnet fills up later, the load balancer runs with insufficient capacity when it tries to scale: the old nodes keep serving, but the stalled scale-out can cause 5xx responses or connection timeouts under exactly the load that triggered it. That was the second half of Jake's sale-day problem: the tasks used the last addresses, and the load balancer had nowhere to grow. If you are chasing 502s and 504s, our ALB 502 vs 504 guide covers the other causes, but check the free count first on a busy day.

The durable fix is to give load balancers their own small subnets (a /27 per zone is plenty for most) so application tasks can never take their addresses. You can change an ALB's subnets in place with aws elbv2 set-subnets, keeping one per zone you serve.

Glue and SageMaker: jobs that need many addresses at once

AWS Glue jobs that use a connection (to Redshift, RDS or anything inside the VPC) run their workers inside the connection's subnet, and each worker needs an address. The message reads "The specified subnet does not have enough free addresses to satisfy the request," and it often appears only sometimes, when two big jobs overlap. The number of addresses follows the worker count, so your fixes are fewer workers per job, running large jobs in sequence rather than in parallel, or pointing the connection at a bigger subnet that can still reach the database. The connection decides the subnet, so changing it is the whole fix.

SageMaker Studio, training jobs and processing jobs inside a VPC place interfaces in the subnets you configured, and a large instance or many parallel jobs can exhaust them: "Unable to create network interface because subnet 'subnet-...' does not have enough free addresses to satisfy the request. Free up addresses or add more addresses for the subnet to use, or create a new domain with a new subnet." Older answers say you must rebuild the Studio domain to change its subnets. That is no longer true: aws sagemaker update-domain now accepts new subnet IDs. The one condition when removing a subnet is that no apps are in the InService, Pending or Deleting state, so stop the running apps first. If SageMaker refuses with a quota message instead, that is a different limit; our ResourceLimitExceeded guide covers it.

Sizing subnets so this does not come back

A few rules of thumb that hold up whether your team is two people or two hundred:

• Separate the always-small from the growing. Load balancers, NAT gateways, endpoints and EKS control-plane interfaces each get small subnets (/27 or /28). Workloads that scale (Pods, Fargate tasks, Lambda, batch jobs) get large ones (/20 or bigger for EKS).
• Size EKS by Pods, not nodes. Count peak Pods, add the warm pool for your settings, add 25% for rolling updates, then double it. A /24 is rarely enough for an EKS workload subnet.
• Leave room in the VPC. Do not carve the whole VPC CIDR into subnets on day one. Unused space is what lets you add a new subnet later without a secondary block.
• Watch the number. A scheduled describe-subnets check that alerts below 20% free gives you days of warning instead of a failed deployment. If you use IPAM, it can track subnet utilisation for you.

The ten-minute fix order

1. Run describe-subnets for the VPC and note the free count in each subnet the failing service uses.
2. Run the describe-network-interfaces totals on the fullest subnet to see which type holds the most addresses.
3. Free the waste: stopped instances, available interfaces, stuck tasks, and on EKS the warm pool (MINIMUM_IP_TARGET plus a small WARM_IP_TARGET).
4. Add another existing subnet with room to the service's subnet list.
5. If none has room, create a bigger subnet in free VPC space, or add a secondary CIDR block and create subnets in it.
6. Move load balancers and EKS control-plane interfaces to their own small subnets so this cannot take them down next time.

Fixes by symptom

Frequently asked questions about free addresses in a subnet

Ethan's fix that Monday took twenty minutes: he added a 100.64.0.0/16 block to the VPC, created two /20 subnets in it for the tasks, and moved the load balancer onto its own two /27 subnets, which suddenly had all their addresses free. The twelve tasks came up, the 502s stopped, and the sale went on. Jake asked how much the new address space cost. "Nothing," said Ethan. "Addresses inside the VPC are free. Running out of them is the expensive part."

Revision note. Written October 16, 2026, with the subnet commands checked in a test VPC. "Don't put all your eggs in one basket," as the old saying goes; with subnets, don't put every workload in one either.