Public IPv4 Charge in 2024: What Paying per Address Means

Starting in February, a major cloud provider bills every public IPv4 address by the hour. Attached to a running service or sitting idle, doesn’t matter. The new public IPv4 charge makes each address its own line on the invoice, so if you run several sites across cloud servers, you pay for the number of addresses you hold and not only for the machines behind them. Got more than one address? Then this is the month to count them and work out which ones you still need.

What Does the Public IPv4 Charge Change in February?

Addresses that used to be free while attached to a running instance now cost money for every hour they exist in the account. The provider announced it last July, and it kicks in at the start of February, so there are a few weeks left to prepare. How the addresses work? Same as before. Only the billing is different.

You see the shift best in the Elastic IP charge. An Elastic IP is a static address you reserve so it stays yours when a server gets replaced. Until now it was billed mainly when it sat unattached (a penalty for hoarding, basically). Under the new rules, in-use and idle addresses are treated alike. One caveat: ranges a customer owns and brings to the platform are handled differently from those rented from the provider, so the fee concerns the addresses you lease.

Why Is a Provider Billing per Address Now?

Because of the IPv4 shortage. Addresses are a scarce resource that providers have to acquire, and that expense now lands on whoever holds each one. IPv4 uses a fixed-length address, so the total pool was limited from the day the protocol was designed. Then the internet grew far beyond what its authors expected, and the regional registries that hand out blocks ran out of fresh ones to allocate.

Since then, anyone who needs more space has to get it from someone who already holds it. The announcement names that rising acquisition cost as the reason for the fee. And it frames the charge as a nudge too: use addresses sparingly, and look at IPv6 where it fits.

Where the IPv4 Address Cost Shows Up in a Multi-Site Setup

The bill grows with the number of addresses. Not with traffic, not with server size. So setups with one address per site feel it most: a tiny instance serving a brochure page and a big one handling a busy shop pay the same for the address itself. And honestly, many accounts hold more of them than their owners remember, because addresses get attached to resources automatically:

• one server per site, each with its own public address,
• load balancers, which take an address in every zone they cover,
• NAT gateways that give private machines outbound access,
• managed databases left publicly reachable,
• reserved addresses from old projects that were never released.

The idle and forgotten entries on that list now cost exactly as much as the busy ones. Did you put sites on separate ranges on purpose? Then weigh that choice against the fee; our guide to subnet spread for small networks explains when that kind of separation serves a real purpose.

How Many IPs Does a Site Network Really Need?

Far fewer than one per site in most cases, because many domains can share a single address through name-based virtual hosting and SNI. With virtual hosting, the web server picks the right site from the hostname the browser asks for. SNI (short for Server Name Indication) does the same job for HTTPS and lets one address present a different certificate for each domain.

That said, separate addresses still make sense in a few situations:

• isolating unrelated projects, so trouble with one does not affect another,
• serving visitors from a specific region,
• keeping mail apart from web traffic, since sender reputation is tied to the address.

In my view this is an ops and cost question, nothing more, and it should be settled with a written plan. Our article on IPv4 and IPv6 address planning walks through one for a larger group of domains. There is another route as well, a reverse proxy: Jalvo places EU and USA addresses in front of existing hosting, so origin servers do not each need a public address of their own.

Audit Your Addresses Before the First Invoice

List every public address in the account, decide which ones serve a purpose, and release the rest before February billing starts. For a small network, a structured pass takes an afternoon:

1. Inventory all public and reserved addresses in every region, not just the one you use daily.
2. Match each to a site or service, and mark those you cannot identify.
3. Release the unattached ones.
4. Consolidate small sites behind a shared address or proxy.
5. Move databases and other internal services to private networking.
6. Review the list again after the first bill arrives.

Careful with step three, though. A released address goes back to the provider’s pool and you are unlikely to get it back, so update DNS records and any allowlists first. And the replacement you receive later may carry someone else’s past. That is why the history of reused IP addresses deserves a check before you point a domain at one.

Is IPv6 Adoption for Websites a Way Out?

Partly. IPv6 removes the scarcity problem, but a public website can’t drop IPv4 yet, because part of the audience and some crawlers and tools still connect over the older protocol. What works in practice is dual-stack on the public edge (both protocols answer there), with IPv6-only or private addressing behind it. That way the paid addresses come down to the few that visitors actually reach.

Before you rely on it, check your own origin and NGINX configuration:

• AAAA records exist for each hostname and point to the right machine,
• every server block has a listen directive for IPv6 alongside the IPv4 one,
• firewall rules cover both protocols,
• log parsers and allowlists do not assume the IPv4 format.

So the public IPv4 charge turns each address into a deliberate decision instead of a default. Count what you hold, trim what nobody uses, consolidate the sites that can share. Not glamorous work. But it is a lot easier to do in January than after the first invoice.

FAQ