¿Cuotas de tráfico S3 de miles al mes? Migra a R2 en 3 pasos y ahorra un 90% (casos reales)

Revisas la factura de AWS y el almacenamiento son solo $230, pero el tráfico llega a $4,500: con 50 TB de tráfico, la cartera se vacía rápido. Hablando con amigos que hacen vídeo o hosting de imágenes, todos se quejan de las cuotas de tráfico de S3. Un amigo con una SaaS me contó que su empresa mueve 10 TB al mes: factura S3 de $891, almacenamiento solo $15; el tráfico representa el 98%.

¿Y con Cloudflare R2? Cero cuota de egreso. Con los mismos 10 TB de tráfico, R2 solo cobra almacenamiento: $15. Este artículo comparte experiencia real: cálculo de costes, pruebas de compatibilidad API, tutorial de migración en 30 minutos y errores que cometí. Si tu aplicación mueve mucho tráfico (más de 500 GB/mes), puedes ahorrar miles al año.

¿Por qué migrar de S3 a R2? Los datos hablan

La trampa del coste oculto de S3

La estrategia de precios de AWS es astuta. El almacenamiento a $0.023/GB parece barato al principio. Pero cuando el tráfico crece, la cuota de egreso a $0.09/GB es lo que más pesa.
Te hago las cuentas. Imagina una plataforma de vídeo con 10 TB almacenados y 50 TB de tráfico mensual (visualización y descarga):

• Almacenamiento: 10 TB × $23/TB = $230/mes
• Tráfico: 50 TB × $90/TB = $4,500/mes
• Total: $4,730/mes
  ¿Lo ves? ¡El tráfico representa el 95%! Y eso con $0.09/GB; volúmenes pequeños ni siquiera tienen descuento.
  Conozco a alguien con un servicio de hosting de imágenes: 20 TB/mes de tráfico, factura S3 anual de $20,676. Se quejaba: «Almacenamiento $276, el resto es tráfico; parece que trabajo para AWS».

Dónde está la ventaja de coste de R2

La gran baza de Cloudflare R2 es: cero cuota de egreso.
Ojo: no es un descuento, es gratis. Tanto 1 TB como 100 TB de tráfico cuestan $0. Para apps con mucho tráfico, es un salvavidas.
Desglose de costes:

• Almacenamiento: $0.015/GB, es decir $15/TB (35% más barato que S3)
• Cuota de egreso: $0 (S3 cobra $90/TB)
• Operaciones: Class A $4.50/millón, Class B $0.36/millón
  R2 también tiene cuota gratuita:
• 10 GB de almacenamiento
• 1 millón de operaciones Class A (escritura, listado)
• 10 millones de operaciones Class B (lectura)
  Para un blog personal o proyecto pequeño, puede quedar dentro de la cuota gratuita.

Comparativa de casos reales (no solo teoría)

Resumo 3 escenarios típicos:

Cuándo no merece la pena migrar

Tras tantas ventajas, también debo decir cuándo R2 no encaja, para que no migres y luego me culpes:

1. Fuerte dependencia del ecosistema AWS: si usas mucho Lambda, Athena, EMR, migrar a R2 implica muchos cambios; puede no compensar.
2. Funciones avanzadas de cumplimiento: S3 tiene Object Lock y Legal Hold; sectores financiero y sanitario pueden exigirlos. R2 aún no los soporta.
3. Tráfico muy bajo: menos de 100 GB/mes; el ahorro es mínimo (quizá unas decenas de dólares); mejor centrarse en el negocio.
4. Requisitos estrictos de ubicación: S3 tiene 33 regiones; R2 ofrece location hint pero menos opciones. Si necesitas datos en un país concreto (p. ej. China o Rusia), confirma antes.
   Mi criterio: si el tráfico supera 500 GB/mes, el ROI compensa. Por debajo, depende de tu sensibilidad al coste.

La verdad sobre compatibilidad API entre R2 y S3 (con guía de errores)

Hasta qué punto es compatible R2

Es la pregunta clave: ¿migrar a R2 hará caer la aplicación? ¿Cuánto código hay que cambiar?
Mi conclusión tras pruebas reales: R2 implementa el 80-90% de las funciones principales de la API S3; las operaciones habituales están cubiertas.
Cloudflare fue inteligente: implementó la parte más usada de la API S3, incluyendo:

Alibaba Cloud - Opción preferida para desarrolladores, 15 % de descuento exclusivo en Lighthouse

Obtener 15% dto. →Anuncio

• Operaciones básicas: PutObject, GetObject, DeleteObject, ListObjects (el 99% de los casos)
• Funciones avanzadas: Multipart Upload, Presigned URLs, configuración CORS
• Gestión de permisos: Bucket policies, IAM-style access keys
  Lo mejor: solo cambias endpoint URL y credenciales; el código casi no se toca.
  Por ejemplo, en un proyecto con AWS SDK for JavaScript, migrar a R2 fue cambiar 3 líneas:

// Configuración S3 original
const s3 = new AWS.S3({
  region: 'us-east-1'
});
// Migración a R2 (solo endpoint y credenciales)
const r2 = new AWS.S3({
  endpoint: `https://${ACCOUNT_ID}.r2.cloudflarestorage.com`,
  accessKeyId: R2_ACCESS_KEY_ID,
  secretAccessKey: R2_SECRET_ACCESS_KEY,
  signatureVersion: 'v4',
});

El resto del código de subida, descarga y borrado quedó igual. Lo probé dos semanas sin problemas de compatibilidad.

Funciones no soportadas (alerta)

R2 no es un reemplazo perfecto de S3. Algunas funciones no están disponibles; confirma antes si tu app las usa:
1. S3 Select (consultas SQL sobre objetos)
Si usas S3 Select para SQL directo en S3, R2 no lo soporta. Hay que descargar y consultar localmente u otra solución.
2. Object Lock y Legal Hold (bloqueo de cumplimiento)
Muy usado en finanzas y salud (WORM - Write Once Read Many). R2 aún no lo tiene; si tu auditoría lo exige, no migres.
3. Versioning (control de versiones)
El versionado de S3 en R2 es limitado. Si dependes mucho del rollback por versiones, prueba con cuidado.
4. Consultas y análisis avanzados
S3 Inventory, S3 Object Lambda, etc., no están en R2.
Mi consejo: antes de migrar, lista las funciones S3 de tu app y compáralas con la documentación oficial de compatibilidad API de Cloudflare. La mayoría solo usa funciones básicas y no tendrá problemas.

Pruebas de compatibilidad con herramientas

Probé varias herramientas habituales; en general cambian sin fricción:

Un error que cometí

En una migración usé ListObjectsV2 con el parámetro StartAfter para paginación. Tras migrar a R2, la paginación se comportó distinto y faltaron datos.
Resultó que la paginación de R2 difiere ligeramente de S3. Al usar ContinuationToken quedó resuelto.
Lección: tras migrar, prueba a fondo; no solo el flujo normal, también casos límite.

Comparativa de 3 métodos de migración: elige el tuyo

Cloudflare ofrece dos herramientas oficiales (Super Slurper y Sippy); la comunidad tiene rclone y más. La elección depende de tu escenario.

Método 1: Super Slurper (recomendado para principiantes, migración única)

Super Slurper es la herramienta oficial de migración en un clic, ideal para «quiero mover todo de una vez».
Ventajas claras:

• Operación sencilla: unos formularios y empieza
• Conserva metadatos (metadata, content-type, etc.)
• No borra datos de origen; riesgo cero
• Gratis; solo pagas operaciones Class A de R2 (muy baratas)
• Tras la actualización de 2024, velocidad 5× mayor
  Desventajas:
• Solo migración única, sin sincronización incremental
• Archivos nuevos en S3 durante la migración no se sincronizan solos a R2
• Objetos individuales menores de 50 GB (archivos enormes pueden dar problemas)
  Para quién:
• Menos de 10 TB de datos
• Puedes tolerar breve inactividad (o el negocio aún no está en producción)
• Cambio total a R2 sin seguir usando S3
  Mi primer proyecto usó Super Slurper: 100 GB en ~30 minutos. Ventana de mantenimiento a las 3 AM; los usuarios casi no lo notaron.

Método 2: Sippy (sin inactividad, migración progresiva)

Sippy es el esquema inteligente de Cloudflare; su gran ventaja es no requiere parada.
Cómo funciona:
Apuntas la app a R2. Cuando un usuario pide un archivo:

1. R2 busca si lo tiene
2. Si sí, lo devuelve (muy rápido)
3. Si no, lo trae de S3, lo copia a R2; la próxima vez sale de R2
   Los datos migran bajo demanda: lo caliente primero, lo frío después.
   Ventajas:

• Cero inactividad; imperceptible para el usuario
• Reduce cuota de tráfico S3 (tras migrar datos calientes, el tráfico va por R2)
• Migras y observas; si algo falla, vuelves a S3
  Desventajas:
• Primera petición de un archivo algo más lenta (hay que traerlo de S3)
• Configuración más compleja; hay que tocar la app
• Mejor con patrones de acceso claros (datos calientes vs fríos)
  Para quién:
• Producción que no puede parar
• Volúmenes enormes (más de 10 TB); migración única tardaría demasiado
• Quieres probar estabilidad de R2 antes del cambio total
  Un amigo con servicio CDN migró 50 TB con Sippy: atendía usuarios mientras migraba en segundo plano; dos meses hasta terminar, sin impacto en el negocio.

Método 3: rclone (para expertos, máxima flexibilidad)

rclone es herramienta open source de sincronización; muy potente pero requiere terminal.
Ventajas:

• Gratis y open source
• Reanudación tras cortes de red
• Sincronización programada (p. ej. incremental cada noche)
• Verificación de integridad (MD5, SHA256)
• Limitación de ancho de banda
  Desventajas:
• Línea de comandos; curva de aprendizaje
• Scripts propios para gestionar progreso
• Durante la transferencia puede generar cuota de egreso S3 (desde marzo 2024 AWS no cobra tráfico de salida por migración)
  Para quién:
• Dominas la terminal y quieres control total
• Necesitas sincronización continua (doble escritura S3/R2 un tiempo)
• Exiges máxima integridad de datos
  Yo prefiero rclone: scripts automatizados y logs detallados. Comando que usé:

rclone copy s3:my-bucket r2:my-bucket \
  --progress \
  --checksum \
  --transfers 32 \
  --s3-chunk-size 64M

--checksum verifica MD5 de cada archivo. --transfers 32 con 32 hilos; muy rápido.

Decisión rápida: ¿cuál elijo?

Árbol de decisión:

¿Puedes parar?
├─ Sí → ¿Menos de 10 TB?
│      ├─ Sí → Super Slurper (más simple)
│      └─ No → rclone (rápido y controlable)
└─ No → Sippy (sin inactividad)
Perfil técnico + control total → rclone

Mi consejo: para la mayoría, Super Slurper basta. Salvo que no puedas parar ni un minuto o tengas más de 50 TB, la simplicidad de Super Slurper compensa más que la flexibilidad de otras opciones.

Railway - Plataforma de despliegue moderna, sin ops complejas, en producción en minutos

Empezar ahora →Anuncio

Práctica: migración sin riesgo en 30 minutos (Super Slurper)

Teoría hecha; ahora paso a paso. Ejemplo con Super Slurper: 30 minutos para configurar (el tiempo de transferencia aparte).

Paso 1: Preparación (5 minutos)

1. Registra Cloudflare y activa R2
Ve a Cloudflare, regístrate y en el menú lateral busca «R2 Object Storage» y actívalo.
Nota: R2 pide tarjeta, pero hay cuota gratuita; proyectos pequeños pueden costar $0.
2. Crea bucket R2
«Create bucket»:

• Nombre (recomendado igual que S3)
• Location hint (si hay cumplimiento EU, si no Automatic)
  ⚠️ Importante: location hint y jurisdictional restrictions no se pueden cambiar después. En la mayoría de casos, Automatic basta.
  3. Crea usuario IAM de solo lectura en AWS
  No uses las claves de la cuenta principal; riesgo de seguridad.
  AWS IAM → Users → Add User:
• Usuario: r2-migration-readonly
• Access type: Programmatic access
• Permissions: Attach existing policies → «AmazonS3ReadOnlyAccess»
  O política personalizada (más segura, solo un bucket):

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "s3:GetObject",
        "s3:ListBucket"
      ],
      "Resource": [
        "arn:aws:s3:::your-bucket-name",
        "arn:aws:s3:::your-bucket-name/*"
      ]
    }
  ]
}

Tras crear, copia Access Key ID y Secret Access Key; solo se muestran una vez.
4. Genera API Token de R2
Cloudflare R2 → Manage R2 API Tokens → Create API Token:

• Nombre: migration-token
• Permissions: Object Read & Write
• Selecciona el bucket creado
  Guarda Access Key ID y Secret Access Key.

Paso 2: Ejecutar migración (15 minutos de configuración)

1. Entra en Data Migration
Consola R2 → «Data Migration» → «Migrate Files».
2. Elige Super Slurper
Verás Super Slurper y Sippy. Elige Super Slurper (migración única).
3. Datos del bucket origen (S3)

• Provider: Amazon S3
• Bucket name: nombre del bucket S3 (p. ej. my-images)
• Bucket region: región (p. ej. us-east-1, visible en consola S3)
• Access Key ID: del usuario IAM
• Secret Access Key: la clave correspondiente
  «Verify Connection»; si va bien, marca verde.
  4. Datos del bucket destino (R2)
• Bucket name: bucket R2 creado
• R2 Access Key ID: del API Token R2
• R2 Secret Access Key: clave correspondiente
  5. Opciones de migración
• Overwrite existing objects: sobrescribir existentes (recomendado marcar)
• Path prefix (opcional): solo una carpeta (p. ej. images/)
  6. Review y Start Migration
  Revisa configuración y «Start Migration».
  7. Espera la transferencia
  Verás:
• Velocidad
• Archivos migrados
• Tiempo restante
  Estimación:
• 100 GB → ~30 minutos
• 1 TB → ~4-6 horas
• 10 TB → ~2-3 días
  Puedes cerrar la página; la migración sigue. Vuelve cuando quieras a ver progreso.

Paso 3: Validar resultado (10 minutos)

Tras terminar, no borres S3 de inmediato; valida primero.
1. Número de objetos
En consola R2 compara:

• Objetos S3: X
• Objetos R2: X
  Si no coinciden, revisa logs de fallos.
  2. Integridad (muestreo)
  Descarga algunos archivos y compara MD5:

# MD5 del archivo en S3
aws s3api head-object --bucket my-bucket --key test.jpg --query 'ETag' --output text
# MD5 en R2 (rclone o descarga directa)
rclone md5sum r2:my-bucket/test.jpg

Si el ETag coincide, el archivo está íntegro.
3. Acceso a archivos
Prueba URL pública R2 o API para descargar.
4. Metadatos
Confirma que no se perdió metadata personalizada:

aws s3api head-object --bucket my-bucket --key test.jpg
# Compara con metadata R2

Paso 4: Cambiar la aplicación a R2

Tras validar, cambia la app. Recomiendo despliegue gradual, no todo de golpe.
1. Configuración de la aplicación
Si usas variables de entorno para S3:

# Configuración S3 original
S3_ENDPOINT=https://s3.amazonaws.com
S3_BUCKET=my-bucket
S3_ACCESS_KEY=xxx
S3_SECRET_KEY=xxx
S3_REGION=us-east-1
# Cambio a R2
S3_ENDPOINT=https://YOUR_ACCOUNT_ID.r2.cloudflarestorage.com
S3_BUCKET=my-bucket
S3_ACCESS_KEY=R2_xxx
S3_SECRET_KEY=R2_xxx
S3_REGION=auto  # R2 usa auto

2. Prueba gradual
Empieza con 10% de tráfico:

• Logs de aplicación
• Tasa de error
• Feedback de usuarios
  Si va bien: 10% → 50% → 100%.
  3. Métricas clave
  Tras migrar vigila:
• Tasa de error API
• Tiempo de respuesta
• Cuota de tráfico (debe bajar mucho)
  4. Conserva backup en S3
  Recomiendo 30 días en S3 antes de borrar. Desde marzo 2024 AWS no cobra tráfico de salida por migración; borrar no cuesta extra.
  Para limpieza automática, política de ciclo de vida:

{
  "Rules": [
    {
      "Status": "Enabled",
      "Expiration": {
        "Days": 30
      }
    }
  ]
}

Tras 30 días se eliminan los objetos automáticamente.

Vultr - Servidor cloud NVMe de alto rendimiento, 32 ubicaciones globales, despliegue Docker con un clic

Ver precios →Anuncio

Optimización y monitorización tras la migración

Migrar no es el final; es el inicio de la optimización. Cómo sacar más rendimiento y valor de R2.

Optimización de rendimiento

1. Acelera con CDN de Cloudflare
R2 ya está en la red global de Cloudflare; con CDN va mejor:

• Bucket R2 → Public Access → Connect Domain
• Vincula tu dominio (debe estar en Cloudflare)
• Caché CDN automática
  El contenido sale del nodo CDN más cercano; muy rápido.
  2. Cache-Control adecuado
  Al subir, define Cache-Control para la CDN:

// Recursos estáticos (imagen, vídeo): caché 1 año
s3.upload({
  Bucket: 'my-bucket',
  Key: 'image.jpg',
  Body: fileBuffer,
  CacheControl: 'public, max-age=31536000, immutable'
});
// Contenido que cambia a menudo: caché 1 hora
s3.upload({
  // ...
  CacheControl: 'public, max-age=3600'
});

3. Dominio personalizado en R2
La URL por defecto es fea: https://xxx.r2.cloudflarestorage.com/file.jpg
Con dominio propio: https://cdn.yoursite.com/file.jpg
Más limpio y mejor rendimiento CDN.

Optimización de coste

1. Datos fríos en Infrequent Access
R2 tiene clase IA para acceso poco frecuente:

• Almacenamiento más barato ($0.01/GB vs $0.015/GB estándar)
• Lectura con cargo extra ($0.01/GB)
  Ideal: archivos históricos, backups, datos fríos.
  2. Optimiza part size en Multipart Upload
  El tamaño de part afecta operaciones Class A; cada part cuenta como Class A:
• Part muy pequeño → más operaciones → más coste
• Part muy grande → retransmisión costosa si falla
  Recomendación:
• Menos de 100 MB → subida única
• 100 MB-1 GB → part 64 MB
• Más de 1 GB → part 128 MB
  Con rclone:

rclone copy s3:bucket r2:bucket --s3-chunk-size 64M

3. Monitoriza operaciones Class A/B
El tráfico es gratis, pero las operaciones no:

• Class A (escritura): $4.50/millón
• Class B (lectura): $0.36/millón
  En consola R2 ves operaciones mensuales. Si Class A es muy alta, revisa subidas duplicadas o peticiones inválidas.

Monitorización: detectar problemas pronto

1. Cloudflare Analytics
R2 incluye Analytics:

• Número de peticiones
• Volumen de tráfico
• Tasa de error
• Archivos más solicitados
  Bucket R2 → Analytics.
  2. Alertas de coste
  Umbral y notificación automática:
  Cloudflare Dashboard → Notifications → Add → «R2 storage usage»
  P. ej. «avisar por email si el gasto mensual supera $50».
  3. Monitorización en aplicación
  En tu app vigila:
• Tasa de error API (objetivo <0.1%)
• Tiempo de respuesta medio (objetivo <100 ms)
• Latencia P99 (objetivo <500 ms)
  Sentry, Datadog u otras APM; si algo falla, rollback.
  4. Compara factura S3 cada mes
• Factura S3 antes de migrar
• Factura R2 después
• Ahorro (¡para celebrar con el equipo! 😄)
  Tengo una hoja Excel mensual; ver el ahorro crecer da mucha satisfacción.

Resumen: ¿merece la pena migrar a R2?

Tras todo esto, mi respuesta: si tu app supera 500 GB/mes de tráfico, migrar a R2 merece mucho la pena.
Tres beneficios principales:

1. Ahorro real: cero cuota de egreso puede recortar la factura cloud un 50-90%. SaaS ahorrando $10,000+ al año es habitual; plataformas de vídeo $50,000+ también.
2. Migración sencilla: Super Slurper en 30 minutos de configuración; compatibilidad API 80-90%; muchas apps solo cambian endpoint. En mis pruebas, menos complejo de lo que parece.
3. Riesgo controlado: no borra origen; despliegue gradual; rollback si hace falta. AWS ya no cobra tráfico de migración; coste de prueba casi cero.
   Pero R2 no lo es todo:

• Si dependes mucho de AWS (Lambda, Athena, etc.), el coste de migración es alto
• Si necesitas Object Lock u otras funciones avanzadas de cumplimiento de S3, R2 aún no las tiene
• Con tráfico muy bajo (menos de 100 GB/mes), el ROI no es claro
  Mi consejo: prueba primero con la cuota gratuita de R2; confirma rendimiento y estabilidad antes de migrar a gran escala. Sippy para migración gradual minimiza el riesgo.
  Una anécdota: un amigo con hosting de imágenes pagaba $1,800/mes en S3; tras R2 solo $18 (almacenamiento). Con el ahorro contrató un diseñador; la UX mejoró mucho. Optimizar costes no es solo ahorrar: es invertir donde más valor aporta.
  Empieza ya:

1. Usa la calculadora R2 para ver cuánto ahorrarías
2. Prueba rendimiento con la cuota gratuita
3. Elige método (Super Slurper / Sippy / rclone)
4. Migra gradualmente y valida estabilidad
5. Cambio total y disfruta del ahorro
   Si tienes problemas en la migración, comenta abajo. ¡Buena migración y facturas más bajas!