What if the CDN bill that wrecks a game studio’s budget next year isn’t caused by traffic growth at all, but by a caching decision someone made in a sprint three years ago? That sounds dramatic until you look at how patch delivery actually works. Game CDNs move enormous binary files to players who re-download them constantly, and the difference between a well-architected delivery pipeline and a sloppy one can swing costs by an order of magnitude, far more than picking the “cheapest” vendor ever will. (Content delivery network)
This piece looks at Bunny.net, Cloudflare, and Fastly through that lens. Not “which is cheapest per gigabyte,” because that comparison is mostly noise. Instead, it walks through the architecture decisions that determine what a game CDN actually costs, and how those decisions will matter heading into 2027.
Why per-gigabyte pricing comparisons mislead game studios
The first mistake teams make is lining up three vendor pricing pages and picking the lowest number. It feels rigorous. It isn’t, for three reasons.
The billing models aren’t the same shape. Cloudflare’s free tier has long included CDN caching with unmetered bandwidth, which makes a per-GB comparison structurally unfair for anyone who fits inside a flat plan. Bunny.net has historically positioned itself as volume-based with a low per-GB rate and no minimum commitment. Fastly has centered on committed monthly spend plus usage rather than a simple retail per-GB rate. Comparing those three as if they were interchangeable is like comparing a taxi meter, a monthly transit pass, and a corporate car lease.
Included features differ. Edge compute, instant purge, image optimization, and log streaming are bundled or priced differently by each vendor. A game studio that needs programmable edge logic is comparing a different product than one that only needs static file delivery.
List prices change. Any figure quoted today should be treated as a snapshot with a date attached. Vendor pricing pages are the only source of truth, and they move.
The metric that actually matters
For game workloads, egress volume dominates the bill, not request counts. Builds and patches are large objects fetched repeatedly by many players. That makes GB delivered the number to obsess over, which is exactly why cache hit ratio matters more than list price.
Here’s the mechanism. A CDN with a high hit ratio serves most requests from edge nodes close to the player. A CDN with a low hit ratio keeps reaching back to origin, and origin egress plus compute costs pile up on top of CDN costs. Two vendors with identical per-GB rates can produce wildly different invoices if one of them is hitting 95 percent and the other is hitting 70 percent.
The architecture decision that changes everything: immutable, content-addressed builds
Before comparing vendors, understand the decision that reshapes the comparison entirely.
Game patches are typically immutable and content-addressed. A given URL always maps to the same bytes. Version 1.4.2 of a build file never changes; a new patch gets a new path. This is a deliberate pattern, and it has a huge cost consequence: it allows extremely long cache TTLs, because there’s no reason to revalidate something that can never change.
The HTTP caching standard defines exactly how freshness and revalidation work, and reading the primary specification on HTTP caching semantics is worth an hour of any infrastructure lead’s time. The short version: `Cache-Control: public, max-age=31536000, immutable` on a content-addressed artifact tells every layer of the stack to hold onto it for a year and never ask again.
When a studio gets this right, hit ratios climb into the high nineties and stay there. When a studio serves patches from mutable URLs, or forgets cache headers, or lets a CDN’s default TTL apply to a 4 GB patch file, origin traffic explodes and every vendor becomes expensive.
Practical tip: audit your cache headers before you audit your vendor contract. In practice, teams that switch CDNs to save money often discover after the migration that their hit ratio was the problem all along, and the new vendor just inherited it.
How each vendor’s architecture shapes cost
Cloudflare: anycast, flat fees, and a free tier that distorts comparisons
Cloudflare runs a large anycast network with a strong emphasis on breadth of edge presence, and its cache behavior is documented in detail in the Cloudflare cache documentation, which is the right starting point for understanding TTL and tiered caching behavior.
The cost implication is unusual. Because the free tier includes CDN caching with unmetered bandwidth, a studio whose delivery fits within plan limits may pay nothing for egress at all. That makes Cloudflare structurally different from the other two: for some workloads, the per-GB conversation never happens.
The trade-off is that “free” comes with limits on what’s included, and heavy game delivery may push into paid tiers or require features that change the economics. It’s worth reading a breakdown of the real Xbox Game Pass cost 2025 figures and whether it’s worth it if you want a sense of how subscription-style pricing models hide their true cost in tier boundaries, because CDN plans work the same way.
Bunny.net: simplicity and low per-GB rates
Bunny.net’s differentiator has historically been straightforward configuration and low per-GB pricing, with regional tiers priced differently. Its documentation portal covers pull zone behavior and cache configuration in detail.
For game studios, the appeal is obvious: predictable, low per-GB rates for large object delivery, without an enterprise contract negotiation. The limitation is that Bunny has traditionally offered fewer programmable edge features than Cloudflare Workers or Fastly Compute, so if your delivery pipeline needs custom logic at the edge, you may end up pairing Bunny with something else.
The architecture question to ask: does your hit ratio depend on edge logic, or just on good cache headers? If it’s the latter, Bunny’s simpler model often wins on cost. If it’s the former, you’re comparing a CDN plus a separate compute layer against an integrated one.
Fastly: committed spend, instant purge, programmable edge
Fastly’s model has centered on committed monthly spend plus usage, with a network built from a smaller number of larger points of presence and a strong emphasis on instant purge and programmable edge computing.
For live-ops teams, instant purge matters. When a bad build ships and needs pulling in seconds, purge latency is an operational feature, not a nice-to-have. Fastly’s developer documentation on caching concepts explains how purge and TTL interact, and it’s genuinely useful reading even if you don’t pick Fastly.
The cost implication: committed spend means you’re forecasting volume, and forecasting wrong in either direction has consequences. Under-forecast and you pay overage. Over-forecast and you’ve bought capacity you didn’t use. That’s a finance conversation as much as an engineering one.
A comparison that respects the differences
| Dimension | Cloudflare | Bunny.net | Fastly |
|---|---|---|---|
| Billing shape | Flat plans plus free tier with unmetered bandwidth | Low per-GB, volume-based, no minimum commitment | Committed monthly spend plus usage |
| Per-GB comparison fairness | Poor, because flat fees distort it | Good, closest to a true per-GB rate | Poor, because commitment levels vary |
| Edge compute | Workers, mature ecosystem | Fewer programmable features historically | Compute, strong programmable edge heritage |
| Purge behavior | Fast, global anycast | Straightforward, less emphasized | Instant purge is a core selling point |
| Best fit | Workloads inside flat-plan limits | Large static delivery on a budget | Live-ops needing instant purge and edge logic |
Notice what the table doesn’t say: it doesn’t crown a winner. That’s because the answer depends on which row your workload stresses.
Multi-CDN: the decision that outranks vendor choice
Here’s the architectural move that quietly dominates all per-GB comparisons: running more than one CDN.
With DNS-based or client-side traffic steering, an operator can shift delivery between vendors based on cost, health, or geography. If Bunny is cheaper for bulk patch delivery in Europe and Cloudflare handles the free-tier-eligible traffic, a multi-CDN setup captures both advantages. Fastly can sit in the mix for the traffic that needs instant purge during a hotfix window.
The catch is operational complexity. Two CDNs means two sets of cache configurations, two purge workflows, and two sets of logs to reconcile. Teams that get this wrong end up with inconsistent cache behavior and a hit ratio that’s worse than either single-vendor setup would have been.
If you’re evaluating this path, the Cloudflare durable objects multiplayer game servers 2026 material is useful context for how edge state and delivery interact in real-time game architectures, since multiplayer and patch delivery often share infrastructure decisions.
What actually drives the bill in practice
Strip away the vendor names and five levers control game CDN cost:
- Cache hit ratio. Immutable, content-addressed artifacts with long TTLs push this into the high nineties. Everything else follows from here.
- Origin egress. Every cache miss costs you twice: once at the CDN, once at origin. Tiered caching reduces this.
- Artifact size and update frequency. A 40 GB build pushed weekly to a million players is a different problem than a 200 MB patch pushed monthly.
- Purge frequency. Every purge invalidates cache and forces re-fetch. Live-ops teams that purge casually pay for it.
- Contract shape. Flat, per-GB, or committed. This determines whether your forecast or your traffic is the risk.
A useful exercise: model your monthly egress at 70 percent, 85 percent, and 95 percent hit ratios under each vendor’s billing shape. The spread within a single vendor usually dwarfs the spread between vendors. That’s the finding most teams miss, and it’s why the cloud cost optimization metrics that actually drive savings conversation applies directly here.
Common mistakes that inflate CDN bills
Serving mutable URLs. If a patch file’s path doesn’t change when its contents change, you can’t cache it aggressively. Fix the path scheme first.
Ignoring tiered caching. Origin shield configurations reduce origin load substantially on large-object workloads. Many teams leave this off by default.
Purging instead of versioning. A purge is a blunt instrument. A new content-addressed path is a scalpel. Teams that purge frequently usually have a versioning problem, not a caching problem.
Comparing list prices without modeling. Three vendors, three billing shapes, one spreadsheet. Build it before you negotiate.
Forgetting about disaster recovery. A CDN outage during a launch window is a revenue event. The cloud disaster recovery architecture design systems that survive real incidents discussion is worth reading for how delivery redundancy fits into a broader resilience plan.
Conclusion
The Bunny versus Cloudflare versus Fastly question is real, but it’s the second question, not the first. The first question is whether your delivery pipeline serves immutable, content-addressed artifacts with long cache TTLs and a hit ratio in the high nineties. Get that right, and the vendor comparison becomes a modest optimization. Get it wrong, and no vendor will save you.
Heading into 2027, the studios that control CDN cost won’t be the ones who negotiated the hardest. They’ll be the ones who treated caching architecture as a product decision, modeled their egress under realistic hit ratios, and kept the option of a multi-CDN setup open. Vendor pricing will change. Cache semantics won’t.
FAQ
Which CDN is cheapest for game delivery?
There’s no universal answer, because the billing models aren’t comparable. Bunny.net’s low per-GB rate often wins for pure large-object delivery. Cloudflare’s free tier with unmetered bandwidth can beat everything if your workload fits inside plan limits. Fastly’s committed-spend model can be competitive at scale but carries forecast risk. Model your own egress at realistic hit ratios before deciding.
Does cache hit ratio really matter more than per-GB price?
For game workloads, usually yes. A CDN with a 95 percent hit ratio serves almost everything from edge and barely touches origin. A CDN with a 70 percent hit ratio pays for origin egress and compute on nearly a third of requests. That gap typically exceeds the difference between vendors’ published rates.
What does content-addressed mean for game patches?
It means a given URL always returns the same bytes. Version 1.4.2 of a file never changes; a new patch gets a new path. This lets you set very long cache TTLs with the immutable directive, because there’s nothing to revalidate. It’s the single highest-leverage caching decision a game studio can make.
Should a game studio use more than one CDN?
Often yes, for cost and risk reasons. Multi-CDN with DNS or client-side steering lets you shift traffic to whichever vendor is cheaper or healthier at a given moment. The trade-off is operational complexity: two cache configurations, two purge workflows, and two sets of logs to reconcile. It works best when a team has dedicated infrastructure ownership.
Why can’t I trust published per-GB prices?
Because commitment levels, regional tiers, and bundled features differ so much that the headline number rarely reflects what you’d actually pay. A vendor with a higher per-GB rate but generous included features can be cheaper overall. Always model total cost against your own traffic profile, and treat any published figure as a dated snapshot.
What’s the fastest way to cut an existing CDN bill?
Audit cache headers first. Look for mutable URLs on large artifacts, missing immutable directives, short TTLs on files that never change, and tiered caching that’s switched off. In practice, most oversized CDN bills trace back to a caching configuration problem rather than a vendor pricing problem, and fixing headers costs nothing.
