The real cost of public IPv4 in AWS, Azure and Google Cloud

The change that made IPv4 a line item

At AWS, a public IPv4 address attached to something used to be free. That is over. On 1 February 2024 AWS began charging $0.005 per hour for every public IPv4 address it provides, whether it is an Elastic IP or an address auto-assigned to an instance. Microsoft Azure and Google Cloud bill external IPv4 on comparable per-hour terms.

Providers adjust pricing, so treat the figures here as the shape of the problem rather than today's quote, and check the current pricing page before you build a business case on them. The direction has been consistent in one direction only.

What that adds up to

The per-hour number looks harmless. Annualized, it is not:

• $0.005 per hour
• $0.12 per day
• roughly $3.65 per month per address
• roughly $43.80 per year per address

Now scale it. A /24 is 256 addresses. If you were running that many public addresses in a single cloud account, the addressing alone would cost roughly $11,200 per year, recurring, for something that delivers no capability beyond existing.

That is the number worth sitting with, because it is pure overhead. It buys no compute, no storage and no bandwidth. And it is charged on addresses that are idle as well as busy: an Elastic IP attached to a stopped instance still bills.

Why AWS started charging

The honest answer is that the charge reflects reality. IPv4 is genuinely scarce, the free pools are gone, and the providers are buying on the same transfer market everyone else is. AWS absorbed the cost until 2024 and now itemizes it. Azure and Google Cloud already billed by the hour, and Google raised its price on the same day.

There is a second motive, which AWS has been open about: a per-address charge is a nudge toward IPv6. If your workload can run dual-stack or IPv6-only, a good deal of this expense simply disappears.

What BYOIP changes

Bring your own IP (BYOIP) lets you announce address space you control from inside the provider's network (how it works at each provider). The registration stays as it is, and the cloud advertises the addresses on your behalf.

The commercial point is straightforward: the per-address hourly charge applies to addresses the provider supplies, and none of the three charges for addresses you bring. AWS says on its pricing page that they are not charged, Azure charges nothing to provision or use them, and Google Cloud charges nothing whether they are idle or in use. That is what turns BYOIP from a technical curiosity into a cost decision. How to set it up at each is in its guide. Confirm the current treatment with your provider before committing, since this is exactly the kind of term that gets revised.

The other providers in our BYOIP guides each have a page of their own, among them DigitalOcean, IBM Cloud, Alibaba Cloud, Akamai Cloud and Hostinger.

Three practical constraints:

• A /24 is the floor. The major providers will not accept anything smaller, which lines up with the routing reality that most networks filter longer prefixes anyway.
• You need the registry side in order. Each wants a valid ROA naming its ASN and proof that you control the block: a certificate in the registry record at AWS and Azure, a PTR record at Google Cloud. None of the three asks for a letter of authorization. Azure also wants the block registered under your name, which a lease may not satisfy.
• Onboarding is not instant. Allow at least a day for a new ROA to reach AWS or Azure. AWS then provisions most ranges within two hours and Azure commissions one in 3-4 hours, while Google Cloud takes about two weeks for a regional prefix and four for a global one, and says that cannot be accelerated.

The part that has nothing to do with cost

Portability is the argument people forget, and over a few years it often matters more than the invoice.

Addresses issued by a cloud provider belong to that provider. Leave, and you renumber: every firewall rule your partners maintain, every allowlist, every hardcoded reference in a system nobody has touched in three years. That renumbering cost is a real switching barrier, and it is one you agreed to without noticing.

Bring your own space and the addresses move with you. Multi-cloud stops requiring a different block per provider. A migration stops requiring a change request at every customer you have. Your reputation history, which took years to build, follows you rather than being handed back.

Running the comparison

The decision comes down to comparing three things over the horizon you actually plan for:

1. What the provider charges for the public addresses you use, annualized, including idle ones.
2. What the same space costs to lease, which is a predictable annual figure with no capital outlay and no registry transfer.
3. What it costs to buy, which is capital up front and then the yearly cost of holding it: a registry membership, or in the RIPE NCC region a sponsoring LIR for independent and legacy space (the registries compared).

For a stable long-term footprint, buying usually wins outright and the addresses become an asset rather than an expense. For anything uncertain or seasonal, leasing gives you the same escape from per-hour billing without committing capital.

What rarely wins on a multi-year view is leaving it on the provider's meter. That is the one option where you pay indefinitely and own nothing at the end.

Where RTM Networks fits

We lease /24s and larger, which is what BYOIP requires, from our own RIPE NCC address space, and sell blocks across the RIPE NCC, ARIN and APNIC regions. Leased space is usually live within 24 hours of payment, and as part of the service, not as an extra, we create the ROA for your provider's ASN and add the certificate or PTR record it checks.

If you want to know whether BYOIP is worth it in your case, the useful thing to send us is your current public IPv4 count and which providers you run on. We will come back with what the equivalent space costs to lease or buy (lease IPv4, buy IPv4), so you can put a real number against what you are paying now.