Amazon SAA-C03: Хранилища и жизненный цикл данных — Руководство по подготовке

By Laurynas Brazys · 19 July 2026 · #amazon #saa-c03 #certification #exam-prep #study-guide

Часть AWS SAA-C03 — Полное руководство по подготовке. Практикуйтесь с проверенными ответами в центре экзаменов Amazon, или пройдите тесты на время на ExamRoll.io.

Классы хранения S3 и спектр стоимости/задержки

Классы хранения S3 представляют собой спектр, в котором задержка извлечения, минимальный срок хранения и плата за извлечение в расчете на ГБ обмениваются на стоимость хранения в расчете на ГБ. Правильный выбор — это самый мощный рычаг для оптимизации затрат на объектное хранилище.

S3 Standard — это класс по умолчанию: долговечность «одиннадцать девяток» в трех или более зонах доступности (AZ), миллисекундная задержка, отсутствие платы за извлечение, самая высокая цена за ГБ. Standard-IA и One Zone-IA снижают стоимость хранения примерно на 40–50%, но добавляют плату за извлечение в расчете на ГБ, минимальный оплачиваемый срок хранения в 30 дней и минимальный размер объекта в 128 КБ (объекты меньшего размера оплачиваются как 128 КБ, что сводит на нет экономию). One Zone-IA дополнительно снижает стоимость за счет хранения в одной AZ — подходит только для воспроизводимых вторичных копий, для которых потеря данных в одной AZ допустима.

S3 Intelligent-Tiering — это правильный выбор, когда шаблоны доступа неизвестны, непредсказуемы или меняются в большом массиве данных. Он автоматически перемещает объекты между уровнями для частого, редкого, архивного мгновенного, архивного и глубокого архивного доступа на основе наблюдаемой активности, взимая небольшую плату за мониторинг каждого объекта. Поскольку плата за извлечение между уровнями для частого и редкого доступа отсутствует и нет минимального срока хранения, это самый безопасный выбор по умолчанию для озер данных и смешанных рабочих нагрузок с объектами ≥128 КБ. Это неправильный выбор, когда вы уже знаете, что объекты постоянно «горячие» (дополнительные расходы на мониторинг) или постоянно «холодные» в течение десятилетия (Deep Archive намного дешевле).

Glacier Instant Retrieval обеспечивает миллисекундный доступ по архивным ценам для данных, к которым обращаются ежеквартально или реже — медицинские изображения, PDF-файлы для комплаенса, которые должны быть предоставлены немедленно по запросу. Glacier Flexible Retrieval предлагает извлечение за минуты-часы. Glacier Deep Archive — самый дешевый уровень в AWS, стоимостью примерно $1/ТБ/месяц, со стандартным временем извлечения 12 часов (или 48 часов для массового извлечения) и минимальным сроком хранения 180 дней — правильный ответ для 7–10-летнего хранения данных в соответствии с нормативными требованиями и для замены ленточных накопителей.

Две основные ловушки затрат — это противоположные ошибки. Выбор класса Standard для долгосрочного хранения редко читаемых данных — это пустая трата денег, поскольку у Standard нет скидки на «холодное» хранение — набор данных объемом 5 ТБ, хранящийся годами в Standard, стоит в несколько раз дороже, чем те же данные в Deep Archive. И наоборот, немедленное перемещение новых объектов в Standard-IA или Glacier — это ловушка, поскольку минимальные платежи за 30/90/180 дней плюс плата за извлечение превышают экономию, пока объекты еще «горячие». Glacier Flexible или Deep Archive также абсолютно несовместимы с любой рабочей нагрузкой, которая ожидает синхронного чтения — пользователь, ожидающий ответа на HTTP GET, не может мириться с SLA на извлечение от нескольких минут до 12 часов. Glacier Instant Retrieval — единственный уровень Glacier, совместимый с немедленным доступом.

Политики жизненного цикла и работа с версиями

Конфигурация жизненного цикла — это декларативный JSON/YAML, прикрепленный к бакету, который перемещает или удаляет объекты по истечении срока их действия в зависимости от возраста, тега или префикса. Переходы оцениваются раз в день и срабатывают только по достижении указанного возраста — переход Days: 30 означает, что в течение первых 30 дней применяются тарифы Standard. Переходы должны осуществляться в последовательно более «холодные» уровни, а объекты размером менее 128 КБ не перемещаются из Standard в IA, поскольку накладные расходы на объект превышают экономию; сначала объедините мелкие объекты с помощью tar/zip или S3 Batch Operations.

Каноническая политика для рабочей нагрузки, где данные «горячие» в течение 30 дней, а затем «холодные», требуют немедленного доступа в течение всего времени, хранятся четыре года, с соблюдением надлежащей гигиены:

Rules:
  - ID: archive-and-clean
    Status: Enabled
    Transitions:
      - Days: 30
        StorageClass: STANDARD_IA
      - Days: 180
        StorageClass: DEEP_ARCHIVE
    NoncurrentVersionTransitions:
      - NoncurrentDays: 30
        StorageClass: GLACIER
    NoncurrentVersionExpiration:
      NoncurrentDays: 365
    Expiration:
      Days: 1460
    AbortIncompleteMultipartUpload:
      DaysAfterInitiation: 7

Частая ловушка при работе с версиями: в бакете с версионированием правило жизненного цикла, которое удаляет текущие объекты, просто вставляет маркеры удаления; предыдущие версии незаметно накапливаются и продолжают тарифицироваться. Неактуальные версии требуют собственных явных правил NoncurrentVersionTransitions и NoncurrentVersionExpiration. Аналогично, всегда включайте AbortIncompleteMultipartUpload — «осиротевшие» части многочастных загрузок невидимы в списке консоли и бесконечно занимают место в хранилище.

Для смешанных шаблонов — скажем, телеметрия IoT, которая является «горячей» для обучения ML в первый месяц, затем запрашивается ежеквартально в течение года, а затем архивируется — правильным ответом будет Intelligent-Tiering на первый год (позволяя классу автоматически оптимизироваться между всплесками активности при обучении и днями простоя) с последующим запланированным переходом в Deep Archive на 365-й день.

Управление версиями, MFA Delete и Object Lock

После включения управление версиями можно только приостановить; его нельзя отключить. Каждый PUT создает новый ID версии; DELETE вставляет маркер удаления, а не удаляет данные. Управление версиями защищает от случайной перезаписи, но не является неизменяемостью: любой субъект с разрешением s3:DeleteObjectVersion может безвозвратно удалить конкретную версию. MFA Delete добавляет требование, чтобы корневая учетная запись предоставляла токен MFA для безвозвратного удаления версий или изменения состояния управления версиями — это закрывает проблему случайного удаления для ценных бакетов, но все же не мешает авторизованному субъекту уничтожить данные.

Настоящая неизменяемость требует S3 Object Lock, для которого необходимо управление версиями и которое, как правило, должно быть включено при создании бакета. У него есть два режима, которые часто путают:

Срок хранения можно применять к отдельным объектам (Retain-Until-Date) или через Legal Hold (блокировка по юридическим причинам), у которого нет срока действия. Для бухгалтерских записей, которые должны храниться один год в «горячем» доступе, девять лет в архиве и не подлежать удалению в течение десяти лет, правильным подходом будет Object Lock в режиме Compliance с десятилетним сроком хранения в сочетании с переходом жизненного цикла в Deep Archive на 365-й день. Режим Governance не является приемлемой заменой для юридического требования — регулятор не примет утверждение «кто-то с разрешениями мог это удалить» в качестве доказательства неизменяемости.

Чтобы применить срок хранения к существующему набору PDF-файлов в рамках одного задания, используйте S3 Batch Operations на основе манифеста S3 Inventory. Batch Operations — это управляемое решение для крупномасштабных изменений (установка срока хранения, добавление тегов, перешифрование через PUT-copy, вызов Lambda) для миллиардов ключей; самописные скрипты для итерации — неправильный подход.

Шифрование: SSE-S3, SSE-KMS и Bucket Keys

В каждом бакете есть шифрование по умолчанию. SSE-S3 (AES-256, ключи под управлением S3) бесплатно и не требует администрирования ключей. SSE-KMS использует главный ключ клиента (CMK) из KMS, что позволяет вести аудиторские журналы CloudTrail для каждого ключа, использовать политики доступа к ключам на основе IAM и контролировать ротацию ключей — ценой этого являются плата за API-вызовы KMS и, что более важно, троттлинг запросов KMS, который может стать узким местом для рабочих нагрузок с высокой пропускной способностью чтения. Выбирайте SSE-KMS, когда вам действительно нужны эти средства контроля (подтверждение соответствия нормативным требованиям, разделение обязанностей, совместное использование ключей между аккаунтами). Использование SSE-KMS по умолчанию «на всякий случай» добавляет ненужные затраты и сложность, когда SSE-S3 уже удовлетворяет требованиям.

S3 Bucket Keys решают проблему стоимости запросов к KMS при использовании SSE-KMS. S3 генерирует недолговечный ключ на уровне бакета из CMK и локально получает из него ключи данных для каждого объекта, избегая вызова GenerateDataKey/Decrypt в KMS для каждого объекта и снижая стоимость запросов к KMS до 99%:

"ServerSideEncryptionConfiguration": {
  "Rules": [{
    "ApplyServerSideEncryptionByDefault": {
      "SSEAlgorithm": "aws:kms",
      "KMSMasterKeyID": "arn:aws:kms:..."
    },
    "BucketKeyEnabled": true
  }]
}

Переключение на SSE-S3 для «экономии на KMS» — это неверное решение, когда требования предписывают использовать KMS. S3 Bucket Keys позволяют достичь целей и по соответствию требованиям, и по стоимости, не отказываясь от KMS.

Включение шифрования по умолчанию для бакета гарантирует, что все будущие загрузки будут зашифрованы (незашифрованные PUT-запросы шифруются прозрачно). Чтобы полностью отклонять незашифрованные PUT-запросы, запретите запись без соответствующего заголовка:

{
  "Effect": "Deny",
  "Principal": "*",
  "Action": "s3:PutObject",
  "Resource": "arn:aws:s3:::my-bucket/*",
  "Condition": {
    "StringNotEquals": {
      "s3:x-amz-server-side-encryption": "AES256"
    }
  }
}

Шифрование по умолчанию не затрагивает уже существующие незашифрованные объекты. Перешифруйте их с помощью S3 Inventory и S3 Batch Operations, запустив задание Copy, которое перезаписывает каждый ключ на месте — это стандартный подход для массового перешифрования.

Специализированное шифрование на стороне клиента уступает шифрованию по умолчанию с KMS: оно рассредоточивает управление ключами по командам разработки, не может централизованно аудироваться через события KMS в CloudTrail и не позволяет использовать S3 Bucket Keys.

Межрегиональная репликация (CRR) и мультирегиональные ключи KMS

Cross-Region Replication (CRR) асинхронно копирует объекты в бакет в другом регионе для соответствия требованиям, аварийного восстановления (DR) или уменьшения задержек. Same-Region Replication (SRR) служит для разделения данных в целях соответствия, агрегации логов и копирования между аккаунтами. Оба типа репликации требуют включенного управления версиями на исходном и целевом бакетах, а также IAM-роли, которую принимает исходный бакет. CRR — это простое решение, когда необходимо зеркалировать бакет в другой регион. Создание скриптов с aws s3 sync, привязка Lambda к событиям ObjectCreated или запуск пакетных копирований по расписанию вносят операционные издержки, условия гонки и могут приводить к скрытым сбоям. Ни CRR, ни SRR по умолчанию не реплицируют существующие объекты; для их копирования используйте S3 Batch Replication.

Взаимодействие с шифрованием — это область, где проекты часто терпят неудачу:

• Объекты SSE-S3 реплицируются прозрачно.
• Объекты SSE-KMS по умолчанию не реплицируются — вы должны явно включить эту опцию, указать целевой ключ KMS в целевом регионе и предоставить роли репликации разрешения kms:Decrypt для исходного ключа и kms:Encrypt для целевого ключа. Ключ из одного региона не может шифровать объекты в другом регионе.
• Объекты, зашифрованные на стороне клиента, реплицируются как непрозрачный шифротекст; целевой регион не получит никакой пользы, если ключевой материал клиента не будет там доступен.

Исторические трудности с управлением двумя независимыми CMK решаются с помощью мультирегиональных ключей AWS KMS, которые предоставляют один и тот же ключевой материал и ID ключа (с префиксом региона) в нескольких регионах. Реплицированный объект затем можно расшифровать в целевом регионе без межрегиональных вызовов KMS и без повторного шифрования ключа данных. Это канонический подход для зашифрованных, реплицируемых бакетов, которые должны оставаться доступными при региональном аварийном переключении.

Совместное использование снимков и объектов между аккаунтами с использованием управляемого клиентом ключа KMS требует, чтобы субъекты целевого аккаунта имели разрешения kms:Decrypt, kms:CreateGrant, kms:DescribeKey и kms:ReEncrypt* для исходного ключа через политику ключа, а также соответствующие разрешения IAM. Ключи, управляемые AWS (например, aws/ebs, aws/s3), не могут быть использованы совместно с другими аккаунтами, поэтому для межаккаунтных сценариев обязательны ключи, управляемые клиентом.

Блокировка публичного доступа и ограничение доступа через CloudFront

S3 Block Public Access (BPA) имеет четыре настройки — блокировать новые публичные ACL, игнорировать существующие публичные ACL, блокировать новые публичные политики бакета, ограничивать публичные политики бакета — настраиваемых для каждого бакета и, что более важно, на уровне аккаунта. BPA на уровне аккаунта имеет приоритет над любой политикой бакета, которая могла бы предоставить публичный доступ, и является правильным средством контроля для требования «ни один объект в этом аккаунте не должен быть публичным». Политики на уровне бакета сами по себе ненадежны: новый бакет может быть запущен без политики; BPA на уровне аккаунта обеспечивает отказ по умолчанию (fails closed).

Чтобы запретить администратору в дочернем аккаунте отключать BPA, примените Service Control Policy на уровне OU или корня Organizations:

{
  "Effect": "Deny",
  "Action": "s3:PutAccountPublicAccessBlock",
  "Resource": "*",
  "Condition": {
    "Bool": { "aws:PrincipalIsAWSService": "false" }
  }
}

Чтобы раздавать контент S3 только через CloudFront, прикрепите Origin Access Control (OAC) — современную замену устаревшему OAI — к дистрибуции и ограничьте политику бакета на основе ARN дистрибуции:

{
  "Effect": "Allow",
  "Principal": { "Service": "cloudfront.amazonaws.com" },
  "Action": "s3:GetObject",
  "Resource": "arn:aws:s3:::my-bucket/*",
  "Condition": {
    "StringEquals": {
      "AWS:SourceArn": "arn:aws:cloudfront::111122223333:distribution/E123"
    }
  }
}

BPA остается включенным на бакете. Для предоставления временного доступа к приватным объектам конкретному пользователю (с истечением срока на загрузку/скачивание) сгенерируйте предзаверенную ссылку (presigned URL), встроенная подпись которой наследует разрешения подписавшего субъекта (principal).

Приватные сетевые пути: Gateway Endpoints

Трафик от EC2 к S3 в пределах VPC не использует автоматически частную магистральную сеть AWS. Без дополнительной настройки вызовы S3 API разрешаются в публичные эндпоинты и проходят через интернет-шлюз или NAT-шлюз, что влечет за собой плату за обработку данных NAT и выставляет трафик в интернет. Gateway VPC endpoint для S3 (и DynamoDB) бесплатен, добавляется как маршрут с префикс-листом в указанные таблицы маршрутизации и удерживает трафик в сети AWS. Также существуют платные interface endpoints (PrivateLink) для S3, которые полезны, когда доступ осуществляется из локальной среды через Direct Connect. Совместите эндпоинт с условием aws:SourceVpce в политике бакета, чтобы обеспечить доступ к бакету только с разрешенных VPC-эндпоинтов — это стандартный подход для регулируемых рабочих нагрузок.

Object Lambda для преобразования «на лету»

S3 Object Lambda встраивает функцию Lambda в путь обработки запросов GET/HEAD/LIST, так что объект, возвращаемый вызывающей стороне, преобразуется в момент чтения. Это позволяет избежать дублирования данных для каждого варианта (отредактированного, с измененным размером, переформатированного) и сохранять единый источник истины в базовом бакете. Типичные примеры использования: сокрытие персональных данных (PII) для аналитиков и предоставление полных данных для аудиторов, добавление водяных знаков на изображения для каждого пользователя, преобразование XML в JSON для устаревших клиентов. IAM и политики бакета по-прежнему контролируют доступ к базовому объекту; функция Lambda видит только то, что разрешено ее роли выполнения.

Уведомления о событиях

S3 отправляет события (s3:ObjectCreated:*, s3:ObjectRemoved:*, события репликации и жизненного цикла) в Lambda, SQS, SNS или EventBridge. EventBridge предпочтительнее, когда вам нужно несколько получателей, фильтрация по метаданным объекта или маршрутизация между аккаунтами; прямые уведомления проще и дешевле для конвейеров с одним получателем, таких как создание миниатюр при загрузке. Уведомления доставляются по принципу «как минимум один раз» (at-least-once), поэтому потребители должны быть идемпотентными.

Оптимизация пропускной способности: Multipart Upload и Transfer Acceleration

Для объектов размером более 100 МБ многочастная загрузка (multipart upload) является лучшей практикой; для объектов более 5 ГБ она обязательна. Части загружаются параллельно, неудачные попытки загрузки частей повторяются независимо, а пропускная способность масштабируется с увеличением параллелизма. Запросы GET с указанием диапазона байтов (Byte-range GETs) обеспечивают аналогичный параллелизм при скачивании. Как уже отмечалось, всегда добавляйте правило жизненного цикла AbortIncompleteMultipartUpload, чтобы избежать оплаты за оставшиеся незавершенные части.

S3 Transfer Acceleration направляет загрузки через ближайшую пограничную точку CloudFront по магистральной сети AWS — используйте эту функцию для глобально распределенных клиентов, загружающих файлы в один бакет. Для скачиваний используйте CloudFront перед S3 для кэширования на пограничных точках. Transfer Acceleration ориентирован на загрузку; CloudFront — на скачивание; они решают связанные, но разные задачи.

EBS: типы томов, шифрование и снимки

Тома EBS — это блочные устройства, привязанные к одной зоне доступности (AZ) и подключаемые к одному инстансу EC2. gp3 — это SSD-накопитель общего назначения, используемый по умолчанию. Его ключевое преимущество перед gp2 заключается в том, что IOPS (до 16 000) и пропускная способность (до 1000 МиБ/с) настраиваются независимо от ёмкости. Это устраняет антипаттерн gp2, когда для достижения нужной производительности приходилось избыточно выделять дисковое пространство. io2 Block Express обеспечивает до 256 000 IOPS с субмиллисекундной задержкой для баз данных, чувствительных к задержкам. st1 и sc1 — это HDD-накопители, предназначенные для рабочих нагрузок с последовательным доступом и холодными данными, где важна пропускная способность. Функция Multi-Attach для томов io1/io2 существует, но ограничена 16 инстансами в одной AZ, использующими кластерную файловую систему. Это узкое исключение, а не общий паттерн «совместного использования EBS». Попытка подключить том EBS к множеству инстансов (например, за балансировщиком нагрузки) — это категориальная ошибка, которая приводит к симптому «при обновлении одни документы видны, а другие нет», поскольку каждый том является частным блочным устройством.

Тома EBS поддерживают шифрование неактивных данных (at rest) по алгоритму AES-256 с использованием ключей данных, обёрнутых с помощью KMS. Шифрование происходит прозрачно — без снижения производительности и без необходимости вносить изменения в приложения. Если том зашифрован, то все производные от него снимки и тома также будут зашифрованы; расшифровать том на месте невозможно. Включите шифрование EBS по умолчанию для каждого региона, чтобы все новые тома и снимки шифровались автоматически, независимо от того, помнит ли об этом разработчик:

aws ec2 enable-ebs-encryption-by-default --region us-east-1
aws ec2 modify-ebs-default-kms-key-id \
  --kms-key-id arn:aws:kms:us-east-1:111122223333:key/abcd-...

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

Снимки (snapshots) — это инкрементальные резервные копии на уровне блоков, хранящиеся в инфраструктуре под управлением S3. Однако они не бесплатны (вы платите за хранение изменённых блоков), не исчезают при удалении исходного тома и не удаляются при разрегистрации AMI, который на них ссылается. Со временем перемещайте их в уровень EBS Snapshots Archive (на 75% дешевле, восстановление занимает 24–72 часа) с помощью команды aws ec2 modify-snapshot-tier, Amazon Data Lifecycle Manager (DLM) или AWS Backup. Fast Snapshot Restore (FSR) предварительно «прогревает» снимок в указанных AZ, чтобы инстансы, запущенные из него, сразу же обеспечивали полную производительность. Включайте эту функцию для AMI, используемых в группах автомасштабирования, которые должны справляться с быстрым горизонтальным масштабированием.

Recycle Bin (Корзина) сохраняет удалённые снимки EBS и образы AMI в течение настраиваемого окна восстановления (от 1 дня до 1 года). Без неё удаление снимков происходит немедленно и необратимо:

aws rbin create-rule \
  --retention-period RetentionPeriodValue=30,RetentionPeriodUnit=DAYS \
  --resource-type EBS_SNAPSHOT \
  --description "30-day snapshot recovery"

Полагаться только на ежедневные снимки EBS для долгосрочного хранения данных в целях соответствия требованиям — распространённая архитектурная ошибка. Снимки по цене ближе к «тёплому» хранилищу и требуют явного перевода в архивные классы.

Amazon EFS: общее POSIX-хранилище для парка Linux-систем

EFS — это полностью управляемая, эластичная, POSIX-совместимая файловая система NFSv4.1, которую можно одновременно монтировать с тысяч клиентов EC2, ECS, EKS или Lambda в разных AZ одного региона, а также с локальных хостов через Direct Connect или VPN. Определяющим свойством является то, что одна и та же файловая система с идентичными дескрипторами файлов и семантикой на уровне байтов видна всем клиентам одновременно. Поэтому EFS — это правильное решение в случаях, когда парку Linux-инстансов за балансировщиком нагрузки необходимо совместно использовать общий набор файлов: загрузки пользователей, конфигурации, общие домашние каталоги.

Точки монтирования (mount targets) размещаются в каждой настроенной вами подсети AZ. Утилита amazon-efs-utils позволяет включить шифрование передаваемых данных (TLS in transit) и авторизацию монтирования через IAM:

sudo mount -t efs -o tls,iam fs-0123456789abcdef0:/ /mnt/shared

Классы хранения EFS имеют два измерения. Управление жизненным циклом перемещает файлы, к которым не было обращений в течение 7–90 дней, из класса Standard в Infrequent Access и, опционально, в Archive, что позволяет сократить расходы на хранение до 92%; Intelligent-Tiering возвращает их обратно при обращении. Классы One Zone хранят данные в одной AZ, что примерно на 47% дешевле. Это подходит для сред разработки/тестирования или для воспроизводимых данных, но никогда не для данных, потеря которых при сбое AZ недопустима. Шагом по оптимизации затрат для рабочей нагрузки, уже использующей EFS Standard-IA, является переход на EFS One Zone-IA без каких-либо изменений в приложении.

Производительность настраивается двумя независимыми параметрами. Режим производительности (задаётся при создании): General Purpose (общего назначения) обеспечивает наименьшую задержку и подходит для обслуживания веб-трафика с большим количеством метаданных; Max I/O — это устаревший вариант, заменённый режимом Elastic. Режим пропускной способности: Bursting (с переменной производительностью) масштабируется в зависимости от размера (базовая скорость 50 КБ/с на ГБ, с накоплением кредитов при работе ниже базового уровня), Provisioned (с выделенной производительностью) позволяет оплачивать фиксированную пропускную способность в МБ/с независимо от размера, а Elastic — текущий стандарт — автоматически масштабируется до 10+ ГБ/с без необходимости планирования ёмкости. Небольшая файловая система под постоянной нагрузкой может исчерпать кредиты для пиковой производительности, и её пропускная способность упадёт до низкого базового уровня. Поэтому для рабочих нагрузок с интенсивным вводом-выводом и малым объёмом данных необходимо использовать режимы Elastic или Provisioned.

EFS не является заменой для блочного хранилища с высоким IOPS. Каждая операция ввода-вывода в EFS — это вызов NFS RPC через сеть, поэтому рабочие нагрузки с одним писателем, субмиллисекундными задержками, характерные для журналов транзакций, следует размещать на EBS io2 Block Express. Один такой том обеспечивает 256 000 IOPS с задержкой менее миллисекунды, чего EFS не может достичь в расчёте на одну операцию. Кроме того, EFS неоправданно дорог для хранения холодных данных по сравнению с Deep Archive; хранить данные для соответствия требованиям на EFS «потому что это просто» — нерационально с точки зрения затрат.

FSx: Windows, Lustre, ONTAP, OpenZFS

FSx — это семейство управляемых файловых систем, выбираемых в зависимости от протокола и рабочей нагрузки:

FSx for Windows File Server предоставляет нативную поддержку SMB 2.0/3.1.1 с NTFS ACL, пространствами имен DFS, теневыми копиями и Kerberos через Active Directory. В конфигурации Multi-AZ разворачивается активный файловый сервер в одной зоне доступности (AZ) с синхронно реплицируемым резервным сервером в другой, а для отказоустойчивости используется единое DNS-имя. Интеграция с AD является обязательной: FSx должен быть присоединен к AWS Managed Microsoft AD или к доступному самоуправляемому AD, а клиенты аутентифицируются как доменные пользователи по доменным SID. Пропуск интеграции с AD или подключение клиентов к файловой системе в недоверенном лесу без межлесного доверия приводит к классическому симптому «доступ запрещен, хотя общий ресурс виден». FSx for Windows — это готовое целевое решение для миграции файловых ресурсов Windows по принципу lift-and-shift.

FSx for Lustre — это параллельная файловая система POSIX для HPC, обучения ML, EDA и геномики, поддерживающая тысячи клиентов, пропускную способность в сотни ГБ/с и операции с метаданными с задержкой менее миллисекунды. Ее ключевой особенностью в AWS является ассоциация с репозиторием данных в S3: ключи объектов отображаются как файлы в пространстве имен Lustre и «лениво» загружаются при первом доступе (или предварительно загружаются через

{
  "Effect": "Deny",
  "Action": "s3:PutAccountPublicAccessBlock",
  "Resource": "*",
  "Condition": {
    "Bool": { "aws:PrincipalIsAWSService": "false" }
  }
}

); новые/измененные файлы экспортируются обратно в S3 по расписанию или по запросу. Канонический паттерн для HPC выглядит так:

1. Скопировать локальные наборы данных в S3 (с помощью DataSync или Storage Gateway).
2. Создать файловую систему Lustre, связанную с этим бакетом.
3. Смонтировать на всех Spot-инстансах; читать входные данные и записывать выходные на максимальной скорости.
4. Экспортировать результаты в S3, который остается надежным долгосрочным репозиторием.
5. Удалить файловую систему Lustre по завершении задания.

Развертывания Lustre типа Scratch не имеют репликации, и данные теряются при сбое оборудования — это самый дешевый и быстрый вариант, подходящий для временных данных заданий. Развертывания типа Persistent реплицируют данные в пределах одной AZ для повышения надежности. Пропускная способность выделяется в МБ/с на каждый ТиБ (50/125/250/500/1000), что отделяет емкость от производительности.

FSx for NetApp ONTAP — это многопротокольное решение: NFS, SMB и iSCSI одновременно для одних и тех же данных, со снэпшотами, репликацией SnapMirror, FlexClones и дедупликацией. Выбирайте ONTAP при консолидации смешанных ресурсов Linux NFS и Windows SMB, требующих межпротокольного доступа с избыточностью Multi-AZ, или при миграции с локальных систем NetApp. FSx for OpenZFS заполняет нишу для рабочих нагрузок Linux, которым требуются функции ZFS (снэпшоты, клоны) через NFS. Не путайте многопротокольные возможности ONTAP с другими вариантами.

Сделайте неверный выбор, и вы получите явную ошибку: EBS для общей рабочей нагрузки, EFS для файлового ресурса Windows SMB или Lustre для интегрированного с AD ресурса Windows — все это неподходящие варианты. В первую очередь сопоставляйте протокол и шаблон доступа.

Storage Gateway: гибридный доступ

Storage Gateway представляет облачное хранилище так, как будто оно локальное. Это отличает его от DataSync, который перемещает данные.

Для приложения рендеринга, которое переместило свою медиатеку в S3, но по-прежнему требует локального чтения с низкой задержкой, подходит S3 File Gateway — доступ по NFS/SMB, локальный кэш, редко используемые объекты извлекаются из S3 по запросу. FSx File Gateway — это решение для филиалов: кэш с доступом по SMB на скорости LAN для центрального облачного ресурса FSx, а не решение для общего доступа между инстансами EC2 (которые должны монтировать FSx напрямую). Volume Gateway применяется, когда рабочая нагрузка использует блочный протокол iSCSI, а не файловую семантику. Tape Gateway заменяет физические ленточные библиотеки, работая с существующим ПО для резервного копирования.

Перенос и миграция данных

AWS DataSync — это сервис для агентной онлайн-миграции данных с NFS, SMB, HDFS и объектных хранилищ в S3, EFS или FSx. Он работает до 10 раз быстрее, чем инструменты с открытым исходным кодом, и обеспечивает шифрование, проверку целостности, планирование, а также сохранение метаданных POSIX и NTFS ACL. Для крупномасштабной миграции по SMB с миллионами мелких файлов и глубокими иерархиями решение с наименьшими накладными расходами — это DataSync в FSx for Windows: протокол SMB сохраняется, ACL и временные метки остаются нетронутыми, пропускная способность для мелких файлов обеспечивается за счет параллельной передачи, а изменения в приложениях не требуются. Миграция такого набора данных напрямую в S3 — это ловушка: объектные хранилища плохо справляются с листингом мелких файлов в глубоких префиксах, а клиенты SMB не могут монтировать бакеты.

AWS Snow Family — это физические устройства для офлайн-переноса данных: Snowcone (до 8 ТБ, в защищенном исполнении для периферийных вычислений), Snowball Edge (до ~80 ТБ полезного пространства, с опциями для вычислений) и Snowmobile (эксабайтный масштаб). Основное правило: если передача данных по сети займет больше недели, Snowball окажется дешевле и быстрее.

AWS Transfer Family предоставляет доступ по протоколам SFTP, FTPS, FTP и AS2 к данным в S3 или EFS — это правильное решение, когда внешние партнеры должны продолжать использовать стандартные протоколы передачи файлов.

AWS Backup, межрегиональное копирование и Vault Lock

AWS Backup централизует политики для EBS, EFS, FSx, RDS, DynamoDB, S3 и других сервисов. План резервного копирования определяет расписание, срок хранения в тёплом хранилище, переход в холодное хранилище, а также действия по межрегиональному/межаккаунтному копированию:

BackupPlan:
  Rules:
    - RuleName: DailyWithDRCopy
      TargetBackupVault: prod-vault
      ScheduleExpression: "cron(0 5 * * ? *)"
      Lifecycle:
        MoveToColdStorageAfterDays: 30
        DeleteAfterDays: 2555        # 7 years
      CopyActions:
        - DestinationBackupVaultArn: arn:aws:backup:eu-west-1:...:backup-vault:dr-vault
          Lifecycle:
            MoveToColdStorageAfterDays: 30
            DeleteAfterDays: 2555

Переход в холодное хранилище требует как минимум 90 дней хранения в тёплом хранилище плюс как минимум 90 дней в холодном; неправильно настроенные жизненные циклы отклоняются. Для настоящего многолетнего хранения в соответствии с нормативными требованиями используйте AWS Backup Vault Lock (WORM), который не позволяет даже администраторам сокращать срок хранения, что удовлетворяет требованиям SEC 17a-4 и подобным предписаниям. Межрегиональное копирование решает задачу регионального аварийного восстановления (DR); межаккаунтное копирование решает проблему программ-вымогателей и внутренних угроз, изолируя резервные копии от зоны поражения (blast radius) основного аккаунта.

Шпаргалка по выбору

← Бессерверные и событийно-ориентированные архитектуры · Все домены · Передача и миграция данных →

Отработать эти вопросы → · Тесты на время на ExamRoll.io →

Просмотреть Amazon →