Most IPv4 leasing mistakes aren't about finding a clean block or negotiating terms. They're about signing for the wrong size and paying for it two months in - either back on the market under time pressure, or sitting on a block at 30% utilization watching abuse reports accumulate on addresses nobody is using.
This is a practical sizing guide for network operators.
The one thing most operators get wrong
You're not sizing for today. You're sizing for the end of the lease term.
If you're signing a 12-month contract, size for month 10. A block that fits at signing and strains by month six isn't a utilization win - it's a planning failure. Going back to market mid-contract means urgency pricing on a second block, a second onboarding process, and potentially running at degraded capacity in the gap.
That combination costs more than sizing up from the start almost every time.
The four variables
Before matching a use case to a CIDR, get these four things clear.
- Projected utilization rate
Not all IPs in a leased block will be active simultaneously. For some use cases, that's by design. Email operators deliberately keep active sending IP counts lower than total pool size - 50 active senders out of a /24 is normal practice, not waste. Hosting providers run 60-80% utilization intentionally.
The threshold that matters: if your expected steady-state utilization exceeds 85%, size up one increment. No headroom means no room to absorb traffic spikes without reputation or service impact.
- Growth horizon vs. lease term
Size for the end of the contract, not the beginning. If that math produces a block that feels too large right now, a shorter initial term with a planned upgrade often makes more operational sense than locking into a long-term commitment on space you'll immediately strain.
- Reputation management capacity
Larger blocks are harder to monitor. A /19 managed by a three-person infra team is 8,192 addresses that could be generating abuse activity without anyone noticing. Size to what your team can actively oversee. Block reputation directly affects renewal terms and future flexibility - neglect has compounding costs.
- Budget discipline against both failure modes
Idle IPs aren't neutral. A block at 30% utilization is generating probe traffic and abuse exposure across 70% of its address space with no operational value to offset it. The goal isn't maximum capacity - it's right-sized.
Use case notes worth reading
Cloud / BYOIP
AWS, GCP, and Azure all enforce a /24 minimum for BYOIP. This is a hard constraint - a /25 or smaller gets rejected regardless of how clean the block is. No workaround exists.
Beyond the minimum: cloud BYOIP also has specific reputation requirements. 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 for AWS and longer for GCP - and cannot be retried quickly if a block is rejected.
Starting with a dirty block means starting over.
If cloud growth is on your roadmap, size for 12 months from the start. A second BYOIP onboarding mid-project is slower and more painful than it sounds.
Email sending
Inbox providers evaluate reputation at the /24 level. The structural principle: one /24 per sending stream. Transactional mail (receipts, alerts, password resets) on one block, marketing on another. When a campaign triggers a complaint spike, it shouldn't touch transactional deliverability. Mixing them makes reputation management significantly harder and recovery slower.
VPN / proxy
VPN exit nodes structurally attract higher complaint rates - port scanning probes, user policy violations, automated false positives. This isn't an operator negligence problem; it's an architectural one. Your active IP pool needs buffer specifically to absorb reputation incidents without impacting users on clean addresses. A /24 with no buffer gets painful fast after a few incidents shrink the usable pool.
Hosting
At roughly one IP per account, a /23 covers 400-500 accounts at comfortable utilization. Hosting is one of the highest-abuse-risk environments for leased IPv4 - customers send email, run web applications, and occasionally violate AUPs in ways that affect neighboring IPs on the same /24. Per-/24 reputation monitoring isn't optional here. A problem with one tenant's behavior can affect everyone else on the same range.
If you have 150+ current customers, start with a /23. If you expect to reach that within six months, start with a /23 anyway.
A note on block quality vs. block size
These are separate decisions and they get conflated constantly. The cheapest /22 on the market may be cheap for a reason - abuse history, blacklist entries, routing irregularities. Don't trade quality for size to save on the monthly rate. The downstream cost of managing a dirty block - deliverability failures, abuse complaint handling, reputation recovery time - consistently exceeds the savings.
One operational gotcha
If your architecture depends on announcing a /23 as two separate /24s - for geographic diversity, traffic separation, or tenant isolation - verify upstream support before signing. Many networks filter prefixes more specific than /24. It's a valid configuration, but it requires upstream coordination that not all providers offer. Confirm it explicitly rather than assuming.
Quick sizing sanity check
Before committing to a block size, run through this:
Am I sizing for the end of the lease term, not today?
Does my utilization model stay below 85% at steady state?
If I hit 90%+ in month eight, what does going back to market actually cost?
Can my team actively monitor this many addresses?
Do I need IP diversity across customers or services - and would multiple /24s serve that better than one large block?
If any of those questions produce uncomfortable answers, adjust before signing rather than after.
Full use case breakdown, pricing estimates, and the internal justification framing (for when you need to explain this to a finance lead or CTO who doesn't speak CIDR): https://ipbnb.com/blog/ipv4-block-size-guide
Top comments (0)