Зачем инфраструктуре сервис S3 в 2026 году

Для тех, кто больше жил в мире файловых и блочных хранилищ, S3 сначала выглядит «чужеродным». Тем не менее модель проста: есть бакеты (bucket), в них складируются объекты (object), каждый объект имеет уникальный ключ (object key) и метаданные.

S3 server не оперирует директориями в классическом понимании. Вся структура объектов в бакетах плоская, обращение к объекту происходит по ключу. При этом для того, чтобы с данными было удобнее работать человеку, и чтобы выстраивать иерархию, есть возможность имитировать папки (directory) частью ключа объекта.

Если вынести за скобки все маркетинговые красивые слова, S3 – это HTTPS сервис с набором предсказуемых операций.

Базовый набор S3 операций выглядит так:

• PUT – записать объект в бакет (новый или заменяющий существующий объект с таким же ключом).
• GET / LIST – получить/прочитать объект или список объектов.
• DELETE – удалить объект.
• HEAD – получить метаданные без скачивания содержимого.

За счёт того, что S3 работает по HTTP(S), любой софт, умеющий говорить по S3 API, может подключиться к совместимому cloud storage S3, будь то публичный облачный сервис S3 или ваше собственное S3 совместимое объектное хранилище.

На практике переход к S3 совместимому хранилищу происходит не из за моды. Есть несколько прагматичных причин:

Масштабируемость. Объём можно наращивать, расширяя инсталляцию, а не перестраивая с нуля всю инфраструктуру хранения.

• Модель Pay as you Go. Клиенты могут платить только за фактический объём, а не за заранее купленное пространство.
• Экосистема. Современные системы бэкапа, аналитики, логирования и CDN «умеют» в S3 API из коробки.
• Универсальность. Один и тот же сервис S3 может одновременно быть репозиторием для Veeam, архивом документов и источником данных для data lake.
• Безопасность. Гибкая и гранулярная система разграничения доступов, а также защита данных от изменений позволяют реализовать разнообразные современные сценарии защиты данных.

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

Versioning нельзя выключить, можно только приостановить. А ещё эта функция включается автоматически, если бакет создаётся с функцией Object lock.

Заезженная присказка гласит, что люди делятся на тех, кто не делает бэкапы, и на тех, кто уже их делает. А главный запрос последних лет – не просто хранить бэкапы, а защищать их от разных киберугроз и, в частности, от шифровальщиков (ransomware). Да и человеческие ошибки хорошо бы предусмотреть. Здесь как раз вступают в игру WORM и Object Lock.

• WORM (Write Once Read Many) – модель, где объект можно записать один раз, но нельзя изменить или удалить до истечения срока удержания (retention).
• Object Lock – реализация WORM на уровне S3 API: политика удержания задаётся на бакет или объект, и даже root пользователь не сможет его удалить до истечения срока.

Для систем резервного копирования это один из способ построить immutable репозиторий, который выдержит как атаки ransomware, так и попытки «почистить следы» изнутри.

Другой популярный способ применения object lock – блокировка данных на время аудиторской проверки. Все объекты, помещаемые в бакет, можно сделать неизменяемыми, что гарантирует аудитору и проверяемой организации, что никто их не скорректировал или не удалил (случайно или преднамеренно).

До сих пор мы говорили про S3 в целом. Но в реальных проектах важно, как именно устроен конкретный сервис S3 – в инфраструктуре провайдера или внутри компании.

Мы в Linx Cloud в качестве основы для нашего сервиса Объектного хранилища (S3) выбрали Ceph. В первую очередь из-за максимальной совместимости с S3-API (лучше только в AWS ), а также из-за масштабируемости и гибкости, которую он нам даёт для развития продукта.

Основные компоненты и их назначение:

• S3 Endpoint URL – HTTPS точка входа. К ней можно подключаться через Интернет, через выделенный канал точка-точка из виртуального ЦОД в Linx Cloud IaaS, из серверного шкафа в ЦОД Linx или из любой удалённой точки, (офиса/ЦОД клиента, облака/ЦОД другого провайдера).
• WAF & NGFW – защита уровня Web Application Firewall и Next Generation Firewall на границе сети.
• Load Balancers – балансировщики нагрузки, распределяющие запросы между узлами.
• Ceph Object Gateway (rgw) – S3 совместимый сервис, принимающий запросы по S3 API и работающий с backend кластером.
• OSD узлы – серверы, на которых хранятся клиентские объекты. Мы применяем фактор репликации 3 (RF3), при котором все данные клиентов хранятся в трёх экземплярах, минимизируя вероятность их потери из-за повреждения диска/сервера/целого серверного шкафа.
• Серверы управления, которые размещены на отдельном оборудовании и позволяют обеспечивают согласованную работу этого программно-определяемого хранилища.

Рассмотрим несколько типовых сценариев, где S3 совместимое хранилище уже практически «must have»:

• Сервис резервного копирования Linx Cloud BaaS может использовать наш S3 как целевое хранилище. Кроме того, если у вас на площадке сервер резервного копирования может работать с S3, смело подцепляйте его как удалённый репозиторий для обеспечения правил 3-2-1 и 3-2-1-1-0.
• Архив и «холодные» данные. Редко используемые данные уезжают из относительного дорогого локального или облачного блочного хранилища в S3 бакеты с более выгодной стоимостью за гигабайт и практически неограниченным ростом объёма.
• Доступ к данным из Интернет. Медиаконтент или документы, предназначенные для удалённого доступа, размещаются в облачное объектное хранилище для того, чтобы пользователи обращались к нему, а не к локальным серверам компании.
• Разгрузка локального хранилища. Логи, события и сырые данные складываются в бакеты и используются аналитическими системами и AI/ML инструментами напрямую по S3 API.

С точки зрения разработчика или системы бэкапа разница минимальна: и свой on prem S3 server, и публичный сервис S3 выглядят как endpoint, для доступа к которому нужны только сетевая связность, access key и secret. Но с точки зрения эксплуатации и рисков различия заметны:

• Свой S3. Вы получаете полный контроль над оборудованием, архитектурой, безопасностью, при этом ответственность за масштабирование, обновления, работоспособность и отказоустойчивость лежит на вашей команде.
• Облачный сервис S3. Вы выносите на сторону заботы об инсталляции, её доступности, масштабированию и получаете стандартный S3 API, при этом подключаетесь к серверу, расположенному в инфраструктуре провайдера, и платите ежемесячно в зависимости от потребления.

Когда что лучше применять.

• Свой S3. Требуется максимальная близость данных к вашей локальной инфраструктуре, есть бюджет на оборудование и опытная команда для пусконаладочных работ и поддержки сервиса.
• Облачный S3. Требуется минимизировать время запуска проекта/продукта, собственная команда отсутствует или занята на более приоритетных активностях, бюджет не позволяет покупать оборудование тем более в прок.

В 2026 году вопрос «нужно ли нам S3 объектное хранилище?» для большинства ИТ команд уже неактуален. Более честная формулировка: «на каком сервисе S3 мы будем строить бэкапы, доставку контента, архив и аналитику?».

Объектное хранилище (S3) с поддержкой Object Lock, стандартным API для интеграции в существующую инфраструктуру становится обязательным элементом архитектуры – таким же, как виртуализация или система резервного копирования. В этом контексте Объектное хранилище (S3) от Linx Cloud – это не просто ещё одно хранилище, а базовый слой для устойчивой и восстановимой инфраструктуры.