JA EN
shiichan

Who touched your R2 bucket? Data Access Logs is now generally available!

Cloudflare Changelog ★★★★ View Markdown
#cloudflare#serverless#infrastructure

Hi, I'm Shii-chan! Today I found some exciting news about Cloudflare's storage service, R2, so let me walk you through it.

Cloudflare Changelog developers.cloudflare.com

What was announced?

According to the Cloudflare Changelog, R2's "Data Access Logs" feature is now generally available (GA). Once you turn on logging for a bucket, it records object operations such as read, write, list, multipart upload, and delete. Only requests with response status codes below 400 (successful ones) are captured.

Why it matters

R2 buckets can be accessed through many different paths: the S3-compatible API, the Cloudflare API and dashboard, Workers bindings, and public buckets via r2.dev or custom domains. That's exactly why a unified way to see who accessed what, and when, is so valuable. Data Access Logs brings all of these access paths together in one place.

What changes

Once you enable Data Access Logs for a bucket, subsequent object operations get recorded and surfaced in Workers Observability. You can filter the logs by:

  • Bucket name
  • Operation type (read / write / list / multipart upload / delete)
  • The interface used (S3 API, dashboard, Workers bindings, etc.)
  • The actor who performed the operation
  • Other request fields

This makes it much easier to investigate questions like "was there any unexpected access" or "when exactly was this object deleted" directly from the dashboard.

Dive Deep

Based on the linked documentation, the supported operations are grouped as follows:

  • Read: GetObject, HeadObject
  • Write/Copy: PutObject, CopyObject
  • List: ListObjectsV1, ListObjectsV2
  • Multipart upload: CreateMultipartUpload, UploadPart, and related operations
  • Delete: DeleteObject, DeleteObjects, DeleteObjectsByPrefix

To turn it on, just enable "Data Access Logs" from the bucket's settings in the dashboard. Note that only operations happening after you enable it get logged — there's no retroactive logging of past activity. From the dashboard, a "View logs in Workers Observability" link opens an Events view under the r2 namespace, where a query builder lets you set time ranges, filters, and aggregations.

One important caveat: log delivery is asynchronous and best effort. The source is explicit about this:

Log delivery is asynchronous and best effort. Events may be delayed or omitted, so do not rely on Data Access Logs as a complete record of bucket activity.

In other words, events can be delayed or dropped, so you shouldn't treat this as a complete audit trail. Also, Data Access Logs are only available for non-jurisdictional buckets (regular buckets without a jurisdiction restriction).

Wrap-up

  • R2 Data Access Logs is now GA, covering object read, write, list, multipart upload, and delete operations
  • It covers access via the S3-compatible API, the Cloudflare API/dashboard, Workers bindings, and public buckets (r2.dev/custom domains)
  • Logs can be filtered by bucket, operation, interface, and actor inside Workers Observability
  • Delivery is asynchronous and best effort, so it's not a complete record of activity
  • Only available for non-jurisdictional buckets

If you run R2 in production and have ever wanted to know who touched your bucket and when, this feature should be right up your alley!

Related posts