When Egress Reprices, the Fix Goes Into Application Code

There is a class of cost regression that leaves no trace in your repository. Nothing shipped, nothing changed in configuration, and the line on the invoice moved anyway — because the number that moved was set by someone who has never read your code.

No setting in your repository selected this rate. Google's documentation is plain about the mechanism: if your CDN provider is already part of the CDN Interconnect program you do not have to do anything, and traffic from supported Google Cloud locations to that provider automatically takes the direct connection. The same page adds that CDN Interconnect requires no configuration and no integration with Cloud Load Balancing. The rate follows where the packets are going. It was never expressed as a choice anywhere in your stack, so there is no line to grep for, no flag to unset, and no commit that would surface in a bisect when the invoice changes.

Google's pricing-update page for CDN Interconnect and Peering gives the new list prices, effective 1 May 2026: $0.08 per GiB in North America against $0.04 before, $0.08 against $0.05 in Europe, and $0.085 against $0.06 in Asia. It names three products — CDN Interconnect, Direct Peering, Carrier Peering — and no others, leaving Dedicated Interconnect and Partner Interconnect untouched. The same page names the response it recommends, and that is worth reading closely: customers on Direct Peering or Carrier Peering are pointed at a Verified Peering Provider, which is a change in who sells you connectivity rather than a change to anything you run. For CDN Interconnect the page names nothing at all. Where the vendor offers a way out, the way out ends in a procurement conversation.

List price is not the number on your invoice, and the distance between the two is set by a contract clause rather than by a page. Google's own page draws the line: a fixed-price agreement that names an absolute $/GiB sees no change until it comes up for renewal, while a discount written as a percentage off list is redefined the moment list is redefined, because list is the thing it refers to. That distinction is worth settling before anyone reassures you the increase does not apply. Underneath the clause the quantity is the same either way: origin egress is the miss rate times bytes delivered times the rate per GiB. Two of those three factors are yours.

The form of that product carries the argument. Cost is linear in the miss rate, so the value of one point of hit ratio is directly proportional to the rate. Double the rate and every cache improvement anyone has ever scoped doubles in value on the same day, with no change in the engineering and no new fact about the workload. Work that failed its business case at the old rate passes at the new one. Nothing about the system improved; the threshold it is measured against moved, and it moved because of a decision taken at a company that has never seen your handlers.

The misdiagnosis that follows is predictable. A line item grows, the deploy log is empty, so the investigation starts in traffic growth or a CDN regression, ends nowhere, and the ticket routes to whoever holds the vendor relationship. Meanwhile every lever that survives a repricing sits in application code. A cache key that carries a request id or a session cookie splits one hot object into thousands of cold ones. A Vary header written broadly enough to list Accept-Encoding variants you never serve does the same thing along a second axis. A five-minute TTL is often standing in for a purge-on-write that was never built, and it caps the hit ratio at whatever five minutes happens to buy. A shield tier left off means each edge node misses through to origin on its own account instead of once for all of them. None of the four is a network setting. All four are decisions in the handlers, and they are worth the same hour of review whether or not a vendor moves a price.

That linearity runs both ways. The jump on the peering SKUs is the miss rate multiplied by the bytes, with the multiplier published in advance and applied on a known date, so the size of the increase on any one service is a statement about that service's cache rather than about the price. A service answering ninety-five percent of requests from cache takes a rounding error; a service at sixty percent takes the whole of it. Google's page names the SKUs to filter billing reports on, and those reports reach back further than the change does, so the ratio the new rate multiplies can be read off history instead of guessed at. What is left is a division of labour nobody agreed to: the rate is a fact about the world, the miss rate is a fact about your handlers, and only one of the two has ever been through code review.