Правила жизненного цикла — встроенный в хранилище механизм автоматического управления данными. Он сам удаляет объекты, которые перестали быть нужными: не нужно писать скрипты и держать их в планировщике, достаточно один раз описать политику для бакета. Так решаются две задачи — контроль расходов на хранение и соблюдение внутренних сроков хранения данных.
Ниже — как устроен механизм. Настройка описана отдельно: «Как настроить правило жизненного цикла через AWS CLI» и «Как настроить правило жизненного цикла через S3 Browser».
Из чего состоит правило
Политика задаётся для бакета целиком и может содержать несколько независимых правил. Каждое правило описывается тремя элементами:
| Элемент | Назначение |
|---|---|
| Фильтр (Filter) | К каким объектам применяется правило: ко всему бакету, к объектам с определённым префиксом или с заданными тегами |
| Условие | Когда правило срабатывает: через N дней после создания объекта либо в конкретную дату |
| Действие (Action) | Что происходит с объектами, попавшими под фильтр |
Дополнительно у правила есть идентификатор ID, по которому его можно найти и изменить, и статус: Enabled — правило действует, Disabled — сохранено, но не применяется. Второе удобно для временного отключения без потери настроек.
Какие действия доступны
| Действие | Что делает |
|---|---|
| Expiration | Удаляет актуальную версию объекта через заданное число дней после создания или в указанную дату |
| NoncurrentVersionExpiration | Удаляет версии, переставшие быть актуальными. Работает только в бакете с включённым версионированием |
| ExpiredObjectDeleteMarker | Удаляет маркеры удаления, под которыми не осталось ни одной версии объекта |
| AbortIncompleteMultipartUpload | Прерывает и удаляет мультипартовые загрузки, не завершённые за указанное число дней |
| Transition | Переводит объекты в другой класс хранения по истечении срока |
Как правила выполняются
Обработка правил асинхронная и фоновая: хранилище периодически обходит бакет и применяет подходящие правила. Объект не исчезает ровно в ту секунду, когда истёк срок — задержка может составлять до суток, и это штатное поведение.
Отсчёт ведётся в днях: от даты создания объекта либо от даты, когда версия перестала быть актуальной. Указать срок меньше одного дня нельзя.
Правило с условием по дате не является одноразовым: пока статус остаётся Enabled, любой попадающий под фильтр объект будет удалён вскоре после загрузки. Если действие нужно однократно, после срабатывания правило следует отключить.
Важно! Удаление по правилу необратимо — корзины в объектном хранилище нет. Единственная страховка от ошибки в правиле — включённое версионирование.
Правила и версионирование
В бакете с версионированием правила работают на двух уровнях. Expiration применяется к актуальной версии и не удаляет данные физически: над объектом появляется маркер удаления, а прежнее содержимое переходит в разряд неактуальных версий. Безвозвратно удаляет их только NoncurrentVersionExpiration.
Практический вывод: чтобы объекты действительно освобождали место, нужны оба правила — одного Expiration недостаточно. Третьим можно добавить ExpiredObjectDeleteMarker: заметного места маркеры не занимают, но засоряют список версий.
Типичные сценарии
- Удалять содержимое префикса logs/ через 30 дней после загрузки.
- Очищать префикс tmp/ через сутки — для промежуточных данных обработки.
- Хранить неактуальные версии документов не дольше 90 дней, оставляя актуальные без ограничения срока.
- Прерывать мультипартовые загрузки, не завершённые за 7 дней.
- Удалять объекты с тегом retention=temporary через 14 дней независимо от того, в какой папке они лежат.
Смотрите также:
к Работе с S3 RTCloud
