IPv4 Strategy for Cloud, AI, and Hosting Providers

Cloud platforms, AI infrastructure operators, and hosting providers face a difficult networking reality: demand for public connectivity keeps growing, but the supply of IPv4 addresses does not.

The Internet Assigned Numbers Authority confirms that its general IPv4 supply has been exhausted. Yet customers, enterprise integrations, legacy applications, security tools, APIs, and network appliances still depend on IPv4 connectivity. IPv6 adoption is essential, but it does not remove the immediate need to support the IPv4 Internet.

For infrastructure providers, IPv4 is therefore more than an address requirement. It is a capacity, continuity, security, and customer-experience issue.

A sustainable IPv4 strategy should answer five questions:

1. How much public IPv4 capacity does the platform actually need?
2. Which workloads require dedicated IPv4 addresses?
3. How will new capacity be obtained without slowing deployment?
4. Who is responsible for routing, reputation, abuse handling, and renewal?
5. How will IPv4 and IPv6 operate together over the long term?

This guide explains how cloud, AI, and hosting providers can build that strategy.

Why IPv4 remains critical for infrastructure providers

IPv4 uses a 32-bit address space. That technical limitation cannot accommodate indefinite growth in Internet-connected services. Available address space is now managed through existing allocations, transfers, leasing, reclamation, and more efficient utilization.

Demand nevertheless remains strong across several infrastructure markets.

Cloud platforms

Public cloud services may require IPv4 addresses for:

- Virtual machines and bare-metal instances
- Public load balancers
- Managed databases and application gateways
- Network address translation gateways
- Customer-controlled firewalls
- VPN and remote-access services
- Multi-cloud and hybrid-cloud connectivity

Customers frequently expect an IPv4 endpoint to be available when they launch a service. If address capacity cannot keep pace with compute capacity, IPv4 becomes a constraint on revenue-producing infrastructure.

AI infrastructure

AI platforms create their own IPv4 requirements. GPU clusters may use private addressing internally, but public addresses are often still required for:

- Inference APIs
- Model-serving endpoints
- AI development environments
- Customer dashboards
- Data-ingestion gateways
- Secure administrative access
- Integration with third-party systems
- Distributed data-processing services

The rapid deployment cycles associated with AI make procurement speed especially important. A platform should not have idle compute capacity because its network team is waiting for usable public address space.

Hosting and data-center services

Dedicated hosting, VPS, colocation, managed infrastructure, and application hosting remain heavily dependent on IPv4. Many customers expect at least one usable public IPv4 address, while services such as managed firewalls, high availability, SSL termination, and specialized appliances can require additional capacity.

IPv4 availability can consequently affect product packaging, customer acquisition, expansion into new locations, and the economics of each server or virtual machine.

Treat IPv4 as an infrastructure portfolio

The first step is to stop treating every address as interchangeable.

An effective portfolio separates IPv4 requirements according to workload, duration, customer value, and failure impact. Providers can classify demand into four broad categories:

- **Core production capacity:** Addresses supporting long-lived services, critical endpoints, customer infrastructure, and workloads that are expensive to renumber.
- **Growth capacity:** Addresses reserved for forecast expansion, new regions, additional servers, or product launches.
- **Elastic capacity:** Addresses used for variable or shorter-term demand.
- **Transitional capacity:** Addresses supporting migrations, acquisitions, renumbering, or dual-stack deployment.

This classification helps the business decide where it needs maximum continuity and where it can accept more operational flexibility.

A production address supporting hundreds of customer workloads should not be sourced under the same controls as temporary development capacity. The cost of an IPv4 arrangement must be compared with the cost of failure—not only with the monthly price per address.

Forecast IPv4 demand from business drivers

Infrastructure providers should connect IPv4 forecasting to measurable commercial activity.

Useful inputs include:

- Number of servers, instances, tenants, or clusters being deployed
- Expected customer growth and churn
- Average address consumption per product
- Regional expansion plans
- Dedicated versus shared-IP product ratios
- Capacity required for high availability
- Utilization and fragmentation within existing blocks
- Addresses reserved for network, broadcast, gateway, or operational purposes
- Quarantine time before an address is reassigned
- Migration and contingency capacity

Forecasting should cover multiple horizons. A rolling 90-day operational forecast supports procurement, while a 12- to 24-month model helps management evaluate leasing, purchasing, address optimization, and IPv6 investment.

Teams should also maintain a capacity buffer. Waiting until the available pool reaches zero turns normal growth into an emergency procurement exercise.

Decide when to lease, buy, or optimize

There is no single sourcing model that fits every provider. Most large operators benefit from a combination of approaches.

Lease IPv4 for scalable, capital-efficient growth

Leasing can be appropriate when a provider needs to:

- Add address capacity without a large upfront purchase
- Launch a new region or service quickly
- Match IPv4 commitments to customer demand
- Preserve capital for compute, storage, GPUs, and network expansion
- Avoid managing a fragmented chain of address suppliers
- Maintain flexibility while long-term demand is uncertain

However, an IPv4 lease should be evaluated as an infrastructure dependency. The provider’s ownership or control of the addresses, renewal terms, routing support, registry position, and operational capabilities matter.

LARUS provides first-party IPv4 leasing from its controlled address pool. Its current service structure allows customers to select capacity-only leasing or add continuity controls covering areas such as routing validity, RPKI/ROA readiness, reverse DNS, abuse workflows, geolocation support, response commitments, and renewal certainty.

Buy when ownership fits the capital strategy

Purchasing may suit organizations with predictable, permanent requirements and the resources to manage transfer, registry, compliance, routing, security, and lifecycle obligations.

The purchase price is only one part of the decision. Buyers should assess:

- Regional Internet Registry requirements
- Title and transfer documentation
- Address history and reputation
- Route authorization
- Ongoing registry responsibilities
- Internal governance
- The future cost of holding underutilized space

Ownership can provide long-term economic value, but it also concentrates administrative and registry-related responsibilities within the operating company.

Optimize existing space before adding capacity

Providers should regularly audit their existing allocations for:

- Unused customer assignments
- Oversized subnets
- Abandoned development environments
- Addresses retained after service termination
- Duplicate reservations
- Poor allocation records
- Fragmentation preventing efficient reassignment

Optimization is worthwhile, but it has limits. Aggressive address reuse can increase operational overhead and create reputation problems if addresses move between customers without suitable review and quarantine.

Organizations holding more IPv4 than they need may also consider selling unused resources. LARUS operates as a direct first-party buyer of IPv4 address space and supports structures in which an organization sells a block and leases back the capacity it still requires.

Make continuity part of procurement

Address availability alone does not make a block production-ready.

Before placing leased or acquired IPv4 space into service, a provider should confirm:

- The party supplying the addresses has the authority to do so
- The permitted use is clearly documented
- The required prefix can be announced from the provider’s ASN
- Route Origin Authorizations can be created and maintained
- Reverse DNS can be delegated or managed
- Geolocation records can be corrected where necessary
- Abuse reports have an established response path
- Renewal and termination terms match the workload
- The process for returning or renumbering addresses is understood
- Support escalation routes and response expectations are documented

The objective is to reduce the number of dependencies between the contract and the live network.

This is one reason first-party sourcing is important. Leasing through multiple intermediaries can create uncertainty about ownership, authorization, renewal, and responsibility when an operational problem occurs. LARUS positions its leasing model as a direct first-party relationship, with LARUS remaining responsible for the underlying resource and continuity layer.

Protect routing with RPKI and ROAs

A valid commercial agreement does not automatically create a secure routing configuration.

Resource Public Key Infrastructure, or RPKI, allows a resource holder to authorize an autonomous system to originate a prefix. The resulting Route Origin Authorization identifies the permitted origin ASN and maximum prefix length. The technical role of ROAs is described in the IETF’s RPKI specifications.

For cloud, AI, and hosting providers, the onboarding process should include:

1. Confirming the originating ASN
2. Creating or updating the applicable ROA
3. Checking the authorized prefix length
4. Validating the route before production use
5. Monitoring for invalid or unexpected announcements
6. Updating authorization before any routing migration
7. Removing obsolete authorization after offboarding

RPKI should be combined with route monitoring, prefix filters, documented change control, and multi-party verification for sensitive routing changes.

Manage reputation as an operational asset

An IPv4 address can be technically routable but commercially unusable if its reputation is poor.

Cloud and hosting environments are frequent targets for spam, credential abuse, malware, scanning, phishing, and other prohibited activity. AI platforms can face additional risks involving automated account creation, proxy misuse, scraping, or unapproved bulk activity.

Providers should evaluate both the history of incoming address space and the behavior of new customers.

A practical reputation program includes:

- Pre-deployment checks against relevant reputation sources
- Clear acceptable-use policies
- Customer identity and risk controls
- Automated detection of abnormal traffic
- Dedicated abuse contacts
- Evidence-based incident handling
- Address quarantine before reassignment
- Accurate forward and reverse DNS
- Processes for correcting geolocation and reputation records
- Documentation of remediation actions

Reputation is not a one-time onboarding check. It must be managed throughout the address lifecycle.

Use shared IPv4 selectively

NAT and carrier-grade NAT can reduce public address consumption, but they should be applied according to the workload.

Shared IPv4 can work well for outbound client traffic, internal services, development environments, and workloads that do not require a unique inbound endpoint. The shared address space reserved for carrier-grade NAT is defined in [RFC 6598].

Dedicated public IPv4 may still be necessary when customers need:

- Inbound connections
- Stable allowlisting
- Customer-controlled DNS
- Independent email reputation
- Protocols that do not behave well through NAT
- Direct server administration
- Compliance-driven traffic separation
- A unique endpoint for a hosted service

The aim should not be to maximize address sharing at all costs. Providers should use the architecture that gives each product an acceptable balance of address efficiency, observability, supportability, and customer experience.

Adopt IPv6 without assuming IPv4 disappears

IPv6 is the long-term answer to address scarcity. Every cloud, AI, and hosting provider should have an active IPv6 roadmap.

That roadmap may include:

- Dual-stack management and customer networks
- IPv6 support for load balancers and APIs
- IPv6-enabled Kubernetes and container platforms
- IPv6 monitoring, logging, and security controls
- Customer documentation and migration tools
- IPv6-capable DNS and automated provisioning
- IPv6 support across billing and address-management systems

However, dual stack can increase operational complexity because teams must secure, monitor, troubleshoot, and document both protocols. IPv6 adoption should therefore be treated as an engineering program, not simply as an address-allocation exercise.

For the foreseeable future, many providers will need an integrated strategy: IPv6 for scale and architectural modernization, combined with dependable IPv4 for universal reachability and customer compatibility.

Build an IPv4 control plane

As a provider grows, spreadsheets and informal ticket workflows become risky. IPv4 capacity should be governed through an integrated control plane or IP address management system.

At minimum, the system should track:

- Prefix and address inventory
- Ownership or lessor information
- Region and RIR
- ASN and routing status
- ROA status
- Customer or workload assignment
- Reverse DNS authority
- Geolocation
- Reputation events
- Lease start, renewal, and end dates
- Utilization
- Quarantine and reassignment history

Commercial and network records should agree. A renewal date that exists only in the procurement team’s inbox is an operational risk.

Alerts should be generated well before capacity thresholds, contract deadlines, ROA expirations, routing changes, or customer migrations require action.

A practical IPv4 strategy checklist

Cloud, AI, and hosting providers can use the following checklist when developing their address strategy:

- Segment address demand by workload and failure impact
- Maintain 90-day and long-term capacity forecasts
- Establish minimum reserve thresholds
- Audit current utilization and reclaim genuinely unused space
- Select leasing or purchasing according to duration, capital, and risk
- Verify the supplier’s authority and the commercial chain
- Document renewal, termination, and renumbering conditions
- Validate reputation before deployment
- Create and monitor appropriate ROAs
- Define rDNS, geolocation, and abuse-handling responsibilities
- Match support commitments to the cost of service failure
- Introduce IPv6 systematically while preserving IPv4 compatibility
- Keep network, customer, and commercial inventory synchronized
- Review the strategy whenever the company launches a region, product, or major customer deployment

IPv4 capacity should support growth—not limit it

For cloud, AI, and hosting providers, IPv4 scarcity is not solved by a single purchase, a temporary lease, or an IPv6 announcement. It requires an operating model that connects capacity planning, sourcing, routing, reputation, security, renewals, and protocol modernization.

The strongest strategy is one in which the business knows how much IPv4 it needs, which services truly require it, where the addresses come from, how they are protected, and what happens if demand or suppliers change.

LARUS supports infrastructure providers with first-party IPv4 leasing and Continuity Assurance. Capacity Only, Production, Enterprise, and Critical options allow organizations to align operational controls with the importance of each deployment.

To discuss block size, deployment geography, ASN requirements, routing, continuity, or renewal needs, contact LARUS or email : sales@larus.net.

Frequently asked questions

1. Why do cloud providers still need IPv4?

Cloud providers need IPv4 because many users, enterprise networks, applications, appliances, and third-party integrations are not yet reachable over IPv6 alone. Public IPv4 endpoints preserve compatibility across the wider Internet.

2. Is leasing IPv4 suitable for production infrastructure?

Yes, provided the lease includes appropriate authority, routing support, renewal terms, reputation controls, and operational responsibilities. Production workloads should be matched to a continuity level based on their cost of failure.

3. How do AI platforms use public IPv4 addresses?

AI platforms may use public IPv4 for inference APIs, dashboards, development environments, data gateways, partner integrations, and secure administration. Internal GPU traffic can often remain on private or IPv6 networks.

4. Should a hosting company lease or buy IPv4?

The answer depends on demand duration, capital availability, internal expertise, and desired flexibility. Leasing can support rapid, capital-efficient growth, while purchasing may suit stable long-term requirements. Many providers use both.

5. Does IPv6 eliminate the need for an IPv4 strategy?

Not yet. IPv6 is essential for long-term scale, but providers must continue supporting IPv4-dependent customers and systems. A dual-stack strategy combines future readiness with current compatibility.

6. What should an IPv4 provider support besides address capacity?

Production providers should consider routing authorization, RPKI/ROA operations, reverse DNS, geolocation, reputation, abuse response, support commitments, renewal certainty, and clear escalation procedures.