Servir assets estáticos desde Cloudflare R2 en vez de S3: ventajas, reglas y límites
Cuándo mover assets y directorios estáticos a Cloudflare R2 en lugar de S3: costes, SSG, dominios personalizados, reglas de caché y patrones de producción.
Los assets estáticos parecen simples hasta que se convierten en una parte impredecible de la factura. Imágenes de producto, PDFs, vídeos, fuentes, paquetes de documentación, exports de informes y builds descargables empiezan como “archivos baratos en un bucket”. Cuando el tráfico crece, el problema deja de ser el almacenamiento y pasa a ser la entrega.
Cloudflare R2 cambia esa ecuación porque ofrece almacenamiento compatible con S3, sin cargo de egress de R2 hacia Internet, y con una ruta limpia para servir objetos desde un dominio gestionado por Cloudflare. Pero R2 no reemplaza todos los patrones de hosting estático. La decisión correcta depende de si estás sirviendo una aplicación web o un conjunto de objetos.
El problema real no es guardar archivos
Un sistema público de assets tiene cuatro responsabilidades:
- Guardar objetos de forma duradera.
- Exponer URLs bajo un hostname controlado.
- Cachear agresivamente los archivos calientes.
- Invalidar o versionar cambios de forma predecible.
S3 suele resolverlo con CloudFront delante. R2 lo resuelve con un dominio personalizado en Cloudflare, Cache Rules, WAF, Access y Workers cuando necesitas lógica. La diferencia práctica no es solo la API del bucket. Es dónde vive la capa edge y cuánto pagas cuando los bytes salen hacia usuarios.
Cuándo R2 encaja mejor
R2 funciona especialmente bien para archivos públicos, leídos muchas veces y relativamente estables:
- assets con hash como
app.4f3a1c.cssovendor.91bc2.js - imágenes, vídeos, fuentes y Open Graph media
- PDFs, whitepapers, reportes y descargas públicas
- releases, datasets, archivos de modelos y paquetes grandes
- directorios estáticos donde la URL debe mapear a una clave de objeto
La ventaja principal es económica y operativa. R2 no cobra egress de R2 a Internet, puede usar tooling compatible con S3 y deja la seguridad, caché y reglas de entrega en el mismo plano de control de Cloudflare.
SSG frente a servir archivos directamente desde R2
La primera pregunta es: ¿estás sirviendo páginas o archivos?
Usa SSG para HTML y rutas. Astro, Cloudflare Pages, Workers Static Assets, Netlify o Vercel entienden rutas como /pricing, fallback de SPA, redirects, headers por ruta, 404 personalizados y despliegues atómicos. Eso es lo que quieres para marketing sites, documentación, blogs y aplicaciones donde importan SEO, canonical, structured data y status codes.
Usa R2 directo cuando la ruta identifica un archivo:
https://assets.example.com/brand/logo.svg
https://downloads.example.com/reports/audit-2026.pdf
https://releases.example.com/app/1.8.4/linux-amd64.tar.gzR2 no infiere automáticamente que /docs/ debe servir /docs/index.html, ni que /app/settings debe caer en /app/index.html. Puedes añadir un Worker delante de R2 para ese comportamiento, pero entonces estás construyendo un pequeño host estático. Puede ser correcto para un archivo de documentación o portal interno, pero debe ser una decisión consciente.
Patrones de producción recomendados
El patrón más seguro es mantener el sitio en una plataforma SSG y mover los archivos pesados a R2:
www.example.com -> sitio o aplicación
assets.example.com -> bucket R2 público
downloads.example.com -> bucket R2 públicoAsí conservas las rutas HTML, preview deployments, SEO y redirects en la plataforma del sitio, mientras las imágenes, PDFs y releases salen desde R2 con caché en Cloudflare.
Para archivos públicos por versión, R2 puede servir directamente un árbol de objetos. No dependas de listados de directorios como navegación. Publica un índice desde el sitio principal o sube un index.html explícito si los usuarios necesitan una página de entrada.
Si necesitas autenticación, tokens, normalización de rutas o headers dinámicos, coloca un Worker delante de R2. Ese Worker puede validar la petición, resolver la clave del objeto, establecer Cache-Control y devolver el archivo.
Dominio personalizado y reglas importantes
En producción, usa un dominio personalizado como assets.example.com. El endpoint r2.dev es útil para desarrollo, pero no debe ser tu superficie pública principal. Con un dominio propio puedes aplicar Cache Rules, WAF, Access, reglas de bots y Workers.
Las reglas de caché deben ser explícitas:
- Assets con hash:
Cache-Control: public, max-age=31536000, immutable. - Archivos mutables como
latest.zip,catalog.jsonoindex.html: TTL corto y purge durante deploy. - Descargas privadas o firmadas: bypass de caché o una cache key diseñada correctamente.
Cache Everything: solo en el hostname del bucket, no globalmente en la aplicación.
El pipeline de subida también importa. Cada objeto debe tener el Content-Type correcto y metadatos de caché adecuados. Un JavaScript servido como application/octet-stream o un SVG con tipo incorrecto puede romper navegadores, previews o políticas de seguridad.
R2 vs S3: una regla práctica
S3 sigue teniendo sentido si tu organización ya es AWS-native, con CloudFront, IAM, signed URLs, logging y gobernanza establecidos. R2 se vuelve atractivo cuando el egress pesa en la factura, los assets son públicos o semipúblicos, y Cloudflare ya es tu capa edge.
Usa esta regla:
- Páginas HTML y rutas de aplicación: SSG, Pages o Workers Static Assets.
- Archivos públicos grandes e inmutables: R2 detrás de un dominio personalizado.
- Árboles de archivos simples: R2 directo.
- Árboles con auth o routing: Worker delante de R2.
- Workflows privados muy integrados con AWS: S3 puede seguir siendo mejor.
La arquitectura ganadora rara vez es “R2 para todo”. Es más precisa: deja las páginas en la plataforma creada para páginas, mueve los bytes públicos de alto volumen a R2 y define caché y seguridad en el punto donde entra el tráfico.