Quick navigation: jump to the quarterly IPv4 capacity review
Cloud and SaaS teams usually forecast compute, storage, and bandwidth in detail. Public IPv4 capacity often receives less attention until a deployment is blocked by address availability. That can happen when new regions, customer-isolated environments, NAT gateways, appliances, or allowlisted integrations consume more public addresses than expected.
IPv4 capacity planning should therefore be part of infrastructure forecasting rather than an emergency procurement task.
Why IPv4 demand is easy to underestimate
A single product can consume public addresses in several layers: load balancers, egress gateways, dedicated customer endpoints, VPN infrastructure, monitoring systems, security appliances, and failover environments. The total grows faster when customers require fixed source addresses for allowlisting.
The underlying resource is finite. ARIN notes that its IPv4 free pool was depleted in 2015 and lists transfers, a waiting list, reserved special-use policies, and IPv6 adoption among the options available after depletion.
Build a demand model by workload
Instead of forecasting 'number of IPs' as a single line item, break demand into workload categories. Each category should have a current count, growth rate, redundancy factor, and expected lifetime.
- Customer-dedicated public endpoints.
- Regional ingress and egress infrastructure.
- Static outbound addresses used for partner allowlists.
- Security, VPN, and network-service appliances.
- Disaster-recovery and failover environments.
- Temporary migration capacity.
- Reserved headroom for launches and incident response.
Translate the forecast into prefixes
Once the workload model is stable, translate the requirement into CIDR blocks. A /24 provides 256 addresses, a /23 provides 512, and a /22 provides 1,024. The network team should also consider aggregation, routing policy, and whether the addresses need to be split across regions or autonomous systems.
Teams that do not want to make a permanent acquisition for every growth event can evaluate how to lease IP addresses for a defined period, especially when capacity is linked to customer demand or an infrastructure transition.
Plan for the dependencies around the prefix
A public prefix quickly becomes connected to systems outside the IP address manager. It may be referenced by DNS, security groups, API allowlists, partner portals, monitoring, SIEM rules, documentation, and customer configurations.
That dependency map is essential for continuity planning. The more systems that depend on a prefix, the more expensive renumbering becomes and the more important renewal or migration planning is.
Include routing security in capacity planning
A forecast is incomplete if it answers quantity but not routability. The team should know which ASN will originate each block and who will manage route authorization.
RIPE NCC's RPKI guidance explains the role of Route Origin Authorisations in stating which AS is authorized to originate a prefix. RPKI ownership and change procedures should therefore be part of the procurement checklist.
Reputation and geolocation can affect launch schedules
Public IP addresses can carry historical signals in threat-intelligence, anti-abuse, email, and geolocation databases. Teams should validate the sources that matter to their workload before announcing a production launch date.
Geolocation is particularly important for applications that use IP location as a policy or user-experience signal. Updates across third-party databases may not occur simultaneously, so a migration plan should allow time for legitimate corrections to propagate.
Use IPv6 to reduce future pressure
IPv6 should be part of the same capacity plan. It does not eliminate every IPv4 dependency today, but dual-stack and IPv6-first designs can reduce the amount of new IPv4 required over time. The most resilient strategy is usually to treat IPv4 as constrained compatibility infrastructure while expanding IPv6 wherever product and customer requirements allow.
Quarterly IPv4 capacity review
- Measure utilization by workload and region.
- Forecast 6- and 12-month demand.
- Identify customer requirements for dedicated or allowlisted addresses.
- Map every production dependency on existing prefixes.
- Confirm routing, ROA, rDNS, geolocation, and reputation requirements.
- Compare lease, acquisition, optimization, and IPv6 options.
- Maintain enough headroom to avoid emergency procurement.
Cloud capacity planning works best when address space is treated like any other scarce infrastructure dependency. A repeatable forecast gives engineering and finance teams time to choose the right sourcing model instead of making a rushed decision during a launch.
Teams comparing sourcing paths can also review LARUS's overview of acquiring IPv4 addresses.
