Where cloud public IPv4 costs come from and how to cut them

Public IPv4 addresses used to be an almost invisible line on cloud bills. The large providers now charge for them by the hour, and for estates with hundreds of addresses the total is hard to ignore. This article explains where the charges come from, how to estimate them and which levers bring them down.

How cloud providers charge, and what a /24 costs

The three hyperscalers price public IPv4 the same way: a flat hourly fee per address.

• AWS charges $0.005 per hour for every public IPv4 address, in use or not, a model in place since February 2024.
• Azure charges $0.005 per hour for a Standard static public IPv4 address.
• Google Cloud charges $0.005 per hour for external IPs on standard VMs.
• OVHcloud prices additional IPv4 differently, at $2.39 per IP per month.

The key property is that the fee is per address, per hour. It does not depend on traffic, so an address that does nothing costs exactly the same as a busy one.

At $0.005 an hour, one address costs about $3.65 a month (0.005 × 730 hours). Multiply by 256 and a full /24 comes to about $934 a month (0.005 × 730 × 256), or roughly $11,200 a year.

On OVHcloud, 256 additional IPv4 addresses at $2.39 each come to about $612 a month. These figures cover only the address fee. Data transfer, NAT and load balancer charges come on top.

To estimate your own exposure, export the list of public IPv4 addresses from every account and region and multiply the count by $3.65. Then look closely at the list itself: addresses left behind by test environments, old migrations and decommissioned services accumulate quietly.

Start with idle and forgotten addresses

The cheapest saving is an address you release. Work through each account and region in turn:

1. List all allocated public IPv4 addresses and what each one is attached to.
2. Flag anything unattached, attached to a stopped instance or tied to a resource nobody claims.
3. Check DNS records, firewall rules and partner configurations before releasing anything, because some addresses are referenced outside your own systems.
4. Release what is genuinely unused, and tag the rest with an owner and a purpose.
5. Repeat the review on a schedule, or alert on new unattached addresses.

Take particular care with addresses that customers or partners have allowlisted. Once released, you are unlikely to get the same address back, and integrations can break.

Do your instances really need public addresses?

Many workloads only need outbound internet access: pulling updates, calling APIs, shipping logs. Giving each of those instances its own public IPv4 multiplies the per-address fee. Routing them through a NAT gateway or a shared egress proxy means only the NAT’s addresses are public.

NAT is not free, though. Managed NAT gateways generally carry their own hourly and data processing charges, so compare the gateway’s cost with the per-IP fees it replaces, using your provider’s current price list. As a rough guide:

• A handful of instances with heavy outbound traffic may be cheaper with individual public IPs.
• Many instances with modest outbound traffic usually favour a shared NAT.
• Inbound services should sit behind a load balancer or reverse proxy rather than exposing every backend directly.

Use IPv6 where the other end supports it

Every service that can run over IPv6 alone is one that doesn’t need a public IPv4 address. Dual-stack designs let internal traffic, service-to-service calls and IPv6-capable clients use IPv6, which reduces how many public IPv4 addresses you need to keep. Check how your provider prices IPv6 addresses, but the main saving comes from shrinking the IPv4 count.

Plenty of clients and partners are still IPv4-only, so public-facing services will keep needing IPv4 for some time. Treat IPv6 as a way to shrink your IPv4 footprint rather than remove it.

Bring your own addresses

For larger estates, BYOIP changes the arithmetic. AWS and Google Cloud don’t charge the hourly fee for BYOIP addresses, Azure doesn’t charge for custom IP prefixes or the IPs derived from them, and OVHcloud doesn’t charge extra for BYOIP. If you hold a /24, the roughly $934 a month in per-IP fees on a hyperscaler goes away.

BYOIP has its own requirements and costs to weigh:

• You need a block of at least a /24 that is cleanly registered and has a good reputation.
• If you don’t hold one, compare the cost of buying or leasing a /24 with the per-IP fees it would replace.
• The registry side takes work: ROAs for the provider’s ASN, validation records and reverse DNS.
• Provisioning is not instant. On Google Cloud, for example, it takes weeks.
• In return, the addresses become portable and can move with you if you change provider.

How TACS can help

TACS can review your public IPv4 footprint as part of our consulting work and show where addresses can be released or consolidated. Where BYOIP makes sense, we can supply a /24 to buy or lease and prepare the registry side for BYOIP.