Объектное хранилище S3 в своей стойке: когда своё дешевле облака

Типичный звонок: «облако под наши файлы стало дорого - можно собрать такое же, но у себя?». Это и есть вопрос про объектное хранилище S3 в своей стойке. Сам S3 - способ хранить данные как объекты, к которым обращаются по HTTP через стандартный API (его придумала Amazon, и теперь это де-факто общий язык для такого хранения). Держать такое хранилище можно в облаке, а можно поставить в собственную стойку.

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

Что такое объектное хранилище и чем оно отличается от привычных дисков

Системы хранения делятся на три типа по тому, как вы адресуете данные. Это не вкусовщина - от типа зависит, какие задачи система тянет, а какие нет.

В объектном хранилище нет дерева папок в привычном смысле. Есть «корзины» (бакеты) и в них объекты - файл плюс метаданные плюс уникальный ключ. Приложение обращается к объекту по этому ключу через API; дерева каталогов, по которому ходят файловые системы, тут просто нет. Отсюда два следствия. Первое: такое хранилище легко растёт вширь - добавляете узлы и диски, адресное пространство не упирается в лимиты файловой системы. Второе: оно не подходит туда, где нужно часто менять кусочки файла или держать низкую задержку, - под базу данных объектное хранилище не кладут.

Если хочется глубже разобраться, чем сетевые и прямоподключённые хранилища отличаются друг от друга, у нас есть отдельный разбор - DAS, NAS и SAN: что выбрать. Объектное S3 - это четвёртый вариант в этом ряду, и берут его именно под объём.

Что значит «S3-совместимое»

S3 - изначально сервис Amazon, но его API стал стандартом. «S3-совместимое хранилище» означает, что система говорит на том же языке запросов, и приложение, написанное под Amazon S3, заработает с ней без переделок. Именно это делает реальным переезд «облако → своя стойка»: бэкап-софт, выгрузки, файловые модули сайтов умеют работать с S3 из коробки, и им неважно, чей S3 под капотом - Amazon, Yandex Object Storage или ваш собственный сервер.

Быстрый выбор: своё или облако

Прежде чем считать деньги, отсеките очевидное по трём вопросам:

• Сколько данных и насколько надолго? Десятки терабайт, которые будут лежать годами, - повод считать своё. Пара терабайт под рукой - почти всегда облако.
• Какой трафик наружу? Если данные активно и постоянно скачиваются (отдача медиа, выгрузки, межсайтовый обмен), облако начнёт бить по карману трафиком. Если данные в основном лежат и редко читаются - облако спокойно тянет.
• Кто будет это администрировать? Своё S3 - это сервер, диски, обновления, мониторинг и ответственность за сохранность. Нет человека, который за это отвечает, - облако честнее, даже если по табличке выходит дороже.

Если на всех трёх вопросах вы качнулись в сторону «своё» - дальше есть смысл считать. Если хотя бы на «администрировании» ответ «некому» - скорее всего, останетесь в облаке, и это нормально.

Экономика: когда своё реально дешевле

Тут кроется главная ошибка - сравнивать только цену за гигабайт. У облака и своего хранилища разная природа затрат.

Облако - это OpEx, операционные расходы: платите помесячно за объём, и пока данных мало, входной билет почти нулевой. Своё - это CapEx, капитальные вложения: сервер с дисками покупается сразу, зато потом вы платите только за электричество, место и обслуживание. На малом объёме облако дешевле почти всегда. Но затраты на облако растут линейно с каждым терабайтом и каждым месяцем, а железо - разовая трата, которая размазывается по годам. В какой-то точке прямые линии пересекаются, и дальше своё уходит в плюс.

Egress - скрытая часть счёта

Egress переворачивает весь расчёт. Если данные не лежат мёртвым грузом, а постоянно отдаются наружу (раздаёте видео, гоняете выгрузки между системами, восстанавливаетесь из бэкапов), счёт за трафик может перерасти счёт за само хранение. У себя в стойке исходящий трафик ничего не стоит - вы один раз заплатили за сеть. Поэтому проекты с активной отдачей данных уходят на своё S3 раньше, чем подсказывает простой расчёт по объёму.

Как прикинуть точку окупаемости

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

1. Возьмите реальный объём данных и прогноз роста на 3 года.
2. Прикиньте месячный исходящий трафик - сколько данных уходит наружу.
3. Посчитайте облако: (хранение за месяц + egress за месяц) × 36 месяцев.
4. Посчитайте своё: железо + диски + сеть, плюс электричество и обслуживание за те же 3 года.
5. Сравните две суммы. Если облако за три года заметно дороже - своё имеет смысл.

Три года - не догма, а типовой горизонт жизни сервера до планового обновления. Здесь важно одно: считайте по сроку службы, а не по одному месяцу.

Что нужно для своего S3: железо без иллюзий

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

Один диск - это не отказоустойчивость

Чтобы хранилище переживало смерть диска, данные хранят с запасом, и тут есть два подхода. Репликация - это несколько копий каждого объекта (обычно три) на разных дисках или узлах: просто и надёжно, но три копии съедают тройной объём. Избыточное кодирование (erasure coding) режет данные на части и добавляет блоки чётности, как в RAID-массивах, только на уровне самого хранилища, а не контроллера - переживает потерю нескольких дисков и тратит меньше места, чем репликация. Расплата - нужно сразу несколько дисков: у типовых решений минимум порядка четырёх в наборе, а лучше больше.

Вывод практический: минимальная честная конфигурация своего S3 - это сервер с дисковой корзиной на несколько дисков. А отказоустойчивость уровня «переживём смерть целого сервера» - это уже от трёх узлов.

На каком железе держать

Конкретные модели зависят от объёма и бюджета, но логика простая. Под объём берут ёмкие HDD - объектное хранилище их любит: большие неизменяемые объекты пишутся последовательно, и быстрый диск тут переплата. NVMe ставят, когда важна скорость отдачи, но за терабайт это дороже, и большинству хватает HDD под основной объём. Чем больше дисков влезает в шасси, тем дешевле терабайт, поэтому под объёмные задачи берут платформы с большим числом дисковых отсеков или отдельные дисковые полки (JBOD). Если планируется активная отдача данных, сразу закладывайте сеть 10 GbE и выше, иначе она станет узким местом. Топовый процессор объектному хранилищу не нужен, а вот память важна - на ней живут метаданные и кэш.

На каком ПО - и почему MinIO в 2026 уже не выбор по умолчанию

Само хранилище - это софт поверх железа. Здесь концептуально три пути, и за последний год расклад сильно изменился.

Если убрать MinIO из позиции «по умолчанию», выбор сводится к сложности задачи. Для простого случая подойдут лёгкие S3-серверы вроде Garage или SeaweedFS: их поднимают на одном-двух серверах без глубокой инфраструктуры, возможностей меньше, зато и порог входа ниже. Для серьёзной инфраструктуры берут Ceph со шлюзом RADOS Gateway - полноценную распределённую систему хранения, где в одном решении живут объекты, блоки и файлы, с гибким кодированием и отказоустойчивостью на уровне стоек и дата-центров. Мощно, но требует нескольких узлов и квалификации: Ceph не поднимают за вечер.

Обзор интерфейсов и галочек мы намеренно не делаем - он быстро устаревает, и выбирать должен ваш инженер под конкретную задачу. Принцип же простой: маленькому проекту - лёгкий S3-сервер, серьёзной инфраструктуре - Ceph, а MinIO в 2026 году берут с открытыми глазами и пониманием его лицензии.

Сценарии, где своё S3 особенно к месту

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

Бэкап-таргет с защитой от шифровальщиков

Объектное хранилище умеет режим неизменяемости (immutability, WORM - «записал один раз, не перезапишешь»). Бэкап, который нельзя удалить или зашифровать до истечения срока, - прямая защита от программ-вымогателей: даже захватив сеть, злоумышленник не сотрёт копии. Большинство систем резервного копирования умеют писать в S3 как в цель, поэтому связка «бэкап-софт → своё S3 с immutability» - один из самых частых поводов поставить такое хранилище. Подробнее про подходы к бэкапу - в статье про резервное копирование серверов.

Архивы и медиа

Видео, сканы документов, результаты съёмок, исторические данные - всё, что много весит, редко меняется и должно лежать годами. На таком объёме egress и помесячная плата облака набегают быстро, а своё S3 отбивается.

Данные, которые нельзя в облако

Когда есть требование держать данные на своей территории - по внутренним правилам или по регуляторике, - вопрос «своё или облако» решается уже не калькулятором. Тогда выход - своё S3 в стойке или связка локального хранилища с облаком для некритичной части.

Когда своё S3 не нужно

Честный раздел, который вам не напишет облачный провайдер - и не напишет продавец железа, которому надо продать сервер.

• Нет администратора. Объектное хранилище - это система, за которой надо следить: диски умирают, софт обновляется, мониторинг должен кому-то звонить. Плохо управляемое своё хранилище дороже и опаснее облака - не сэкономите, а потеряете данные.
• Мало данных. Пока объём измеряется единицами терабайт, облако почти наверняка дешевле и проще. Считать своё имеет смысл от десятков терабайт.
• Рваная нагрузка. Если объём то взлетает, то падает, гибкость облака - его сильная сторона: платите за то, что реально заняли.
• Нужна глобальная раздача. Если контент отдаётся пользователям по всему миру, облако с сетью доставки (CDN) сделает это лучше одной вашей стойки.
• Негде поставить. Нет места в стойке, нормального питания и охлаждения - сначала решается это, а уже потом хранилище.

Чек-лист перед запуском своего S3

Прежде чем закупать железо, ответьте на вопросы:

1. Реальный объём данных сейчас и прогноз на 3 года.
2. Сколько данных уходит наружу в месяц (это ваш egress, главный аргумент против облака).
3. Какой уровень отказоустойчивости нужен - пережить диск или пережить целый сервер.
4. Кто администрирует хранилище и кто отвечает за сохранность.
5. Какое ПО и какая у него лицензия (особенно актуально после истории с MinIO).
6. Как и куда вы бэкапите само хранилище - объектное S3 не отменяет резервных копий.

Прошли по списку и поняли, что задача ваша, - дальше дело за конфигурацией под объём и нагрузку.

Частые вопросы

Чем объектное хранилище отличается от файлового и блочного?

Способом доступа. Блочное даёт «сырые» блоки под файловую систему или БД, файловое - папки и файлы по сети, объектное - объекты целиком по ключу через HTTP API. Объектное заточено под объём и неизменяемые данные; для скорости и частых правок берут блочное.

Что такое S3-совместимое хранилище?

Это хранилище, которое понимает тот же набор запросов (API), что и Amazon S3. Приложение, написанное под Amazon, заработает с ним без переделок - поэтому переезд с облака на своё хранилище не требует переписывать софт.

Сколько дисков и серверов нужно для своего S3?

Минимум для отказоустойчивости на уровне дисков - несколько дисков в одном сервере (у типовых решений с erasure coding это порядка четырёх и больше). Чтобы пережить отказ целого сервера, нужно несколько узлов - обычно от трёх.

MinIO или Ceph - что выбрать?

Зависит от масштаба. Ceph - для серьёзной распределённой инфраструктуры на несколько узлов, но требует квалификации. MinIO в 2025-2026 ужесточил лицензирование и перевёл бесплатную версию в архив, поэтому для нового проекта стоит смотреть и на альтернативы (Garage, SeaweedFS) или на коммерческую поддержку. Решение принимайте под конкретную задачу и с учётом лицензии.

Можно ли использовать S3 как место для бэкапов?

Да, это один из лучших сценариев. Объектное хранилище поддерживает неизменяемость (immutability), а большинство систем резервного копирования умеют писать в S3 напрямую. Бэкап в S3 с защитой от перезаписи - сильная страховка от шифровальщиков.

Когда облачное S3 выгоднее своего?

Когда данных немного, нагрузка непредсказуема, нет администратора или нужна глобальная раздача. На малом объёме облако почти всегда дешевле и проще - своё начинает выигрывать на больших объёмах и долгом сроке хранения.