Resumen

  • La tarifa de R2 consultada el 19 de septiembre de 2026 fija en cero el cargo por transferencia saliente tanto en Standard como en Infrequent Access. Esta última clase cobra, por separado, 0,01 dólares por GB recuperado y tiene precios superiores por operaciones. Tarifas de Cloudflare.
  • Cloudflare documenta un procedimiento para copiar objetos de R2 a un destino local. Eso permite plantear una prueba de salida, pero no acredita por sí solo una migración completa, un coste total nulo ni la continuidad de una aplicación en otro servicio. Documentación de exportación.

Para evaluar la oferta de Cloudflare, conviene empezar por la factura, no por una declaración general sobre la libertad del cliente. Si el precio publicado de la transferencia saliente es cero, aumentar el volumen que sale no añade coste por ese concepto. Sin embargo, leer, recuperar y trasladar los datos puede generar otros cargos. Después queda una tarea diferente: conseguir que el sistema que utilizaba esos datos siga funcionando en un destino alternativo.

La diferencia no es meramente semántica. Un cargo variable por salida puede encarecer una exportación; eliminar ese componente mejora la economía de la operación. Pero una empresa también necesita saber cuánto pagará por las solicitudes, cuánto trabajo requiere preparar el destino y qué dependencias conservará una vez terminada la copia. Ninguna de esas respuestas se obtiene multiplicando el tráfico por cero.

La documentación examinada permite establecer las condiciones publicadas de R2 y la existencia de un procedimiento de exportación. No permite afirmar que el 19 de septiembre haya entrado en vigor una rebaja, ni calcular el ahorro obtenido por un cliente real. El punto de partida es una tarifa observada en esa fecha, no una comparación histórica. La cuestión económica es qué hace esa tarifa y dónde deja de explicar el resultado.

Dos clases de almacenamiento, varias unidades de coste

La distinción resulta especialmente visible al comparar Standard con Infrequent Access. El nombre de esta última orienta sobre el patrón de uso al que podría convenir, pero no sustituye un cálculo de actividad. Según la tabla de precios de Cloudflare, los principales importes publicados son los siguientes, en dólares estadounidenses:

Concepto Standard Infrequent Access
Almacenamiento, por GB-mes 0,015 0,010
Operaciones de clase A, por millón 4,50 9,00
Operaciones de clase B, por millón 0,36 0,90
Transferencia saliente, por GB 0,00 0,00

Infrequent Access tiene una tarifa de almacenamiento un tercio inferior: la diferencia es de 0,005 dólares por GB-mes. En cambio, su precio unitario para las operaciones de clase A es el doble y el de las operaciones de clase B es 2,5 veces el de Standard. Son relaciones aritméticas entre precios de la misma tabla, no variaciones de precios a lo largo del tiempo.

Las operaciones de clase A comprenden, en términos generales, acciones de escritura, listado y modificación; las de clase B, lecturas y consultas de metadatos. Esta descripción ayuda a identificar por qué mover un volumen de datos puede implicar más que un cargo por bytes. No permite deducir cuántas solicitudes facturables producirá una aplicación o una exportación específica. Para eso hace falta observar la secuencia real de acciones y su clasificación.

Infrequent Access añade un cargo de recuperación de 0,01 dólares por GB y una duración mínima de almacenamiento de 30 días. Standard no tiene esa duración mínima. Además, la franquicia mensual gratuita corresponde únicamente a Standard: 10 GB-mes de almacenamiento, un millón de operaciones de clase A y diez millones de clase B. Cloudflare también indica que el uso se redondea hacia arriba a la siguiente unidad de facturación. Estas condiciones figuran en su documentación de precios.

Cada elemento puede modificar la comparación. La franquicia no debe extenderse a Infrequent Access ni asignarse por cuenta o proyecto sin comprobar el ámbito correspondiente. Tampoco basta conocer el mínimo de 30 días para reconstruir una factura por borrado anticipado o cambio de clase: se necesitan las reglas detalladas aplicables. Una tabla de tarifas es el inicio del análisis, no un simulador completo de facturación.

Por eso, «almacenamiento más barato» y «carga de trabajo más barata» son afirmaciones distintas. La primera está respaldada por el precio unitario de Infrequent Access. La segunda depende de las cantidades almacenadas, las operaciones, la recuperación y las demás condiciones. La salida gratuita de tráfico es común a ambas clases; no decide por sí sola cuál conviene.

Cinco dólares que pueden desaparecer sin ningún cargo de transferencia

Un cálculo ilustrativo permite aislar el mecanismo. Supongamos 1.000 GB-mes de almacenamiento, aplicando linealmente los precios publicados y dejando fuera franquicias, redondeos, ajustes por duración mínima, impuestos, descuentos y costes ajenos a R2. No es una factura de cliente ni una medición de tráfico.

El componente de almacenamiento sería de 15 dólares en Standard y de 10 dólares en Infrequent Access. La diferencia bruta a favor de esta última sería de 5 dólares. A su precio publicado de recuperación, 500 GB facturables recuperados sumarían otros 5 dólares y consumirían esa diferencia, antes de considerar los mayores precios por operaciones.

Con 1.000 GB facturables recuperados, almacenamiento y recuperación en Infrequent Access sumarían 20 dólares, frente a los 15 dólares del componente de almacenamiento de Standard. La transferencia saliente seguiría teniendo precio cero en ambos casos. El ejemplo no muestra una contradicción en la tarifa: muestra dos conceptos de cobro diferentes. Tampoco presupone que cada acceso recupere un objeto completo o que el volumen recuperado coincida necesariamente con una medición de tráfico de red.

La misma comparación puede escribirse de forma más general. Sea S el almacenamiento medido en GB-mes, A los millones de operaciones de clase A, B los millones de operaciones de clase B y R los GB facturables recuperados en Infrequent Access. Con iguales cantidades de almacenamiento y operaciones en ambas alternativas, el modelo de componentes sería:

  • Standard: 0,015 × S + 4,50 × A + 0,36 × B.
  • Infrequent Access: 0,010 × S + 9,00 × A + 0,90 × B + 0,010 × R.
  • Diferencia de Infrequent Access frente a Standard: −0,005 × S + 4,50 × A + 0,54 × B + 0,010 × R.

Estas fórmulas son cálculos propios sobre los precios publicados. Excluyen las condiciones anteriores y también el destino, el trabajo técnico, la validación, el funcionamiento simultáneo de los dos entornos y otros servicios. Un resultado positivo en la última expresión significa que Infrequent Access cuesta más dentro de este modelo limitado; no determina la factura final.

El uso de GB-mes importa: expresa almacenamiento a lo largo del periodo, no una fotografía del tamaño del conjunto de datos. También importa que A y B se midan en millones de operaciones, mientras R mide recuperación facturable. Mezclar esas unidades puede producir una cifra aparentemente precisa que no corresponde al uso del cliente.

El ejemplo de 500 GB no es, por tanto, una regla universal según la cual se pueda recuperar la mitad de cualquier conjunto antes de perder dinero. Aísla almacenamiento y recuperación bajo supuestos concretos. Los precios superiores por operaciones pueden consumir parte de la diferencia; las franquicias y las reglas de facturación pueden modificarla. Su utilidad es más modesta y más verificable: mostrar qué variables debe conservar una comparación que no quiera confundir tráfico gratuito con actividad gratuita.

La exportación está documentada; su resultado todavía debe medirse

Sería igualmente incorrecto presentar R2 como un almacén sin salida. La guía de Rclone de Cloudflare describe una copia desde un bucket de R2 hacia un destino local y ofrece este ejemplo:

rclone copy r2:user-uploads/dog.txt .

El ejemplo es relevante porque su dirección es hacia fuera de R2. Una función que solo importase datos no demostraría esa posibilidad. Aquí hay un procedimiento de exportación que el cliente puede someter a prueba. Este análisis no ha ejecutado el comando ni ha medido su rendimiento.

La configuración documentada utiliza el backend de almacenamiento compatible con S3 y el proveedor Cloudflare R2. Requiere un identificador de clave de acceso, una clave secreta y el endpoint de la API S3; la guía también identifica la cuenta de Cloudflare y un token de API de R2 con permisos y alcance adecuados. Son condiciones de preparación, no pruebas de que los clientes carezcan de credenciales o tengan impedida la salida.

El comportamiento del comando también delimita la conclusión. Según la documentación de Rclone sobre copy, copia entre origen y destino, omite archivos idénticos y no borra archivos del destino. Cuando el origen es un directorio, copia su contenido, no el directorio como tal. «No borra» no significa que la operación sea de solo lectura ni que todo el contenido existente en el destino vaya a permanecer sin cambios.

Rclone permite una vista previa mediante --dry-run, sin ejecutar la copia. Esa opción ayuda a revisar la acción prevista, pero no mide el caudal de transferencia, no acredita una copia completada y no comprueba que una aplicación funcione al otro lado. El resultado de una vista previa y el de una ejecución real deben registrarse como evidencias diferentes.

Tampoco conviene intercambiar sin más los conceptos de copia y sincronización. Cloudflare advierte de que sync puede eliminar en el destino archivos que no existan en el origen. Esa diferencia, señalada en su guía, exige un plan específico antes de utilizar una operación destructiva. La elección del procedimiento afecta a qué debe revisarse y a qué puede perderse; no es un detalle de redacción de una orden.

Nada de lo anterior establece que una transferencia de R2 a otro proveedor se realice íntegramente del lado de los servidores solo porque ambos extremos sean compatibles con S3. Este análisis no presupone esa propiedad. Para presupuestar la transferencia hay que conocer el recorrido y los recursos realmente utilizados, no adjudicarles una arquitectura a partir de una etiqueta de compatibilidad.

Compatibilidad no significa identidad de comportamiento

Cloudflare explica que R2 implementa la API S3 para facilitar la migración, pero también señala diferencias en las funciones y mantiene un registro del estado de implementación. Esa es la frontera que describe su documentación de compatibilidad: una base para comprobar necesidades concretas, no una garantía general de equivalencia.

La pregunta útil no es si una aplicación «usa S3», sino qué operaciones, parámetros y respuestas necesita. Una comprobación representativa debe partir de ese inventario. También debe identificar qué metadatos, políticas, identificadores u otros elementos de estado son necesarios para que los datos sigan siendo utilizables en el destino. Son cuestiones que debe resolver el cliente para su carga de trabajo, no deficiencias de R2 demostradas aquí.

La evidencia examinada no permite enumerar funciones específicas como compatibles o incompatibles más allá de lo expresamente documentado. En particular, no se puede inferir el estado de una función solo porque no aparezca en un resumen. Afirmar una carencia sin comprobarla sería tan improcedente como prometer equivalencia total a partir del nombre de la API.

Esta distinción explica por qué copiar objetos es una condición más estrecha que sustituir una carga de trabajo. La copia responde a una pregunta sobre los datos. La sustitución incorpora lo que la aplicación exige de ellos, cómo se autoriza el acceso y qué debe ocurrir cuando el sistema vuelve a recibir trabajo. Según el diseño del cliente, esa distancia puede ser pequeña o considerable. La documentación no la mide para una empresa concreta.

Hay, además, una defensa legítima de la integración. Puede reducir trabajo y aportar eficiencias que el cliente valore más que el coste de preparar una alternativa. La necesidad de adaptar una aplicación no demuestra por sí sola una conducta abusiva del proveedor. Para evaluar dependencia hay que distinguir el valor que se elige conservar de las condiciones que impedirían abandonar el servicio cuando fuese necesario.

Una prueba de salida debe terminar en el destino, no en el contador de bytes

El siguiente paso verificable sería un ensayo representativo, con criterios definidos antes de empezarlo. La finalidad no sería demostrar de antemano que R2 es fácil o difícil de sustituir. Sería conocer qué parte del proceso está resuelta y qué queda pendiente. Este artículo propone esa prueba; no informa de una migración realizada.

Primero, delimitar la muestra y el resultado esperado. El cliente tendría que elegir datos y acciones que representen su uso real, no solo un objeto conveniente para la demostración. Debería especificar qué contenido y estado asociado necesita preservar, qué comportamiento espera de la aplicación y qué margen de interrupción acepta. Sin esos criterios, completar una copia puede convertirse en un éxito técnico que no resuelve el problema empresarial.

Segundo, medir actividad y tiempo por separado. El registro tendría que conservar volumen recuperado, clases de operaciones, reintentos observados, duración de la copia y tiempo dedicado a verificar el resultado. No basta una cifra agregada de GB. Tampoco sería riguroso atribuir todos los reintentos o retrasos al almacenamiento de origen sin comprobar dónde se produjeron.

Tercero, conciliar costes. Los cargos medidos deberían separarse de las estimaciones y relacionarse con el periodo de facturación correcto. A los componentes de R2 se sumarían, cuando existan, los del destino, el trabajo técnico y el tiempo durante el cual ambos entornos deban mantenerse. Esa suma es una propuesta de presupuesto completo, no una afirmación sobre costes ya observados.

Cuarto, validar el servicio alternativo. Habría que comprobar integridad y comportamiento en el destino, y después identificar las dependencias que siguiesen siendo necesarias. El objetivo no tiene por qué ser eliminar toda relación comercial con Cloudflare. Debe ser demostrar que la función que se pretende sustituir ya no necesita apoyarse, de forma no prevista, en el mismo servicio que se quiere dejar.

La prueba también necesita límites. Un resultado con una muestra no garantiza cualquier escala; un éxito con datos inmóviles no resuelve automáticamente un sistema que sigue cambiando. Esas diferencias deben quedar descritas al interpretar el ensayo. Lo contrario convertiría una verificación acotada en otra promesa general de portabilidad.

Una ventaja real, sin una conclusión de mercado todavía

La ausencia de un cargo publicado por salida merece reconocerse por lo que es. No hay que restarle valor solo porque no elimine todos los costes. Para una operación con mucho tráfico saliente, ese componente puede ser importante. Su peso en la decisión concreta depende de las demás partidas y de la arquitectura del cliente.

También hay que reconocer el procedimiento documentado de exportación. Aporta algo que una promesa comercial aislada no ofrece: un punto de partida operativo. Pero pasar de ese punto a una alternativa que pueda sostener la aplicación requiere evidencia de ejecución, no una interpretación más ambiciosa del mismo documento.

Las fuentes examinadas son documentación de Cloudflare sobre tarifas, configuración y compatibilidad, junto con la descripción de copy de Rclone. No incluyen una factura representativa, una migración medida ni datos de comportamiento de clientes. Por ello, no permiten determinar ahorro realizado, pérdida de clientes, rentabilidad de R2, intención de subvencionar servicios o un efecto competitivo en todo el mercado. Tampoco sustentan una comparación de costes con ofertas concretas de otros proveedores.

La conclusión es acotada: R2 ofrece tráfico saliente sin cargo y una vía documentada para copiar datos fuera. Infrequent Access muestra con especial claridad por qué eso no equivale a una factura nula: combina almacenamiento más barato con recuperación facturable, operaciones más caras y una duración mínima. Para convertir la posibilidad de salir en una alternativa empresarial creíble, falta observar una transferencia representativa y un servicio validado en el destino.