Привет! Меня зовут Евгения Тарашкевич. Я инженер из группы эксплуатации К2 Cloud, и моя специализация — системы хранения данных. Сегодня хочу поделиться с вами опытом и знаниями о работе с объектным хранилищем S3.

Эта статья будет полезна инженерам, которые только начинают работать с ним, и тем, кто уже использует его в продакшене, но хочет структурировать знания и разобраться в типовых проблемах.

Разберём:

• базовую функциональность S3 и его ключевые возможности;

• типичные вопросы, с которыми чаще всего сталкиваются инженеры;

• подходы к обеспечению безопасности и надёжности хранения данных;

• best practices, которые я выработала за годы эксплуатации хранилищ.

Разобравшись во всем этом, вы сможете выстроить стабильную и отказоустойчивую инфраструктуру хранения. Надеюсь, этот материал поможет вам почувствовать себя увереннее в работе с S3 и избежать ошибок.

Что такое S3: особенности и преимущества 

S3 — это мощный и масштабируемый сервис для хранения множества произвольных данных. Под «произвольными» я имею в виду любые данные: от изображений и логов до архивов баз данных и резервных копий.

За какие особенности и плюсы S3 ценят инженеры:

Отсутствие ограничений по объему — вы можете хранить столько данных, сколько нужно, без необходимости заранее планировать размер хранилища.

Масштабируемость — платформа отлично справляется как с десятками мегабайт, так и с сотнями терабайт.

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

Гибкость и универсальность — можно хранить любые типы файлов без предварительной подготовки.

Безопасность — встроенные механизмы позволяют надёжно защищать данные с помощью политик доступа, шифрования и логирования.

Взаимодействовать с хранилищем S3 можно несколькими способами:

Через веб-консоль — например, такую как в K2 Cloud. Там удобно создавать бакеты, загружать файлы и управлять доступом через интерфейс.

Через интеграции с приложениями — например, можно подключить S3 к Nextcloud, использовать в связке с системами резервного копирования или в составе CI/CD пайплайнов.

Через утилиты и API — это актуально для автоматизации.

В числе популярных инструментов для работы с S3 API: aws cli, S3 Browser — удобная утилита для Windows; s5cmd — продвинутая и высокопроизводительная CLI-утилита.

Мы с командой рекомендуем использовать s5cmd, особенно если вы работаете с большими объёмами данных. У неё отличная производительность благодаря возможности указывать глубину очереди и задавать количество параллельных потоков при скачивании или загрузке объектов. Это позволяет гибко настраивать процесс работы с данными и достигать высокой эффективности, особенно при массовых операциях.

Почему инженеру важно уметь работать с S3

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

Какие инструменты нужны инженеру, чтобы эффективно использовать S3:

• контроль над данными: версионирование, политики очистки, временные ссылки;

• надёжность хранения: защита от потери данных через Object Lock, Legal Hold и шифрование;

• безопасность: гибкая настройка прав доступа через IAM, ACL и bucket policies;

• оптимизация процессов: использование multipart upload и автоматизации через API.

Знание функциональности S3 помогает снижать риски, экономить ресурсы и повышать устойчивость сервисов. Поэтому освоение этих инструментов — необходимый шаг для любого инженера, который работает с облачной инфраструктурой.

Три столпа S3: версионирование, политики жизненного цикла и multipart upload

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

Версионирование

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

Версионирование — это когда каждая запись объекта сохраняется как отдельная версия в бакете. У каждой версии есть уникальный version ID, который позволяет отличать одну версию от другой.

В чём плюсы версионирования:

• Возможность восстановить объект после изменения или удаления — можно просто откатиться на нужную версию.

• Возможность отслеживать историю изменений.

• Повышение надёжности хранения — данные защищены даже в случае случайного или преднамеренного удаления.

Если вы включили версионирование, то отключить его уже нельзя — можно только приостановить. Это значит, что все уже созданные версии продолжат храниться в бакете. Новые версии создаваться не будут, пока версионирование приостановлено.

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

При удалении объекта, на самом деле объект не исчезает полностью — вместо этого появляется специальный маркер delete marker. Он помечает объект как удалённый, не занимает места и не является реальным объектом. Его можно удалить вручную, и тогда последняя версия объекта восстановится.

Как управлять версиями и объектами

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

Разберём команду листинга содержимого бакета:

aws s3 ls s3://<bucket-name> --recursive --human-readable --summarize

Эта команда выполняет полный обход всех объектов в бакете, включая префиксы. Благодаря параметрам --human-readable и --summarize вывод становится более удобным для восприятия: вы увидите общее количество объектов и итоговый размер бакета.

Вторая команда aws s3api list-object-versions --bucket <bucket-name> позволяет получить список всех версий объектов и delete-маркеров. Для отображения объектов и их версий нужны разные команды. Обычный листинг не покажет версии — для их просмотра понадобится отдельный вызов API.

Многокомпонентная загрузка (Multipart Upload)

Метод multipart upload, или многокомпонентную загрузку, используют при работе с файлами большого объема, чтобы разбить один большой файл на несколько меньших частей, которые затем загружаются в бакет параллельно. Multipart upload пригодится в проектах, где объекты превышают сотни мегабайт.

Какие преимущества даёт использование многокомпонентной загрузки:

• Надёжность. Высокая устойчивость к сети за счёт параллельных запросов и ускорения процесса. 

• Эффективность. Параллельная загрузка частей существенно сокращает общее время передачи данных в хранилище.

• Гибкость. Можно загружать части поэтапно и собирать их в единый объект позже, когда все части успешно загружены.

Если загружать один большой файл стандартным методом, то его передача может прерваться из-за нестабильного соединения или таймаутов. Multipart upload поможет избежать этой проблемы благодаря распределению нагрузки на сеть и устойчивости к частичным сбоям.

Механизм multipart upload встроен во многие современные приложения и утилиты, например, NextCloud и s5 cmd. В работе инженера бывают ситуации, когда нужно выполнить multipart загрузку вручную, например, при интеграции с самописными системами или тестировании API.

Что важно знать при ручной инициализации multipart upload:

Upload ID — при инициализации multipart upload вы получаете уникальный идентификатор загрузки. Он должен быть одинаковым для всех частей, которые относятся к одному объекту.

Part number — каждая часть должна иметь уникальный номер (от 1 до 10 000). Номера нельзя повторять. Если вы по ошибке перезапишите часть с тем же номером, система не выдаст предупреждение или ошибку, и произойдёт тихая перезапись данных. Обращайте на это внимание, чтобы не перегрузить бакет неиспользуемыми данными. Велика вероятность, что многокомпонентая загрузка завершится некорректно, и загруженные части объекта продолжат хранится в бакете, пока их не удалят.

Дубликаты и ошибки — повторная загрузка одной и той же части без необходимости приведёт к ненужным расходам ресурсов и потенциально неконсистентному результату. Поэтому при ручной multipart загрузке важно контролировать номера частей и загрузку каждой из них.

Завершение загрузки — после успешного выполнения запроса CompleteMultipartUpload все части объединяются в единый объект. Upload ID становится недействительным, и все метаданные процесса загрузки автоматически удаляются из бакета. Объект доступен для обычной работы как единый файл, без следов многокомпонентной загрузки.

Для выполнения многокомпонентной загрузки вручную используется метод CreateMultipartUpload с указанием имени бакета, ключа объекта и endpoint хранилища. После выполнения запроса возвращаются параметры: Bucket, Key и UploadId. Последние два значения понадобятся для последующей загрузки частей.

Например, мы предварительно разбили файл в 10 МБ на две части по 5 МБ. Каждая часть загружается поочерёдно с помощью метода UploadPart, с указанием следующих параметров: Key, UploadId, PartNumber, Endpoint, Body (содержимое части).

В ответ на каждую загрузку возвращается ETag, который понадобится для завершения загрузки. После загрузки всех частей используют метод CompleteMultipartUpload, где указывают: Key, UploadId, список всех частей с их PartNumber и соответствующими ETag.

При успешном завершении UploadId аннулируется. В бакете остаётся только итоговый файл. Промежуточные части удаляются автоматически. Проверка содержимого бакета подтверждает наличие итогового объекта. 

При ручной загрузке или ошибках в процессе завершения сессии загрузки части файла могут остаться в бакете. Такие незавершённые multipart-загрузки продолжают занимать реальное дисковое пространство.

В примере мы использовали всего две части, но в реальной эксплуатации количество частей может достигать тысяч или десятков тысяч. Все они будут храниться до тех пор, пока вручную не будут удалены или не сработает механизм очистки. Это важно учитывать при проектировании процессов загрузки и мониторинга хранилища.

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

Для этого используется команда list multipart uploads с указанием бакета и endpoint. Она показывает все незавершённые загрузки. 

Чтобы узнать, сколько частей загружено в рамках этой сессии, нужно применить команду list parts с указанием соответствующего upload ID. В примере видно, что в рамках одной незавершённой загрузки хранятся две части — это три сущности, занимающие место в бакете.

Для удаления такой загрузки используется метод abort multipart upload с передачей ключа объекта и upload ID. Это полностью удаляет саму сессию загрузки и все её части, но не влияет на другие объекты в бакете.

Практика показывает, что multipart upload полезен при работе с файлами размером от 100 МБ. Многие приложения позволяют настраивать порог, при котором активируется многокомпонентная загрузка, и это даёт гибкость в работе с различными объёмами данных.

В своей работе вы можете столкнуться с бакетами, в которых миллионы объектов, версий или фрагментов незавершённых загрузок. В таких случаях ручное удаление становится бессмысленным, а написание собственных скриптов — трудоёмким и не всегда удобным. Чтобы решить эту задачу, на помощь приходит lifecycle policy. 

Lifecycle Policy

Политика жизненного цикла (lifecycle policy) — это встроенный механизм, который позволяет автоматически удалять неиспользуемые данные в объектном хранилище без ручного вмешательства.

Для чего используют lifecycle policy:

• Удаление устаревших версий объектов;

• Удаление незавершённых multipart-загрузок;

• Очистка delete-маркеров;

• Удаление объектов по сроку хранения.

Чем хорош механизм политик жизненного цикла:

Гибкая настройка. Политику можно привязать к определённым префиксам, тегам или возрасту объектов.

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

Контроль и предсказуемость. Вся логика работы настраивается в конфигурации, а значит, не случится неожиданного удаления нужных объектов.

Политику жизненного цикла можно задать через веб-консоль или с помощью S3 API, используя специализированные утилиты. Для работы через API я использую метод put-bucket-lifecycle-configuration с передачей конфигурационного JSON-файла.

Удаление незавершённых multipart-загрузок. Конфигурация находит все незавершённые multipart-upload процессы и автоматически прерывает их после заданного периода, например, 10 дней.

Удаление версий объектов и delete-маркеров. Политика позволяет автоматически удалять устаревшие версии и маркеры удаления, освободить место в бакете и снизить затраты.

Такие конфигурации удобно создавать и настраивать через API — это даёт большую гибкость, особенно при массовом управлении данными. Для точной и надёжной настройки lifecycle-политики я советую использовать утилиты с поддержкой S3 API.

Как корректно удалить бакет и почему это может не получаться

Причина, как правило, в том содержимом, которое блокирует удаление. Чтобы успешно удалить бакет, в нём не должно быть активных объектов, версий объектов, Delete-маркеров.

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

Для автоматической очистки бакета можно использовать lifecycle policy, которая удалит все версии объектов, Delete-маркеры, незавершённые multipart-загрузки. На скриншоте выше — пример такой конфигурации. Она поможет полностью очистить бакет и избавить от необходимости вручную удалять каждый объект или версию.

Почему не сходится количество объектов в бакете

Количество объектов в бакете может отличаться в зависимости от того, чем его считать: например, веб-консоль показывает одно число, а приложение — другое. Причина в том, что в S3-подобных хранилищах объект — это не единственный элемент, который занимает место. Чтобы точно посчитать содержимое бакета, нужно учитывать объекты, версии объектов, незавершённые multipart-загрузки, части объектов, привязанные к этим загрузкам.

Чтобы корректно подсчитать реальные объекты в бакете, используют основной листинг объектов. Команда aws s3 ls s3://<bucket-name> --recursive --human-readable --summarize покажет количество объектов и суммарный размер.

Проверка незавершённых multipart-загрузок делается с помощью команды aws s3api list-multipart-uploads --bucket <bucket-name>. Это покажет «головные» multipart-загрузки. Затем для каждой использовать команду aws s3api list-parts --bucket <bucket-name> --upload-id <upload-id> --key <object-key>. Эта команда покажет количество загруженных частей.

Проверка версий объектов выполняется командой aws s3api list-object-versions --bucket <bucket-name>. В выводе у каждого объекта будет VersionId, а флаг IsLatest указывает, является ли эта версия текущей.

Если у вас, например, 4 объекта, одна незавершённая multipart-загрузка с двумя частями и 9 версий объектов — общее количество элементов, учитываемых в размере бакета, будет существенно выше, чем просто 4.

Безопасность данных в S3

Разберём механизмы безопасности, которые можно использовать при работе с объектным хранилищем S3.

Основные инструменты:

ACL и IAM-роли. Глобальные доступы, которые дают возможность контролировать полномочия пользователей при работе с объектами или бакетами.

Bucket Policy. Более гибкие политики, которые позволяют фильтровать доступы не только по проектам, управлять доступом как к объектам и бакетам целиком, так и к каким-либо префиксам. 

Presigned URLs (временные ссылки). С их помощью можно временно предоставить доступ к объектам без постоянных прав. 

Шифрование объектов. Поддержка sse-c шифрования на стороне сервера с ключами клиента — для защиты данных «в покое».

Object Lock (блокировка версий от удаления). Гарантирует неизменность данных: объект нельзя удалить или изменить в течение заданного времени.

Legal hold. Бессрочная блокировка объекта.

ACL: контроль доступа к данным

Первый элемент системы безопасности в S3 — ACL (Access Control List). С его помощью можно настраивать точечный доступ к объектам и бакетам в хранилище.

Права доступа через ACL можно задать в веб-консоли. Кому они выдаются:

Анонимные пользователи. Любой пользователь без авторизации.

Аутентифицированные пользователи, например, пользователи K2 Cloud облака. Все пользователи, успешно прошедшие авторизацию.

Конкретные проекты. Проекты, в том числе сторонние, с granularity до отдельных ролей.

Для чего можно выдать права:

Чтение (Read). Получение списка объектов, просмотр и скачивание содержимого.

Запись (Write). Добавление новых объектов или перезапись существующих.

Управление ACL (Read/Write ACL). Просмотр, изменение и добавление политик доступа для объектов и бакетов.

ACL применяется для совместной работы и при раздаче временного или ограниченного доступа к данным без использования более сложных политик.

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

Удаление бакета возможно только его владельцем. Даже при наличии прав на объекты, сам бакет остаётся недоступен для удаления, если вы не владелец.

Роли в IAM (Identity and Access Management)

В K2 Cloud доступ к объектному хранилищу через IAM настраивается на уровне проектов. Если пользователь входит в проект и у него есть роль, которая предоставляет доступ к S3, то он получает полные права доступа ко всем бакетам и объектам в рамках этого проекта. Когда вы выдаёте доступ к своему бакету какому-либо проекту, все пользователи с соответствующей ролью в этом проекте получат доступ к вашему бакету. Это нужно учитывать при проектировании прав доступа.

Bucket policy

Bucket policy — это мощный инструмент для более тонкой настройки прав доступа к объектному хранилищу. Разберём на примере, как он помогает регулировать доступ не только к целому бакету, но и к отдельным объектам или префиксам.

Для работы с bucket policy используется специализированная утилита, поддерживающая S3 API, и метод put-bucket-policy.

Пример конфигурации на скриншоте содержит атрибуты:

Effect — определяет тип действия: Allow (разрешить) или Deny (запретить).

Principal — сущность, к которой предоставляется доступ, например, проект.

Action — список разрешённых действий, таких как s3:GetObject, s3:PutObject, s3:DeleteObject.

Resource — указывает, к каким ресурсам применяется политика: может быть конкретный объект, весь бакет или префикс.

Condition — дополнительное условие, при котором правило вступает в силу (например, доступ только с определённого IP или при определённой аутентификации).

На скриншоте выше — демонстрируется политика, в которой указан проект-получатель доступа. Ему разрешено скачивание, загрузка и удаление объектов в бакете. При этом ресурс задан корню бакета и дочерним элементам, то есть применяется ко всем объектам.

Если вы только начинаете использовать bucket policy или пока не до конца уверены в синтаксисе и правилах их настройки, мы рекомендуем воспользоваться официальным инструментом AWS Policy Generator. Он позволяет легко и наглядно сгенерировать корректную политику доступа, задать нужные параметры и получить валидный JSON, который можно применить к бакету.

Я рекомендую всегда тестировать политики на отдельном тестовом бакете. Это поможет избежать случайной потери доступа или удаления важных прав. Bucket policy позволяют гибко ограничивать доступ по IP-адресам, включая разрешения (Allow) и запреты (Deny) на отдельные IP или подсети. Политики можно применять на уровне бакета и для отдельных объектов или префиксов. Будьте особенно внимательны при применении политик с ограничением доступа — при ошибке можно потерять доступ к данным даже как владелец.

Presign URL

Когда нужен временный доступ к объекту без выдачи постоянных прав или настройки публичного доступа, можно использовать presigned URL — временные ссылки на объекты.

Такая ссылка содержит все необходимые параметры для доступа к объекту, в том числе информацию для авторизации. Любой человек, независимо от своей роли или аккаунта, может пройти по ссылке и скачать файл. Проходить аутентификацию при этом не нужно. Создатель ссылки — обычно это владелец бакета — должен иметь доступ к хранилищу и авторизационные ключи (access key, secret key).

Presign URL можно создать через веб-консоль, со сроком действия строго 24 часа, либо через S3 API, тогда можно задать срок вручную в секундах. Максимальный срок действия — 30 дней. Если указать больший срок, он автоматически сократится до 30 дней. По истечении срока попытка перейти по ссылке приведёт к ошибке Access Denied.

Этот способ удобен, когда нужно передать файл только один раз, ограничить время на его скачивание или если открывать публичный доступ к файлу небезопасно. 

Шифрование на стороне сервера: метод SSE-C

SSE-C (Server-Side Encryption with Customer-Provided Keys) — это метод шифрования данных, где пользователь предоставляет ключ S3-сервису для шифрования данных на стороне сервера. Разберём, как это работает.

Загрузка данных (энкрипция)

Когда вы загружаете объект в бакет S3 с использованием SSE-C, вы предоставляете ключ шифрования, который будет использован сервисом для шифрования данных. Этот ключ передаётся в HTTP-заголовках (например, x-amz-server-side-encryption-customer-key).

Во время передачи данных от клиента к серверу данные не зашифрованы. Это делает использование безопасного протокола, такого как HTTPS, важным для защиты данных в процессе передачи.

Как только данные достигли сервера, сервис S3 использует предоставленный вами ключ для шифрования данных перед их сохранением на диске. Encrypted данные сохраняются, а ваш ключ — нет.

Скачивание данных (декрипция)

Чтобы запросить скачивание объекта, нужно снова предоставить тот же ключ шифрования, который использовался для его загрузки. Этот ключ помогает декодировать зашифрованные данные. Сервис S3 использует ключ для расшифровки объекта на сервере перед его передачей.

Передача данных
Декодированные данные передаются обратно к клиенту. Для безопасности передаваемых данных нужно использовать HTTPS.

Преимущества метода SSE-C:

• Повышенный уровень безопасности: даже если злоумышленник получит доступ к объекту, он не сможет его расшифровать без ключа.

• Полный контроль над ключами остаётся у клиента.

• Сервером автоматически шифрует и дешифрует данные.

Для загрузки зашифрованного объекта в хранилище с использованием метода SSE-C (Server Side Encryption with Customer-Provided Keys) нужно заранее сгенерировать ключ по стандарту AES-256 и подготовить файл, который нужно загрузить (например, file.txt).

При загрузке указывают две опции: --sse-c — стандарт шифрования AES256; --sse-c-key — пользовательский ключ, с которым объект будет зашифрован.

После выполнения команды файл будет загружен в S3 в зашифрованном виде. Если попытаться скачать объект без указания ключа, вы получите ошибку «отказано в доступе» (Access denied): файл не может быть расшифрован без оригинального ключа. Если указать ключ, который использовали при загрузке, то объект успешно скачается и расшифруется, а файл сохранится локально.

Object Lock — защита объектов от удаления и перезаписи

Object Lock — это механизм блокировки версий от удаления и перезаписи. Он реализует принцип Write Once, Read Many (WORM): объект можно записать только один раз, а читать — неограниченное количество раз.

В чём преимущества Object Lock:

• Защита от случайного или преднамеренного удаления.

• Дополнительный уровень безопасности при хранении критичных данных.

• Гибкие настройки и поддержка различных политик хранения.

• Лёгкость в управлении

Режимы работы Object Lock:

Governance — гибкий режим. Позволяет увеличить или уменьшить срок блокировки. Можно изменить режим на Compliance. Обойти блокировку можно при помощи опции bypass-governance-retention. Подходит для защиты от случайного удаления.

Compliance — строгий режим. Нельзя уменьшить срок или изменить режим. Объект нельзя удалить ни через веб-консоль, ни через API. Даже владелец бакета или объекта не может удалить версию до окончания срока блокировки. Если retention period, например, два дня, то в течение этого времени никто не сможет удалить объект.

Object Lock можно включить на уровне бакета или отдельных объектов. При создании бакета с поддержкой Object Lock автоматически включается версионирование, отключить его потом нельзя. Добавление новой версии объекта не удаляет защищённую версию — она продолжит храниться в бакете до завершения срока блокировки.

Разберём пример на скриншоте. Чтобы использовать функционал Object Lock, необходимо создавать бакет с включённой опцией ObjectLockEnabledForBucket. Это указывается при помощи метода create-bucket.

После создания бакета конфигурация Object Lock настраивается через метод put-object-lock-configuration. В демонстрации был выбран режим Governance с периодом блокировки 2 дня. Это значит, что все загружаемые в бакет объекты будут автоматически защищены на этот срок.

После загрузки файла в такой бакет мы попытались удалить объект стандартным методом. Несмотря на то, что операция удаления возвращает успех, объект не удаляется — в бакете появляется delete marker, а защищённая версия продолжает храниться. Это можно проверить через команду list-object-versions.

После этого мы попытались удалить конкретную версию с помощью метода delete-object и указанием version-id. Попытка завершилась с ошибкой AccessDenied, потому что версия объекта защищена установленной политикой.

Legal hold  или бессрочная блокировка объекта

Дополнительно к Object Lock можно использовать механизм бессрочной блокировки объекта, или Legal Hold. В отличие от Object Lock с фиксированным сроком, у Legal Hold нет периода действия — блокировка активна до тех пор, пока её явно не отключат. Это удобно для защиты от случайного удаления.

Как включить Legal Hold:

1. Бакет должен быть создан с параметром ObjectLockEnabledForBucket.

2. Объект загружается с помощью метода put-object, при этом необходимо указать параметр ObjectLockLegalHoldStatus=ON.

3. После загрузки можно проверить статус блокировки с помощью метода get-object-legal-hold, указав version-id.

Если Legal Hold включён, удалить объект невозможно, пока блокировка активна.

Снять блокировку может любой пользователь с полными правами на объект. Для этого используется метод put-object-legal-hold с параметром Status=OFF. После этого объект будет доступен для удаления стандартным методом.

Legal Hold удобно применять, когда важна защита от человеческой ошибки, но нет требований к строгому ограничению удаления, как в случае с режимом Compliance. Legal Hold можно использовать совместно с Object Lock. Если действует retention period, то снятие Legal Hold не позволит удалить объект до окончания этого срока. Если retention period истёк, но Legal Hold всё ещё активен, объект тоже нельзя удалить.

S3 — мощный и гибкий инструмент. Работа с ним требует понимания внутренних принципов, чтобы не только загружать и скачивать объекты, но и эффективно управлять жизненным циклом данных, контролировать доступ, настраивать версионирование и защиту данных от случайных ошибок или от злоумышленников. Важно уметь организовывать данные в бакетах таким образом, чтобы они были структурированы и легко доступны. Пусть ваша работа с S3 будет эффективной и безопасной, а сервис S3 и встроенная функциональность поможет в автоматизации рутинных процессов, чтобы извлекать максимум потенциала.