За первые три квартала 2026 года мы провели переговоры с более чем ста российскими компаниями, использующими объектное хранилище S3. У большинства запрос одинаковый: тариф не менялся, объем полезных данных тот же, а счет вырос. Разберем, где именно прячутся расходы и почему первоначальный расчет расходится с реальным счетом.
Почему тариф не менялся, а счет вырос
Когда компания выбирает S3, главный ориентир — цена гигабайта в месяц. По этому параметру сравниваются провайдеры и строится бюджет. Пока данные размещены без движения, такой расчет точен. Расхождение начинается, когда хранилище начинают активно использовать.
Счет за S3 складывается не только из объема хранения. В него также входят операции с объектами и исходящий трафик. Обращение к хранилищу может тарифицироваться отдельно или входить в лимит тарифа, и чем активнее приложение работает с данными, тем заметнее эти статьи расходов. Место в хранилище при этом может почти не меняться, а в счете появляются строки, которых в первоначальном расчете не было.
С неожиданной платой за исходящий трафик сталкиваются единицы. Чаще причина роста счета — другая ситуация: компания выбирала тариф только по цене хранения и не обратила внимания на то, что тарифный план включает ограниченное количество запросов. Когда реальный объем запросов оказывался на порядок больше включенного лимита, счет резко вырастал. Поэтому до выбора тарифа стоит понять не только объем данных, но и то, как приложение с ними фактически работает: именно это в конечном счете и определяет итоговый счет.
Откуда берутся 30 Тб, когда данных было 10
Версионирование в S3 сохраняет предыдущие копии файлов. Функция полезная: она позволяет откатиться к нужной версии, если что-то пошло не так. Но срок хранения этих версий редко определяют заранее, и именно здесь начинается проблема. Новые версии копятся, старые остаются, и через несколько месяцев компания обнаруживает, что платит за данные, о существовании которых давно забыла.
Например, компания хранит 10 Тб видеофайлов. После изменения настроек обработки обновляет набор дважды. Пользователь видит 10 Тб актуальных материалов, именно столько нужно бизнесу. Но внутри хранилища при включенном версионировании и без настроенной очистки остаются все три набора, то есть уже 30 Тб. Счет вырастает втрое, хотя объем полезных данных не изменился.
Версии файлов составляют лишь часть проблемы. После диагностики приложения в хранилище остаются подробные логи. После завершения аналитического проекта там накапливаются временные выгрузки. Каждый из этих массивов появился по делу, но необходимость его дальнейшего хранения редко пересматривают. Данных становится больше, хранилище масштабируется само по себе, и расхождение между тем, за что платят, и тем, что реально нужно, нарастает незаметно. В собственной инфраструктуре переполненный диск обычно сигнализирует о проблеме сразу. В S3 объем хранилища масштабируется, поэтому без настроенных уведомлений такого сигнала может не быть — счет просто продолжает расти.
Для автоматической очистки в S3 предусмотрены правила жизненного цикла: можно настроить удаление незавершенных загрузок старше месяца или ограничить число хранимых версий одного файла, например тремя. Хранилище будет удалять лишнее самостоятельно. Но настраивают эти правила заранее редко. По общим наблюдениям, около 90% компаний хранят больше данных, чем реально используют, и разбираться с этим начинают только тогда, когда оплачиваемое место заканчивается и в работе приложений появляются ошибки.
Показательный пример: одна компания обнаружила, что хранила в 10 раз больше данных, чем использовала. Команда включила версионирование, рассчитывая на автоматическую дедупликацию — которой в S3 нет. Хранилище сохраняло новую версию при каждой перезаписи файла. Объем вырос в 10 раз, место закончилось, и только тогда ситуацию начали разбирать. Совет здесь один: включать версионирование только там, где оно действительно необходимо, и понимать, что каждая версия — это отдельный объект, занимающий свое место. Удалять данные подряд при этом рискованно: среди старых копий может оказаться единственная версия, пригодная для восстановления. Поэтому сначала у каждого крупного массива стоит найти владельца, который определит, зачем он хранится и как долго, и только после этого настраивать очистку.
Как дешевый класс хранения становится дорогим
Перевод редко используемых данных в более дешевый класс хранения оправдан, если данные читают эпизодически и объем достаточно велик. Но у этого решения есть несколько условий, которые легко упустить при выборе тарифа.
Низкая цена размещения нередко сочетается с более дорогим чтением или отдельной платой за извлечение. Для некоторых классов действует минимальный оплачиваемый срок хранения: удалить файл раньше разрешено, но платить придется за весь период. Есть и минимальный оплачиваемый размер объекта — небольшой временный файл тарифицируется как более крупный. В итоге дешевый класс может оказаться невыгодным именно для той нагрузки, под которую его выбирали. Холодные классы хранения на российском рынке используются относительно редко, и именно поэтому их условия чаще всего остаются неизученными до момента, когда они уже повлияли на счет.
Отдельного внимания заслуживает скорость получения данных из холодного класса — она напрямую влияет на то, подходит ли такой класс для резервных копий. Холодные классы бывают двух типов: одни дают прямой доступ, другие требуют предварительного восстановления из архива. Даже при прямом доступе передача большого массива небыстрая: выгрузка 100 Тб по каналу 1 Гбит/с потребует около 9,3 суток непрерывной работы. Для резервной копии скачивание составляет лишь часть пути: нужно еще распаковать данные, восстановить базу и запустить приложение. Если бизнес допускает четыре часа простоя, дешевое размещение не компенсирует многодневное восстановление. Важный момент: скорость отдачи данных у большинства холодных классов сопоставима с горячим хранением. Разница не в скорости, а в стоимости каждого запроса. Холодный класс выгоден ровно до тех пор, пока данные лежат без движения. Как только к ним начинают обращаться регулярно, стоимость запросов может перекрыть всю экономию от дешевого размещения. Класс стоит выбирать под требования конкретной системы, а не по строке в прайсе.
Когда расходы выходят из-под контроля
Управляемый счет — не тот, что не меняется каждый месяц. Управляемый — тот, по которому компания понимает причины изменения расходов и видит риск выхода за бюджет до получения счета, а не после. Полный расчет стоимости эксплуатации S3 с учетом хранения, операций, трафика и сценариев восстановления сегодня запрашивают практически все компании на этапе переговоров с провайдером. Рынок в этом плане заметно повзрослел по сравнению с
Выстроить этот контроль помогает политика ревизии данных. Без назначенного владельца данных и зафиксированной даты следующей проверки ревизия остается разовой акцией. Через полгода ситуация повторяется. Чтобы этого не происходило, контроль расходов должен быть встроен в регулярный процесс: пороговые уведомления на рост потребления, ответственный за каждое уведомление и плановые ревизии состава хранилища. Отдельный тренд, заметный в 2026 году: крупные компании всё чаще запрашивают расчет хранения больших объемов — от 1 до 3 Пб — и сопоставляют стоимость облачного хранения с собственной инфраструктурой. При таких объемах они считают не только цену гигабайта, но и совокупную стоимость владения: затраты на оборудование, резервирование, эксплуатацию, персонал, электроэнергию и требования к доступности. Это показывает, что рынок все чаще принимает решение о модели хранения на основе полной экономики, а не отдельной ставки за хранение.
Что проверить, если счет оказался выше ожидаемого
За два часа нельзя провести полный аудит большого хранилища, но можно найти то, что стоит разобрать в первую очередь. Понадобятся детализация последнего счета, отчет о составе хранилища и настройки сроков хранения. Удобнее начать с одного крупного проекта: связать расходы с конкретным приложением и найти человека, который за него отвечает.
Первый шаг — сопоставить оплаченный объем с объемом актуальных данных. Если приложение использует 10 Тб, а в счете существенно больше, смотрим прежние версии, дополнительные копии и временные массивы, проверяем правила очистки и когда они фактически выполнялись. Затем разбираем остальные строки счета: какое приложение и куда передавало данные, какие операции дали основной вклад. Рост числа клиентов и ошибка в архитектуре приложения могут дать одинаковое увеличение суммы, но потребуют совершенно разных действий. Наконец, стоит проверить условия массовой выгрузки и то, сколько реально займет восстановление системы на полном объеме — именно это чаще всего оказывается неожиданностью.
Если же предстоит выбор нового провайдера, то ключевых вопроса три. Из чего складывается цена хранения и какие классы доступны. Как организовано резервирование данных и какие методы S3 API поддерживаются — неполная или нестандартная реализация создаст проблемы при интеграции с приложениями, использующими S3 API.
