In one of my previous jobs, I used a company hackathon to look at the CDN costs. I had a hunch the company was overpaying and wanted to see if there was anything to optimise. There was. The CDN spend was roughly equivalent to the salary of one engineer in Switzerland.
That kicked off a few months of digging into bandwidth costs, provider differences, data sovereignty, and internal policies. Here is what I found.
Hyperscalers are expensive
| Provider | EU-EU | vs AWS CloudFront |
|---|---|---|
| AWS CloudFront | $0.085/GB | baseline |
| Google Cloud CDN | $0.08/GiB | 1.06x cheaper |
| Azure CDN Standard | $0.081/GB | 1.05x cheaper |
| KeyCDN | $0.040/GB | 2.1x cheaper |
| Gcore CDN | $0.033/GB | 2.6x cheaper |
| Bunny Standard | $0.010/GB | 8.5x cheaper |
| Bunny Volume | $0.005/GB | 17x cheaper |
EU-EU egress, first volume tier, 2026.
Why such a price difference?
The answer is mostly infrastructure. A CDN is a network of servers spread across the world: the more points of presence (PoPs), the closer the content is to any given user, and the faster the delivery. AWS CloudFront runs 750+ standard PoPs plus 1,140 embedded nodes inside ISP networks. That is an enormous amount of hardware to maintain, insure, and staff. The price reflects it.
Bunny's Volume Network, at 10 PoPs, covers the main internet exchange points and gives you solid performance for bulk traffic at a fraction of the cost. For most use cases, static assets, software downloads, video on demand, you will not notice the difference. Where you will notice is latency for users in less-covered regions, and in the SLA: fewer PoPs means fewer redundant paths, which is why the gap in PoP count does not fully translate into a gap in reliability.
The SLA number is also worth reading carefully. A 99.9% SLA means up to 8.7 hours of allowed downtime per year. A 99.99% SLA means 52 minutes. But all of these are measured as monthly uptime, and the compensation is credits, not refunds. The practical difference between providers at this level is mostly in how fast they respond when something goes wrong, not in whether something will go wrong.
| Provider | PoPs | SLA |
|---|---|---|
| AWS CloudFront | 750+ (+ 1,140 embedded ISP) | 99.9% |
| Google Cloud CDN | 100+ cache locations | 99.95% |
| Azure CDN Standard | 192 PoPs, 109 metro cities | 99.9% |
| Gcore CDN | 210+ PoPs | ~99.9% |
| KeyCDN | 60+ PoPs | 99.99% |
| Bunny Standard | 119 PoPs | 99.99% |
| Bunny Volume | 10 PoPs | 99.99% |
Azure CDN Standard from Microsoft is being retired September 2027; the successor is Azure Front Door.
Data privacy, not born equal
Price is not the only variable. The country of incorporation of your CDN provider determines who can legally compel access to the data flowing through it. US providers are subject to the CLOUD Act, which allows US law enforcement to demand data from any US company regardless of where the servers are located. The EU subsidiaries that AWS, Google and Microsoft use for EMEA billing do not change this: the statute reaches the entire corporate group.
The cheaper alternatives in this table are not US companies. KeyCDN is Swiss, which benefits from an EU adequacy decision meaning GDPR transfers require no additional safeguards. Gcore is incorporated in Luxembourg and Bunny.net in Slovenia, both EU member states, making GDPR the native framework with no cross-border transfer mechanism needed. For a personal blog this does not matter much. It mattered a great deal in my previous job: a Swiss GDPR-compliant company with millions of users across the world. Picking a CDN was not just a performance and cost decision, it was a compliance one. A US provider, even with an EU subsidiary, creates a paper trail that your legal team has to justify. A Slovenian or Luxembourg CDN does not.
| Provider | Legal entity | Country | CLOUD Act risk | GDPR basis |
|---|---|---|---|---|
| AWS CloudFront | Amazon Web Services, Inc. | USA (Delaware) | Yes | EU-US Data Privacy Framework (contested) |
| Google Cloud CDN | Google LLC | USA (Delaware) | Yes | EU-US Data Privacy Framework (contested) |
| Azure CDN Standard | Microsoft Corporation | USA (Washington) | Yes | SCCs between Irish subsidiary and US parent |
| KeyCDN | proinity Holding GmbH | Switzerland | No | Swiss adequacy decision |
| Gcore CDN | G-Core Labs S.A. | Luxembourg (EU) | No | Native GDPR, CNPD supervisory authority |
| Bunny.net | BunnyWay d.o.o. | Slovenia (EU) | No | Native GDPR |
All three US providers have EU contracting subsidiaries but the US CLOUD Act reaches any data in the possession or control of a US-incorporated parent, regardless of where subsidiaries are incorporated.
Do it yourself
I looked at running a self-hosted setup. The idea: rent a few VPS instances from Hetzner at strategic locations, provision them with Vagrant, manage the fleet with Kubernetes. Hetzner sells 10 Gb/s uplinks for a handful of euros a month. At that bandwidth the per-GB cost becomes so small it barely registers, and you end up with a self-managed edge network that on paper looks like a bargain. The problem is Bunny high volume, which would have cost roughly $5,000 for the same traffic the company was paying a Swiss engineer's salary for on a hyperscaler.
The internal crusade
The technical case was straightforward. Getting buy-in from the organisation required a bit more work.
Management had questions. The company ran an "all-hyperscaler strategy", and that was not an accident. One contract, one invoice. Moving even part of the CDN spend to an independent provider meant a new vendor relationship, a new billing line, and a perceived increase in complexity that someone would have to justify to finance. The argument that it would save the equivalent of an engineering headcount per year helped, and they were supportive once the numbers were on the table.
The engineering team had a different concern. They were not worried about bills. They were worried about the customers. The platform served millions of users globally, and any regression in delivery quality would show up immediately in support tickets, churn, and conversion. Switching CDN providers and hoping for the best was not a proposal anyone was going to accept.
A proper test was set up. A multi-factor A/B router split traffic based on country, device type, ISP, and measured latency. Cohorts were chosen carefully: free users in markets with historically low conversion rates, not generating significant revenue, which meant the risk of a bad experience was contained and the signal clean. Premium partners were explicitly excluded. They kept the hyperscaler experience throughout.
Everything was measured. Download times, time to first byte, error rates, session length, conversion. The test ran long enough to reach statistical significance across enough countries to be confident the results generalised.
The outcome: static asset delivery was on average 0.3 seconds slower under the new CDN. In isolation that sounds alarming. In practice it was imperceptible. The frontend had been built with enough care around loading states, progressive rendering, and perceived performance that users did not notice. None of the measured metrics moved in a meaningful direction. The quality concern was real and worth taking seriously. It just turned out not to be a blocker.
That data closed the argument. Management got the cost reduction without a customer impact story to explain away. Engineering got the evidence they needed to feel comfortable with the switch. From first proposal to full migration it took a few months, most of it spent on the A/B test runtime and diverse depths of tests and analyses (trying on more and more users gradually).
Results
85% of the traffic ended up routed through Bunny high volume, 16x cheaper per GiB than the hyperscaler we used. The remaining 15% stayed on the original hyperscaler for premium partners, a deliberate choice to preserve the experience for the highest-value users. Blended across the full traffic mix, that is an 80% reduction in CDN spend. The Swiss engineer's salary was back in the budget.