Amazon S3 как объектное хранилище: архитектурные свойства, модели управления данными и механизмы обеспечения надёжности

1. Общая характеристика Amazon S3

Amazon Simple Storage Service (Amazon S3) представляет собой сервис объектного хранения данных, предназначенный для масштабируемого размещения, защиты и управления данными в облачной инфраструктуре Amazon Web Services (AWS). В отличие от файловых систем и блочных устройств хранения, Amazon S3 использует объектную модель: базовой единицей хранения является объект, размещаемый в логическом контейнере — бакете. Объект включает пользовательские данные, метаданные и уникальный ключ, по которому он адресуется внутри бакета.

Принципиальное отличие объектного хранилища от файловой системы состоит в отсутствии полноценной иерархической структуры каталогов. В бакетах общего назначения Amazon S3 используется плоское пространство имён: строка вида path/to/file.txt является не путём в файловой системе, а ключом объекта. Отображение «папок» в консоли AWS является пользовательской абстракцией, построенной на основе общих префиксов ключей. Поэтому операция ListObjectsV2 с параметрами Prefix и Delimiter должна рассматриваться как фильтрация ключей по строковому префиксу, а не как обход дерева каталогов.

Внутренняя физическая архитектура Amazon S3 не раскрывается AWS полностью. Корректнее описывать сервис через его документированные свойства: региональную привязку бакета, распределённое хранение, автоматическую избыточность, высокую доступность и заявленную долговечность хранения. Для класса хранения S3 Standard данные избыточно размещаются минимум в трёх зонах доступности (Availability Zones, AZ) в пределах региона. AWS указывает, что Amazon S3 обеспечивает строгую согласованность чтения после записи для операций записи и удаления объектов во всех регионах AWS.

Бакет (bucket) является логическим контейнером для объектов и создаётся в определённом регионе AWS. После создания нельзя изменить имя бакета и регион его размещения. Для бакетов общего назначения (general purpose buckets) по умолчанию используется глобальное пространство имён Amazon S3: имя бакета должно быть уникальным среди всех AWS-аккаунтов в пределах соответствующего раздела AWS (partition). Кроме того, AWS поддерживает региональное пространство имён аккаунта (account regional namespace), при котором имя резервируется в региональной области конкретного аккаунта. По умолчанию AWS-аккаунт может создать до 10 000 бакетов общего назначения; количество объектов внутри бакета не ограничивается сервисной квотой.

Объект состоит из данных, ключа и метаданных. Максимальный размер одного объекта составляет 5 TB. Для загрузки объектов размером более 5 GB необходимо использовать механизм Multipart Upload, поскольку одиночная операция загрузки не поддерживает объекты большего размера. Метаданные подразделяются на системные, например Content-Type, Last-Modified и ETag, и пользовательские, задаваемые через префикс x-amz-meta-*. Изменение метаданных объекта фактически требует перезаписи объекта, поскольку метаданные являются частью объектной сущности.

Важным различием является разграничение понятий долговечности хранения и доступности сервиса. Долговечность (durability) характеризует вероятность сохранения данных без потери, тогда как доступность (availability) отражает вероятность успешного доступа к данным в заданный момент времени. Например, S3 Standard проектируется для долговечности 99,999999999% и доступности 99,99%, тогда как S3 One Zone-Infrequent Access обеспечивает тот же заявленный уровень долговечности, но хранит данные только в одной зоне доступности и имеет меньшую доступность.

Amazon S3 предоставляет доступ к данным через HTTP/HTTPS интерфейс и REST API. Основные операции над объектами соответствуют стандартным HTTP методам: PUT используется для загрузки или перезаписи объекта, GET — для чтения данных, HEAD — для получения метаданных без передачи тела объекта, DELETE — для удаления, а POST — для отдельных сценариев, включая загрузку через HTML формы и multipart upload. В production сценариях применяется HTTPS с TLS, а аутентификация запросов выполняется с использованием AWS Signature Version 4. AWS SDK и AWS CLI работают поверх того же API, скрывая низкоуровневые детали формирования HTTP запросов и криптографической подписи.

2. Версионирование объектов

Версионирование S3 (S3 Versioning) — это механизм сохранения нескольких версий объекта с одним и тем же ключом. Его основное назначение состоит в защите от случайной перезаписи, удаления и некорректного обновления данных. При включённом версионировании каждая операция PUT создаёт новую версию объекта с уникальным идентификатором версии (Version ID).

Операция удаления при включённом версионировании имеет особую семантику. Если объект удаляется без указания конкретного Version ID, Amazon S3 не уничтожает данные физически, а создаёт маркер удаления (Delete Marker). При последующем обращении к ключу без указания версии пользователь получает ответ о недоступности объекта, однако предыдущие версии продолжают существовать. Для восстановления объекта необходимо удалить Delete Marker. Для окончательного удаления требуется удалить конкретную версию объекта с указанием её Version ID.

Бакет может находиться в одном из трёх состояний относительно версионирования. В состоянии Unversioned версионирование не включено и версии объектов не сохраняются. В состоянии Versioning-enabled все новые объекты получают уникальный Version ID. В состоянии Versioning-suspended новые объекты получают Version ID со значением null, а ранее созданные версии сохраняются. Важно, что после включения версионирование нельзя вернуть в исходное состояние Unversioned; его можно только приостановить.

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

3. Шифрование данных

Amazon S3 поддерживает несколько моделей шифрования данных. Серверное шифрование (Server-Side Encryption, SSE) выполняется на стороне AWS после получения объекта и до его записи на физический носитель. Клиентское шифрование (Client-Side Encryption) выполняется до передачи данных в Amazon S3, поэтому AWS получает уже зашифрованный объект.

SSE-S3 — это серверное шифрование с ключами, управляемыми Amazon S3. В этом варианте AWS полностью управляет ключевым материалом и выполняет шифрование данных с использованием алгоритма AES-256. Данный режим является базовым и не требует отдельного управления ключами со стороны пользователя.

SSE-KMS — это серверное шифрование с использованием AWS Key Management Service (AWS KMS), то есть сервиса управления криптографическими ключами. При таком подходе ключи создаются и контролируются через KMS. Для пользовательских ключей (customer managed keys) доступны политики доступа, аудит использования, ротация и возможность ограничить доступ к данным через отзыв доступа к ключу. При обращении к объектам, зашифрованным SSE-KMS, могут выполняться дополнительные запросы к KMS, что необходимо учитывать при расчёте стоимости и производительности. Для снижения числа вызовов KMS может использоваться механизм S3 Bucket Keys.

SSE-C — это серверное шифрование с ключами, предоставляемыми клиентом (Customer-Provided Keys). В этом режиме пользователь передаёт ключ при каждом запросе на запись или чтение объекта. AWS применяет ключ для шифрования или расшифрования, но не сохраняет его. Ответственность за хранение, ротацию и доступность ключевого материала полностью возлагается на пользователя. Данный режим поддерживается через API, SDK и CLI, но не является типовым вариантом для управления через консоль.

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

Начиная с 2023 года Amazon S3 автоматически применяет серверное шифрование SSE-S3 ко всем новым объектам, если для них явно не указан иной механизм шифрования. При необходимости для бакета можно настроить шифрование по умолчанию с использованием SSE-KMS и конкретного KMS-ключа. Отличие SSE-KMS от SSE-S3 имеет не только технический, но и регуляторный характер: SSE-KMS предоставляет более развитые механизмы аудита, разграничения доступа и управления жизненным циклом ключей.

4. Управление доступом и политики безопасности

Модель управления доступом в Amazon S3 строится на сочетании политик идентичностей и ресурсных политик. Политика IAM (Identity and Access Management policy, политика управления доступом идентичности) связывается с пользователем, группой или ролью и определяет, какие действия разрешены данной идентичности. Политика бакета (bucket policy, ресурсная политика бакета) связывается с самим бакетом и определяет, каким субъектам разрешён доступ к ресурсу.

Итоговое решение о доступе принимается на основе совокупности разрешающих и запрещающих правил. Запрос может быть разрешён, если существует применимое разрешение в IAM policy или bucket policy и отсутствует явный запрет. Явный запрет (explicit Deny) имеет приоритет над любыми разрешениями и всегда приводит к отклонению запроса.

В bucket policy субъект доступа указывается через элемент Principal. В качестве субъектов могут выступать конкретные IAM-пользователи или роли, другие AWS-аккаунты, AWS-сервисы, а также все субъекты через "Principal": "*". Последний вариант не обязательно означает публичный доступ: он может использоваться совместно с условиями, например для ограничения доступа только из определённой организации или через конкретный сетевой endpoint.

Условия (conditions) играют важную роль в построении безопасных политик. Условие aws:SourceVpce позволяет ограничить доступ конкретным VPC endpoint, что снижает риск передачи данных через публичный интернет. Условие aws:SecureTransport используется для запрета HTTP-запросов и принудительного применения HTTPS/TLS. Условие s3:prefix ограничивает операции перечисления объектов определённым префиксом, что применимо в многоарендных моделях хранения. Условие aws:PrincipalOrgID позволяет разрешить доступ только аккаунтам внутри определённой AWS Organization.

Необходимо различать операции уровня бакета и операции уровня объекта. Для операций над бакетом, например s3:ListBucket, используется ARN вида arn:aws:s3:::example-bucket. Для операций над объектами, например s3:GetObject, s3:PutObject и s3:DeleteObject, используется ARN вида arn:aws:s3:::example-bucket/*. Неверное указание ARN является распространённой причиной ошибок доступа, особенно при настройке backend-хранилищ для инфраструктурных инструментов.

Современная практика управления доступом в Amazon S3 предполагает преимущественное использование IAM policies, bucket policies и S3 Access Points. Списки контроля доступа (Access Control Lists, ACL) исторически применялись для управления доступом к отдельным бакетам и объектам, однако AWS рекомендует по возможности использовать политики как более гибкий и централизованный механизм. В режиме S3 Object Ownership Bucket owner enforced ACL отключаются, владелец бакета становится владельцем всех объектов, а доступ управляется исключительно политиками.

5. Логирование, аудит и наблюдаемость

Amazon S3 предоставляет несколько механизмов наблюдаемости и аудита. Server Access Logging, или серверное логирование доступа, фиксирует запросы к бакету и сохраняет записи в целевом бакете. Такие логи содержат сведения о времени обращения, методе запроса, статусе ответа, объёме переданных данных, пользовательском агенте и других параметрах HTTP-уровня. Рекомендуется использовать отдельный целевой бакет для хранения логов, чтобы избежать смешения рабочих данных и данных аудита.

Серверные access logs доставляются по модели best-effort, то есть без строгой гарантии полноты, порядка и времени доставки. Возможны задержки и дубликаты записей. Поскольку сами логи также являются объектами Amazon S3, для них необходимо задавать правила жизненного цикла, иначе они будут неограниченно увеличивать объём хранилища и стоимость эксплуатации.

AWS CloudTrail решает иную задачу. Он фиксирует API-вызовы уровня управления, а при включении data events — также операции уровня объектов. CloudTrail предоставляет структурированные JSON-записи, лучше интегрируется с аналитическими и SIEM-системами и предпочтителен для задач соответствия требованиям безопасности и регуляторного аудита. Server Access Logging целесообразен для диагностики на HTTP-уровне, анализа источников загрузок, referrer-заголовков и пользовательских агентов.

Таким образом, Server Access Logging и CloudTrail не являются взаимозаменяемыми инструментами. Первый ориентирован на технический анализ запросов к объектам, второй — на аудит действий субъектов и API-вызовов в инфраструктуре AWS.

6. Классы хранения Amazon S3

Класс хранения (storage class) определяет экономические и эксплуатационные свойства размещения объекта: стоимость хранения, стоимость запросов, минимальный срок хранения, минимальный тарифицируемый размер, задержку доступа и устойчивость к отказам. Выбор класса хранения должен основываться на профиле доступа к данным, требованиях к восстановлению, критичности потери данных и экономической модели системы.

S3 Standard предназначен для часто используемых данных и обеспечивает миллисекундную задержку доступа, высокую доступность и размещение данных минимум в трёх зонах доступности. S3 Standard-Infrequent Access (S3 Standard-IA) применяется для редко используемых данных, к которым при этом требуется быстрый доступ. S3 One Zone-Infrequent Access (S3 One Zone-IA) также обеспечивает миллисекундный доступ, но хранит данные в одной зоне доступности, поэтому подходит только для воспроизводимых или вторичных данных.

S3 Glacier Instant Retrieval предназначен для архивных данных, к которым иногда требуется немедленный доступ. S3 Glacier Flexible Retrieval используется для архивов, где допустимо восстановление в течение минут или часов. S3 Glacier Deep Archive предназначен для долгосрочного архивного хранения с наименьшей стоимостью хранения и временем восстановления до нескольких часов. S3 Intelligent-Tiering автоматически перемещает объекты между уровнями доступа в зависимости от фактического паттерна использования.

При выборе класса хранения необходимо учитывать минимальный срок хранения. Если объект удаляется или переводится в другой класс раньше установленного минимального срока, тарификация всё равно рассчитывается за полный минимальный период. Для классов infrequent access также применяется минимальный тарифицируемый размер объекта, что делает их экономически неэффективными для большого количества мелких объектов. Кроме того, в классах IA стоимость операций чтения выше, чем в S3 Standard, поэтому при частом доступе экономия на хранении может быть нивелирована стоимостью запросов.

S3 One Zone-IA требует отдельного рассмотрения. Этот класс хранит данные избыточно внутри одной зоны доступности, но не предназначен для защиты от физической потери всей зоны. Следовательно, он применим для данных, которые можно восстановить из исходных источников, повторно вычислить или скопировать из другого хранилища.

7. Правила жизненного цикла объектов

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

Переход (transition) переводит объект в другой класс хранения через заданное число дней после создания. Истечение срока хранения (expiration) удаляет объект после заданного периода. Для бакетов с включённым версионированием существуют отдельные действия: NoncurrentVersionTransition переводит нетекущие версии в другой класс хранения, а NoncurrentVersionExpiration удаляет нетекущие версии после заданного срока. Действие AbortIncompleteMultipartUpload удаляет незавершённые multipart-загрузки, поскольку уже загруженные части занимают место и тарифицируются до завершения или отмены загрузки.

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

Жизненный цикл объектов является не только инструментом оптимизации стоимости, но и элементом архитектуры управления данными. Для журналов, резервных копий, старых версий объектов и временных артефактов отсутствие lifecycle-правил может привести к неконтролируемому росту стоимости хранения.

8. Репликация данных

S3 Replication — это механизм асинхронного копирования объектов из исходного бакета в один или несколько целевых бакетов. Репликация между регионами называется Cross-Region Replication (CRR), а репликация в пределах одного региона — Same-Region Replication (SRR). CRR применяется для сценариев аварийного восстановления, географического распределения данных, соответствия требованиям юрисдикции и снижения задержки доступа для пользователей из разных регионов. SRR используется для агрегации логов, копирования данных между аккаунтами, разделения прав доступа и создания дополнительной управляемой копии данных.

Репликация выполняется асинхронно. В типовых условиях задержка может составлять секунды или минуты, однако без дополнительных механизмов она не является строгой гарантией. Replication Time Control (RTC), или контроль времени репликации, является платной опцией с соглашением об уровне обслуживания: 99,99% объектов должны быть реплицированы в течение 15 минут.

Для настройки репликации необходимо включить версионирование как на исходном, так и на целевом бакете. По умолчанию реплицируются только новые объекты, созданные после включения правила репликации. Для уже существующих объектов требуется использовать S3 Batch Replication или отдельную процедуру копирования, например через aws s3 sync.

Не все объекты и действия реплицируются автоматически. По умолчанию не реплицируются объекты, созданные до включения правила, объекты, зашифрованные SSE-C, delete markers без соответствующей настройки, а также объекты, которые уже являются репликами, если цепочка репликации не задана явно. Если исходный бакет использует SSE-KMS, необходимо указать KMS-ключ назначения, а роль репликации должна иметь права на расшифрование исходным ключом и шифрование целевым ключом.

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

9. Object Lock и неизменяемое хранение

S3 Object Lock реализует модель Write Once Read Many (WORM), то есть «однократная запись — многократное чтение». Этот механизм предотвращает удаление или перезапись версии объекта до истечения заданного срока хранения либо до снятия правового удержания. Object Lock применяется в системах, где требуется неизменяемость данных: финансовая отчётность, медицинские записи, журналы аудита, доказательная база и архивы, подпадающие под регуляторные требования.

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

В режиме Governance Mode объект защищён от удаления большинством пользователей. Однако субъекты, обладающие разрешением s3:BypassGovernanceRetention, могут обойти ограничение, если это явно разрешено политиками. Этот режим подходит для защиты от ошибочных операций и внутренних административных нарушений.

В режиме Compliance Mode объект не может быть удалён или изменён никем, включая root-пользователя AWS-аккаунта, до истечения срока хранения. Срок retention нельзя сократить или отключить. Такой режим используется для строгих регуляторных требований, когда неизменяемость данных должна быть технически принудительной.

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

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

10. S3 Express One Zone и directory buckets

S3 Express One Zone — это высокопроизводительный класс хранения Amazon S3, предназначенный для приложений, чувствительных к задержке доступа. Он обеспечивает однозначные миллисекундные задержки операций PUT и GET и размещает данные в пределах одной выбранной зоны доступности. Для работы с этим классом используются directory buckets, или бакеты каталогов.

Directory bucket отличается от бакета общего назначения моделью размещения и доступа. Он ориентирован на низколатентные сценарии и может быть создан в конкретной Availability Zone, что позволяет размещать объектное хранилище ближе к вычислительным ресурсам. В отличие от бакетов общего назначения, directory buckets имеют иную модель endpoint’ов и применяются прежде всего для высокопроизводительных рабочих нагрузок, а не для универсального долговременного хранения.

Следует учитывать, что S3 Express One Zone не является заменой S3 Standard для всех сценариев. Его преимущества проявляются в системах, где критична задержка доступа и где допустимо размещение данных в одной зоне доступности. Для долговременного хранения критически важных данных, требующих межзональной избыточности, более уместны классы хранения, размещающие данные минимум в трёх Availability Zones.

11. Много-региональный доступ и аварийное восстановление

Для задач аварийного восстановления и географического распределения данных могут применяться различные механизмы Amazon S3. CRR обеспечивает асинхронное копирование данных в другой регион и тем самым снижает показатель целевой точки восстановления (Recovery Point Objective, RPO). Однако переключение приложений на другой регион обычно требует дополнительной логики на уровне DNS, конфигурации приложения или маршрутизации.

S3 Multi-Region Access Points предоставляют единый глобальный endpoint для доступа к данным, размещённым в нескольких регионах. Такой механизм может маршрутизировать запросы к ближайшему или доступному региону и применяется в архитектурах, где требуется более высокая устойчивость к региональным сбоям и снижение задержки для географически распределённых пользователей.

При сравнении механизмов восстановления необходимо различать RPO и RTO. RPO определяет допустимый объём потери данных во времени, а RTO — допустимое время восстановления сервиса. CRR без RTC обычно обеспечивает малое, но не строго гарантированное RPO. CRR с RTC добавляет временную гарантию репликации. Версионирование и резервное копирование позволяют восстановить состояние данных, но RTO зависит от процедуры восстановления. Multi-Region Access Points могут снижать RTO за счёт более автоматизированной маршрутизации запросов.

12. Производительность и эксплуатационные особенности

Amazon S3 является масштабируемым сервисом, однако эксплуатационная архитектура должна учитывать особенности объектного доступа. Операции над объектами не эквивалентны операциям файловой системы. Например, атомарного переименования объекта в S3 нет: операция rename обычно реализуется как копирование объекта в новый ключ и удаление старого объекта. Это важно для систем, которые предполагают POSIX-семантику файловой системы.

Для крупных объектов рекомендуется использовать Multipart Upload. Этот механизм делит объект на части, которые могут загружаться параллельно. При сетевых сбоях повторной загрузки требует только неудачная часть, а не весь объект. Такой подход повышает устойчивость передачи и может улучшать производительность загрузки.

При резком росте количества запросов к бакету или к определённому диапазону ключей возможны временные ответы 503 Slow Down. Они указывают на необходимость повторов с экспоненциальной задержкой и корректной клиентской обработки ошибок. Поэтому приложения, работающие с S3, должны реализовывать retry-механику, учитывать идемпотентность операций и избегать проектирования, при котором корректность системы зависит от немедленного успешного выполнения каждого запроса.

13. Заключение

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

Для корректного использования Amazon S3 необходимо различать долговечность и доступность, версионирование и резервное копирование, серверное и клиентское шифрование, IAM policies и bucket policies, а также storage classes с различными экономическими и эксплуатационными характеристиками. Неправильный выбор класса хранения, отсутствие lifecycle-правил, неучтённые версии объектов, некорректные политики доступа и неуправляемые multipart-загрузки могут приводить к росту стоимости и снижению надёжности системы.

Современная архитектура S3 включает не только классические бакеты общего назначения, но и специализированные механизмы: Object Lock для неизменяемого хранения, S3 Replication для копирования данных между бакетами и регионами, S3 Access Points для масштабируемого управления доступом, S3 Express One Zone и directory buckets для низколатентных сценариев. Поэтому Amazon S3 следует рассматривать не как простое облачное хранилище файлов, а как комплексную платформу управления объектными данными, требующую формального подхода к безопасности, стоимости, доступности и жизненному циклу информации.

Сводная таблица ключевых характеристик

Характеристика	Значение
Тип хранилища	Объектное хранилище
Базовая единица хранения	Объект: данные, ключ и метаданные
Максимальный размер объекта	5 TB
Максимальный размер одиночной загрузки	5 GB
Механизм загрузки крупных объектов	Multipart Upload
Пространство имён general purpose bucket	Плоское, на основе ключей
Папки в general purpose bucket	Логическая визуализация префиксов
Согласованность	Strong read-after-write consistency для операций с объектами
S3 Standard durability	99,999999999%
S3 Standard availability	99,99%
Версионирование	Можно включить или приостановить; возврат к unversioned невозможен
Удаление при включённом versioning	Создание Delete Marker без физического удаления версий
Шифрование по умолчанию	SSE-S3 для новых объектов
Основное отличие SSE-KMS	Управление ключами, аудит и политики KMS
Object Lock	WORM-модель для защиты версий объектов
Lifecycle rules	Автоматический переход, истечение срока хранения и удаление нетекущих версий
CRR	Асинхронная репликация между регионами
SRR	Асинхронная репликация внутри региона
S3 Express One Zone	Низколатентное хранение в одной Availability Zone