Ok got it, thanx

I'm not a lawyer so I don't know what the regulatory requirements are. Could you build something yourself even without official support? 1. Create some cryptographic material that you bind to a worker (perhaps unique key material per region). You can encrypt this yourself if you're extra paranoid but Workers secrets already have several layers of encryption. 2. Derive per object keys. 3. Construct a

TransformStream

(technically

FixedLengthStream

) that encrypts the data, & then send that to R2. You could use the region info in the headers (e.g.

CF-IPCountry

) to do access controls/key derivation. While the data may not be physically located in a specific region, the ability to decrypt that content is restricted to requests originating in whatever region.

In theory this would work however, in all the major cloud providers e.g aws, azure etc.. it is as simple as choosing the storage location. I have a lot of use cases where data needs to reside either in Australia or New Zealand and it common where government entities are involved or the data has citizen information

the theory seems sound but then there’s the overhead of explaining or justifying that to the business or auditors/regulatory bodies - as well as that process of creating the Worker to handle it

Isn't the point of the regulations that other country's governments aren't able to access the data? If you had a worker that knew the private keys and that worker was globally distributed, those private keys would still be on servers where other country's governments could access them. Even if the private keys were encrypted, the worker would have to have the non-encrypted versions when running. Not a lawyer and maybe I'm missing something, but it doesn't really sound like a solution.

@User Sure. You could mitigate that concern by placing the keys to live in region-locked origin that only honored requests from Workers running in the same country (or however you want to restrict that access). It all depends on what your threat model is and the language of the relevant regulations. I wasn't suggesting this how R2 will have you manage data sovereignty & I fully recognize the cost burden it shifts to developers and that's not OK. We will eventually add support for it. I was simply suggesting this as an interim possibility for anyone that urgently wants to use R2 in it's current state AND has data sovereignty needs.

How fast are r2 download speeds?

Yes 😉

Minimum 1bit/minute

you mean: per hour

Subject to weather conditions and how in shape your postie is to deliver the usb stick, no downloads on sundays

Waiting for R2.

we are two lmao

Unfortunately we don’t actually know ourselves yet. I’m building the benchmark infrastructure this week which will inform us where we are (just as a starting point so we can validate our changes have the expected behavior).

Is migration from other S3 provider easy?

Basically it connects to your S3 bucket, then whenever you access files it lazily pulls them and migrates them to R2. So then you only incur egress costs once. to quote Isaac Mcfadyen from above^^

Very nice

Yes, our goal is to make it as easy as possible.

Will there be something to delete it from the S3 bucket after transfer is successful? (Maybe an optional config defaulting to not delete)

Or will we have to handle that ourselves?

I am not sure that is in the current plan, but it is a great suggestion 🙂

It's already part of the current plan for this & it will be the default to not delete.

Great suggestion obviously 🙂

fwiw, it’d be good to see max object sizes as high as possible

eg in the tens of GBs

also, range requests are important

Range requests are available. The S3 endpoint currently has a ~5GB limit in PutObject (maybe just a smidge lower). You can do a multipart upload for larger files up to ~5TB. The runtime bindings are trickier. The bindings themselves have the same limit as the S3 endpoint but your Worker itself will have the 500 MB inbound request limit as described https://developers.cloudflare.com/workers/platform/limits/#request-limits (& also buffered uploads). I don't know what this will look like as the work hasn't started.