AWS Reserved IP Addresses
When you create a subnet in an Amazon Virtual Private Cloud (VPC), not all IP addresses inside the CIDR range are usable.
AWS reserves 5 IP addresses in every subnet.
Example:
| CIDR | Total IPs | AWS Reserved | Usable |
|---|---|---|---|
| /24 | 256 | 5 | 251 |
| /23 | 512 | 5 | 507 |
| /22 | 1024 | 5 | 1019 |
These reserved addresses are used for routing, DNS services, and AWS infrastructure, and cannot be assigned to EC2 instances or other resources.
Which IP Addresses AWS Reserves
For every subnet, AWS reserves the following five addresses:
| Address | Purpose |
|---|---|
| First IP | Network address |
| Second IP | Reserved for the VPC router |
| Third IP | Reserved by AWS |
| Fourth IP | Reserved by AWS |
| Last IP | Broadcast address |
Example subnet:
CIDR: 10.0.0.0/24
Reserved addresses:
10.0.0.0
10.0.0.1
10.0.0.2
10.0.0.3
10.0.0.255
Usable addresses:
10.0.0.4 – 10.0.0.254
Total usable IPs:
251
Cloud Subnet Reserved IP Comparison
All major cloud providers reserve addresses inside subnets.
| Cloud Provider | Reserved IPs per subnet |
|---|---|
| AWS | 5 |
| Azure | 5 |
| Google Cloud | 4 |
Because of these platform reservations, the usable capacity of a subnet is always smaller than the theoretical CIDR size.
To calculate usable addresses automatically, use the:
This tool accounts for AWS, Azure, and GCP reserved IP behavior.
Why AWS Reserves These Addresses
AWS uses reserved addresses to support core VPC infrastructure services such as:
- VPC routing
- internal DNS
- platform networking services
- control plane infrastructure
These addresses are managed by AWS and are not available for customer workloads.
Why Reserved Addresses Matter for Subnet Planning
Subnet sizing mistakes are a common cause of infrastructure scaling issues.
Because AWS reserves five IP addresses per subnet, smaller subnets may run out of capacity faster than expected.
This is especially important when deploying:
- EC2 instances
- NAT gateways
- load balancers
- container platforms like Amazon EKS
Large environments should avoid using the smallest possible subnet sizes.
Instead, plan for:
- service growth
- additional ENIs
- autoscaling infrastructure
Internal AWS Platform IP Addresses
AWS also relies on several well-known platform addresses that are not part of your subnet but are required for instance functionality.
Blocking these addresses can break instance behavior.
169.254.169.254 — AWS Instance Metadata Service
The IP address 169.254.169.254 provides access to the Instance Metadata Service (IMDS).
IMDS exposes information about the running EC2 instance, including:
- instance identity
- networking configuration
- IAM role credentials
- region and availability zone
- instance metadata
Many automation tools and SDKs rely on this service.
Blocking access to this address can break application behavior and credential retrieval.
AmazonProvidedDNS — VPC DNS Resolver
Each VPC includes an internal DNS resolver located at:
Base VPC CIDR + 2
Example:
VPC CIDR: 10.0.0.0/16
DNS Resolver: 10.0.0.2
This resolver is used for:
- private hosted zones
- AWS service name resolution
- internal DNS within the VPC
Unless custom DNS servers are configured, instances rely on this resolver.
AWS Infrastructure and ENI Consumption
Some AWS services create additional network interfaces inside subnets.
Examples include:
- Application Load Balancers
- Network Load Balancers
- NAT Gateways
- EKS worker nodes
- VPC endpoints
Each of these consumes additional IP addresses through Elastic Network Interfaces (ENIs).
If subnets are undersized, services may fail to deploy or scale.
AWS Subnet Planning Best Practices
To avoid subnet exhaustion:
- avoid extremely small CIDR ranges
- allow buffer capacity for scaling
- consider ENI consumption from managed services
- monitor available subnet IP capacity
This becomes particularly important when running container platforms such as Amazon EKS, where pods may consume additional IP addresses.
To estimate required subnet sizes for container platforms: