I wish the R2 access control was similar to S3 - able to issue keys with specific accesses to particular prefixes, and ability to delegate ability to create keys.
It currently feels a little limited and… bolted on to the Cloudflare UI.
From S3 to R2: An economic opportunity
21–30 of 183 posts
Re: From S3 to R2: An economic opportunity
#22Since I know there will be Cloudflare people reading this (hi!), I'm begging you: please wrestle control of the blob storage API standard from AWS. AWS has zero interest in S3’s API being a universal standard for blob storage and you can tell from its design. What happens in practice is that everybody (including R2) implements some subset of the S3 API, so everyone ends up with a jagged API surface where developers c…
[deleted]
Re: From S3 to R2: An economic opportunity
#23Is there any reason to not use R2 over a competing storage service? I already use Cloudflare for lots of other things, and don't personally care all that much about the "Cloudflare's near-monopoly as a web intermediary is dangerous" arguments or anything like that.
Re: From S3 to R2: An economic opportunity
#24If you are storing large amount of data: E2 is the cheapest (20$/TB/year, 3x egress for free) If you are having lots of egress: R2 is the cheapest (15$/TB/month, free egress) R2 can get somewhat expensive if you have lots of mutations, which is not a typical use case for most.
What's E2? Top google result for "e2 blob storage" is azure, but that can't be it since the pricing table comes at around $18/TB/month.
Re: From S3 to R2: An economic opportunity
#25Since I know there will be Cloudflare people reading this (hi!), I'm begging you: please wrestle control of the blob storage API standard from AWS. AWS has zero interest in S3’s API being a universal standard for blob storage and you can tell from its design. What happens in practice is that everybody (including R2) implements some subset of the S3 API, so everyone ends up with a jagged API surface where developers c…
I think the subtle API differences reflect bigger and deeper implementation differences... For example, "Can one append to an existing blob/resume an upload?" leads to lots of questions about data immutability, cacheability of blobs, etc. "What happens if two things are uploaded with the same name at the same time" leads into data models, mastership/eventual consistency, etc. Basically, these 'little' differences are…
This is a good point, but just a standard for the standard create/read/update (replace)/delete operations combined with some baseline guarantees (like approximately-last-write-wins eventual consistency) would probably cover a whole lot of applications that currently use S3 (which doesn't support appends anyway).
Heck, HTTP already provides verbs that would cover this, it would just require a vendor to carve out a subset of HTTP that a standard-compliant server would support, plus standardize an auth/signing mechanism.
Re: From S3 to R2: An economic opportunity
#26Cloudflare has been attacking the S3 egress problem by creating Sippy: https://developers.cloudflare.com/r2/data-migration/sippy/ It allows you to incrementally migrate off of providers like S3 and onto the egress-free Cloudflare R2. Very clever idea. He calls R2 an undiscovered gem and IMO this is the gem's undiscovered gem. (Understandable since Sippy is very new and still in beta)
What are the economics that Amazon and other providers have egress fees and R2 doesn't? Is it acting as a loss leader or does this model still make money for CloudFlare?
also, egress fees are a sort of vendor lock-in, because getting data out of the cloud is vastly more expensive then putting new data into the cloud..
Re: From S3 to R2: An economic opportunity
#27The other hidden cost when you are working with data hosted on S3 is the LIST requests. Some of the data tools seem very chatty with S3, and you end up with thousands of them when you have small filed buried in folders with a not insignifcant cost. I need to dig into it more, but they are always up there towards the top of my AWS bills.
Re: From S3 to R2: An economic opportunity
#28> In fact, there’s an opportunity to build entire companies that take advantage of this price differential and I expect we’ll see more and more of that happening.
Interesting. What sort of companies can take advantage of this?
Re: From S3 to R2: An economic opportunity
#29I just love minio. It is a drop-in replacement for S3. I have never done a price comparison for TOC to S3 or R2, but I have a good backup story and run it all inside docker/dokku so it is easy to recover.
Re: From S3 to R2: An economic opportunity
#30Cloudflare has been attacking the S3 egress problem by creating Sippy: https://developers.cloudflare.com/r2/data-migration/sippy/ It allows you to incrementally migrate off of providers like S3 and onto the egress-free Cloudflare R2. Very clever idea. He calls R2 an undiscovered gem and IMO this is the gem's undiscovered gem. (Understandable since Sippy is very new and still in beta)
What are the economics that Amazon and other providers have egress fees and R2 doesn't? Is it acting as a loss leader or does this model still make money for CloudFlare?
Amazon doesn't have unit cost for egress. They charge you for the stuff you put through their pipe, while paying their transit providers only for the size of the pipe (or more often, not paying them anything since they just peer directly with them at an exchange point).
Amazon uses $/gb as a price gouging mechanism and also a QoS constraint. Every bit you send through their pipe is basically printing money for them, but they don't want to give you a reserved fraction of the pipe because then other people can't push their bits through that fraction. So they get the most efficient utilization by charging for the stuff you send through it, ripping everybody off equally.
Also, this way it's not cost effective to build a competitor to Amazon (or any bandwidth intensive business like a CDN or VPN) on top of Amazon itself. You fundamentally need to charge more by adding a layer of virtualization, which means "PaaS" companies built on Amazon are never a threat to AWS and actually symbiotically grow the revenue of the ecosystem by passing the price gouging onto their own customers.