Cloudflare R2

R2's zero-egress-fee model makes it the clear choice for agent workloads that read heavily — caching layers, content delivery, or artifact retrieval where S3 egress costs compound fast. S3 API compatibility means agents using the AWS SDK (with a custom endpoint) work without code changes. Workers bindings add a second integration path for agents running on Cloudflare's edge. The feature set is intentionally smaller than S3 — no object lock, no bucket versioning, limited lifecycle policies — but this simplicity actually reduces agent configuration surface. Multipart upload, pre-signed URLs, and conditional requests all work. The main gap: event notifications are newer and less mature than S3's SNS/SQS integration.

API tokens generated in the Cloudflare dashboard serve as the primary credential. For S3-compatible access, R2 issues access key + secret pairs that plug directly into AWS SDKs. Scoping is per-token: read-only, write-only, or read-write on specific buckets. Workers bindings bypass token auth entirely — the binding itself is the authorization, configured in wrangler.toml. This is simpler than IAM but less granular — no resource-level policies, no condition keys, no temporary credential rotation via STS equivalent. For agents, the simplicity is a net positive: one token per bucket with clear permissions, no policy interaction debugging. CORS is configured per-bucket for browser access.

Documentation is clean, well-organized, and significantly more navigable than AWS's equivalent. The developer docs at developers.cloudflare.com/r2 cover setup, S3 compatibility, Workers bindings, and migration guides from S3/GCS. Code examples are current and include both S3-SDK and Workers-native patterns. The migration guide from S3 is especially useful — it explicitly lists which S3 features are and aren't supported. Dashboard UX is straightforward for bucket creation and token management. The main documentation gap is around edge cases: rate limit behavior, large object handling specifics, and event notification patterns are thinner than the core CRUD docs.

R2 exposes the S3-compatible REST API through account-scoped endpoints (https://<account-id>.r2.cloudflarestorage.com). ListObjectsV2, GetObject, PutObject, and DeleteObject behave as expected. Agents using Boto3 or @aws-sdk/client-s3 can point at R2 by overriding the endpoint — no wrapper library needed. Workers bindings provide a separate, more ergonomic interface for edge-deployed agents: env.BUCKET.get(key), env.BUCKET.put(key, body). The dual API surface (S3 compat + Workers native) is unusual but practical. Gaps from full S3 compatibility: no SelectObjectContent, no Glacier storage classes, no batch operations API. For most agent use cases (store, retrieve, list, delete), the compatibility is sufficient.

Error responses follow S3 conventions — XML bodies with Code and Message elements. Status codes match S3 expectations (403/404/409/503). Rate limits are less explicitly documented than S3's per-prefix model, which creates uncertainty for high-throughput agent workloads. In practice, R2 handles sustained writes well for most agent use cases, but the lack of published rate limit numbers means capacity planning relies on empirical testing rather than documented guarantees. Retry behavior should follow standard exponential backoff. The Workers binding path has different error semantics — exceptions rather than HTTP status codes — which agents consuming both paths need to handle distinctly.