Earlier quoted context omitted.
To host static websites, you use Cloudflare Pages.
Cloudflare Pages locks you into git-based deployment, which isn't always practical, especially for sites that are heavy with images and other non-text static assets. I don't want to use git to manage the images for my website and I don't want to have to pay Github every month for Git LFS storage and bandwidth costs.
Cloudflare R2 storage: Rapid and reliable object storage, minus the egress fees
141–150 of 220 posts
Re: Cloudflare R2 storage: Rapid and reliable object storage, minus the egress fees
#142Earlier quoted context omitted.
> So if R2 is S3 with no egress, suddenly there is a value proposition again. Isn't B2 from Backblaze already filling that need? I means more choice is always better for sure, but considering R2 goal seems really to be a CDN more than a backup space and it does feel like their money maker is in the CDN part, not the storage part... I feel like trusting them to store it long-term without using the CDN part is a little…
B2 charges for egress, $0.01/GB. More interesting to me is Wasabi, which charges ~$0.006/GB*month and no egress fees at all.
This caught me out when I was transferring 100GB files that only needed to be up for a few hours, and I ended up getting charged as if I had hosted them for 3 months.
Re: Cloudflare R2 storage: Rapid and reliable object storage, minus the egress fees
#143Earlier quoted context omitted.
Scaleway also provides a similar service. Had an issue recently (deleted a bucket, and couldn't create another bucket with the same name) and their support replied back in minutes .
Scaleway S3 was slow as hell for small files last time I tried, is it better now?
Re: Cloudflare R2 storage: Rapid and reliable object storage, minus the egress fees
#144Earlier quoted context omitted.
> So if R2 is S3 with no egress, suddenly there is a value proposition again. That doesn't appear to be what they're doing, they don't seem to have changed their existing operating model at all: > R2 will zero-rate infrequent storage operations under a threshold — currently planned to be in the single digit requests per second range. Above this range, R2 will charge significantly less per-operation than the major pro…
This is about the operation, not about bandwidth the way that I read it. All providers have prices for bandwidth and prices for different "tiers" of operations (store, retrieve, delete, list, etc). The way I read it is that bandwidth is always 100% free, and storage operations are free under a certain threshold. I hope I'm right ;)
Re: Cloudflare R2 storage: Rapid and reliable object storage, minus the egress fees
#145Very exciting. Object storage is getting really competitive and i love the naming scheme alliance - S3, B2 (Backblaze) and now R2, who will do one with a “1”? On a serious note i’m wondering about the signed urls and ACL capabilities of the cloudflare offering cause this is something we use. I’m also interested does R2 replace S3 and CloudFront at the same time? That’d be nice and one headache less.
Re: Cloudflare R2 storage: Rapid and reliable object storage, minus the egress fees
#146Very generous offer from Cloudflare. I signed up. The main question: how can Cloudflare make this into a sustainable business? * cost/gb is cheaper or same as s3, gcp, azure * no egress charges to customers, but they still have to pay for transit when they cross an AS! what is the hidden angle Cloudfare is using here?
I don't know/think there is a hidden angle. Eg. What could be the hidden angle of providing domains at cost ( which they do). I think it's a matter of having a more complete cloud suite and expanding their portfolio while gaining market share. Clarification: I don't think they do this at cost. Just cheaper than the big 3.
They seem to learn a lot by centralizing a lot of the internet's traffic through their core. Perhaps it makes their ddos-protection more robust when they can train on "what normal usage" looks like "for the longer tail".
Perhaps they are building moats around that business and expecting a future when Fortune1000 requires their cdn.
Re: Cloudflare R2 storage: Rapid and reliable object storage, minus the egress fees
#147Earlier quoted context omitted.
I don't know/think there is a hidden angle. Eg. What could be the hidden angle of providing domains at cost ( which they do). I think it's a matter of having a more complete cloud suite and expanding their portfolio while gaining market share. Clarification: I don't think they do this at cost. Just cheaper than the big 3.
I suspect the story is a bit more complicated. They seem to learn a lot by centralizing a lot of the internet's traffic through their core. Perhaps it makes their ddos-protection more robust when they can train on "what normal usage" looks like "for the longer tail". Perhaps they are building moats around that business and expecting a future when Fortune1000 requires their cdn.
Their CDN is based on their SDN. Which is also at the core of all their products, including DDOS protection.
Their primary product is the SDN and a CDN was a logical pick as first product "release".
Eg. You shouldn't consider their products in "regions" as traditional cloud providers. In cloudflare it's programmable, not configurable.
Re: Cloudflare R2 storage: Rapid and reliable object storage, minus the egress fees
#148I know the Cloudflare team hangs out here, so thanks, and great job! This was absolutely necessary for my line of work. Couple of quick questions/confirmations: * R2 will support the same object sizes as S3? We have 500GB+ objects and could go to a 1TB per object. * R2 will support HTTP Range GETs, right? Egress bandwidth for objects on S3 is the biggest line item on the AWS bill for a company I work for, by an order…
Hey, I'm the PM for R2. Yes to range requests. Current object limit is smaller than that, but we don't have a fundamental restriction there. Shoot me an email to gmckeon [at] cloudflare.
I had tried using BackBlaze 8 months ago as a much cheaper (especially with B2 and CF's Free Data Transfer partnership) replacement for Amazon S3 and was running into a limitation on B2.
I had a scenario where my users can upload images from the browser to BackBlaze. I wanted the ability to control the file name of the uploaded file. I don't want the user to be able to modify the network request to upload the file with a different file name. Nor do I want the users to be able to upload files with names which would overwrite existing files.
B2 didn't let me upload files with a specific filename in the pre-signed URL.
For example there's this API:
curl https://apiXXX.backblazeb2.com/b2api/v2/b2_get_upload_url -H 'Authorization: XXXXXXXXXXXXXXXXXXXXXXXXX=' -d '{"bucketId": "XXXXXXXXXXXXXXX"}'
which gave me an upload URL where I can upload the file to.
And then there's this:
https://www.backblaze.com/b2/docs/b2_upload_file.html
which lets users upload files to that URL.
But this allowed my users to upload file with any name they want. It would also allow them to overwrite existing files (from other users).
My question is more from a security point of view so preventing one user from overwriting another user's content is crucial. For example, lets say you right click on an image from someone else on facebook and get the actual image's file name. Now you try to upload an image on facebook and you edit the network request in the browser's inspector tool to the image file name which you got for another user. Facebook obviously prevents this in their own way using pre-signed urls which include the filename in the signature. However on BackBlaze if I try this, the "pod" url which is received doesn't include any file name signature. The pod URL is just where the image gets stored on your end. A user can easily edit the network request and modify the "X-Bz-File-Name" Header to another user's filename. This would be a major security vulnerability if I went with BackBlaze. As a workaround, right now it seems like users would first have to upload files to my own server, then my server would have to upload them to BackBlaze to avoid this issue. This sounded like hassle.
Amazon S3 solves this problem using createPresignedPost which includes a signature of the filename in the URL. I contacted BackBlaze's support and got a response their S3 api doesn't support createPresignedPost:
https://www.reddit.com/r/backblaze/comments/kzszym/is_backbl...
You can read B2's staff's response to my question:
https://www.reddit.com/r/backblaze/comments/l0c9s7/is_there_...
Is there a way to prevent this on R2? Something where the link provided by b2_get_upload_url (whatever R2's equivalent will be) only works for specific a file name?
Re: Cloudflare R2 storage: Rapid and reliable object storage, minus the egress fees
#149Earlier quoted context omitted.
This is about the operation, not about bandwidth the way that I read it. All providers have prices for bandwidth and prices for different "tiers" of operations (store, retrieve, delete, list, etc). The way I read it is that bandwidth is always 100% free, and storage operations are free under a certain threshold. I hope I'm right ;)
This is correct. Bandwidth (ingress and egress) always free, regardless of volume. Transactions free at low volume (~<1/sec) but we’ll charge at higher volumes. Storage we charge for. For both transactions and storage, we aim to be at least 10% less expensive than S3. And, again, for the sake of absolute clarity: egress/ingress always free.
Re: Cloudflare R2 storage: Rapid and reliable object storage, minus the egress fees
#150Earlier quoted context omitted.
> So if R2 is S3 with no egress, suddenly there is a value proposition again. Isn't B2 from Backblaze already filling that need? I means more choice is always better for sure, but considering R2 goal seems really to be a CDN more than a backup space and it does feel like their money maker is in the CDN part, not the storage part... I feel like trusting them to store it long-term without using the CDN part is a little…
B2 charges for egress, $0.01/GB. More interesting to me is Wasabi, which charges ~$0.006/GB*month and no egress fees at all.
[0]: https://wasabi.com/paygo-pricing-faq/#free-egress-policy