Casos reales de R2

Ya conoces la máquina: qué es un objeto, los cinco verbos del binding, el multipart para lo grande, el acceso público y las llaves presignadas. Falta la pregunta que ordena todo lo demás —¿para qué se usa R2 en producción?—. No es una lista de anécdotas: los casos donde R2 brilla comparten una raíz común, y verla es entender por qué esta pieza existe. Servir medios, guardar backups, sostener un lago de datos, reemplazar a S3 bajo tus herramientas: cuatro patrones muy distintos que se vuelven baratos o directamente posibles por la misma causa, el egress que no se cobra. Este recorrido cierra el nivel conectando la mecánica con la economía.

Servir imágenes y assets

El caso de manual. Un catálogo de fotos, los avatares de una red, el CSS y el JavaScript de un sitio: bytes inmutables, numerosos, leídos muchas más veces de las que se escriben. Aquí es donde el egress de la nube clásica muerde con más saña, porque el coste crece con la popularidad —cuanto más éxito tiene tu contenido, más pagas por servirlo—. R2 corta esa correlación de raíz.

El montaje canónico pone R2 como origen tras un dominio propio, con la caché del edge por delante. La primera petición de cada objeto lo trae del bucket; las siguientes las sirve la caché desde el punto de presencia más cercano, sin volver a tocar R2. Con una cache-control generosa —los assets con hash en el nombre son inmutables y caducan lejísimos—, la enorme mayoría del tráfico ni siquiera llega al almacén, y el que llega no paga salida.

Cuando necesitas lógica —autorizar quién ve una imagen privada, elegir una variante— pones un Worker delante que decide y sirve el objeto en streaming, como viste con get:

export default {
  async fetch(request: Request, env: Env): Promise<Response> {
    const clave = new URL(request.url).pathname.slice(1);
    if (!(await autorizado(request, env))) return new Response("prohibido", { status: 403 });
    const obj = await env.BUCKET.get(clave);
    if (obj === null) return new Response("no encontrado", { status: 404 });
    const headers = new Headers();
    obj.writeHttpMetadata(headers);
    headers.set("cache-control", "public, max-age=31536000, immutable");
    return new Response(obj.body, { headers });
  },
} satisfies ExportedHandler<Env>;

El patrón es un gradiente: caché pura para lo público y cacheable, Worker con get para lo que pide control, y siempre R2 como el origen barato del que todo cuelga.

flowchart LR
Cliente[cliente] --> Cache[cache del edge]
Cache -- acierto --> Cliente
Cache -- fallo --> Worker[worker autoriza y sirve]
Worker --> R2[R2 origen sin egress]
R2 --> Worker --> Cache
style R2 fill:#a6e3a1,color:#11111b

Backups y un data lake barato

Las copias de seguridad tienen una asimetría cruel en la nube tradicional: guardarlas es barato, pero restaurarlas —justo cuando más lo necesitas, en plena crisis— dispara la factura de egress al sacar todo el volumen de golpe. Es un backup que castiga usarlo. En R2 ese castigo desaparece: almacenar es económico y recuperar no cuesta transferencia, así que un plan de recuperación deja de tener una multa incorporada. Herramientas como rclone vuelcan directorios enteros al bucket con un comando, eligiendo multipart solas para los ficheros grandes.

# Copia incremental de un directorio al bucket, via API S3 de R2.
rclone copy ./datos r2:mi-bucket/backups/2026-07-30 --transfers=8

Y como los backups envejecen, R2 deja definir reglas de ciclo de vida que caducan objetos por antigüedad —borra lo de hace más de noventa días, aborta las subidas incompletas— sin que un cron tuyo tenga que barrer el bucket. La retención se declara una vez y la plataforma la aplica sola, de modo que el almacén no crece sin freno con copias que ya nadie necesita.

El data lake es la misma economía llevada al análisis. Depositas datos en formato columnar —Parquet— sobre el bucket, particionados por fecha o por clave, y dejas que un motor los consulte: R2 SQL, DuckDB, Spark, o un catálogo Iceberg gestionado como R2 Data Catalog. La clave económica se repite: un motor analítico barre volúmenes enormes una y otra vez, y en la nube clásica cada barrido paga egress si el cómputo y el almacén viven separados. Con R2 el barrido no paga salida, y un lago de datos que en otro proveedor sería caro de consultar se vuelve asequible de explotar.

// Escribir una particion Parquet del dia; luego la consulta un motor externo.
await env.LAKE.put(`eventos/fecha=2026-07-30/parte-001.parquet`, buffer, {
  httpMetadata: { contentType: "application/vnd.apache.parquet" },
  storageClass: "InfrequentAccess",
});

El reemplazo compatible de S3

El cuarto caso no es una aplicación nueva sino una sustitución silenciosa. Como R2 implementa la API de S3, cualquier herramienta que hable ese idioma —y son legión: clientes de backup, motores de datos, CLIs, los SDK oficiales en todos los lenguajes— apunta a R2 cambiando el endpoint y las credenciales, sin tocar una línea de su lógica.

// El mismo cliente de S3 de siempre, apuntando a R2.
const s3 = new S3Client({
  region: "auto",
  endpoint: `https://${env.ACCOUNT_ID}.r2.cloudflarestorage.com`,
  credentials: { accessKeyId: env.R2_KEY_ID, secretAccessKey: env.R2_SECRET },
});

Con region: "auto" y ese endpoint, boto3, aws-sdk o rclone creen que hablan con S3. Esto vuelve la migración un ejercicio de configuración, no de reescritura, y —más sutil— te da una salida: adoptar R2 no te encierra, porque el mismo código que lo usa serviría contra cualquier otro almacén compatible. La compatibilidad, que en la lección uno era la vía de entrada, es también la garantía de que la puerta de salida sigue abierta.

Hay un matiz operativo que conviene recordar. Wrangler sube ficheros de hasta unos cientos de megabytes y de uno en uno; para volúmenes grandes o cargas masivas, la vía correcta es una herramienta S3-compatible como rclone, que trocea, paraleliza y reanuda por ti. Elegir la herramienta según el tamaño del trabajo es parte del oficio.