Amazon DVA-C02: Хранилище, Amazon S3, CloudFront и файловые системы (EFS, FSx) — Руководство по подготовке

By Laurynas Brazys · 27 July 2026 · #amazon #dva-c02 #certification #exam-prep #study-guide

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

Основы Amazon S3, средства контроля безопасности и шаблоны для разработчиков

Amazon S3 — это каноническое надёжное объектное хранилище. Разработчикам следует проектировать API на основе операций

undefined

/

undefined

/

undefined

и многочастных загрузок (

undefined

,

undefined

,

undefined

) для больших объёмов данных, а также использовать вспомогательные функции SDK, такие как

undefined

или

undefined

в boto3, для временной загрузки данных клиентами. Защищайте объекты с помощью шифрования на стороне сервера (SSE-S3, SSE-KMS через

undefined

с параметром

undefined

или принудительно установив шифрование по умолчанию для бакета с помощью

undefined

), требуйте использования TLS через условие

undefined

в политиках бакета и блокируйте случайный публичный доступ с помощью S3 Block Public Access и явных запретов (deny) в политиках бакета. Распространённые ошибки включают приоритет явных запретов IAM над разрешениями роли, наследование предварительно подписанными URL привилегий подписавшего их субъекта (при этом они по-прежнему подчиняются политикам бакета и политикам VPC-эндпоинтов), а также неверные настройки CORS при загрузке напрямую из браузера (настраивается через

undefined

). Используйте правила жизненного цикла (

undefined

) для перемещения объектов в Intelligent-Tiering, GLACIER или для удаления неактуальных версий, и обязательно включите версионирование (

undefined

) перед тем, как полагаться на правила для неактуальных версий. Для аудита и восстановления включите журналы доступа к серверу S3 (server access logs) или используйте S3 Access Points, а для обеспечения неизменяемого хранения применяйте Object Lock в режиме хранения (retention mode). При проектировании архитектуры учитывайте согласованность в конечном счёте для перезаписывающих PUT-запросов (чтение после записи гарантировано для PUT новых объектов, но обновления существующих ключей могут демонстрировать согласованность в конечном счёте в пограничных сценариях).

Продвинутые возможности S3: Object Lambda, потоки с presigned URL, политики и нюансы жизненного цикла

S3 Object Lambda позволяет преобразовывать ответы

undefined

, прикрепляя функцию Lambda к точке доступа S3 Object Lambda Access Point; Lambda получает

undefined

и должна вызвать

undefined

(через S3 Object Lambda/Control API), чтобы вернуть преобразованные байты. Типичные сценарии использования — это изменение размера изображений, редактирование (удаление конфиденциальных данных) или преобразование формата «на лету» без дублирования объектов. Для загрузок из браузера генерируйте предварительно подписанные POST-запросы (

undefined

в SDK) с ограниченной политикой (например,

undefined

, префикс ключа), чтобы избежать злоупотреблений. Политики бакета и политики эндпоинтов VPC (Gateway/Interface) являются мощным инструментом для ограничения доступа: предпочитайте явное разрешение (allow) с условиями для ресурса (например,

undefined

, и с осторожностью

undefined

) и избегайте открытых принципалов с использованием wildcard (*). К подводным камням правил жизненного цикла относятся переходы для версионированных бакетов — явно настраивайте

undefined

и

undefined

— и правило

undefined

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

undefined

или используйте

undefined

, чтобы отклонять запросы, не использующие TLS. Для обеспечения соответствия требованиям по неизменяемости данных включайте Object Lock перед загрузкой объектов. Когда требуется программное принудительное применение правил, комбинируйте события S3 (через SNS, EventBridge) с Lambda для применения тегов или выполнения проверки после загрузки.

CloudFront, стратегии кэширования и пограничные вычисления (Lambda@Edge vs CloudFront Functions)

CloudFront ускоряет глобальную доставку контента и защищает источники (origins). Для источников S3 предпочитайте Origin Access Control (OAC) с подписью Sigv4 вместо устаревшего Origin Access Identity, чтобы подписывать запросы к источнику и запрещать прямой публичный доступ к S3. Настройка поведения кэша (Cache behavior) включает использование заголовков Cache-Control/Expires, пересылку заголовка Authorization и формирование ключей кэша на основе строк запроса/cookie; отдавайте предпочтение белому списку для ключа кэша (cache key whitelisting) или политикам Cache Policy и Origin Request Policy для уменьшения фрагментации кэша. Для частного контента используйте подписанные URL-адреса (signed URLs) или подписанные cookie-файлы (signed cookies) CloudFront (создаются через

undefined

или вспомогательные функции SDK). Используйте CloudFront Functions для легковесных манипуляций с субмиллисекундной задержкой (на этапах viewer request/response) и Lambda@Edge для более сложной логики, требующей сред выполнения Node/Python и срабатывающей на этапах origin-request или origin-response; помните, что функции Lambda@Edge развёртываются из региона us-east-1, подвержены холодным стартам и имеют задержку региональной репликации. Инвалидация кэша влечёт за собой затраты и задержки — предпочитайте версионирование ключей объектов (развёртывание файлов с новыми именами или добавление версии в строку запроса), чтобы избежать инвалидаций. Инструментируйте CloudFront с помощью логов реального времени и метрик CloudWatch для обнаружения аномалий почти в реальном времени и запускайте Lambda для автоматического реагирования. Распространённые ошибки включают пересылку слишком большого количества заголовков/cookie, что нарушает кэширование, и предположение о мгновенном распространении инвалидации.

Общие файловые системы: критерии выбора EFS и FSx, монтирование и подводные камни

Выбирайте EFS для POSIX-совместимых файловых систем NFSv4.1, одновременно монтируемых на нескольких Linux-клиентах; выбирайте варианты FSx, когда вам нужны функции SMB/Windows или высокопроизводительная система Lustre. EFS поддерживает шифрование неактивных данных (at rest) через KMS, шифрование при передаче (in transit) с помощью опции монтирования TLS и точки доступа для сопоставления UID/GID для каждого приложения. Монтируйте с помощью amazon-efs-utils (mount -t efs -o tls,accesspoint=fsap-0123456789 fs-12345678:/ /mnt) или клиента NFS для рабочих нагрузок с высокой пропускной способностью. Выбирайте режим производительности generalPurpose или maxIO и режим пропускной способности bursting или provisioned в зависимости от характера нагрузки по пропускной способности/IOPS. FSx for Windows интегрируется с Active Directory и предоставляет SMB-ресурсы с NTFS ACL, пространствами имен DFS и нативной семантикой Windows — монтируйте с помощью net use \\fs-xxxx\share или через клиенты EC2 Windows; распространенные проблемы включают сложность присоединения к AD и разрешение имен DNS. FSx for Lustre идеально подходит для высокопроизводительных вычислений и может быть прозрачно связан с S3 через задачи репозитория данных для импорта/экспорта наборов данных. Сетевые нюансы: откройте порты NFS/SMB в группах безопасности, используйте цели монтирования (mount targets) в каждой AZ для EFS и убедитесь, что политики IAM не могут использоваться для ограничения доступа на уровне NFS — точки принудительного применения это POSIX-разрешения и группы безопасности. Для резервного копирования предпочитайте автоматизированные снимки (EFS Backup, снимки FSx) и регулярно тестируйте восстановление.

Практическая задача: сценарий использования

Сценарий: AcmeAnalytics использует статическую панель мониторинга для клиентов, размещенную в бакете S3 и распространяемую по всему миру через дистрибуцию CloudFront. Инженерной команде необходимо предоставлять доступ к частным файлам данных, выполнять преобразование CSV в JSON на лету для некоторых объектов и обеспечивать, чтобы новые сборки панели мониторинга инвалидировали кэш с минимальными затратами.

Задача: Реализовать безопасную доставку частных объектов, динамическое преобразование без дублирования хранилища и низкозатратную стратегию обновления кэша.

Рекомендуемый подход:

1. Создайте бакет S3 с PutBucketEncryption (SSE-KMS) и PutBucketPolicy, чтобы запретить доступ без TLS и разрешить его только от CloudFront Origin Access Control (создайте OAC и прикрепите к дистрибуции); используйте PutBucketVersioning для включения версионирования.
2. Настройте S3 Object Lambda Access Point; реализуйте Lambda-функцию, которая обрабатывает GetObjectContext, извлекает оригинал через S3 GetObject, преобразует CSV в JSON в памяти и возвращает результат с помощью s3control.write_get_object_response.
3. Настройте поведения кэша CloudFront: направляйте запросы /private/* на S3 Object Lambda Access Point (в качестве origin), установите политику кэширования (Cache Policy), которая кэширует на основе заголовка Accept, если необходимо, и включите минимальные TTL; для ресурсов панели мониторинга используйте версионированные имена файлов, чтобы избежать инвалидаций.
4. Для редких, но необходимых инвалидаций, вызывайте cloudfront.create_invalidation(DistributionId=..., InvalidationBatch={...}) из CI после развертывания; в остальных случаях, при рутинных изменениях, загружайте ресурсы с хэшем содержимого в имени файла, чтобы обойти затраты на инвалидацию.

Обоснование: Ограничение доступа к S3 только для CloudFront через OAC и принудительное использование SSE-KMS обеспечивает безопасность данных при передаче и в состоянии покоя. S3 Object Lambda обеспечивает преобразование на лету без дублирования объектов, а использование версионирования объектов или имен файлов с хэшем содержимого позволяет избежать дорогостоящих инвалидаций, сохраняя при этом эффективность кэширования.

← Мониторинг · Все домены · Базы данных и кеширование (RDS →

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

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