The Rising Cost of IPv4: How Cloud Providers Are Passing the Buck

For most of the Internet’s history, an IPv4 address was essentially free. If you needed one, you asked your ISP or your cloud provider, and they handed it over—no line item, no monthly fee. That era is over. Today, public IPv4 addresses have become a scarce, tradeable commodity, and cloud providers are increasingly passing the cost directly to their customers. What was once a rounding error in your cloud bill is now a noticeable line item, and for startups, serverless workloads, and large-scale architectures, the math is starting to favor IPv6 in ways that few expected just a few years ago.

From Free Resource to Monthly Utility

The underlying cause is simple: the IPv4 address space is fully allocated. The last unassigned blocks were handed out by regional registries in 2011 (to ISPs) and effectively exhausted in 2019. Since then, any new public IPv4 address a cloud provider wants must be bought on the secondary market—from universities, old enterprises, or other holders willing to sell. Prices have skyrocketed. In 2015, a single IPv4 address cost around $10–15 on the secondary market. By 2025, the average price had climbed to $50–$60 per address, with large blocks (e.g., a /16, or 65,536 addresses) selling for well over $3 million.

Cloud providers have two choices: eat that cost or pass it on. Unsurprisingly, they are passing it on. In early 2024, Amazon Web Services (AWS) began charging $0.005 per public IPv4 address per hour for all EC2 instances, regardless of whether the address is attached to a running server or just reserved as an Elastic IP. That works out to roughly $43 per IP per year. Google Cloud and Microsoft Azure followed with similar pricing models. For a cloud provider with millions of public IPs deployed, the savings are enormous—but for the customer, it means that every public-facing server now carries an unavoidable annual fee.

How This Changes the Cost Equation for Startups and Small Teams

For a hobbyist running a single t4g.micro instance on AWS, an extra $43 per year is annoying but manageable. For a startup running 20 microservices, each with its own public IP, the math changes quickly: $860 per year just for the IP addresses, before you even pay for compute, storage, and data transfer. That is real money in a lean budget.

The impact is even sharper on development and staging environments. Many teams mirror production with public IPs to test webhooks, APIs, or external integrations. Under the old model, you could spin up a test VM with a public IP for a few hours and pay almost nothing. Under the new model, that same test run now incurs a measurable cost because the IP is charged by the hour. As a result, teams are rethinking their architectures: using NAT gateways (which have their own costs) to share a single public IP across many test instances, or moving test workloads to IPv6-only VPCs where possible.

The Serverless and Container Double Whammy

Serverless functions (AWS Lambda, Google Cloud Run, Azure Functions) and container orchestration (Kubernetes) are supposed to abstract away infrastructure management—including IP addressing. But serverless platforms themselves must assign IPs to their execution environments. When a Lambda function needs to access an external API, it egresses through a NAT gateway or a VPC endpoint, and the underlying public IPs are not free. Providers have responded by either absorbing the cost (for very low volumes) or, increasingly, passing it through.

Consider a high‑traffic serverless app that invokes 10,000 functions per second. The associated NAT gateways and load balancers may require a pool of public IPs to avoid port exhaustion. Those IPs—often a dozen or more—now appear on the monthly bill. Worse, because serverless workloads are ephemeral, they cannot easily “reserve” an IP for the long term; they must either pay per hour for a static Elastic IP or rely on dynamic public IPs that are charged regardless. The result is that the cost of IPv4 has become a nontrivial part of serverless egress fees, eating into the “pay only for what you use” promise.

Financial Incentives to Migrate to IPv6

Every cloud provider now offers native IPv6 support. Most give away IPv6 addresses for free—no hourly charge, no limit on how many you use. An EC2 instance with a public IPv6 address pays $0.005 per hour less than the same instance with a public IPv4 address. Over a year, for a 1,000‑instance cluster, that saving exceeds $43,000. For a large enterprise, the math becomes irresistible.

This creates a powerful financial incentive to redesign applications for dual‑stack (IPv4 and IPv6) or IPv6‑only operation:

• Dual‑stack allows gradual migration. The application listens on both protocols, and clients that support IPv6 (about 40–45% of global Internet users) connect over the free IPv6 path, reducing the number of paid IPv4 addresses needed.
• IPv6‑only eliminates IPv4 entirely, usually behind a translation gateway (NAT64/DNS64). This is more complex but can drive the IPv4 cost to zero for internal services and even for some public‑facing apps.

Real‑world examples are already emerging. Meta (Facebook) announced in late 2024 that its largest AI training clusters are IPv6‑only, saving millions of dollars annually in IP lease and cloud provider fees. Startups building new greenfield services often choose IPv6 from day one, treating IPv4 as a legacy compatibility layer rather than the default.

The Hidden Cost That Remains

Before you rush to disable IPv4, there is a catch. Many third‑party APIs, legacy SaaS products, and even some CDN edge locations still lack IPv6 support. If your service is IPv6‑only, it cannot talk to them without a translation gateway (e.g., a NAT64 appliance), which itself may require IPv4 egress IPs—restarting the cost cycle. And cloud providers typically charge for those translation services. So the financial incentive to adopt IPv6 is strong, but the transition is rarely friction‑free.

The Buck Stops (Eventually) with IPv6

Cloud providers did not invent IPv4 scarcity; they inherited it. But their decision to pass the rising cost directly to customers—by charging per IP per hour—is accelerating a long‑overdue migration. For small startups, the extra $43 per IP per year might be a nuisance. For large‑scale cloud users, it is a serious line item that demands architectural changes. The message is clear: IPv4 is no longer a trivial utility; it is an expensive, legacy resource. The financial case for IPv6 has never been stronger. Whether you migrate now or later, the cloud bill will eventually convince you.