Что такое versioning в S3 и зачем его включают

Versioning в S3 — это режим, при котором под одним и тем же ключом хранятся несколько версий объекта, каждая со своим VersionId. Его включают, чтобы защищаться от случайного удаления и перезаписи файлов, иметь возможность откатиться к прошлому состоянию и выполнять требования по аудиту. Основной минус — рост объёма и стоимости хранения из‑за накопления старых версий.

Versioning в S3 — это функция многоверсионного хранения: каждый новый PUT/COPY одного и того же объекта создаёт отдельную версию, а старые версии остаются доступны по своему VersionId. Чтение без указания версии возвращает «актуальную» версию, но при необходимости можно явно запросить или восстановить любую прошлую.

Versioning включается на уровне бакета и может находиться в состояниях Disabled, Enabled и Suspended. После первого включения обратно в полностью выключенное состояние вернуться нельзя — только приостановить, чтобы не создавать новые версии, при этом уже существующие версии остаются в бакете.

При включённом versioning операция DELETE по умолчанию не стирает данные физически: создаётся специальная версия — delete marker, которая скрывает объект для обычных запросов. Но предыдущие версии продолжают существовать, их можно запросить по VersionId, удалить выборочно или «откатить» объект, сделав прошлую версию снова актуальной.

Versioning обычно используют вместе с правилами жизненного цикла (Lifecycle Rules) и репликацией версий. Lifecycle позволяет автоматически удалять старые версии или переводить их в более дешёвые классы хранения, чтобы не раздувать стоимость, а репликация (межрегиональная или в другие бакеты) даёт дополнительную отказоустойчивость и сценарии disaster recovery.

• Ключевые особенности работы versioning: хранение нескольких версий одного объекта под одним ключом; каждая запись создаёт новую версию вместо перезаписи; чтение без VersionId даёт последнюю версию; DELETE создаёт delete marker, не уничтожая автоматически старые версии.
• Зачем включают versioning: защита от человеческих ошибок (случайное удаление/перезапись), защита от логических багов в приложениях (массовое повреждение данных), поддержка аудита и трассировки изменений, а также основа для надёжного бэкапа в сочетании с репликацией и lifecycle-политиками.
• Основные компромиссы: рост стоимости хранения (каждая версия тарифицируется отдельно), усложнение управления (в бакете может накапливаться множество версий), необходимость продумать автоматическую очистку и интеграцию с логикой приложений, если важно работать с конкретными версиями, а не только с последней.

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