The Compelling Economics of Cloudflare R2

Good read from Corey Quinn (Last Week in AWS) hit my inbox this morn. It was from a podcast but supposedly you can find the full transcript at the link below…but I couldn’t find it. Possible because of my ad killer or anti-malware sw. Anyway here’s a snip……

How in the world will Cloudflare stay in business?
The short answer is “by selling services for more than it costs to provide them.” As of its most recent quarterly report, Cloudflare has 77% gross margins.

I regret to inform you that you’ve been misled: The way that companies buy and sell bandwidth is complicated and arcane. Cloudflare touches on a lot of it in an older blog post that gets into transit, peering, 95th percentile billing, etc.

Effectively, instead of paying by the gigabyte, companies (including AWS) pay by the gigabit per second utilization of links to other networks. In AWS’ Egregious Egress from this past summer, Cloudflare does a bunch of math to show that AWS is at minimum charging an 80x markup in the U.S. for data transfer. This of course assumes that Amazon (motto: “We’re cheap but call it Frugal!”) can’t negotiate better rates than Cloudflare can. I very much doubt that to be true.

So far, R2 gives S3 some real competition — and customers can really save
I’m very pleased by this development. I think it throws a major wrench into AWS’ excessive egress charges, and it opens up a whole bunch of opportunities for customers. With Cloudflare Workers and a bunch of other services that Cloudflare is busy rolling out, there’s starting to be a strong economic incentive to move certain workloads to its platform. Data gravity is real; “where your data lives” is usually with the provider that starts to see a lot of your other workloads as well.

All of this is, of course, subject to change. We don’t have complete pricing dimensions for R2 yet, nor have we seen terms of service. But this does make it very clear that AWS is either going to have to address its egress fees or risk losing workloads as the patterns I’ve described solidify into best practices.

Observability is critical for managing and improving complex business-critical systems. With observability, any software engineering team can gain a deeper understanding of system performance, so you can perform ongoing maintenance and ship the features your customers need. Preview Honeycomb’s upcoming O’Reilly book to understand the value of observable systems and how to build an observability-driven development practice.


The link provided in the email was wrong. Here’s the correct link to the transcript……