skip to content

In an AWS VPC, how many usable IP addresses does a /24 subnet give you, and which addresses does AWS reserve in every subnet?

level: middleimportance: should knowfreq 58%

answer

  1. not 256 usable
  2. AWS takes more than the usual two
  3. five gone from every subnet
  4. router and resolver live at base+1 and base+2
  5. 2^(32-mask) minus five

basics

~20 s

AWS reserves five addresses in every VPC subnet — the network address, the VPC router, the DNS resolver, one held for future use, and the last (broadcast) address — so a /24 gives 251 usable addresses, not 256.

solid answer

~40 s

A /24 holds 256 addresses but AWS takes five of them in every subnet, leaving 251. The reserved ones are the first four and the last: the base address itself, base+1 for the VPC router, base+2 for the Amazon-provided DNS resolver, base+3 held for future use, and the final address, which AWS reserves even though broadcast is not supported in a VPC. So in 10.0.1.0/24 the addresses 10.0.1.0 through 10.0.1.3 and 10.0.1.255 are unavailable. The tax matters most at small sizes: a /28 is the smallest subnet a VPC allows and yields only 11 usable addresses, and the largest permitted is /16. It also matters because managed services quietly consume addresses through the elastic network interfaces they place in your subnets, not just the instances you launch yourself.

code

bash · 4 lines
bash
# AWS reports the live count, which already excludes the five reserved addresses
aws ec2 describe-subnets --subnet-ids subnet-0aaa \
  --query 'Subnets[0].[CidrBlock,AvailableIpAddressCount]' --output text
# 10.0.1.0/24    251

go deeper

for a junior

Remember that a /24 yields 251, not 254 or 256, and that AWS reserves the first four addresses and the last one in every subnet.

for a middle

Explain what each reserved address does — network, VPC router, DNS resolver, future use, last address — and derive usable counts with 2^(32-mask) minus five rather than reciting them.

for a senior

Show the operational consequence: elastic network interfaces created by managed services consume the same pool, so size subnets against projected interface count, not instance count, since the CIDR is immutable.

for a principal

Own the standard: what default subnet sizes you mandate across the organisation, how much VPC space you leave unallocated for future tiers, and what you accept as the cost of over-provisioning address space.

## The arithmetic A subnet's CIDR mask fixes how many addresses it contains: a /24 contains 2^(32-24) = 256, a /26 contains 64, a /28 contains 16. AWS then removes **five** addresses from every subnet, regardless of size. Usable count is therefore `2^(32-mask) - 5`: ``` /16 -> 65536 - 5 = 65531 /20 -> 4096 - 5 = 4091 /24 -> 256 - 5 = 251 /26 -> 64 - 5 = 59 /28 -> 16 - 5 = 11 ``` Note this is stricter than the classical convention on a physical LAN, which reserves two (network and broadcast). AWS reserves three more. ## What the five are for Take a subnet `10.0.1.0/24`: - **10.0.1.0** — the network address. Reserved by the same convention as any IP network. - **10.0.1.1** — the **VPC router**. This is the implicit gateway inside every subnet; it is what your instances' default route points at, and it is what actually performs the lookup in the subnet's route table. There is no router appliance you manage; this address is the router. - **10.0.1.2** — the **DNS resolver**. The Amazon-provided DNS server actually lives at the base of the *VPC* CIDR plus two, but AWS reserves base+2 in every subnet so the arithmetic is uniform. This address is what resolves names for instances using the VPC's DNS. - **10.0.1.3** — reserved by AWS for future use. It has never been given a public purpose; you simply cannot have it. - **10.0.1.255** — the last address. Broadcast is not supported inside a VPC at all, but the address is reserved anyway. The last address is the last address of the *subnet*, not of the octet: in `10.0.1.64/26` the reserved pair is `10.0.1.64` and `10.0.1.127`, with `.65`, `.66` and `.67` taken as router, DNS and future-use. ## Why this is an interview question and not trivia Because address exhaustion in a VPC is a real outage, and the five-address tax is one of the reasons a subnet is smaller than people assume. What consumes addresses is broader than most candidates expect: **every elastic network interface (ENI) in the subnet takes one**, and ENIs are created on your behalf by managed services, not only by instances you launch. A stopped EC2 instance still holds its primary private address. Managed databases, load-balancer nodes, and functions attached to a VPC all place ENIs in your subnets. Scale those out across Availability Zones and a /27 that looked generous on a diagram is full in production. The minimum size compounds this. A VPC subnet may be no smaller than /28 and no larger than /16, and a /28 leaves 11 addresses — enough for a handful of interfaces and nothing more. Some AWS services also impose their own floor on top of the five; internet-facing load balancers, for example, require reasonably sized subnets with several free addresses in each Availability Zone they use, because they scale by adding interfaces. If you plan subnets at the minimum, the first scaling event fails. ## Practical sizing guidance Address space inside a VPC is free, so the cost of over-sizing a subnet is only that you consume more of the VPC's CIDR — and the cost of under-sizing it is a migration, because a subnet's CIDR cannot be changed after creation. The usual advice is to make application subnets comfortably larger than the peak interface count you project (often /22 or /20 in a /16 VPC), keep entry-point subnets small but not minimal, and leave unallocated space in the VPC CIDR between them so you can carve more subnets later without adding a secondary CIDR block. One last check worth doing in an interview answer: quote the formula, not the memorised number. `2^(32-mask) - 5` shows you know *why* 251 rather than that you memorised 251.

  • What is the smallest and largest subnet you can create in a VPC, and why does the minimum bite?
    A VPC subnet must be between /28 and /16. A /28 has 16 addresses and only 11 usable after the five reserved, which is easily consumed by a couple of managed-service interfaces. Because a subnet's CIDR cannot be changed later, sizing at the minimum turns the first scaling event into a migration.
  • Besides EC2 instances, what else consumes addresses in a subnet?
    Every elastic network interface in it. Managed services place ENIs into your subnets on your behalf, a stopped instance keeps its primary private address, and an instance with several interfaces or secondary addresses consumes several. Counting only running instances is why capacity estimates come out low.

saying these in an interview costs you the question

  • Says a /24 gives 254 usable addresses
  • Cannot name what the reserved addresses are for
  • Thinks only the network and broadcast addresses are taken
  • Counts only EC2 instances when estimating subnet capacity
  • Believes a stopped instance releases its private address

context

resolving links…