Buckets are created based on your location when creating it and that bucket's data stays in that loc
Buckets are created based on your location when creating it and that bucket's data stays in that location
KYour bucket's content themselves aren't replicated/distributed yet
IThey're claiming R2 buckets are distributed which they are, not replicated and not a single bucket. But yes, it's somewhat misleading.
S@.ashleyk thanks for bringing this up, I think our original intention was to convey that you don't choose a region when creating a bucket because we'll choose it for you, but didn't expect that it could be read as being "globally replicated", which is fair criticism. I've brought it up internally!
The ultimate goal is to be intelligent about where we serve data from, but that's quite a ways away
The ultimate goal is to be intelligent about where we serve data from, but that's quite a ways away
SWell then we won't be able to get rid of it, we'd have to forever support those kinds of buckets (for people who have to have some kind of control, we have do jurisdiction hints in the works)
The way I see it is that there are certain things we can do (performance and otherwise) that wouldn't be possible if people get to choose where to put their bucket. I think the edge (
) we have over other providers is Cloudflare's edge network, which is better utilized by the one who sees traffic patterns (aka R2), instead of the person creating the bucket (who basically guesses where their traffic might come from)
(for people who have to have some kind of control, we have do jurisdiction hints in the works)The way I see it is that there are certain things we can do (performance and otherwise) that wouldn't be possible if people get to choose where to put their bucket. I think the edge (
) we have over other providers is Cloudflare's edge network, which is better utilized by the one who sees traffic patterns (aka R2), instead of the person creating the bucket (who basically guesses where their traffic might come from)SThis is a little hand-wavy at the moment, but there's some cool stuff planned around distribution and what-not
UNo you need a payment method because its usage based charging that happens to have some usage included
Umqtt
KWith the Cloudflare proxy in front of R2, it is automaticlly compressing my JSON files stored in R2, which is fine overall. But is there any way to force Cloudflare to return a header and/or request the response uncompressed?
works to stop compression but still doesn't cause a header to be returned
works to stop compression but still doesn't cause a header to be returned
KThis is specifically a problem with JSON, but not image files
YDoes the bucket support transferring to others?
R?r2-roadmap
FThese features are now available!!Future roadmap
- Public buckets, with custom domains: https://developers.cloudflare.com/r2/data-access/public-buckets/#enable-public-access-for-your-bucket
- Presigned URLs in the S3-compatible API
Read more: https://blog.cloudflare.com/r2-ga/
- Object Lifecycles
- Jurisdictional Restrictions (e.g. 'EU')
- Live Migration without Downtime (S3->R2)
SFor the record, I definitely would also interpret that as globally replicated
K doesn't work for S3
KIt's an open issue on GH
BYou can do some quick math and see with R2 pricing even getting to $100 is not that realistic in terms of experimenting.
B$100 is 6.5 TB storage, 22 million class As, or 275 million class Bs, I highly doubt most experimenting can even get to a fraction of those numbers.
Kthe reads would be 106 reads per second - for a month
Kunmetered ratelimiting is on all plans
Kbop
IYes, usually. If a botnet is distributed enough to pass the rate limiting, it'll almost certainly be flagged by the DDoS protection
BI’d imagine if you get attacked that hard you can talk to support about it and probably have it waived.
KI wouldn't rely on that though - there's no guarantees support will waive bills, and they'd likely expect you to take action or get in touch with them from day 1 as a pre-req
KMainly since I've seen horror stories of KV/Workers usage not being waived
K
B
BSounds like interesting stories.
KMostly people who have a very clear increase in requests over a week but take no action, then expect it for free
KNever said it would - but you also can't sit idly and expect a refund for it. That's why there's 'or get in touch with support'
Kimho all the products need to do what Workers already does for the free tier and have a fail closed/fail open cap
CIs there a read or write limit for r2 requests to a given bucket?