IPv4 Planning for AI Infrastructure and GPU Cloud Providers

AI infrastructure planning often begins with GPUs.

Operators compare accelerator models, cluster size, power density, cooling, storage throughput, interconnect performance, and data-center capacity. These decisions are essential, but they do not complete the infrastructure plan.

A GPU cloud also needs a reliable addressing strategy.

Customers must reach inference APIs, training environments, management portals, gateways, storage services, observability platforms, VPN endpoints, and other public-facing infrastructure. The platform itself may need predictable outbound identities for software repositories, customer allowlists, security services, and data-transfer workflows.

IPv4 planning should therefore begin before GPU capacity enters production.

The correct question is not:

How many public IP addresses does each GPU require?

Most GPU workers should not be directly exposed to the public Internet.

The better question is:

Which platform boundaries, customer services, and operational functions require stable public IPv4 identity?

That distinction helps AI infrastructure providers conserve addresses without placing critical services behind an improvised or fragile network design.

AI Infrastructure Is More Than Compute

A GPU cloud platform is not simply a collection of accelerator servers.

A production environment may include:

GPU worker nodes

CPU control and orchestration nodes

Kubernetes or another workload scheduler

• High-performance storage
• Container registries
• Training-data ingestion systems
• Inference gateways
• Customer dashboards
• Authentication services
• VPN or private-connectivity gateways
• Monitoring and logging systems
• Billing platforms
• Support and administration tools
• Internet-facing load balancers

Many GPU environments use Kubernetes-based orchestration. Kubernetes assigns addresses to pods and creates stable service addresses while the underlying workloads may change. External access is normally delivered through Services, load balancers, Ingress, or Gateway implementations rather than by exposing every pod directly.

NVIDIA’s cloud-native tooling similarly treats networking as an integrated part of scale-out GPU infrastructure. Its Network Operator works alongside the GPU Operator to provision components needed for high-throughput, low-latency GPU clusters.

This produces two different addressing environments:

East-west networking

East-west traffic moves inside the AI cluster or between internal services.

Examples include:

• GPU-to-GPU communication
• Worker-to-storage traffic
• Distributed training traffic
• Scheduler-to-node communication
• Internal monitoring
• Service-to-service API calls

This layer normally uses private address space, internal routing, virtual networking, or specialized cluster fabrics.

North-south networking

North-south traffic enters or leaves the platform.

Examples include:

• Public inference APIs
• Customer SSH or remote desktop access
• Web dashboards
• VPN gateways
• Internet-facing load balancers
• Software and model downloads
• Customer data uploads
• Outbound access to third-party platforms

This is where public IPv4 planning becomes commercially and operationally important.

Why GPU Cloud Providers Still Need IPv4

IPv6 can and should be considered in new infrastructure, but it does not remove the need to plan for IPv4 compatibility.

Customers, enterprise firewalls, external APIs, software repositories, access-control systems, security products, and partner networks may still depend on IPv4. Major cloud providers continue to support static public IPv4 services and maintain specific quotas and controls around them.

For example, AWS describes Elastic IP addresses as static public IPv4 addresses for dynamic cloud workloads. Its default quota is five Elastic IP addresses per account per region, although customers can request increases or bring their own IPv4 address space.

Google Cloud also applies quotas to external addresses and notes that infrastructure projects must have sufficient networking quota for subnets, external IP addresses, firewall rules, and cluster access.

For an AI provider building its own cloud rather than consuming a hyperscaler, the planning responsibility sits directly with the operator.

IPv4 becomes an input to the service—not an address request to consider after deployment.

Which AI Services Need Public IPv4?

Not every workload requires a dedicated public address. IPv4 should be assigned according to function, isolation requirements, customer expectations, and operational risk.

Inference API endpoints

Public inference services need reachable and stable endpoints.

A provider may use shared load balancers for standard API customers while reserving dedicated addresses for enterprises that require:

• Source allowlisting
• Dedicated environments
• Regulatory separation
• Private routing arrangements
• Stable endpoint identity
• Custom security policies

The address plan should distinguish between shared API infrastructure and dedicated enterprise endpoints.

Customer access gateways

Customers may access GPU instances through SSH gateways, bastion services, VPNs, remote desktop systems, or private-access platforms.

A shared gateway model reduces address consumption, but some customers may require dedicated ingress addresses for security or compliance reasons.

Outbound egress identity

Enterprise customers frequently need predictable source addresses.

They may need to allowlist the GPU environment when it connects to:

• Private datasets
• Object-storage services
• Financial systems
• Enterprise APIs
• Software repositories
• Internal development platforms
• Customer-controlled databases

Shared NAT can conserve IPv4, but a single shared egress pool may not provide enough isolation or accountability for all tenants.

An AI cloud may therefore need several egress tiers:

Shared platform egress

Dedicated tenant egress

Regulated-workload egress

Administration egress

Security-scanning egress

Control and management services

Administrative systems should generally be protected behind VPNs, Zero Trust access, restricted gateways, or private connectivity.

Where public addresses are required, they should be separated from customer workloads and controlled through strict access policies.

Load balancers and regional gateways

Each region may require multiple public addresses for:

• Production ingress
• Failover ingress
• API gateways
• Web portals
• VPN termination
• Dedicated customer environments
• Outbound NAT
• Disaster-recovery services

The requirement grows as the provider expands across facilities, regions, and upstream networks.

Customer-assigned resources

Some GPU cloud providers allow customers to receive dedicated public IPv4 addresses or routed blocks.

This may be relevant for:

• Long-running GPU virtual machines
• AI development environments
• Dedicated inference clusters
• Model-serving platforms
• Security research
• Customer-managed Kubernetes clusters
• Hosted private-cloud environments

The provider must decide whether addresses are assigned per instance, per customer, per cluster, or per service boundary.

Per-instance allocation is simple to understand but can consume IPv4 quickly. Gateway and load-balancer models are more efficient but may not satisfy every customer requirement.

Build an IPv4 Demand Model Before Procurement

IPv4 demand should be forecast using a service-based model.

A practical formula is:

Total IPv4 requirement = platform addresses + customer addresses + regional addresses + failover capacity + growth reserve

Platform addresses

Count addresses required for shared infrastructure, including:

• Public web services
• Authentication endpoints
• API gateways
• Shared load balancers
• VPN gateways
• NAT gateways
• Monitoring endpoints
• Administration gateways
• DNS services

Customer addresses

Estimate how many customers will require:

• A dedicated public endpoint
• Dedicated outbound identity
• One or more public GPU-instance addresses
• A routed subnet
• Separate production and development addresses

The model should use expected customer adoption rather than assuming every tenant requires dedicated IPv4.

Regional addresses

Calculate requirements separately for each data center or cloud region.

Do not assume that the same address can always move instantly between regions. Routing design, upstream providers, network border policies, registry records, and platform limitations may affect portability.

Failover capacity

A provider that allocates every available address has no room to respond to:

• A regional outage
• An upstream-provider change
• A block-reputation problem
• Customer migration
• Emergency replacement
• Routing maintenance
• Acquisition of a new facility

Failover inventory should be treated as production capacity, not wasted inventory.

Growth reserve

GPU deployments can grow unevenly.

A customer may begin with a small inference workload and later require a dedicated cluster. A region may add hundreds of GPUs faster than the procurement team expected. A platform may introduce public notebooks, hosted agents, vector databases, or additional inference endpoints.

The address plan should include a defined reserve and a trigger for procuring the next block.

Example IPv4 Planning Model

Consider a GPU cloud launching in three regions.

The provider expects to operate:

• Shared inference gateways
• Customer and administration VPNs
• Regional outbound NAT
• Dedicated enterprise egress
• Public GPU instances for selected customers
• Disaster-recovery capacity
• Additional addresses for growth

Rather than assigning a public address to every GPU server, the provider could create address pools for:

1. Shared platform services

2. Dedicated customer ingress

3. Dedicated customer egress

4. Public virtual machines

5. Management and security

6. Failover and migration

7. Future regional growth

This structure gives the network team better visibility into how address space is being consumed.

It also makes commercial decisions clearer. The provider can price dedicated IPv4 as a premium feature instead of silently absorbing the cost across every GPU instance.

Avoid Assigning Public IPv4 to Every GPU Node

Direct public addressing may be appropriate for some bare-metal or customer-controlled environments, but it should not be the default for every accelerator.

Exposing every GPU node can increase:

• Address consumption
• Attack surface
• Firewall complexity
• Abuse risk
• Customer-isolation requirements
• Reputation exposure
• Renumbering work

Private worker networks combined with controlled ingress and egress usually provide a more scalable architecture.

Public IPv4 should be placed at deliberate boundaries:

• Load balancers
• Gateways
• Dedicated tenant edges
• Public virtual machines
• Managed egress pools
• Customer-controlled routed environments

The objective is not to minimize address use at any cost.

It is to assign scarce addresses where they create operational or commercial value.

Plan for Address Reputation

For an AI cloud provider, an address is not useful merely because it can be routed.

The previous use of an IPv4 block may affect:

• Email and notification delivery
• Customer security controls
• Fraud-detection systems
• API access
• Content platforms
• Search engines
• Threat-intelligence feeds
• Geolocation databases

A block associated with spam, proxies, malware, scanning, or abusive hosting may create problems during customer onboarding.

Before leasing or buying IPv4, providers should review:

• Blocklist history
• Current reputation
• Historical routing
• Geolocation records
• Existing route objects
• Reverse DNS
• Prior abuse patterns
• Unexpected announcements

A low headline price can become expensive if engineers spend weeks repairing reputation and customer-access problems.

Treat Tenant Abuse as an Infrastructure Risk

GPU clouds can attract demanding and sometimes high-risk workloads.

Potential misuse may include:

• Automated scanning
• Credential attacks
• Fraudulent automation
• Spam
• Malicious model-hosting activity
• Unauthorized proxy services
• Copyright-infringing workloads
• Resource theft

The address plan should support accountability.

Providers should be able to identify which tenant, service, cluster, or gateway was using an address at a specific time. Shared NAT logs, allocation records, customer identity, and abuse-response procedures must be designed before scale makes attribution difficult.

The contract should also define:

• Acceptable use
• Complaint handling
• Suspension procedures
• Customer notification
• Evidence retention
• Address replacement
• Responsibility for reputation damage

IPv4 supply without abuse controls is not scalable infrastructure.

Routing and Security Requirements

Obtaining a block is only one part of deployment.

The provider should also plan for:

BGP authorization

Confirm which Autonomous System will announce the block and which facilities or upstreams will accept the route.

Where leased address space is announced by the lessee, a Letter of Authorization may be required.

RPKI and ROA management

The Route Origin Authorization should reflect the intended origin ASN and prefix length.

ROA changes must be coordinated during:

• Initial deployment
• ASN migration
• Multi-origin routing
• Provider changes
• Customer handover
• Lease termination

Internet Routing Registry objects

Route objects may be required by upstream providers or routing filters.

The IRR record should align with the intended announcement and operational responsibility.

Reverse DNS

Decide whether reverse DNS will be managed by:

• The IPv4 provider
• The GPU cloud
• The customer
• An automated delegation platform

Responsibility should be documented before customers begin using the addresses.

Geolocation

The physical deployment region, registry region, and geolocation-database result may not match automatically.

Providers should maintain geofeed or correction processes so customer services are not incorrectly localized or blocked.

WHOIS and RDAP accuracy

Registration contacts should remain current and should reflect the relevant operational relationships.

A registry record should describe reality, not be treated as permission to run the network.

Lease or Buy IPv4 for GPU Infrastructure?

The correct model depends on the project’s timeline, capital structure, and expected lifespan.

When IPv4 Leasing Makes Sense

Managed IPv4 leasing may be suitable when the provider:

• Is launching a new GPU region
• Needs addresses quickly
• Has uncertain customer demand
• Wants to preserve capital for GPUs and data-center construction
• Is testing a new service
• Needs temporary migration capacity
• Expects address requirements to change
• Wants operational support for routing and registry workflows

i.LEASE offers managed leasing with reputation screening, LOA support, RPKI and reverse DNS coordination, geolocation processes, and operational assistance.

Leasing can align IPv4 cost with revenue growth. The provider can secure capacity for the current deployment and expand when tenant demand justifies it.

However, lease terms must be evaluated carefully.

A GPU provider should check:

• Renewal rights
• Price-adjustment terms
• Termination notice
• Routing authorization
• Address-replacement procedures
• Abuse responsibilities
• Reputation support
• Provider accountability
• What happens if the upstream holder changes

A cheap lease with weak continuity terms can become a production risk.

When Buying IPv4 Makes Sense

Buying IPv4 addresses may be appropriate when the provider:

• Has stable long-term demand
• Operates permanent data-center regions
• Needs predictable address control
• Has capital available
• Can manage registry and operational responsibilities
• Wants to treat IPv4 as a long-term infrastructure asset

Buying can reduce repeated lease-renewal exposure, but it creates other responsibilities.

The buyer must manage:

• Transfer documentation
• Registry records
• Account security
• RPKI
• Reverse DNS
• Abuse contacts
• Address reputation
• Corporate changes
• Future transfers
• Registry-layer risk

i.LEASE provides structured buying workflows that include block screening, escrow coordination, registry transfer support, and operational handover.

Ownership language should not create false comfort. Completing a purchase does not automatically guarantee routing, reputation, registry continuity, or operational usability.

The transaction is one stage of the infrastructure lifecycle.

A Hybrid Strategy

Many GPU cloud providers will benefit from a hybrid model.

They may buy IPv4 for:

• Core regions
• Permanent platform services
• Long-term enterprise customers
• Stable public network identity

They may lease IPv4 for:

• New-market launches
• Seasonal capacity
• Temporary customer projects
• Migration pools
• Disaster recovery
• Rapid expansion
• Experimental services

This avoids making a single irreversible procurement decision before the platform’s real demand is known.

Multi-Region IPv4 Planning

AI providers often expand one facility at a time.

The first region may have excess address capacity, while the second region runs out quickly because its customer mix is different.

Each region should therefore have its own forecast covering:

• Customer count
• Public-service design
• Dedicated egress adoption
• Public-instance demand
• Failover requirements
• Upstream-provider structure
• Expected growth
• Regulatory constraints

The global plan should also define whether blocks can be moved between regions and how long such a move would take.

A prefix that exists in inventory but cannot be routed where the next GPU cluster is located is not immediately usable capacity.

Common IPv4 Planning Mistakes

Planning after GPU deployment

Waiting until servers are installed can delay customer onboarding and create pressure to accept unsuitable or poorly documented address space.

Counting servers instead of services

The number of GPUs does not directly determine the IPv4 requirement. Public service boundaries, tenants, gateways, and egress models are more useful planning units.

Ignoring failover inventory

Running at full address utilization leaves no room for migrations, reputation incidents, or new customer requirements.

Choosing only by price

Address reputation, routing readiness, renewal terms, and provider accountability may matter more than a small monthly price difference.

Treating a transaction as the end

A signed lease, completed transfer, or escrow release does not guarantee usability.

IPv4 must remain manageable when it is announced, recorded, renewed, reviewed, challenged, maintained, and used.

Depending on one undocumented provider chain

When addresses pass through several brokers or intermediaries, responsibility may become unclear during a routing, renewal, registry, or abuse incident.

Infrastructure should be evaluated under stress, not only under normal conditions.

How i.LEASE Supports AI and GPU Cloud Providers

i.LEASE is designed as an execution layer for the IPv4 secondary market.

The platform supports organizations that need to:

• Lease IPv4 addresses
• Buy address space
• Expand into new regions
• Prepare registry documentation
• Coordinate routing authorization
• Manage RPKI and reverse DNS
• Review address reputation
• Support operational handover
• Plan address lifecycle and renewal

Its role does not end when buyer and seller are matched.

The objective is to connect market access with operational execution so that address space can support real infrastructure after the commercial transaction is complete. i.LEASE describes this model as combining secondary-market access with registry and lifecycle workflows rather than leaving execution to disconnected follow-ups.

A marketplace shows supply.

An execution layer makes supply usable.

For GPU cloud providers, that difference matters because failed IPv4 planning can delay high-value infrastructure that is already consuming power, rack space, and capital.

IPv4 Planning Checklist for GPU Clouds

Before launching or expanding an AI region, confirm:

Architecture

• Which services require public access?
• Which workloads can remain private?
• Will ingress and egress be shared or dedicated?
• Do customers receive individual addresses or routed pools?

Demand

• How many shared platform addresses are required?
• How many customers need dedicated ingress?
• How many customers need dedicated egress?
• What growth reserve is required?
• What failover capacity is required?

Procurement

• Will the addresses be leased, purchased, or both?
• Are the blocks clean and routable?
• Is the source of the address space clear?
• Are renewal or transfer terms documented?

Routing

• Which ASN will originate the prefix?
• Will upstreams accept the planned prefix?
• Is an LOA required?
• Is the ROA correct?
• Are IRR route objects ready?

Operations

• Who controls reverse DNS?
• Who manages geolocation?
• Who receives abuse reports?
• How is tenant use attributed?
• What happens if a block develops a reputation problem?

Continuity

• What happens when a lease expires?
• Is replacement capacity available?
• Can the service migrate without customer disruption?
• Who is responsible during a registry dispute?
• Is there a clear escalation path?

Final Thoughts

GPU supply may determine how much AI compute a provider can sell.

IPv4 planning helps determine whether customers can reliably reach, use, secure, and integrate that compute.

The most effective strategy is not to assign a public address to every accelerator. It is to identify the service boundaries where stable public IPv4 creates operational value:

• Inference endpoints
• Customer gateways
• Dedicated tenant environments
• Predictable outbound identity
• Regional load balancers
• Public virtual machines
• Failover infrastructure

IPv4 should then be procured as part of the platform architecture—not as an emergency purchase after capacity is live.

For short-term growth, uncertain demand, and new-region launches, leasing may preserve capital and improve flexibility.

For mature regions and permanent service identity, buying may provide longer-term control.

In both cases, the provider must evaluate more than inventory.

It must evaluate routing, reputation, authorization, registry records, renewability, abuse handling, and continuity.

AI infrastructure is judged by what happens under load.

IPv4 infrastructure should be judged the same way.

 

Frequent Asked Questions