skip to content

Launches into an AWS VPC subnet start failing because it has run out of free IPv4 addresses. What are your options, and why can't you simply make that subnet bigger?

level: seniorimportance: should knowfreq 45%

answer

  1. the shortage is one zone's problem
  2. that CIDR was fixed at creation
  3. look for interfaces nobody is using
  4. add space rather than resize
  5. a second block can join the VPC

basics

~20 s

A subnet's CIDR is immutable, so it cannot grow. You add capacity instead: carve a new subnet in the same Availability Zone from unused VPC space, or attach a secondary CIDR block to the VPC and build subnets from that, then reclaim addresses held by idle interfaces.

solid answer

~50 s

You cannot resize a subnet — its CIDR is fixed at creation, and neither the console nor the API offers a way to change it, because the addresses are already in use by live interfaces. So the fix is additive. First, reclaim: every elastic network interface holds an address, including ones left behind by stopped instances and decommissioned managed resources, so find and delete the orphans. Then add: if the VPC CIDR has unallocated space, create a new subnet in the *same* Availability Zone as the exhausted one and associate it with the same route table, then point the affected workload at both subnets. If the VPC is fully carved up, attach a secondary IPv4 CIDR block to the VPC — a range that overlaps nothing the VPC connects to — and build subnets from it, remembering that anything routing to this VPC from outside needs the new range added to its routes.

code

bash · 10 lines
bash
# 1. How bad is it, per subnet?
aws ec2 describe-subnets --filters Name=vpc-id,Values=vpc-0abc \
  --query 'Subnets[].[SubnetId,AvailabilityZone,CidrBlock,AvailableIpAddressCount]' --output table

# 2. Add space to the VPC when its CIDR is fully carved up
aws ec2 associate-vpc-cidr-block --vpc-id vpc-0abc --cidr-block 100.64.0.0/16

# 3. Carve a subnet in the SAME AZ as the exhausted one, then route it identically
aws ec2 create-subnet --vpc-id vpc-0abc --cidr-block 100.64.0.0/20 --availability-zone eu-west-1a
aws ec2 associate-route-table --subnet-id subnet-0new --route-table-id rtb-0private

go deeper

for a junior

Know that a subnet's CIDR cannot be changed after creation, so running out of addresses is solved by adding another subnet rather than by resizing.

for a middle

Explain what consumes addresses — every network interface, stopped instances included, plus five reserved per subnet — and how a secondary VPC CIDR block gives you room when the VPC is fully carved.

for a senior

Work the incident: confirm it is zone-bound, reclaim orphaned interfaces, add a same-zone subnet on the same route table, extend the workload's subnet list, and only then consider a secondary CIDR.

for a principal

Own the prevention: the sizing standard, the unallocated headroom you reserve inside each VPC CIDR, the free-address alarming, and whether IPv6 adoption is the structural answer for your estate.

## The symptom EC2 rejects the launch with an insufficient-free-addresses error (`InsufficientFreeAddressesInSubnet`), an Auto Scaling group starts failing to replace capacity in one Availability Zone while the others are fine, or a managed service cannot create the interface it needs. The tell is that it is *zone-specific*: subnets belong to exactly one Availability Zone, so exhaustion shows up as one zone failing while the rest look healthy. ## Why you cannot grow the subnet A subnet's CIDR block is set at creation and is immutable. There is no modify operation for it. Enlarging `10.0.1.0/24` to `10.0.0.0/23` would require the adjacent space to be free, would change the broadcast and reserved addresses of the block, and would have to happen underneath live interfaces — AWS simply does not offer it. Enlarging the VPC CIDR does not help either: subnets do not inherit space from the VPC, they are explicitly carved from it. This immutability is the reason subnet sizing is a decision you make once, and the reason experienced teams over-provision address space, which is free. ## Step one: find what is actually holding addresses Before adding space, count. Every ENI in the subnet consumes one address, plus one for each secondary private address on it. Common surprises: - Stopped EC2 instances keep their primary private address. - Interfaces left behind by deleted resources sometimes linger in `available` state. - Managed services place interfaces in your subnets on your behalf, and scale by adding more of them. - Five addresses per subnet are reserved by AWS and never available. ```bash aws ec2 describe-network-interfaces \ --filters Name=subnet-id,Values=subnet-0aaa \ --query 'NetworkInterfaces[].[NetworkInterfaceId,Status,Description]' --output table ``` Deleting genuinely orphaned interfaces buys immediate headroom and sometimes ends the incident outright. ## Step two: add a subnet from unallocated VPC space If the VPC CIDR still has gaps, this is the cheapest fix. Create the new subnet **in the same Availability Zone** — putting it elsewhere does not help a zone-bound shortage, and moves traffic across zones. Associate it with the same route table as the exhausted subnet so it inherits identical reachability, then add it to whatever selects subnets: the Auto Scaling group, the service's subnet list, the load-balancer target configuration. Nothing needs to move; the new capacity simply lands in the new subnet. ## Step three: add a secondary CIDR to the VPC When the VPC CIDR is fully consumed, you can attach additional IPv4 CIDR blocks to the VPC and carve subnets from them: ```bash aws ec2 associate-vpc-cidr-block --vpc-id vpc-0abc --cidr-block 100.64.0.0/16 ``` Things to get right here: - **No overlap.** The new range must not overlap the VPC's existing CIDRs, and in practice must not overlap anything the VPC has routed connectivity to — otherwise you have created an address collision you cannot route around. - **Propagate the range.** The VPC's own route tables gain a `local` route for it automatically, but anything routing *into* this VPC from elsewhere does not learn it for free; its routes have to be updated to include the new block. - **Pick a range nobody else uses.** Teams frequently reach for `100.64.0.0/10` (the carrier-grade NAT range) for this exact purpose, because it is unlikely to collide with corporate RFC 1918 space. - **Check the quota.** The number of CIDR blocks per VPC is a service quota, not unlimited, and can be raised on request. ## Step four: prevent the recurrence The long-term fix is sizing policy, not remediation. Estimate against *interface* count including managed-service interfaces and scale-out headroom, not against instance count today. Reserve unallocated ranges inside each VPC CIDR between the subnets you create, so the next expansion is a new subnet rather than a secondary CIDR. And instrument it: `AvailableIpAddressCount` per subnet is observable, and alarming when it drops below a threshold turns a hard launch failure into a scheduled change. IPv6 is the other structural answer — a VPC gets a /56 and each subnet a /64, which makes exhaustion a non-issue for that address family — but it is a migration, not an incident response.

  • Why does creating the replacement subnet in a different Availability Zone not solve the problem?
    Because a subnet exists in exactly one Availability Zone, and the shortage is zone-bound. Capacity added elsewhere cannot serve launches pinned to the exhausted zone, and workloads that do spread there start crossing zones — changing failure behaviour and adding cross-zone data transfer. Match the zone, then extend the workload's subnet list.
  • What must you check before attaching a secondary CIDR block to a VPC?
    That the range overlaps nothing the VPC already holds and nothing it has routed connectivity to, since overlapping addresses cannot be routed between. Then make sure remote route tables learn the new block — the VPC gets its own local route automatically, but external routes pointing at this VPC do not update themselves.
  • How would you catch this before it becomes a launch failure?
    Alarm on the free-address count per subnet rather than waiting for an error. AWS exposes `AvailableIpAddressCount` on each subnet, so a threshold well above zero gives you a scheduled change window. Pair it with a sizing rule that counts elastic network interfaces, including those managed services create, rather than counting instances.

saying these in an interview costs you the question

  • Suggests editing the subnet CIDR to a shorter prefix
  • Thinks enlarging the VPC CIDR grows existing subnets
  • Adds the replacement subnet in a different Availability Zone
  • Counts only running instances when sizing subnets
  • Adds an overlapping secondary CIDR block

context

resolving links…