21–30 of 39 posts
We've been waiting for this since it was announced. We have > 2PB of media heavy data, and transfer a lot via S3 to the internet. This will reduce our monthly S3 charge from tens-of-thousands USD per month, to ~$200.
The storage cost on r2 is .015/GB. Might want to redo the math
I haven't been able to get either working:
const s3Client = new S3Client({
endpoint: 'https://my-account-id.r2.cloudflarestorage.com',
credentials: secrets.r2Credentials,
})
await s3Client.send(
new PutObjectCommand({
Bucket: 'my-bucket,
Key: 'test',
Body: JSON.stringify({hello: 'world'}),
}),
)
const r2Client = new AwsClient({
...secrets.r2Credentials,
})
fetch(
await r2Client.sign(
'https://my-account-id.r2.cloudflarestorage.com/' +
'?Key=test&Bucket=my-bucket',
{
method: 'put',
body: JSON.stringify({ hello: 'world' }),
},
),
).then((response) => console.log(response.status))
I've verified that the key has full access and even rerolled it to make sure I didn't mess up the copy paste, but still no luck.
Any ideas where I could be going wrong?
Got any examples for https://github.com/aws/aws-sdk-js-v3 or https://github.com/mhart/aws4fetch ? I haven't been able to get either working: const s3Client = new S3Client({ endpoint: 'https://my-account-id.r2.cloudflarestorage.com', credentials: secrets.r2Credentials, }) await s3Client.send( new PutObjectCommand({ Bucket: 'my-bucket, Key: 'test', Body: JSON.stringify({hello: 'world'}), }), ) ^ This fails with a 500 c…
I think you need to set s3ForcePathStyle to true for the first example (or however you do it in the v3 version of the SDK[2]). For the latter, we don't support pre-signed requests. Feel free to ask on discord [3] too. Might get more timely responses.
[1] https://developers.cloudflare.com/r2/examples
[2] https://docs.aws.amazon.com/AWSJavaScriptSDK/v3/latest/clien...
I’m an engineer on the R2 team. Happy to answer any questions in this thread.
Earlier quoted context omitted.
Thats problem is for CDN product. On R2 like other Developer products (KV, Worker, DO) you are already paying the bandwidth over the storage price. All those products can be used to HTML and non-HTML product. https://www.cloudflare.com/supplemental-terms/#cloudflare-de... Thats the major problem of the CDN product, they dont say that are no traffic fee, they just say they will not charge you "except" on some cases (t…
This is the exact case when the "except" will be triggered. He is describing a video/image cdn in his comment.
When using the "free" cache product, solving this is Cloudflare's problem - they have a lot of incentives to stop people from being able to do that as it would otherwise cost them money.
However, when using the R2 product, Cloudflare sure would be incentivized to do whatever they can to make all these requests succeed so they can bill you for them.
Before someone tries bringing up their rate limiting product, that is more than an order of magnitude more expensive than R2.
I’m an engineer on the R2 team. Happy to answer any questions in this thread.
1. Are the rate limits for all users on a given bucket, or by source IP as some other providers do?
2. What is the plan for the rate limits post beta?
3. Do you support the x-amz-content-sha256 header. i.e. If a put contains that header and the content hash doesn't match is it rejected?
4. What does it mean to support pre-signed URLs? Can't a client pre-sign a URL that anyone else can use? My understanding is they are the same as normal usage from the server's perspective, just the key holder signs the request, and the other person actually makes the request.
5. Why is the read limit smaller than the write limit?
I’m an engineer on the R2 team. Happy to answer any questions in this thread.
Does the worker api support multipart uploads?
I’m an engineer on the R2 team. Happy to answer any questions in this thread.
Thanks for the awesome product! I have a few questions: 1. Are the rate limits for all users on a given bucket, or by source IP as some other providers do? 2. What is the plan for the rate limits post beta? 3. Do you support the x-amz-content-sha256 header. i.e. If a put contains that header and the content hash doesn't match is it rejected? 4. What does it mean to support pre-signed URLs? Can't a client pre-sign a U…
1 & 2 - We're reserving some ability to rate-limit during beta as we figure out how best to scale our systems under load. I'll defer to vlovich & greg-m for post-beta plans.
3. We do support that header. Mismatching content hashes will be rejected during write. If you ever experience otherwise, please report it.
4. We only support sigv4 auth via header currently: https://docs.aws.amazon.com/AmazonS3/latest/API/sigv4-auth-u...
With presigned urls, we will support sigv4 in url parameters https://docs.aws.amazon.com/AmazonS3/latest/API/sigv4-query-...
5. See #1. We'll be improving the throughput of both operations, but currently reads have higher throughput than writes.
Earlier quoted context omitted.
Thanks for the awesome product! I have a few questions: 1. Are the rate limits for all users on a given bucket, or by source IP as some other providers do? 2. What is the plan for the rate limits post beta? 3. Do you support the x-amz-content-sha256 header. i.e. If a put contains that header and the content hash doesn't match is it rejected? 4. What does it mean to support pre-signed URLs? Can't a client pre-sign a U…
I'm also an engineer on R2 team. 1 & 2 - We're reserving some ability to rate-limit during beta as we figure out how best to scale our systems under load. I'll defer to vlovich & greg-m for post-beta plans. 3. We do support that header. Mismatching content hashes will be rejected during write. If you ever experience otherwise, please report it. 4. We only support sigv4 auth via header currently: https://docs.aws.amaz…