Reserved and internal-use IP addresses in AWS

When you create a subnet in an Amazon Virtual Private Cloud (VPC), not all IP addresses in the CIDR range are available for your workloads. AWS reserves several addresses in every subnet for networking and platform services such as routing, DNS, and infrastructure management.

IP addresses reserved by AWS

In every AWS subnet, Amazon reserves five IP addresses:

  • The first IP address – network address
  • The second IP address – reserved by AWS for the VPC router
  • The third IP address – reserved by AWS
  • The fourth IP address – reserved by AWS
  • The last IP address – broadcast address (not used by AWS, but still reserved)

These addresses cannot be assigned to EC2 instances or other resources.

Example: /24 subnet in AWS

A subnet with CIDR 10.0.0.0/24 contains 256 total IP addresses.

AWS reserves:

  • 10.0.0.0
  • 10.0.0.1
  • 10.0.0.2
  • 10.0.0.3
  • 10.0.0.255

This leaves 251 usable IP addresses for EC2 instances, load balancers, and other AWS services.

Why AWS reserves these addresses

AWS uses the reserved IP addresses to provide core VPC functionality, including:

  • VPC routing and gateway services
  • DNS resolution within the VPC
  • Infrastructure and control plane operations

These addresses are managed by AWS and cannot be repurposed for customer workloads.

Practical implications for subnet planning

Because AWS reserves five addresses per subnet, small subnets can run out of usable IPs faster than expected.

This is particularly important when deploying:

  • Load balancers
  • Container platforms such as ECS and EKS
  • NAT gateways
  • Large numbers of EC2 instances

As with other cloud providers, it is generally safer to size subnets larger than the theoretical minimum.

The usable IP calculator above accounts for AWS’s reserved addresses and shows how many IPs are actually available for your workloads.

Internal-use addresses in AWS

In addition to reserving IP addresses inside each subnet, AWS also relies on well-known internal and link-local IP addresses that are required for platform services and instance functionality.

These addresses are not part of your VPC subnet, but access to them is often required for instances to operate correctly.

Care should be taken when configuring security groups, network ACLs, firewalls, or custom routing to avoid unintentionally blocking access to these addresses.

169.254.169.254 — AWS Instance Metadata Service (IMDS)

The IP address 169.254.169.254 is used by the AWS Instance Metadata Service (IMDS).

IMDS provides information about the currently running EC2 instance, including:

  • Instance identity and metadata
  • Networking configuration
  • Availability zone and region
  • IAM role credentials (via IMDSv2)
  • User data

Many applications, agents, and automation tools rely on IMDS. Blocking access to this address can break functionality related to identity, configuration, and automation.

AmazonProvidedDNS — VPC DNS resolver

Within each VPC, AWS provides a DNS resolver at the base of the VPC CIDR block plus two
(for example, 10.0.0.2 in a 10.0.0.0/16 VPC).

This resolver is used for:

  • Resolving internal AWS service names
  • Resolving private hosted zones
  • Standard VPC DNS functionality

Access to this resolver is required unless you explicitly configure and use custom DNS servers.

Practical guidance

  • These addresses should not be used as destination IPs for customer workloads
  • Access to instance metadata and DNS services is often required
  • Avoid overly restrictive egress rules without explicit exceptions
  • When using firewalls, NACLs, or routing appliances, ensure required AWS service addresses remain reachable

For official documentation, refer to AWS VPC and networking documentation:

https://docs.aws.amazon.com/vpc/latest/userguide/VPC_Subnets.html

Special-purpose subnet considerations in AWS

Unlike Azure, AWS does not require specific subnet names for most services. However, several AWS services impose implicit subnet constraints that can significantly affect usable IP capacity.

These constraints are service-specific and are not reflected in simple usable IP calculations.

Load balancers and ENI consumption

AWS load balancers (Application Load Balancer, Network Load Balancer) create and manage Elastic Network Interfaces (ENIs) inside your subnets.

Key considerations:

  • Each load balancer can consume multiple IP addresses per subnet
  • Scaling events may allocate additional ENIs dynamically
  • Undersized subnets can prevent load balancer scaling or deployment

This is especially relevant in environments with:

  • Multiple load balancers per VPC
  • High availability across multiple Availability Zones

NAT Gateways

NAT Gateways are deployed into a specific subnet and consume IP addresses for their network interfaces.

Key considerations:

  • Each NAT Gateway requires its own ENI
  • High-throughput or multi-AZ designs often require multiple NAT Gateways
  • NAT Gateways are long-lived infrastructure components and should not be placed in small subnets

Amazon EKS and container workloads

Kubernetes clusters using Amazon EKS can place significant pressure on subnet IP capacity.

Key considerations:

  • Each worker node consumes at least one IP address
  • Each pod can consume additional IP addresses depending on the CNI configuration
  • High pod density can exhaust subnet IP space faster than expected

Subnet exhaustion is one of the most common scaling issues in EKS environments.

Practical guidance

  • Treat infrastructure-related subnets differently from application subnets
  • Avoid using minimal subnet sizes for shared infrastructure
  • Plan for dynamic scaling and ENI allocation
  • Monitor available IP capacity in subnets used by managed services

The usable IP calculator provides baseline subnet math. AWS service behavior can further reduce effective capacity and should be considered during design.