Why AWS Reserves 5 IPs Per Subnet (and how to plan around it)

If you have ever created a tiny /28 subnet in AWS expecting 14 usable addresses and only got 11, you have run into one of the more confusing parts of AWS VPC design. AWS reserves five IP addresses in every subnet you create. Two are the standard network and broadcast addresses you would expect on any IPv4 subnet; the other three are AWS-specific reservations used by the platform itself.

This article explains exactly which addresses AWS reserves, why those choices were made, the implications for subnet sizing, and how to plan VPC capacity so you do not run into ENI exhaustion under load. If you are starting a greenfield VPC design, you can run the numbers in our Cloud subnet calculator with AWS mode enabled.

The five reserved addresses, explained

In any AWS subnet, regardless of size, these five addresses are not available to assign to your EC2 instances, ENIs, Lambda functions, or anything else:

For a /24 subnet at 10.0.0.0/24, the reserved addresses are 10.0.0.0, 10.0.0.1, 10.0.0.2, 10.0.0.3, and 10.0.0.255. That leaves 251 usable addresses instead of the 254 you would expect on a non-AWS network.

Why three AWS-specific reservations?

The .1 address being the gateway is intuitive: every subnet needs a default gateway, and AWS picked the first usable address. The .2 reservation for the Amazon-provided DNS resolver (the one your VMs reach at 10.0.0.2 if your VPC is 10.0.0.0/16) is more AWS-specific. Without an integrated resolver, you would need to deploy and manage DNS servers in every VPC. The .3 address is reserved for future use but has been unused for over a decade. AWS has not removed it because doing so would change the behavior of millions of existing VPCs.

The practical consequence: on small subnets, the AWS overhead is significant. A /28 has 16 total addresses and only 11 are usable — that is a 31% loss to reserved addresses. By contrast, a non-cloud /28 would give you 14 usable.

The /28 minimum and the /16 maximum

AWS enforces a minimum subnet size of /28. Below that, the platform refuses to create the subnet. The rationale is the math above: /29 (8 total addresses) would leave only 3 usable after the 5 reservations, which is too tight for any real workload.

The maximum subnet size is /16 (65,536 addresses). Larger subnets are not supported even if your VPC itself is bigger — for example, a /15 or /14 VPC must be carved into multiple /16-or-smaller subnets.

The hidden cost: ENIs, not just instances

The single biggest mistake in AWS subnet sizing is planning for the number of EC2 instances rather than the number of ENIs (Elastic Network Interfaces). Several AWS services create ENIs dynamically in your subnets, each consuming one address from the pool.

• EC2 instances consume 1 ENI per instance by default, but larger instance types support multiple ENIs and many secondary IPs.
• Lambda functions in a VPC create Hyperplane ENIs on cold start. At high concurrency the pool can drain quickly.
• AWS Fargate tasks each get their own ENI.
• RDS, ElastiCache, ELB, MSK, OpenSearch all create ENIs in your subnets when they launch.
• EKS pods using the VPC CNI plugin consume ENIs and secondary IPs from your VPC. See our article on EKS VPC CNI prefix delegation for the deep dive.

A subnet sized correctly for 100 EC2 instances can run out of addresses with only 30 EC2 instances if you are also running Lambda, Fargate, and RDS in the same subnet.

How to plan VPC capacity properly

The general rule for production AWS workloads: plan for 4-10x your expected peak ENI count. A /24 subnet (251 usable) comfortably supports about 50 mixed workloads (instances + Lambda + Fargate + managed services). A /22 (1,019 usable) supports about 250.

A typical greenfield three-tier production VPC looks like this:

10.0.0.0/16                       # VPC (65,531 usable)
+-- 10.0.0.0/20    (4091)         # web-tier-az-a
+-- 10.0.16.0/20   (4091)         # web-tier-az-b
+-- 10.0.32.0/20   (4091)         # web-tier-az-c
+-- 10.0.48.0/20   (4091)         # app-tier-az-a
+-- 10.0.64.0/20   (4091)         # app-tier-az-b
+-- 10.0.80.0/20   (4091)         # app-tier-az-c
+-- 10.0.96.0/24   (251)          # db-tier-az-a (small, RDS only)
+-- 10.0.97.0/24   (251)          # db-tier-az-b
+-- 10.0.98.0/24   (251)          # db-tier-az-c
+-- 10.0.99.0/28   (11)           # tgw-attachment-az-a
+-- 10.0.99.16/28  (11)           # tgw-attachment-az-b
+-- 10.0.99.32/28  (11)           # tgw-attachment-az-c
+-- 10.0.100.0/22  (1019) onward  # reserved for future

This gives every workload tier enough headroom for serverless and managed-service ENIs to grow into, while keeping database and transit subnets appropriately small. You can model this exact layout in our VLSM Designer and export it as Terraform with the IaC Export tool.

What happens when you run out of IPs?

This is the failure mode every AWS architect dreads. When a subnet has no free addresses left:

• New EC2 launches fail with InsufficientFreeAddressesInSubnet
• Lambda cold starts fail; concurrency drops to zero
• Fargate tasks fail to launch
• RDS/ElastiCache scale-up operations fail
• EKS pod scheduling fails (with VPC CNI)

The fixes are all painful at production scale:

1. Add a secondary CIDR to the VPC. Up to 4 secondary CIDRs are allowed, including from CGNAT space (100.64.0.0/10). Newer subnets can use the secondary range.
2. Re-IP affected workloads to larger subnets. Requires recreating ELBs, sometimes Auto Scaling groups, and is a maintenance window operation.
3. Migrate EKS clusters to use VPC CNI prefix delegation (which packs 16 pods per ENI instead of 1 per IP) and/or move pods to a CGNAT secondary CIDR.

Comparison with other clouds

AWS is not alone in reserving addresses, but it reserves the most. Here is how the major clouds compare:

For multi-cloud organizations, plan address space with the AWS reservation count in mind even for non-AWS subnets — it gives you uniform sizing rules and makes peering planning simpler. See our article on multi-cloud VPC peering for the full org-level allocation chart.

Key takeaways

• AWS reserves 5 IPs per subnet: .0, .1, .2, .3, and last.
• The smallest subnet you can create is /28, giving 11 usable addresses.
• Plan for ENI count, not instance count — Lambda, Fargate, and managed services consume ENIs from your subnets dynamically.
• Use /20 or /22 for production workload tiers, /24 for databases, /28 for transit and gateway endpoints.
• Secondary CIDRs (including CGNAT space) are the standard fix when a VPC runs low on addresses.

If you want to model an AWS subnet design before applying it, our Cloud calculator handles the 5-IP reservation automatically and shows you what is actually usable.