IPv4 Subnet Sizing Guide: How to Choose the Right Block Size for Your Use Case

There are two ways to get IPv4 block sizing wrong, and both are expensive.

The first is leasing too small. You estimate conservatively, the project scales faster than expected, and by month four of a six-month contract you're back on the market under time pressure - paying a premium for urgency, absorbing the operational cost of onboarding a second block, and running at degraded capacity in the gap between.

The second is leasing too large. The block sits at 30% utilization. You're paying for idle addresses every month, and those idle addresses aren't neutral - they accumulate probe traffic, generate abuse reports from automated scanners, and quietly drag down the reputation of the active IPs sitting next to them.

The right size comes from matching three things: your use case, your growth horizon, and a handful of operational constraints that aren't obvious until someone explains them. That's what this guide does.

If you need a primer on how IPv4 leasing works technically before sizing, start here: how IPv4 leasing works →

IPv4 block size at a glance

Budget and pricing

Lease rates scale roughly linearly with block size - a /22 costs approximately four times a /24 at the same per-IP rate, because it contains four times the addresses. A /22 typically runs $400-550/month; a /21, $800-1,100/month.

The more relevant comparison is the monthly rate against the cost of getting the size wrong: an emergency second block acquired mid-project - with urgency pricing and a second onboarding process - consistently costs more than sizing up from the start. For exact pricing based on size, region, and availability: IPv4 pricing calculator →

The four variables that drive your sizing decision

Before matching a use case to a block size, you need a framework. These four variables determine the right answer in every scenario.

Projected utilization rate

Not all IPs in a leased block will be active simultaneously - and in some use cases, that's intentional. Hosting providers typically run 60-80% utilization. Email senders deliberately keep active IP counts lower to protect sender reputation: a pool of 50 active sending IPs out of a /24 is normal practice, not waste. The practical rule is straightforward: if your expected steady-state utilization exceeds 85%, size up one increment. Running a block near capacity leaves no room to absorb traffic spikes without impacting reputation or service quality.

Growth horizon vs. lease term

A block should be sized for the end of the lease term, not the beginning. If you sign a 12-month contract today, size for month 10 of that contract - not for what you need right now. If that math produces a block that feels too large for your current state, consider whether a shorter initial term with a planned upgrade makes more operational sense than a long-term commitment on space you'll immediately strain.

Reputation management capacity

Larger blocks are harder to monitor. A /19 (8,192 addresses) managed by a three-person infrastructure team means thousands of IPs that could be generating abuse activity without anyone noticing. Size to what your team can actively oversee. IPbnb provides 24/7 abuse monitoring as part of every lease - which meaningfully raises the ceiling of what a small team can handle - but platform monitoring doesn't replace your own operational oversight. Block reputation directly affects lease renewal terms and future flexibility, so neglecting it has compounding costs.

Budget discipline

Lease rates scale roughly linearly with block size. A /22 costs approximately four times a /24 at the same per-IP rate. The question isn't just what size you need - it's what under-sizing would cost if you need an emergency second block, versus what over-sizing costs per month in idle address spend. In most cases, sizing correctly from the start is cheaper than either failure mode.

Sizing by use case

Hosting provider / shared hosting

Recommended: /23 to /21

Shared hosting assigns roughly one IP per customer account, with some accounts needing additional IPs for SSL certificates, dedicated sending domains, or tenant isolation. A /23 (512 addresses) covers approximately 400-500 accounts at comfortable utilization. Growth typically comes in /23 increments as customer count rises.

Hosting is one of the highest-abuse-risk environments for leased IPv4. Customers send email, run web applications, and occasionally violate acceptable use policies in ways that affect the reputation of neighboring IPs in the same /24. This makes per-/24 reputation monitoring particularly important - a problem with one customer's behavior can affect everyone else on the same range. IPbnb's abuse monitoring covers this at the platform level, but the hosting operator still needs clear customer-facing acceptable use terms and a fast internal response process for complaints.

The common mistake: leasing a /24 to launch a hosting business, assigning IPs to 200 accounts, and discovering there's no room left for growth without going back to market. If you have 150 or more current customers, start with a /23. If you expect to reach that within six months, start with a /23 anyway.

See available /23 and /22 blocks →

Cloud deployment / BYOIP

Recommended: /24 minimum; /23 or /22 for multi-region or multi-service deployments

AWS, GCP, and Azure all enforce a /24 minimum for BYOIP. This is a hard constraint - a /25 or smaller will be rejected by the cloud provider's onboarding process regardless of how clean the block is. There is no workaround.

Beyond the minimum: a single /24 is sufficient for one service in one region. If you're deploying across multiple regions, running services that need reputation isolation from each other, or scaling a customer-facing product, a /23 or /22 gives room to segment workloads without returning to market mid-deployment.

The cloud BYOIP use case has specific reputation requirements beyond standard leasing. AWS explicitly reserves the right to reject prefixes with poor history. Block reputation needs to be verifiable before you start the cloud provider's validation process, which can take one to two weeks - and GCP onboarding typically runs longer - and cannot be retried quickly if a block is rejected. Starting with a block that fails validation means starting over.

The common mistake: leasing the minimum /24 for a cloud deployment that will grow, then discovering mid-project that expansion requires a separate block, a separate LOA, and a new BYOIP onboarding process with the cloud provider. If cloud growth is on your roadmap, size for 12 months of growth from the start.

For the full provider-by-provider setup requirements: BYOIP with leased IPv4 on AWS, GCP, and Azure →

ISP / small telco

Recommended: /21 to /18 depending on subscriber count

ISPs assign IPs to subscribers: business customers typically get one or a small block of dedicated addresses, residential subscribers share IPs through NAT. Block size follows subscriber count and growth projections rather than a fixed formula.

A working starting point: at one IP per business subscriber and 8:1 NAT for residential, a /21 (2,048 addresses) supports roughly 500-800 business subscribers, or a mixed base of several thousand residential subscribers. Scale up in /21 or /20 increments from there.

ISPs typically sign longer lease terms than other operator types - annual contracts are standard. This makes initial sizing especially consequential. Under-sizing on a 12-month contract means either running at the edge of capacity for the contract duration or negotiating a block addition mid-term, which adds cost and operational complexity.

The common mistake: sizing for today's subscriber count without accounting for the onboarding pipeline. If you have 200 active customers today and 80 deals in progress, size for 280 - not 200.

Clean IPv4, ready to deploy

Lease Clean IPv4 Fast With Zero Platform Fees

Start leasing

VPN operator / privacy proxy service

Recommended: /22 to /20

VPN and proxy operators need geographic and reputational diversity across exit nodes, and often need to rotate IPs as individual addresses accumulate reputation incidents. A /22 (1,024 addresses) provides enough range for meaningful rotation and diversity for small to mid-size deployments.

VPN traffic generates a structurally higher rate of abuse complaints than most other use cases - not because of operator negligence, but because exit nodes attract port scanning probes, user policy violations, and automated false positives. This makes active monitoring and fast abuse response non-negotiable. It also means the block needs buffer above the active IP count specifically to absorb reputation incidents without impacting users on clean addresses.

A note on acceptable use: some platforms restrict or require pre-approval for VPN and proxy use cases. Verify before you sign. IPbnb's team can advise on compatible configurations and acceptable use parameters during onboarding.

The common mistake: leasing a /24 for a VPN service without buffer. After a few abuse incidents affect several IPs, the usable pool shrinks to the point where active users feel the impact.

Browse /22 blocks for VPN deployments →

Email sending / ESP infrastructure

Recommended: /24 per sending pool

Email reputation is evaluated at the /24 level by most major mailbox providers. A dedicated /24 per sending stream - transactional email, marketing email, domain-specific sending - isolates reputation damage between pools. Mixing sending types on shared IPs means a deliverability problem with one stream affects all of them.

Sizing for email is about isolation more than quantity. Most sending operations don't need 256 active IPs - they need clean, dedicated, properly warmed IPs assigned to specific purposes. A /24 per pool, warmed gradually to full sending volume, is the right structural approach.

The common mistake: leasing one large block and routing all email traffic through it. When a marketing campaign triggers a spam complaint spike, it hits transactional mail on the same addresses - and transactional deliverability is far harder to recover than marketing.

For a detailed breakdown of what IP reputation monitoring looks like in practice: IP reputation tools and best practices →

SaaS / API-heavy application

Recommended: /24

SaaS workloads typically need clean, stable IPs for API authentication, outbound webhooks, and allow listing by enterprise customers. IP stability matters more than quantity here. A single /24 is sufficient for most SaaS teams running in one region.

One important separation: if the product also sends transactional email - receipts, alerts, password resets - use a dedicated /24 for that traffic, separate from API traffic. Mixing the two on the same IPs makes reputation management significantly harder, because the risk profiles of API traffic and email traffic are different and require different monitoring approaches.

Browse clean /24 blocks for SaaS deployments →

Data center / colocation operator

Recommended: /21 to /20

Data centers assign IPs to customer servers and services. A /21 (2,048 addresses) covers a mid-size colocation footprint. For multi-tenant environments, consider whether leasing several /22s gives more operational flexibility than a single large block - non-contiguous /24 ranges can be assigned per-customer for better isolation, which simplifies reputation management and limits blast radius when a single tenant causes problems.

The common mistake: assuming one large contiguous block is always simpler to manage than multiple smaller ones. At data center scale, per-customer IP isolation often outweighs the administrative convenience of a single large prefix.

See /21 and /20 blocks available →

Short-term project / testing / staging

Recommended: /24, month-to-month

For temporary workloads - load testing, staging environments, short-term infrastructure experiments - a /24 provides enough address space for most use cases without over-commitment. Month-to-month terms with no minimum keep exit costs low and give you full flexibility to return the block when the project ends.

Confirm the platform supports short flexible terms before signing. IPbnb supports month-to-month leasing with no long-term commitment required.

Browse month-to-month /24 blocks →

Quick reference: block size by use case

What happens when you choose the wrong size

Getting the size wrong in either direction has a predictable cost.

Too small: You return to market under time pressure. In the RIPE region, sourcing and onboarding an additional block mid-project takes time - and urgency means paying a premium. Running at capacity in the gap affects service quality and IP reputation. The cost of correcting an undersized block mid-contract almost always exceeds the cost of sizing correctly from the start.

Too large: Idle addresses aren't neutral. A block running at 20-30% utilization generates probe traffic and abuse reports across the unused range, creating reputation risk with no operational value to offset it. In the RIPE region, operators are expected to demonstrate efficient address space use - an underutilized block can complicate renewal negotiations and invite scrutiny you'd rather avoid.

How to justify your sizing decision internally

Most sizing decisions involve someone who isn't a network engineer - a finance lead, a CTO, a procurement manager who wants to understand why a specific block size was requested before approving the spend. These three framings translate well across technical and non-technical stakeholders.

The cost of under-sizing. Returning to market mid-project means paying for a second block at urgency rates, absorbing a second onboarding process, and potentially running at degraded capacity in between. The cost of sizing correctly upfront is almost always lower than the cost of fixing a shortage mid-contract. If you're being pushed toward a smaller block to save on monthly spend, price out what an emergency block acquisition would cost - in fees, operational time, and project delay - and compare the two numbers.

The cost of over-sizing. Idle IPs cost money and create risk. A block sitting at 30% utilization is generating abuse exposure across 70% of its address space with no revenue or operational value to offset it. Finance teams respond well to the argument that idle address space is a liability, not a buffer. The goal is not maximum capacity - it's the right capacity.

The occupancy model. Frame the sizing decision the way a property manager frames building occupancy: target 70-80% utilization at steady state, with headroom for peaks or growth. Below 60% is wasteful; above 90% creates operational risk and leaves no margin for error. This model gives non-technical stakeholders a clear mental framework for evaluating the request - and it makes the reasoning auditable if the decision is ever revisited.

IPv4 Pricing Calculator

See exactly what you pay. No hidden fees or markup.

Open calculator

Four sizing mistakes worth avoiding

Sizing for today, not for the end of the lease term. Block size should reflect utilization at month 10 of a 12-month lease. A block that fits perfectly on day one but strains by month six is a planning failure with a predictable cost.

Confusing block size with block quality. The cheapest /22 on the market may be cheap for a reason - abuse history, blacklist entries, routing irregularities. Block size and block reputation are separate decisions. Don't trade quality for size to save on the monthly rate. The downstream costs of managing a dirty block - deliverability failures, abuse complaint handling, reputation recovery time - consistently exceed the savings.

For a full breakdown of what to check before leasing: six common IPv4 leasing mistakes →

Planning to split a leased block into sub-/24 announcements without verifying upstream support. Many networks filter prefixes more specific than /24. If your plan depends on announcing a /23 as two separate /24s - for geographic diversity or traffic separation - confirm your upstream explicitly supports this before signing. It's a valid configuration, but it requires upstream coordination that not all providers offer.

Leasing one large block when multiple smaller blocks would serve better. For use cases that need IP diversity across customers, services, or geographies - hosting, data centers, VPN - several /24s or /23s often outperform a single /21 in reputation isolation and operational flexibility. Consolidation looks simpler on paper. In practice, segmentation reduces blast radius when something goes wrong.

Getting the size right upfront eliminates two of the most common and most avoidable costs in IPv4 leasing. Most teams either know roughly what they need and need confirmation, or they've made a sizing mistake before and want a framework to avoid repeating it. Either way, the use case table and the four-variable framework give you what you need to make a defensible decision and move forward.

Browse available IPv4 blocks by size and region on IPbnb, or estimate your lease cost before committing: IPv4 pricing calculator →