Кратко

  • В опубликованных тарифах R2, проверенных 19 сентября 2026 года, исходящая передача данных стоит 0 долл. США за ГБ для Standard и Infrequent Access. Но у Infrequent Access отдельно предусмотрена плата за извлечение данных — 0,01 долл. за ГБ, а операции стоят дороже, чем у Standard. Это разные составляющие счёта, а не противоречие в тарифе. Источник: Cloudflare.
  • Cloudflare описывает копирование объекта из R2 в локальное хранилище с помощью Rclone. Такая инструкция показывает, что путь выгрузки существует в документации, но не доказывает стоимость, скорость или полноту переноса конкретного приложения. Источник: Cloudflare.
  • Экономический результат зависит от объёма хранения, числа оплачиваемых операций, объёма извлечения и условий перехода. Проверка работающей замены должна идти отдельно от проверки того, удалось ли скопировать данные.

Какой именно барьер отсутствует

Для покупателя облачного хранилища важны два разных обещания: «за исходящий трафик платить не нужно» и «уйти к другому поставщику можно без существенных расходов». Первое описывает тарифную строку. Второе потребовало бы знания архитектуры приложения, условий нового размещения и результатов самого переноса. Подмена одного другим превращает понятную цену в неподтверждённый вывод о свободе выбора.

В случае Cloudflare полезно начинать с узкого, но вполне материального факта. В проверенной таблице цен R2 ставка за исходящую передачу равна нулю. При применении именно этой ставки увеличение исходящего объёма не увеличивает соответствующий компонент платы. Это преимущество не исчезает оттого, что рядом существуют другие расходы. Однако оно не делает бесплатными действия, необходимые для чтения и переноса объектов.

Этот разбор относится к опубликованным условиям, наблюдавшимся 19 сентября 2026 года. Он не устанавливает, что в этот день Cloudflare снизила цену или ввела новую политику. Без сопоставимой прежней тарифной сетки и подтверждённой даты изменения нельзя описывать нынешнюю ставку как свежую скидку. Для оценки сегодня достаточно другого вопроса: какие расходы предусмотрены действующей опубликованной структурой цен и что из неё следует для выбора клиента.

У этого вопроса есть финансовая и эксплуатационная части. Финансовая проверяет, какие измеряемые действия превращаются в начисления. Эксплуатационная — можно ли получить пригодные данные, восстановить нужное поведение приложения и обслуживать пользователей на другой площадке. Нулевой тариф влияет на первую часть, но не выполняет вторую работу вместо клиента.

Поэтому корректный вывод не должен ни обесценивать отсутствие платы за трафик, ни объявлять его доказательством полной переносимости. Между ними находится проверяемая последовательность: доступ к данным, их перенос, проверка результата, запуск замены и подтверждение того, что она выполняет требуемую работу. Документация R2 позволяет предметно обсуждать начало этой последовательности. Её завершение требует дополнительных наблюдений.

Дешевле хранить — не обязательно дешевле читать

Cloudflare публикует для R2 две разные комбинации цен. У Standard выше ставка хранения, но ниже ставки операций. У Infrequent Access дешевле хранение, зато дороже операции и отдельно оплачивается извлечение данных. Таблица ниже воспроизводит перечисленные единичные ставки; это не расчёт счёта какого-либо клиента. Тарифы R2.

Компонент Standard Infrequent Access
Хранение, долл. США за ГБ·месяц 0,015 0,010
Операции Class A, долл. за миллион 4,50 9,00
Операции Class B, долл. за миллион 0,36 0,90
Исходящая передача, долл. за ГБ 0,00 0,00
Минимальная продолжительность хранения Не установлена 30 дней

Для Infrequent Access дополнительно указана ставка извлечения данных 0,01 долл. за ГБ. Class A в общих чертах охватывает операции записи, перечисления и изменения; Class B — чтение и получение метаданных. По одной этой классификации нельзя определить, сколько оплачиваемых запросов создаст конкретная программа переноса. Это необходимо выяснять на уровне её фактических действий.

Разница между классами выражается вполне точно. Ставка хранения Infrequent Access на 0,005 долл. за ГБ·месяц, или на треть, ниже Standard. При этом ставка Class A вдвое выше, а Class B — в 2,5 раза. Речь идёт о соотношении опубликованных единичных цен, а не об изменении тарифов во времени и не о подтверждённой экономии клиента.

Существуют и условия, которые мешают просто умножить объём на ставку и назвать результат окончательным счётом. Ежемесячный бесплатный объём Standard включает 10 ГБ·месяц хранения, один миллион операций Class A и десять миллионов Class B. На Infrequent Access этот бесплатный объём не распространяется. Документация также предусматривает округление использования вверх до следующей единицы тарификации. Условия тарификации Cloudflare.

Эти детали особенно важны при сравнении небольших или нерегулярных нагрузок, но их нельзя заменять догадками. Здесь не установлено, как бесплатные объёмы распределяются между всеми возможными учётными записями или проектами конкретного покупателя. Не рассчитаны и точные последствия досрочного удаления либо смены класса хранения. Наличие 30-дневного минимума у Infrequent Access — известное условие; конкретное начисление требует применимых правил и истории использования.

Практический смысл таблицы в другом. Поставщик продаёт не единую величину «облако за гигабайт», а набор измеряемых услуг. Выбор класса меняет относительную цену сохранения данных и обращения к ним. Чтобы сравнение имело смысл, клиенту нужно удерживать в расчёте обе стороны, а не выбирать удобную строку и считать остальные несущественными.

Почему пятидолларовая разница может исчезнуть

Покажем механизм на условном объёме 1 000 ГБ·месяц. По перечисленным ставкам компонент хранения Standard составит 15 долл., а Infrequent Access — 10 долл. Исходная разница равна 5 долл. При ставке извлечения Infrequent Access 0,01 долл. за ГБ извлечение 500 оплачиваемых ГБ добавит те же 5 долл. Это поглотит всю разницу компонентов хранения ещё до учёта различий в оплате операций. Основа расчёта: цены Cloudflare.

Если в том же условном сравнении извлечение составит 1 000 оплачиваемых ГБ, сумма хранения и извлечения Infrequent Access достигнет 20 долл. Сопоставляемый компонент хранения Standard останется равным 15 долл. Из этого не следует, что Standard всегда дешевле: мы изолировали только часть условий и не подставляли реальную нагрузку.

В частности, эти 500 или 1 000 ГБ — заданные величины оплачиваемого извлечения. Они не означают, что любое обращение извлекает объект целиком, что именно такой объём обязательно появится при миграции или что произведён физический замер передачи. Это иллюстрация арифметики тарифа, а не отчёт о поведении приложения.

Более общий расчёт помогает увидеть, где меняется результат. Обозначим через S объём хранения в ГБ·месяц, через A и B — число операций соответствующих классов в миллионах, через R — оплачиваемое извлечение Infrequent Access в ГБ. При одинаковых S, A и B для обоих вариантов линейная модель компонентов стоимости в долларах имеет следующий вид:

Standard = 0,015 × S + 4,50 × A + 0,36 × B

Infrequent Access = 0,010 × S + 9,00 × A + 0,90 × B + 0,010 × R

Разница IA минус Standard =
−0,005 × S + 4,50 × A + 0,54 × B + 0,010 × R

Модель специально не учитывает бесплатные объёмы, округление, корректировки из-за минимальной продолжительности хранения, налоги, договорные условия, скидки и кредиты. За её пределами также находятся расходы принимающей стороны, работа инженеров, проверка данных, параллельная эксплуатация и другие сервисы. Применение ставок здесь непрерывное и линейное; это не воспроизведение системы выставления счетов.

Отрицательный член в последней строке представляет преимущество Infrequent Access по цене хранения. Положительные члены показывают, как его могут уменьшить более дорогие операции и извлечение. Поэтому пример с 500 ГБ нельзя превращать в универсальную точку безубыточности. Как только меняется количество операций или вступают в действие исключённые условия, сравнение становится другим.

Равный объём данных также не гарантирует равных расходов на операции. Для финансового решения полезны не только байты, но и оплачиваемые запросы. Пока их число неизвестно, нельзя честно назвать цену выгрузки, даже если ставка за сам исходящий трафик известна точно. Разумное бюджетирование начинается с разделения этих величин, а не с попытки уместить их в одно обещание «бесплатного выхода».

Выгрузка описана, но перенос сервиса ещё не выполнен

Было бы неверно рассматривать R2 как хранилище, для которого не показан путь наружу. В инструкции Cloudflare по Rclone есть пример копирования объекта из корзины R2 в локальное место назначения:

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

Это пример именно исходящего копирования из R2, а не только загрузки данных в продукт. Документация описывает настройку через S3-совместимый механизм доступа с выбором Cloudflare R2, использованием идентификатора ключа доступа, секретного ключа и конечной точки S3 API. В требованиях настройки также фигурируют идентификатор учётной записи Cloudflare и токен R2 API с подходящей областью доступа. Инструкция Cloudflare по Rclone.

Такое описание полезнее общего заявления, что данные «можно забрать»: оно указывает процедуру, которую клиент способен проверить. Но инструкция не является протоколом успешного переноса. Для этого материала команда не выполнялась; скорость, число повторных попыток и результаты проверки полученных объектов не измерялись. Нельзя приписывать примеру свойства испытанной промышленной миграции.

Важна и семантика команды. По документации Rclone, copy копирует между источником и назначением, пропускает идентичные файлы и не удаляет файлы в месте назначения. Если источником служит каталог, копируется его содержимое, а не сам каталог. Rclone также предусматривает --dry-run, позволяющий предварительно посмотреть действия без выполнения копирования. Описание rclone copy.

Отсутствие удаления не превращает copy в операцию только для чтения и не гарантирует неизменность всего содержимого назначения. Предварительный просмотр, в свою очередь, не измеряет пропускную способность, не подтверждает доставку и не показывает, сможет ли приложение работать на новом месте. У каждого из этих инструментов есть полезная, но ограниченная доказательная роль.

Отдельно следует отличать копирование от синхронизации. Cloudflare предупреждает, что sync может удалить в месте назначения файлы, отсутствующие в источнике. Поэтому переход от одного слова к другому — не безобидная редакционная замена в плане переноса. Для разрушительных действий нужен отдельный проверенный порядок, а не предположение, что все похожие команды ведут себя одинаково. Предупреждение в инструкции Cloudflare.

Сами требования к ключам и токенам не означают, что клиенты R2 лишены контроля над доступом. Они обозначают вопросы для конкретного испытания: кто может разрешить операцию, какие полномочия нужны и доступны ли они той команде, которая отвечает за переход. Обнаруженная в отдельной организации проблема с управлением доступом тоже не была бы автоматически доказательством ограничения со стороны продукта.

Наконец, выгрузка одного объекта не устанавливает сохранность всех данных и состояния приложения. Покупателю необходимо самому определить, какие свойства результата существенны для его сервиса. Иначе команда может завершиться, а спор о том, что считалось успешным переносом, только начнётся. Успех операции и успех хозяйственного решения требуют разных критериев.

Совместимый интерфейс — начало проверки, а не её итог

Cloudflare описывает R2 как реализацию S3 API, облегчающую миграцию, но одновременно указывает на различия в функциях API и отслеживает состояние реализации по мере развития продукта. Это аргумент в пользу проверки фактически используемых операций и параметров, а не основание объявлять все S3-совместимые среды взаимозаменяемыми. Документация совместимости R2.

В рассмотренных сведениях нет достаточного перечня статусов отдельных функций для вывода, что конкретная необходимая возможность поддерживается или отсутствует. Поэтому данный разбор не устанавливает дефект определённой операции и не обещает полного совпадения поведения на обоих концах переноса. Неизвестность здесь нельзя автоматически записать ни в достоинства, ни в недостатки Cloudflare.

Для клиента вопрос стоит конкретнее: какие действия выполняет его приложение, какие ответы считает корректными и какое состояние должно сохраниться? В перечень проверки могут войти свойства объектов, используемые идентификаторы, правила доступа и другие зависимости — если они действительно нужны этому приложению. Это программа исследования, а не утверждение, что у любого пользователя R2 есть все перечисленные зависимости.

Смысл такого подхода в том, чтобы проверять заменимость по функции, а не по названию интерфейса. Две системы могут подходить для одной задачи и требовать дополнительной работы для другой; в данном случае вывод должен следовать из испытания конкретной задачи. Одного общего обозначения API недостаточно, чтобы рассчитать инженерные часы или утвердить дату переключения.

При этом сама дополнительная работа ещё не доказывает недобросовестное удержание клиента. Она может быть связана с масштабом нагрузки, выбранной архитектурой или требованиями самого покупателя. Чтобы приписать расходы специфическому барьеру поставщика, сначала нужно показать этот барьер и отделить его от обычной работы по смене среды.

Что должно показать испытание выхода

Содержательный тест начинается не с массового копирования, а с описания результата. Для одной задачи достаточно получить пригодную копию данных; для другой нужно запустить замену с теми же существенными функциями. Для перехода действующего сервиса потребуется ещё и проверка непрерывности работы. Эти цели не равнозначны, и нельзя объявлять выполненной более широкую, располагая доказательством только узкой.

Первый шаг — выбрать представительную часть нагрузки. Критерий представительности должен отражать реальные требования покупателя: используемые операции, свойства данных и характер обращения к ним. В этом материале такой выбор не делался, поэтому здесь нет универсального набора объектов, который гарантированно заменит испытание каждого клиента.

Второй шаг — зафиксировать разрешения, источник, назначение и безопасный порядок действий. Настройка доступа должна быть воспроизводимой, а не зависеть от случайно сохранившейся возможности одного сотрудника. Это рекомендация по контролю испытания, не сообщение о состоянии доступа у пользователей Cloudflare. Предварительный просмотр может помочь проверить план, но не должен подменять его исполнение.

Третий шаг — выполнить ограниченный перенос и измерить затраченное время, запросы, оплачиваемое извлечение, повторные попытки и расходы назначения. Затем следует проверить результат по заранее выбранным признакам. Неудача на этом этапе потребует выяснить причину, а не сразу объявить продукт непереносимым; успех потребует точно указать, на какой объём и условия он распространяется.

Четвёртый шаг — проверить приложение на замене. Для такой проверки важен не только факт запуска, но и выполнение существенных функций. Если остаются обращения к исходной среде, их следует назвать и оценить: часть может быть сознательно сохранённой интеграцией, часть — неучтённой зависимостью. Независимость нельзя подтвердить, не определив, от чего именно предполагалось отказаться.

Пятый шаг — составить план переключения, периода совместной работы и возврата при неприемлемом результате. Возврат к прежней системе защищает от последствий неудачного перехода, но сам по себе не доказывает жизнеспособность замены. Эти две возможности полезны по-разному и должны оцениваться раздельно.

Ни один из этих шагов не был выполнен в рамках данного разбора. Они показывают, каких сведений не хватает между тарифной таблицей и уверенным обещанием исполнимого выхода. Следующее содержательное доказательство — не повторение нулевой ставки, а измеренный перенос представительной нагрузки с проверкой её работы после смены среды.

Что это позволяет сказать о конкуренции

Экономическая ценность нулевой ставки за исходящий трафик вполне реальна на уровне соответствующего компонента цены. Но доказательство влияния на рыночную власть потребовало бы дополнительных данных: о поведении покупателей, стоимости альтернатив, фактических переходах или реакции конкурентов. Тариф и инструкция сами по себе таких наблюдений не дают.

Не установлены здесь и финансовые мотивы Cloudflare, прибыльность R2 либо влияние продукта на выручку компании. Из отсутствия одной платы нельзя вывести ни наличие субсидирования, ни намерение компенсировать её определённой другой услугой. Можно исследовать структуру стимулов, но нельзя выдавать возможную стратегию за раскрытый факт.

На стороне покупателя вывод уже применим. Стоимость передачи данных и стоимость смены поставщика нужно учитывать отдельно. У R2 есть нулевая ставка первой и документированный способ выгрузки; величина второй остаётся вопросом конкретной нагрузки. Чем ближе клиент подходит к измеренной, работающей замене, тем содержательнее становится его выбор между уходом и добровольным продолжением сотрудничества.

Это не обещание, что уход окажется лучшим решением. Если интеграция полезна, а действующий сервис отвечает требованиям, сохранение отношений может быть рациональным. Важно другое: решение должно опираться на сопоставимые расходы и проверенные возможности, а не на ошибочное равенство между бесплатным трафиком и бесплатной заменой работающей системы.