The Cloud Repriced the Network

On 11 January, Google Cloud published a short post saying that customers who wish to stop using Google Cloud and move their data to another provider or to their own hardware can do it without paying network data transfer fees, and that this applies to all customers globally. The fee that made leaving expensive was removed by the company charging it, on its own initiative, in about four hundred words.

The same week, the deadline on the other change came into view. AWS announced in July 2023 that from 1 February 2024 every public IPv4 address would cost $0.005 per hour, across every service and every region, whether the address is attached to a running instance or sitting idle in the account. Six months of notice, and then a resource that had been free for eighteen years becomes a line item.

Nothing happened to the cost of moving bytes between 11 January and 23 January, and nothing happened to the cost of an IPv4 address either. Transit prices have been falling steadily for two decades. Address scarcity has been getting worse continuously since the middle of the last decade, not in a step at the end of last July. Neither announcement was tracking an input.

So here is the reading I keep coming back to, and it is not cynical so much as structural. Cloud network pricing has never described what the network costs. It describes where the provider stands: what it can charge for because you cannot easily go elsewhere, and what it has to stop charging for because somebody is about to make it. Both of these announcements are that same instrument, turned in opposite directions in the same month.

The arithmetic is small and the surface is large. At $0.005 per address-hour, one address is about $3.65 a month, which is nothing. The number that matters is not the rate, it is how many addresses you are holding and have never had a reason to count. Every NAT gateway, every public load balancer, every managed database endpoint you left public, every node in a cluster that got an address by default, and every Elastic IP reserved during an incident three years ago and never released.

The idle address was already billed, which is the tell. An unattached Elastic IP has carried a charge for years, and the stated reason was always conservation: the address is scarce, you are holding one out of circulation, pay for it. That argument does not change when the address is attached. What changed in July was not the reasoning but the willingness to apply it to the ninety-odd percent of addresses that were in use, and the free tier of 750 hours a month for a first-year account tells you who the charge is aimed at.

Azure has priced it this way the whole time. Microsoft's own documentation is blunt about it: public IPv4 addresses carry a charge and public IPv6 addresses do not. A Standard SKU public IP is static allocation only, meaning the address is assigned when you create the resource and held until you delete it, so on Azure the billing event has always been allocation rather than attachment. The idle-address charge is not an anomaly there. It is the entire model, and it predates this news by years.

That is the awkward comparison. The same scarce resource, subject to the same registry exhaustion, was free at one provider and billed at another for the better part of a decade. Both companies buy addresses in the same market. If price tracked cost, that gap could not have existed, and it certainly could not have closed on a date chosen by one of them with six months of notice. What closed it was a decision that the market would now bear it.

The scarcity underneath all of this is real. Worth saying plainly, so the rest of this is fair. IANA handed out the last of the central IPv4 pool on 3 February 2011, and RIPE NCC made its final routine allocations on 25 November 2019, since when European operators have been served from a waiting list. Address space stopped being something a provider requests and became something it buys from whoever is selling. It is a genuine input cost, and it has been rising the entire time the addresses were free.

Google's post landed on 11 January. Regulation (EU) 2023/2854, the Data Act, was published in the Official Journal on 22 December and entered into force twenty days later, which is also 11 January. Its switching provisions, including the phased withdrawal of the charges providers levy for moving a customer's data out, do not bind anyone until September 2025. The post does not mention the regulation at all, and I would not claim a causal link I cannot see. I would note the date.

And I would read the waiver for what it is gated on rather than what it removes. It is for customers who wish to stop using the service, which is a different product from cheap egress. Ordinary outbound traffic, the kind a running system produces every day serving its users, is untouched by any of this and remains the most marked-up line on the bill. What has been made free is the one-time act of leaving, once, by someone who is leaving.

That distinction is the whole thing. A waiver on exit lowers the switching cost, which is exactly the number a regulator is interested in and exactly the number a competitor wants lowered. A waiver on running egress would lower the operating cost of staying, which nobody has offered, because it is the part the leverage is actually built on. I do not know yet what the other providers will publish in response, and I would not assume the shape will be the same.

Egress is the price of the door, not the price of the bytes. Inbound is free everywhere and always has been, which is not generosity about the direction of a packet. It is that filling the store costs the provider nothing it wants back, and emptying it is the moment the relationship ends. When the outbound rate is a hundred times what bulk transit sells for, the extra is not a delivery charge. It is the price of the exit, collected in installments, from anybody whose architecture happens to send a lot of data to users.

The same bytes have two prices, and Azure will sell you either. Azure lets you set a Routing Preference on a public address: carry the traffic across Microsoft's global network for as long as possible, or hand it off to the public internet at the nearest exit. Microsoft's documentation says the second option lowers the egress cost, and it is the same bytes to the same user. That is a clean demonstration that the number on the bill is a product decision about which network you are buying, and only loosely a measurement of anything.

Captive resources get priced once they stop being contestable. A public IPv4 address is not something you can go and buy separately and bring in through the front door of a running deployment, which is what makes it chargeable at whatever number is chosen. The general form: any resource that is scarce, necessary, and unobtainable from anyone but your provider will eventually acquire a price, and the date it acquires one is a decision about the market rather than a fact about the resource.

Own your address plan. Find out how many public IPv4 addresses your accounts hold, which of them are attached to something that genuinely needs to be reached from the internet, and which are there because a default said so. Most environments discover that a large share of their addresses exist to give private workloads a route out, which is a job a single NAT device or an outbound gateway does with one address instead of dozens, and which IPv6 does for free on every provider I have looked at.

The addresses that survive that audit are the ones somebody outside depends on, and those are worth pinning deliberately: brought in under your own allocation where the provider supports it, or at least documented as load-bearing so nobody releases one during a cleanup and discovers that a partner's firewall rule was the real dependency. The point of the exercise is not the $3.65. It is that the audit finds every unmanaged public entry point you own, which is the useful output regardless of price.

Then know what your exit weighs. Not whether you would leave, which is a question nobody answers honestly in the abstract, but the arithmetic: how many terabytes would have to move, how long that takes at the bandwidth you actually have, and what it would cost at list price on the day. It is an afternoon's work and it converts a vague feeling of being stuck into a number you can put in front of people.

And having the number is what lets you use a waiver like this one at all. An offer to move your data out for free is worth precisely nothing to an organization that does not know how much data it has, where it is, or which of forty services would have to be stood up somewhere else first. The fee was never the largest part of the switching cost. It was the visible part, and the visible part is the one that gets removed.

I want to be careful not to sell the cynicism harder than the facts support. Address scarcity is real and the acquisition market for IPv4 space is real, so the charge arriving in February is not invented, and a company that removes a fee it was collecting has done a good thing whatever moved it. Providers are entitled to price their products, and both of these prices are published, dated, and easy to model, which is more than most industries manage.

What I take from the pair is narrower and harder to unsee. Twelve days apart, two network prices moved in opposite directions, and the direction each moved was set by where the pressure was coming from rather than by anything on the wire. The bytes did not change. So the only durable position is to know what you hold and what your exit weighs, because the next revision will arrive as a short post on a Thursday, and you will want to already have the numbers.