IPv4 Addresses Are Now a Real Line on Your Hosting Bill

A single blocked Hetzner IP address took 325 unrelated domains offline in Italy. One of them belonged to a Portuguese hosting provider, which lost email connectivity with its Italian customers for 16 days. Neither had anything to do with the pirated football stream the block was aimed at (Sommese, Sperotto, van der Ham, Affinito and Prado, 90th Minute: A First Look to Collateral Damages and Efficacy of the Italian Piracy Shield, University of Twente, peer-reviewed, CNSM 2025). On average, domains caught in that collateral damage stayed unreachable for around 320 days. CDN IP blocking is not a censorship story — it is a reachability risk sitting inside every anycast CDN contract, and almost nobody prices it.

The mechanic: anycast means sharing reachability with strangers

A hyperscale CDN serves thousands of customers from the same anycast IP ranges. That is the design — it is what makes anycast fast and what makes DDoS absorption possible. It also means the routable address your customers resolve to is shared with tenants you did not choose and cannot audit.

‍

When a regulator blocks by IP rather than by domain, everything on that address goes with it. Your site does not need to be the target. It only needs to be a neighbour.

‍

The clearest public example of the mechanic is a Cloudflare Community thread from July 2026: a site owner found their domain unreachable from Russia because it resolved to a shared Cloudflare IP that had been added to the state blocklist over a completely unrelated site sharing the same address. The browser simply spun — no error, no notification, connection silently dropped.

‍

You cannot fix this by being compliant. Your legal standing is irrelevant to a /24 null route.

‍

The Twente study put names to who actually gets hit. Of 7,114 domains affected during the study window, researchers manually confirmed 510 as legitimate sites with no connection to streaming — hotels, restaurants, retail shops, an accountant, a car mechanic, a nunnery, and a telehealth missionary program among them. In three separate cases, blocking one IP address caused 60 collateral blocks each. Mail server IPs were blocked in 782 cases and nameserver disruption in 397 — meaning the damage extends past the website to email and DNS.

‍

And there is a second-order effect that should concern anyone leasing IPv4 space. Of the 10,918 blocked addresses, 24% were linked to leased address space, and 453 addresses were leased for the first time after they had already been blocked. The new tenant inherits an address that is silently unreachable from Italy, with no notification and no obvious cause. A further 250 addresses were re-leased to different companies while still under block. If you lease IPv4 space for a CDN origin or a mail server, check the block status of the range in your target markets before you announce it — the study's authors describe the polluted address space they leave behind as one of the system's lasting harms.

Four jurisdictions, one pattern

This is not a Russia story. It is a structural consequence of IP-level enforcement, and it is happening across regulatory contexts with very different intentions.

‍

Sources: TorrentFreak (2025); RIPE Labs and APNIC Blog (2025) on the Piracy Shield study; TechRadar (2025); The Record (2024, 2025); DNS at Risk.

‍

Note what Italy, Spain and Austria have in common: these are EU member states pursuing copyright enforcement, not censorship. The intent does not change the blast radius. Any business with customers in those markets carries the same exposure as one serving a heavily censored market — which is why this belongs in an infrastructure risk register rather than a politics conversation.

‍

The Austrian outcome is the most useful signal in the table: a regulator that tried IP-level blocking on shared infrastructure and then banned it, because the collateral damage was indefensible. That is the direction of travel, but it arrives jurisdiction by jurisdiction, years apart.

Blocking happens at four layers, and each has a different fix

Teams conflate these, then apply the wrong countermeasure and conclude nothing works.

The ECH case deserves its own note because it is the single most common misdiagnosis in this space. Cloudflare enables Encrypted Client Hello by default; Russian networks have blocked TLS connections using the ECH extension since 2024. The result is a site that becomes unreachable in waves, which owners routinely misread as "Cloudflare is fully banned." It usually isn't. With ECH turned off, connections fall back to plain SNI and typically stop being dropped — a zone-level configuration change, not a migration.

‍

Check ECH before you plan a CDN migration. It is free, reversible, and resolves a meaningful share of cases that look like IP blocking but aren't.

Why you find out last

There is no notification. No appeal path that operates on infrastructure timescales. In Italy, the blocklist behind Piracy Shield is not published — AGCOM has repeatedly refused freedom-of-information requests for it, leaving only single-IP lookup tools with no bulk export. Cloudflare told Human Rights Watch in May 2025 that it is generally unable to identify or confirm government-directed blocking and had received no notice from any Russian entity about the reported disruptions.

‍

Read that carefully: the regulator will not tell you, and your CDN cannot tell you. Your first signal is a traffic drop from one country, and if that country is not a top-three market you may not notice for weeks.

‍

Monitoring from inside the affected market is the only reliable detection. Synthetic checks from your own CI or from a US/EU monitoring region will pass while real users in the blocked market see nothing. If you have meaningful revenue from a market with an active blocking regime, you need a probe that actually resolves and connects from inside it.

What no CDN vendor will tell you

A large CDN cannot publish this article. Cloudflare cannot write "our IP ranges are subject to state-level blocking in several markets, so consider a provider with a smaller footprint." Akamai cannot either. The structural incentive runs the other way: their answer to concentration risk will always be more of their own product. That is not dishonesty, it is positioning — but it means the SERP for this problem is written entirely by parties who cannot recommend the fix.

‍

The fixes that exist are gated behind Enterprise. Cloudflare's BYOIP, where Cloudflare announces IP space you lease or own across its locations, is Enterprise-only. The traditional onboarding path ran up to four to six weeks, involving addressing teams, network engineering, legal, and a Letter of Agency — Cloudflare has since launched a self-serve BYOIP API that removes much of that manual process. Either way, BYOIP is a posture you adopt in advance, not a lever you pull during an outage.

‍

Not every "dedicated IP" product solves this problem, and the distinction matters. Cloudflare's Dedicated CDN Egress IPs sound like the answer and are not: they govern traffic from Cloudflare to your origin, for origin allowlisting and firewall lockdown, not the address your users resolve to. Buying them changes nothing about whether a regulator can reach you. The controls that affect the user-facing address are BYOIP, leased static IPs with address maps, and the certificate option below.

‍

And leased static IPs solve only half the problem. They are still Cloudflare addresses. If a neighbour on your shared IP gets you blocked, a static address fixes it. If a regulator blocks Cloudflare's ranges wholesale — as happened across eastern Russia in March 2025 — a static Cloudflare IP goes down with everything else. Only address space that is yours, or a provider whose ranges are not listed, survives range-level blocking. Match the control to which of the two failure modes you actually face.

‍

There is one cheap partial mitigation almost nobody uses. Business and Enterprise customers can reduce the number of Cloudflare IPs their domain shares with other customer domains by uploading a Custom SSL certificate. That does not give you a dedicated address, but it shrinks the neighbourhood — fewer strangers on your IP means lower probability of inheriting someone else's block. For a Business-plan site with exposure to an active blocking regime, it is the highest ratio of risk reduction to effort available.

‍

And the honest limit on all of this: if a block is a lawful order directed at your own content in a market where you operate, the answer is legal and compliance work, not a different IP range. Infrastructure diversity solves collateral damage — being caught by someone else's enforcement. It does not solve being the target, and any provider who pitches it that way is selling you a problem rather than a solution.

What breaks in production

You migrate CDN and inherit a new set of neighbours. Moving from one hyperscale anycast provider to another swaps one shared-IP exposure for a different one. If the new provider's ranges are already listed in your target market, you have executed a migration for nothing. Check the destination's IP ranges against the market's blocklist status before cutover, not after.

‍

Your monitoring says everything is fine. Covered above, and it is the most common failure. Region-blind synthetic monitoring is how a two-week outage in a secondary market becomes a quarterly revenue surprise.

‍

Lowering TTLs after you need them is too late. If your records sit at 86,400 and a market goes dark, your fastest possible failover is a day away. Pre-lowered TTLs on anything exposed to a blocking regime are cheap insurance — the same discipline covered in our [CDN migration playbook → /blog/cdn-shutdown-migration-playbook].

‍

Regional CDNs solve reachability and introduce other constraints. A provider with local presence in a market is far less likely to be blocked there, and often has better last-mile performance. It will also usually have a smaller global footprint, different feature coverage, and its own compliance obligations in that jurisdiction. That is a real trade, not a free win.

‍

"Not blocked yet" is a depreciating asset. Selecting a provider purely because regulators have not reached it is a position with a shelf life. The durable property is not obscurity — it is how fast you can move when it changes, which is a procurement and architecture question rather than a provider-selection one.

The mitigation ladder

Work down this list; each step costs more than the one above it.

‍

1. Check ECH first. If the symptom is intermittent unreachability in a specific market, disable ECH on the zone and re-test before doing anything else. Free, reversible, resolves a large share of misdiagnosed cases.
2. Deploy in-market monitoring. You cannot manage exposure you cannot see. One probe resolving and connecting from inside each market that matters.
3. Upload a Custom SSL certificate if you are on a plan that supports it, to reduce the number of domains sharing your IPs.
4. Pre-lower TTLs on any hostname serving a market with an active blocking regime.
5. Keep a second CDN configured and warm, carrying real traffic at a small percentage rather than sitting idle with stale config and expired certificates.
6. Evaluate a regional provider for markets where reachability is a revenue-critical requirement, accepting the feature and footprint trade honestly.
7. Consider BYOIP or leased static IPs if you have Enterprise scale and the market exposure justifies it — static IPs for neighbour risk, BYOIP for range-level risk. Start the process before you need it.

The decision framework

Three questions decide how much of this ladder applies to you.

‍

• Do you have revenue from a market with an active IP-blocking regime? If no, steps 1 and 2 are still worth doing and the rest is over-engineering. If yes, you need at least through step 5.
• Is the exposure collateral or direct? Collateral — someone else's content on your shared IP — is an infrastructure problem with infrastructure fixes. Direct — a lawful order about your content — is a legal problem, and no CDN change resolves it.
• How fast can you currently switch providers? Not "do you have a second CDN," but: certificates provisioned, config parity verified, TTLs low, contract already in place. If the honest answer is measured in weeks, that is the gap to close, regardless of which provider you use today.

‍

INXY brokers CDN capacity across multiple providers — including regional and specialist networks that do not appear on hyperscaler comparison pages — on a single contract and a single invoice. The practical consequence is that adding or switching a provider is a configuration decision rather than a procurement cycle, which is precisely the capability this risk requires. We will also tell you when your problem is ECH rather than IP blocking and costs nothing to fix, because a migration you did not need is not a sale worth making.

‍

If you have a market where traffic dropped and you are not sure why, send us the affected hostnames and the market. [Request an infrastructure audit → /book-a-demo]. To review delivery options: [CDN, streaming and data delivery → /data-delivery].

‍

This article describes publicly reported regulatory and network conditions for general information. It is not legal advice — obligations differ by jurisdiction and by the nature of the content being served, and decisions with regulatory consequence should be reviewed by qualified counsel in the relevant market.

FAQ

Why is my site blocked in a country when I have done nothing wrong? Hyperscale CDNs serve many customers from shared anycast IP ranges. When a regulator blocks by IP address rather than by domain, every site on that address becomes unreachable regardless of its content. Documented cases include a single blocked IP disrupting 325 unrelated domains in Italy.

‍

Is Cloudflare blocked in Russia? Not fully. Sites behind Cloudflare load from Russia but unreliably, due to ECH connection blocking, shared-IP collateral damage, and targeted blocks of individual resources. Roskomnadzor has officially recommended against foreign CDNs, which is a recommendation rather than a prohibition, but a clear regulatory signal.

‍

What is ECH and why does it break my site? Encrypted Client Hello is a TLS extension that encrypts the server name during the handshake. Cloudflare enables it by default, and some national networks block TLS connections using it. This produces intermittent unreachability that looks like IP blocking. Disabling ECH on the zone usually restores connections.

‍

How do I know if my CDN's IP ranges are blocked somewhere? Monitor from inside the affected market. Synthetic checks running from US or EU regions will pass while real users in the blocked market see nothing. Neither the regulator nor your CDN will notify you — in Italy the blocklist itself is not published, and Cloudflare has stated it generally cannot confirm government-directed blocking.

‍

Does switching CDN providers fix IP blocking? Only if the destination's IP ranges are not already listed in that market. Moving between two hyperscale anycast providers swaps one shared-IP exposure for another. Regional providers with local presence are less likely to be blocked in their own market, at the cost of smaller global footprint and different feature coverage.

‍

Can I get dedicated IP addresses from a CDN? Some providers offer it at Enterprise tier. Cloudflare's BYOIP announces IP space you lease or own across its network, and leased static IPs with address maps fix which addresses your domain resolves to. Note that Dedicated CDN Egress IPs are a different product governing Cloudflare-to-origin traffic, not the user-facing address.

‍

A colocation quote says "$15 per Mbps, 95th percentile." A cloud invoice says "$0.09 per GB." A dedicated server listing says "20 TB included, unmetered after." None of these numbers can be compared to each other until you know what each one is actually measuring — and that gap is where 95th percentile billing gets misread most often, in both directions. This is what the four models actually do, where each one shows up, and the one traffic pattern that makes 95th percentile expensive instead of cheap.

What 95th percentile actually measures

The mechanic is older than most of the infrastructure it now bills. A provider samples your bandwidth every five minutes — 288 samples a day, roughly 8,640 across a 30-day month — then sorts all the samples from highest to lowest and discards the top 5%. Whatever sample sits just below that cutoff becomes your billed rate for the month (Wikipedia, "Burstable billing"; Kentik, 2026).

‍

The consequence of that mechanic is the part worth internalizing: discarding the top 5% of a 30-day month gives you roughly 36 hours of unmetered headroom. You can burst to any level for a day and a half, spread across the month, and pay nothing extra for it (Wikipedia; major.io, 2026). That is the entire value proposition of the model — it absorbs short spikes without forcing you onto a higher committed rate, and it is why the model has been standard for internet transit and peering for over two decades.

‍

Two details in the fine print change the bill more than the headline rate does. First, direction: some providers bill the 95th percentile of the higher of inbound or outbound traffic; others average the two. Billing on the maximum of the two directions, rather than the average, can push the effective rate meaningfully higher for asymmetric workloads — a video-heavy site with outbound-dominant traffic is billed differently depending on which convention the contract uses, so this is a line worth reading before signing, not after the first invoice. Second, what counts as traffic: some DDoS-protected bandwidth products exclude attack traffic from the measurement entirely and only meter legitimate post-scrubbing traffic — a distinction that matters enormously if you are DDoS-protected and assumed the meter includes everything hitting your network (Alibaba Cloud documentation, 2026).

‍

‍

If you have read our breakdown of [cloud egress pricing → /blog/cloud-egress-fees-comparison], the metered row is the one that piece covers in depth. This article covers the other three, which is where colocation and dedicated-server buyers actually spend their negotiating time.

The one traffic pattern that breaks the model

95th percentile billing rewards spiky traffic and punishes sustained traffic, and most people intuit it backwards.

‍

Spiky is cheap. If your load is low most of the month with occasional bursts — a batch export job, a viral moment, a monthly report run — the discard window absorbs it. You are billed near your baseline, and the burst was functionally free.

‍

Sustained is expensive, and here is the mechanic that surprises people: because the calculation only discards the top 5%, a workload that runs hot most of the time gets almost no benefit from the discard. Worse, a single unusually heavy day — a product launch, a Monday traffic pattern that repeats weekly, a marketing push — can set the billed rate for the entire month if it lands inside the 95% that doesn't get discarded, rather than the 5% that does (major.io, 2026; Wikipedia). Many sites see their heaviest single day of the week determine the whole month's bill, precisely because that pattern is common enough not to fall in the discarded top 5%.

‍

This is the reverse of how metered billing works, where every byte costs the same regardless of when it moved. Under 95th percentile, when your traffic happens matters as much as how much of it there is.

Where each model actually shows up, and why

95th percentile dominates IP transit and peering because it was built for exactly that use case — bulk carriers with genuinely bursty aggregate traffic, where a fixed committed rate would either overcharge for headroom or undercharge for real peaks. It is also common in colocation contracts and DDoS-protected bandwidth, where the provider is reselling transit it bought the same way.

‍

Metered per-GB dominates cloud hyperscalers because their cost structure and customer base look nothing like a transit carrier's — highly variable per-customer usage, no meaningful volume discard, and a billing system built to itemize everything. There is essentially no 95th-percentile cloud product at hyperscaler scale.

‍

Unmetered and bundled dominate dedicated servers and VPS because the provider is selling you a port, not a byte count. A "20 TB unmetered after" server is really selling you a guaranteed connection speed with a soft usage ceiling attached for abuse prevention, not a precise 20 TB meter.

What no vendor will tell you

A provider that only offers a committed rate, with no 95th-percentile option, can be a signal about their network, not just their pricing philosophy. Practitioners who have run colocation deployments for years have flagged this directly: a datacenter that refuses to offer burstable billing, insisting on a flat committed rate instead, sometimes doesn't have the backbone headroom to absorb burst traffic across its customer base — burstable billing only works if the provider is genuinely oversubscribed in the statistical sense, banking on the fact that not all customers spike simultaneously (major.io, "Lessons learned: Five years of colocation," 2026). It's one of the first things INXY checks when qualifying a new bandwidth partner, and if a shortlisted provider won't do 95th percentile at all, ask why before assuming it's just a pricing preference.

‍

The inbound-vs-outbound billing convention is the negotiating point nobody raises. A provider billing on the higher of the two directions, instead of the average, is charging more for the identical traffic pattern than a provider using the average convention — and this is rarely called out clearly in a sales conversation. For asymmetric workloads (heavy egress, light ingress, or the reverse), ask which convention applies before comparing quoted rates, because the headline $/Mbps number is not comparable across providers until you know this.

What breaks in production

Your own monitoring doesn't match the provider's meter. If you're graphing bandwidth with a different sampling interval, a different discard rule, or router counters instead of the provider's measurement point, your internal dashboard and your invoice will disagree — sometimes by a meaningful margin. Ask the provider for their raw sample export, not just the monthly summary number.

‍

A recurring weekly pattern quietly becomes your permanent rate. A Monday-heavy traffic shape that repeats every week for a full month can settle into the 95th percentile as if it were your baseline, even though it only represents one day in seven. Reviewing daily, not just monthly, samples is the only way to catch this before it becomes a permanent line item.

‍

"Unmetered" gets confused with "unlimited." A bundled dedicated server transfer allowance is almost always capped by port speed, and abuse thresholds exist even on plans marketed as unmetered. Sustained saturation of a "1 Gbps unmetered" port can trigger a conversation with the provider that a metered plan would never have caused, because metered billing has no concept of "too much," only "billed."

‍

Billing method changes mid-relationship without much warning. Providers periodically retire or restrict specific burstable billing methods — Alibaba Cloud discontinued new sign-ups for its monthly 95th-percentile method for Anti-DDoS bandwidth in March 2026, moving customers toward the daily variant (Alibaba Cloud documentation, 2026). Check your contract's renewal terms for what happens if your specific billing method is deprecated.

How to pick correctly

Four questions, in order:

‍

1. Is your traffic genuinely spiky, or does it just look spiky on a monthly average? Pull daily, not monthly, granularity before assuming 95th percentile favors you. A workload that's "spiky" only because you've never looked at daily resolution is often sustained in disguise.
2. What's the billing direction convention? Max of inbound/outbound, or average? This changes the effective rate for asymmetric traffic more than the headline number does.
3. Do you need a hard ceiling, or genuine elasticity? Committed rate gives predictability at the cost of paying for unused headroom. 95th percentile gives elasticity at the cost of a bill that moves with your traffic shape.
4. Is DDoS-protected bandwidth in the mix? If so, confirm explicitly whether attack traffic counts toward your meter. This is a materially different product depending on the answer, and it is not always obvious from the sales page.

‍

Most of the disputes we see between infrastructure teams and providers on this topic aren't about the headline rate — they're about a billing convention nobody asked about until the first invoice. INXY brokers dedicated servers and colocation with the billing model matched to the actual traffic shape, not the default the provider happens to sell, because the "cheapest" $/Mbps number on a quote sheet is frequently not the cheapest bill once the direction convention and traffic pattern are accounted for.

‍

If you're comparing quotes right now, send us the traffic profile — daily granularity, not monthly averages — and we'll tell you which billing model actually wins for your shape before you sign anything. [Request an infrastructure audit → /book-a-demo]. To see the underlying capacity options: [dedicated servers, colocation and racks → /hosting-solutions].

FAQ

What is 95th percentile billing? A method that samples your bandwidth every five minutes across the month, discards the highest 5% of those samples, and bills you at the rate of the next-highest sample. It gives roughly 36 hours a month of unmetered burst headroom, which makes it favorable for spiky traffic and unfavorable for sustained high usage.

‍

Is 95th percentile billing cheaper than metered billing? It depends entirely on your traffic shape. For bursty workloads with real idle periods, 95th percentile is usually cheaper because the discard window absorbs the peaks. For sustained, consistently high traffic, metered per-GB billing can be more predictable, since 95th percentile offers little benefit when there's no meaningful low-traffic period to discard against.

‍

Why did my bandwidth bill spike from one bad day? Under 95th percentile billing, a single unusually heavy day can set the billed rate for the entire month if it falls within the 95% of samples that aren't discarded. A weekly-recurring traffic spike, such as a Monday pattern, is especially prone to this because it repeats often enough not to land in the discarded top 5%.

‍

What does "unmetered bandwidth" actually mean? It typically means there is no per-gigabyte charge up to the limit of your port speed, rather than truly unlimited transfer. The real ceiling is almost always the connection speed itself, and sustained saturation can trigger provider intervention even on plans marketed as unmetered.

‍

Does 95th percentile billing measure inbound or outbound traffic? It depends on the provider's convention. Some bill on whichever direction (inbound or outbound) is higher in a given sample; others bill on the average of the two. For asymmetric traffic patterns, this convention can materially change the effective cost, so it is worth confirming before comparing quotes across providers.

‍

Does DDoS attack traffic count toward my 95th percentile bill? It depends on the product. Some DDoS-protected bandwidth services explicitly exclude attack traffic from the billing measurement and only meter legitimate traffic that reaches your origin after scrubbing. This is not universal, so confirm it directly rather than assuming it from the marketing copy.

‍

At 10 TB per month of internet egress, list-price AWS is roughly $913, Azure $882, Google Cloud $1,137, and Cloudflare R2 zero (EgressCost.com, 2026). Same bytes, same month. That spread is not a rounding error — and it is not the whole bill either, because the charges that actually surprise teams sit on adjacent line items. This piece normalizes what the major providers charge in cloud egress fees, shows the four surcharges that never appear on the egress line, and gives you a test for when flat-rate bandwidth beats per-GB metering.

What the major providers actually charge

Egress pricing is tiered, regional, and quoted differently on every provider's page — which is why side-by-side numbers are rare. The table below normalizes entry rates and the modeled cost of 10 TB of internet egress per month in a standard US region.

‍

Rates verified by EgressCost.com against provider documentation in June–August 2026; AWS regional rates confirmed independently (CloudZero, 2026). Regional variation is significant and often missed — AWS Asia Pacific (Singapore) opens at $0.12/GB and Cape Town at $0.154/GB (CloudZero, 2026), so a us-east-1 estimate applied to an APAC deployment will understate the bill by a third or more.

‍

One mechanic that catches finance teams: AWS volume tiers are cumulative across services within an account and region, not per service. Five terabytes out of EC2 and six out of S3 in the same month land in the same meter. Read per-service cost breakdowns in isolation and you will model the wrong tier.

The four charges that never appear on the egress line

The headline $/GB is the part everyone budgets. These are the parts that show up in the post-mortem.

‍

NAT Gateway processing. AWS charges $0.045/GB for every byte through the gateway, plus roughly $0.045/hour per gateway. Three gateways for multi-AZ redundancy cost about $100/month before processing a single packet, and traffic bound for the internet pays gateway processing and standard egress (LeanOps, 2026).

‍

Cross-AZ traffic. $0.01/GB in each direction, so $0.02 round-trip. A chatty Kubernetes cluster spread across three availability zones generates this constantly. A cluster pushing 10 TB/month of inter-AZ traffic pays roughly $200/month in network fees that never leave AWS (LeanOps, 2026).

‍

Cross-region replication. Roughly $0.02/GB between US regions, billed on the source side. A 10 TB nightly replication to a European hot standby is on the order of $200/day (Bacancy, 2026) — a disaster-recovery decision that quietly became a networking decision.

‍

Public IPv4 addresses. AWS bills $0.005/hour per public IPv4 address, attached or idle — about $3.60/month each (Economize, 2026). Immaterial for one address, a real line item for a fleet of several hundred.

What changed in 2026

On 1 May 2026, Google Cloud raised list prices for CDN Interconnect, Direct Peering, and Carrier Peering, citing infrastructure investment (Google Cloud, 2026). The increase roughly doubled North American peering egress from $0.04 to $0.08 per GiB, with Europe moving $0.05 → $0.08 and Asia $0.06 → $0.085 (SpendArk, 2026).

‍

Standard internet egress did not change, so most workloads pay what they paid in April. The teams affected are the sophisticated ones. CDN Interconnect was the discounted lane that made Google Cloud Storage viable as a CDN origin, and it applies automatically to traffic destined for allowlisted CDN IP ranges — no configuration, no opt-in, no opt-out. If your origin sits in GCS and you serve through Cloudflare, Akamai, or Fastly, your origin-to-edge egress rate changed on 1 May and nothing in your Terraform did.

‍

That mechanic has a second-order consequence most teams miss: because the discount is tied to allowlisted CDN IPs, changing CDN provider can silently change your origin egress rate. Factor it into any delivery migration before you cut over — see [what actually breaks in a CDN migration → /blog/cdn-shutdown-migration-playbook].

Flat-rate bandwidth is a different product, priced differently

Outside the hyperscalers, bandwidth is usually bundled or flat-rated rather than metered per gigabyte.

‍

‍

Sources: Better Stack (2026), DEV Community (2026), APICalculators (2026). Hetzner's US regions have been reported as including materially less transfer than EU regions — verify the allowance for your specific location before modeling, because that single line changes the arithmetic completely.

‍

The gap is real: a media-heavy workload at 10 TB/month sits inside Hetzner's included allowance and costs roughly $40/month in DigitalOcean overage on top of the instance. At AWS list rates the same traffic is around $913.

‍

Here is the part no bandwidth provider will put in a comparison table: a €1/TB provider and a $90/TB provider are not selling the same product. What you buy at the higher price is transit blend quality, peering density, burst headroom, and the ability to absorb an unannounced traffic spike without your network engineer's phone ringing. Cheap bandwidth is often a thinner blend with more single-homed paths, which shows up as p95 latency variance and packet loss on specific eyeball networks rather than as an outage. If you are serving an API to a global audience, model the transit blend, not just the price. If you are serving static assets through a CDN anyway, the origin's transit quality matters far less and the cheap bandwidth is close to free money.

‍

This is the trade INXY prices for clients weekly: bundled or unmetered transfer on [dedicated and cloud servers → /hosting-solutions] where the transit blend is fit for the workload, rather than the cheapest per-terabyte number on the market.

Why the EU Data Act will not cut your monthly bill

Regulation (EU) 2023/2854 has applied since 12 September 2025. Article 29 phases out switching charges: until 12 January 2027 providers may charge only reduced fees limited to costs directly linked to the switch, and from that date they may impose no switching charges at all — a prohibition that expressly captures data egress charges levied for the purpose of switching (Pinsent Masons, 2025; Turing Law, 2025).

‍

The three largest providers moved ahead of the deadline with free-exit programmes: Google announced one on 11 January 2024, AWS on 5 March 2024, and Microsoft on 13 March 2024 (UK Competition and Markets Authority, Appendix N).

‍

Now the caveat that the compliance blog posts skip. The Data Act removes the penalty for leaving. It does not make the service cheaper while you stay. Two consequences follow:

‍

1. Multi-cloud egress is explicitly carved out. Charges remain permitted for egress conducted for in-parallel use of services, on the reasoning that multi-cloud deployment is ongoing data movement rather than a one-off switching operation (Pinsent Masons, 2025), with Article 34(2) allowing those costs to be passed through at cost. If your architecture runs continuously across two providers, the 2027 date does nothing for that line item.
2. The cost will look for somewhere else to live. A prohibition on switching charges does not remove the commercial instinct behind it. Expect pressure to migrate into support tiers, minimum commitments, premium networking, and the categories the regulation leaves standing.

‍

Free-exit programmes are also one-time and conditional on actually leaving. They are not a discount you can apply to a running workload.

How to audit your egress in one afternoon

1. Pull 90 days of billing data grouped by usage type, not by service. On AWS, the usage types you want are DataTransfer-Out-Bytes, NatGateway-Bytes, and the regional DataTransfer-Regional-Bytes codes. Grouping by service hides the cumulative tier.
2. Split internet egress from internal transfer. These have different fixes. Internet egress is a delivery-architecture problem; cross-AZ and NAT are a topology problem.
3. Find your p95, not your average. Egress is spiky. A monthly average tells you what you paid; the p95 tells you what a flat-rate or 95th-percentile contract would actually cost. If p95 is more than roughly twice your mean, per-GB metering is punishing you for a traffic shape a committed-rate contract would absorb.
4. Check what fraction is cacheable. Static assets, media segments, and installer binaries served directly from object storage are the cheapest thing to fix — putting a [CDN in front of the origin → /data-delivery] converts origin egress into cache-fill traffic, typically an order of magnitude less volume.
5. Inventory public IPv4 addresses and idle NAT gateways. Both bill whether or not they carry traffic.
6. Model the same volume against one flat-rate and one zero-egress provider. Not to migrate — to know your negotiating position. A concrete alternative quote is the only leverage that reliably moves an enterprise discount.

‍

If step 6 is the one you keep postponing, that is the part we do for free: send the usage-type export and we will model it across the networks we broker. [Request an infrastructure audit → /book-a-demo].

What breaks in production

Assuming the CDN eliminates egress. It relocates it. You still pay origin-to-edge cache fill, and if your cache hit ratio is poor — short TTLs, high cardinality cache keys, query strings not normalized — the cache-fill bill can approach what you were paying before. Measure cache hit ratio by content type before crediting the CDN with savings.

‍

Modeling in decimal terabytes when the provider bills in binary. A 10 TB estimate is 10,000 GB or 10,240 GB depending on the convention, a 2.4% error that compounds at petabyte scale. Pin the convention before presenting the number to finance.

‍

Ignoring request pricing on zero-egress storage. R2's Class A operations run $4.50 per million (LeanOps, 2026). A workload with millions of small writes can hand back a meaningful share of the egress savings.

‍

Treating a free-exit programme as a migration budget. It covers the data transfer out. It does not cover dual-running two environments, the engineering time, or the period where you pay both providers.

‍

Optimizing egress and creating a latency problem. Google Cloud Standard Tier is cheaper than Premium because traffic exits closer to the source and traverses the public internet for longer. That is the correct trade for backups and batch export. It is the wrong trade for an interactive API where p99 is a product requirement.

The decision framework

Four questions, in order:

‍

1. Is the traffic cacheable? If yes, the fix is delivery architecture, not a provider switch. Put a CDN in front and measure cache hit ratio.
2. Is the traffic spiky? If p95 is far above the mean, look at committed-rate or flat-rate bandwidth. Per-GB metering charges you for the peak shape.
3. Is it egress-dominant relative to storage? If bandwidth outweighs storage on your bill, [S3-compatible object storage → /s3-compatible-object-storage-for-business] changes the economics outright, because the egress line stops scaling with delivery volume. If your data mostly sits untouched, the reverse applies — you would be paying a storage premium for an egress benefit you do not use.
4. Is p99 latency a product requirement? If yes, the cheapest transit blend is not the answer, and the comparison table above stops being the whole picture.

‍

Most teams that come to INXY with an egress problem have a delivery-architecture problem and a contract problem, in that order. We broker bandwidth, CDN capacity and object storage across multiple vendors on a single invoice, which means we can model your actual traffic against several networks and tell you when the answer is "stay where you are and renegotiate" — a conclusion no single provider is structurally able to reach.

‍

The concrete next step is not a sales call. Send your last 90 days of billing data grouped by usage type and we will return a modeled comparison across the providers that fit your traffic shape, including the case for staying put. [Request an infrastructure audit → /book-a-demo]. If you would rather look at the components first: [CDN, streaming and data delivery → /data-delivery], [dedicated and cloud servers → /hosting-solutions], or [S3-compatible object storage → /s3-compatible-object-storage-for-business].

FAQ

How much does cloud egress cost per GB in 2026? Entry rates for internet egress are $0.09/GB on AWS, $0.087/GB on Azure, and $0.12/GB on Google Cloud Premium Tier. Cloudflare R2 charges nothing for egress. All three hyperscalers tier downward with volume, and AWS and Azure converge at $0.07/GB above 50 TB and $0.05/GB above 150 TB per month.

‍

Does the EU Data Act ban egress fees? From 12 January 2027, providers serving EU customers may not charge switching fees, and that ban expressly covers egress charges incurred to switch providers. It does not ban egress charges for ongoing use, and it explicitly permits charging for data egress in in-parallel multi-cloud deployments. Your running bill is unaffected.

‍

Why did my Google Cloud networking bill increase in May 2026? Google raised list prices for CDN Interconnect, Direct Peering, and Carrier Peering effective 1 May 2026, roughly doubling North American peering egress from $0.04 to $0.08 per GiB. Standard internet egress was unchanged. The increase applies automatically to traffic bound for allowlisted CDN IP ranges, with no configuration change required.

‍

Is Cloudflare R2 actually free for egress? R2 charges $0.00/GB for egress at any volume, with no fair-use cap. You pay for storage at $0.015/GB-month and for API operations, with Class A operations at $4.50 per million. For write-heavy or request-heavy workloads, operations cost can offset a meaningful share of the egress saving.

‍

Should I use a CDN to reduce egress fees? A CDN converts origin egress into cache-fill traffic, which is typically an order of magnitude smaller. The saving depends entirely on cache hit ratio. Short TTLs, unnormalized query strings, and personalized responses all push traffic back to origin, and a poorly configured CDN can produce cache-fill costs close to your original egress bill.

‍

What is the cheapest bandwidth for high-traffic workloads? Flat-rate and bundled-transfer providers price far below hyperscaler metering — roughly €1/TB in overage versus around $90/TB at AWS entry rates. The trade is transit blend quality and burst headroom. For CDN-fronted static content the cheap option is usually correct; for latency-sensitive traffic served directly from origin, it usually is not.

‍

‍

Written by Igor Kirichenko, Senior Infrastructure Solutions Architect at INXY Hosting. INXY is a vendor-agnostic infrastructure marketplace and consultancy, brokering bandwidth, CDN, object storage and dedicated capacity across multiple providers on a single invoice.

‍

Published 29 August 2026. All rates are list prices verified against provider documentation at time of publication. Cloud pricing changes frequently; this page is reviewed quarterly and rates should be confirmed against the provider before budgeting.

‍

Edgio told customers its platform would run until November 2025. It went dark on 15 January 2025, taking with it 300 points of presence, more than 7,000 ISP interconnections, and over 275 Tbps of capacity serving roughly 935 customers (DataCenterDynamics, 2024; elevenflo, 2026). Amazon Prime Video, Sony, Samsung and Microsoft's Azure CDN were all on it. This is the third CDN exit in three years, and the pattern is stable enough to plan against. This is the CDN migration sequence we run when the wind-down date is not negotiable.

Sources: DataCenterDynamics (2024), Telecoms.com (2023), elevenflo (2026), Streaming Media Blog (2026).

‍

Read the right-hand column twice. In all three cases Akamai acquired contracts, not assets. No network transferred. That distinction is the single most consequential fact in this article, and it is the one most coverage buries.

‍

If your contract "moves to Akamai," you are not being migrated in any technical sense. You are being sold a new service on a different network with different peering relationships, a different PoP footprint, a different cache architecture, and different configuration semantics. Your commercial relationship has continuity. Your p95 latency, your cache hit ratio, and your config do not. Teams that treat a contract transfer as a paperwork exercise discover this in production.

‍

The market context matters for how you plan: the vendor pool shrank from 2023 to 2026 while total CDN delivery revenue was flat to down by low single digits (Streaming Media Blog, 2026). Akamai reported $1.25 billion in delivery revenue for 2025, down 5% year over year — and that figure included the acquired Edgio, StackPath and Lumen contracts, without which delivery revenue would have fallen close to 9% (Streaming Media Blog, 2026). Delivery is a shrinking-margin business with a consolidating supplier base. Plan for more of these events, not fewer.

The wind-down date is not a promise

Edgio's commitment ran to November 2025. The actual shutdown was 15 January 2025 — and even that date came with a caveat. Microsoft told Azure customers it could not guarantee Edgio would not cease operations earlier due to circumstances beyond its control, froze configuration changes on Edgio profiles from 3 January, and force-migrated workloads from 7 January for anyone who had not acted (Microsoft Learn).

‍

The mechanic behind this is worth understanding, because it repeats. During a Chapter 11 wind-down, the network stays up only as long as someone funds it. Akamai agreed to pay certain costs for Edgio to operate its network through the transition (DataCenterDynamics, 2024). That funding is a commercial arrangement between two parties, neither of which is you.

‍

Treat any announced wind-down date as the latest possible date, not the expected one, and assume the configuration freeze lands two weeks before it. The freeze is the deadline that actually binds you, because after it you cannot change origins, purge, or add hostnames on the dying platform.

What actually breaks, in order of how badly

The CNAME swap is the easy part. Here is what determines whether the cutover takes three weeks or three months.

‍

‍

The three at the top are where forced migrations go over schedule. If you serve paywalled video or protected downloads, your signed-URL scheme is the critical path, not your DNS. In the migrations INXY runs, that single dependency sets the timeline more often than any other factor, and it is almost never the one teams plan around first.

‍

The WAF row deserves separate planning. Managed rulesets differ enough between providers that a ruleset which was quiet for two years will generate false positives on day one somewhere else. Budget a tuning cycle, or decouple the decision entirely by running [WAF and DDoS protection → /security-and-protection] independently of the delivery layer, so a future CDN change does not force a security re-tune at the same time.

The 30-day cutover sequence

1. Days 1–3: Inventory every hostname and every consumer of it. Not just what is in your CDN dashboard — grep the codebase, the mobile app source, installer scripts, CI configuration, partner integrations and documentation for the CDN hostname. This is the step teams skip and regret. When Edgio went down, dotnetcli.azureedge.net and dotnetbuilds.azureedge.net were baked into .NET install scripts, Docker configurations and CI/CD pipelines across the ecosystem, forcing Microsoft to stand up replacement domains and ask every downstream consumer to update references (The Hacker News, 2025). Anything compiled into a shipped mobile binary cannot be cut over on your schedule at all — it moves at app-store release cadence.
2. Days 1–3, in parallel: Export the full current configuration and the last 30 days of logs. Configuration and log access die with the platform, sometimes before the traffic does. You need the logs to validate cache hit ratio parity afterwards, and you cannot get them retroactively.
3. Days 3–7: Shortlist on the constraints that are hard to change, not on price. Signed-URL compatibility, edge-compute requirements, PoP coverage in your top five eyeball networks, and log format. Price is negotiable in an emergency. Token-scheme compatibility is not.
4. Days 5–10: Provision certificates for every hostname on the new provider. Start early. Let's Encrypt enforces issuance rate limits per registered domain, and an emergency migration of dozens of subdomains is exactly the shape of request that hits them. If you control your own certificates, import rather than reissue.
5. Days 7–14: Build config parity and run the new provider in log-only mode. Deploy WAF rules in detection mode, replicate cache rules, and put a test hostname live on the new CDN pointing at the same origin. Compare cache hit ratio by content type against the exported baseline. A hit-ratio gap here is a configuration bug, and it is far cheaper to find now than during cutover.
6. Days 14–18: Implement dual-token validation. Your origin should accept both the old and new signed-URL schemes for the duration of the migration. Without this, every cached player session and every in-flight download breaks at the moment of cutover.
7. Days 18–21: Lower DNS TTLs to 60 seconds and let the old TTL expire fully. If your records have been sitting at 86,400, you need a full day at the old value before the new low TTL is universally observed. Do this before you need it.
8. Days 21–24: Pre-warm the new edge. A cold cache means every request is an origin miss. Cutting a high-traffic property over to an empty cache produces a thundering herd against origin at exactly the moment you have the least tolerance for it. Warm the top-N objects by request volume, and confirm origin shield is enabled and configured before you send real traffic. If your [origin servers → /hosting-solutions] were sized against a warm-cache baseline, this is the step that exposes it.
9. Days 24–27: Cut over by weight, not by switch. Move 5% of traffic, hold, watch origin load, error rate and p95 latency by region. Then 25%, then 50%, then 100%. Weighted DNS gives you a rollback that takes one TTL rather than one incident review.
10. Days 27–30: Validate, then decommission. Reconcile the first full billing period against modeled volume, confirm log pipelines and SIEM ingestion, retire dual-token validation only after the longest signed-URL expiry window has passed, and raise DNS TTLs back to normal.

‍

Thirty days assumes you have the engineering capacity to run this alongside your roadmap. Most teams holding a wind-down notice do not. If that is your situation, [managed migration and DevOps support → /devops-and-management-solutions] is the difference between hitting the freeze date and negotiating with a bankruptcy trustee.

What no vendor will tell you

Consolidating onto the survivor re-concentrates the risk you just got burned by. The default response to a CDN failure is to accept the acquirer's contract, because it is the path of least resistance during an emergency. But the reason you are in an emergency is single-provider concentration, and the acquirer is by definition a provider in a consolidating market with shrinking delivery margins. You have solved the immediate incident and preserved the structural exposure.

‍

Switching CDN can silently change your origin egress bill. Google Cloud's CDN Interconnect discount applies automatically to traffic destined for allowlisted CDN IP ranges — no configuration required. Move your delivery to a provider outside that allowlist and your origin-to-edge traffic reprices to standard internet egress. Google also roughly doubled CDN Interconnect and peering list prices on 1 May 2026, from $0.04 to $0.08 per GiB in North America (Google Cloud, 2026; SpendArk, 2026). If your origin is in GCS, model the origin-side cost of each CDN candidate before shortlisting. Most CDN comparisons never mention it because the charge appears on a different provider's invoice. We cover the mechanics in [our breakdown of cloud egress pricing → /blog/cloud-egress-fees-comparison].

‍

"Multi-CDN" bought as insurance and never exercised is not insurance. A second provider with a stale configuration, expired certificates and an untested failover path will not save you at 3am. If you run multi-CDN, run real traffic through both continuously, even at a 90/10 split, and rotate which one carries the majority once a quarter.

What breaks in production

The cache hit ratio drops and nobody notices for a week. Different providers derive cache keys differently. The config looks equivalent; the hit ratio is not. Origin load and origin egress both rise, and if you are not monitoring hit ratio by content type you will see it first on the bill.

‍

Purge stops working mid-deploy. Release pipelines that call the old provider's purge API keep returning success against a dead endpoint, or fail the build. Audit every automation that touches the CDN, not just the CDN itself.

‍

Geo-routing behaves differently. Anycast footprints differ. A user population that was served from Frankfurt may land in Amsterdam. Usually fine; occasionally it breaks a geo-fencing or licensing rule that was implicitly relying on the old topology.

‍

The old provider's logs disappear before your finance team reconciles the final invoice. Export before, not after.

‍

Rollback is impossible after the freeze. Once the dying platform stops accepting configuration changes, your rollback path is gone. Complete the cutover before the freeze, not before the shutdown.

How to buy so this is never an emergency again

Four contract and architecture decisions, worth more than any provider comparison:

‍

1. Abstract the hostname. Serve assets from a hostname you control, on DNS you control, with the CDN behind a CNAME. Never publish a provider-owned hostname into a client, an installer, or a mobile binary.
2. Keep the signed-URL scheme in your application layer where you can support two providers simultaneously, rather than delegating it entirely to the edge.
3. Negotiate configuration export and log portability into the contract. In writing, with a defined format. It costs nothing at signing and is unobtainable during a bankruptcy.
4. Avoid deep edge-compute lock-in for logic that could live at origin. Edge compute is the least portable thing you can adopt, and the switching cost is invisible until the day you need to switch.

The decision framework

When a shutdown notice lands, answer three questions before you shortlist anything:

‍

• What is my configuration freeze date? Work backwards from that, not from the shutdown date. It is typically the real deadline.
• What is my least portable dependency — tokens, edge compute, or WAF? That dependency sets the migration timeline and eliminates most candidate providers. Choose against it, not against price.
• Am I re-concentrating? If the answer to the emergency is one provider again, you have deferred the same incident rather than resolved it.

‍

INXY brokers CDN capacity across multiple vendors on a single contract and a single invoice, which is what makes the fourth option available: adding or removing a provider without a new procurement cycle, and running a warm second CDN without doubling your commercial overhead. It also means we can tell you when the acquirer's offer is genuinely the right landing spot — a conclusion a CDN vendor cannot credibly reach about its own bid.

‍

If you are holding a wind-down notice, the fastest useful step is a compatibility check, not a quote. Send your current configuration export and traffic profile and we will tell you which providers can actually accept your token scheme and match your PoP coverage, before you spend a week shortlisting ones that cannot. [Request an infrastructure audit → /book-a-demo]. If you would rather review the components first: [CDN, streaming and data delivery → /data-delivery], [dedicated servers, colocation and racks → /hosting-solutions], or [WAF, anti-DDoS and edge security → /security-and-protection].

FAQ

What happens when a CDN provider shuts down? Service ends on a published wind-down date, but configuration changes are typically frozen one to two weeks earlier, and the date can move in if funding for the network fails. Customer contracts are often sold to another provider without any network or technology transferring, which means the acquirer is a new deployment rather than a continuation.

‍

How long does a CDN migration take? For a straightforward static-asset workload, two to four weeks including validation. Properties using signed URLs, edge compute, or a tuned WAF ruleset take considerably longer, because those components are provider-proprietary and require application changes rather than configuration translation. Inventory your least portable dependency first — it sets the timeline.

‍

Did Edgio customers automatically move to Akamai? Akamai acquired Edgio's customer contracts, not its network, technology or personnel. Affected customers had to deploy onto Akamai's infrastructure as a new implementation. Microsoft separately force-migrated Azure CDN from Edgio workloads to Azure Front Door from 7 January 2025 for customers who had not acted, describing the automatic path as best-effort.

‍

Should I switch to multi-CDN after a provider failure? Multi-CDN removes single-provider concentration, but only if both providers carry real traffic continuously. A standby CDN with stale configuration and expired certificates fails when you need it. Below a certain traffic volume the operational overhead of maintaining config parity across two providers can exceed the resilience benefit.

‍

Why does my cache hit ratio drop after migrating CDNs? Providers derive cache keys differently — query-string handling, header inclusion, cookie variance and device-class segmentation all vary. A configuration that looks equivalent can fragment the cache and produce more origin misses. Compare hit ratio by content type against your pre-migration baseline, which is why exporting logs before the old platform goes dark matters.

‍

Can changing CDN affect my cloud bill? Yes. Google Cloud's CDN Interconnect discount applies automatically to traffic bound for allowlisted CDN IP ranges. Moving delivery to a provider outside that allowlist reprices origin-to-edge traffic at standard internet egress rates. Google roughly doubled peering list prices in North America on 1 May 2026, making this a larger consideration than it was previously.

‍

‍

Written by Dmitry Schulz, Senior Infrastructure Solutions Architect at INXY Hosting. INXY is a vendor-agnostic infrastructure marketplace and consultancy, brokering dedicated servers, CDN, colocation and cloud capacity across multiple providers on a single contract.

‍

Published 29 August 2026. Provider exit dates and pricing verified at time of publication; CDN market conditions change and this page is reviewed quarterly.

‍