Usable IP Calculator

Cloud subnet calculators often show total IP addresses, but cloud providers reserve part of every subnet for internal services. This usable IP calculator shows how many IP addresses you can actually use in Azure, AWS, and GCP subnets.

How this calculator works

This tool takes an IPv4 CIDR prefix (for example 10.0.0.0/24) and calculates:

• Network address and broadcast address
• Netmask (dotted decimal)
• Total addresses in the range (2^(32-prefix))
• Reserved addresses (based on the selected model)
• Usable addresses (total minus reserved)
• First/last usable IP (when applicable)

The math is performed locally in your browser. Nothing is sent to a server.

What “usable IPs” means

In “classic” subnetting, the network and broadcast addresses are not usable as host IPs.
In cloud environments, providers may reserve additional addresses inside the subnet for platform services.

That’s why the same CIDR can have different “usable IP” counts depending on where you deploy.

Reserved IPs in cloud subnets

Cloud providers reserve IP addresses inside each subnet/VPC/VNet to run platform services (routing, DNS, internal infrastructure). This section summarizes the common reserved-address behavior and how the calculator models it.

Note: Some managed services may impose additional subnet requirements (minimum sizes, dedicated subnets, etc.). Always validate against the specific service you’re deploying.

Microsoft Azure reserved IPs

In Azure VNets, Azure reserves five IP addresses per subnet:

• The first four IPs in the subnet
• The last IP in the subnet

Example: 10.0.0.0/24 has 256 total addresses, but 5 are reserved → 251 usable.

This is why small subnets can become painful quickly when you add private endpoints, load balancers, app gateways, and other services that consume IPs.

Amazon Web Services (AWS) reserved IPs

In AWS VPC subnets, AWS also reserves five IP addresses per subnet. The reserved addresses include:

• The network address
• The broadcast address
• Additional addresses used for AWS platform services (commonly including routing and DNS)

Example: 10.0.0.0/24 has 256 total addresses → 251 usable in the typical AWS model.

Google Cloud (GCP) reserved IPs

In Google Cloud VPC subnets, Google reserves addresses for platform services as well. The exact internal use differs by implementation, but the common “cloud subnet” planning model is similar: expect fewer usable IPs than the total CIDR count.

For practical subnet sizing, this calculator applies a cloud-style reserved-address model for GCP when you select the GCP option.

Generic (classic subnetting) model

If you select Generic, the calculator uses traditional subnet behavior:

• /0–/30: reserves 2 addresses (network + broadcast)
• /31 and /32: treated as having 0 reserved (point-to-point / single host cases)

This is useful when you’re doing “pure” networking math without cloud-specific reservations.

FAQ

Why does this calculator exist when others already do?

Many subnet calculators show total addresses only. This tool focuses on usable IPs in cloud environments, where additional addresses are reserved and small subnets often fail in practice.

Why does /27 not give me “30 usable IPs” in cloud?

Because cloud providers often reserve more than just network and broadcast. With 5 reserved addresses, a /27 (32 total) typically leaves 27 usable, not 30.

Should I use very small subnets like /30, /31, or /32?

Be careful. Even if the math works, many cloud services require larger subnets or have constraints that make very small subnets impractical. When in doubt, size up.

Does this tool validate provider-specific service requirements?

No — it models common reserved-address behavior. Service-specific constraints (for example, dedicated subnets or minimum size requirements) should be checked in provider documentation.

Subnet sizing rule of thumb

If you’re subnetting for real workloads (private endpoints, AKS, app gateways, etc.), avoid micro-subnets. A safe starting point is often:

• /24 for “general purpose” subnets where growth is expected
• /26 or /27 only for tightly controlled, low-IP workloads
• Prefer leaving headroom rather than re-IP’ing later