Amazon SAP-C02: Хранение и управление данными — Руководство по подготовке

By Laurynas Brazys · 31 July 2026 · #amazon #sap-c02 #certification #exam-prep #study-guide

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

Объектное хранилище, жизненный цикл и распределение по уровням (Amazon S3 и сопутствующие сервисы)

Amazon S3 — это основа для долговечного и высокодоступного объектного хранилища, которую следует рассматривать как каноническое, долгосрочное хранилище для неструктурированных данных. Решения по проектированию сосредоточены на выборе класса хранения, правилах жизненного цикла, семантике согласованности и управлении данными. Выбирайте S3 Standard для часто используемых объектов, Intelligent-Tiering, когда шаблоны доступа неизвестны, Standard-IA или One Zone-IA для нечастого доступа и Glacier/Deep Archive для длительного хранения с более высокой задержкой восстановления. Внедряйте политики жизненного цикла на основе тегов или префиксов для автоматического перемещения объектов и удаления старых версий; включайте версионирование до настройки жизненного цикла или репликации, чтобы объекты не были случайно удалены безвозвратно. Используйте Cross-Region Replication (CRR) для географической долговечности и соответствия регуляторным требованиям к размещению данных, или Same-Region Replication (SRR) для соблюдения нормативных требований и разделения обязанностей. Защищайте критически важные архивы с помощью S3 Object Lock в режиме управления (governance) или соответствия (compliance) и включайте MFA Delete там, где это необходимо. Распространенные ошибки включают слишком агрессивные переходы в жизненном цикле, которые влекут за собой плату за восстановление и задержки от минут до часов, неучет стоимости или времени извлечения из Glacier, а также использование публичных эндпоинтов вместо эндпоинтов VPC Gateway/Interface (что может сделать данные доступными в публичном интернете или повлечь расходы на исходящий трафик NAT). Сбалансируйте стоимость с задержкой извлечения и долговечностью: агрессивно распределяйте по уровням холодные данные, но обеспечивайте ускорение (CloudFront, S3 Transfer Acceleration, многочастные загрузки) для горячего входящего трафика и доступа с низкой задержкой там, где это необходимо.

Общие файловые системы и высокопроизводительное хранилище (EFS, FSx)

Выбирайте общие файловые системы, когда приложениям требуется семантика POSIX, низкая задержка или семантика SMB. Amazon EFS предоставляет эластичную файловую систему NFS с долговечностью в нескольких зонах доступности (multi-AZ) и согласованностью POSIX, подходящую для веб-контента, домашних каталогов и многих HPC-нагрузок, которые допускают семантику сетевых файлов. EFS имеет два режима производительности (Bursting и Provisioned throughput) и переходы жизненного цикла в EFS Infrequent Access. Amazon FSx предлагает специализированные файловые системы: Windows File Server для интеграции с SMB/Active Directory и FSx for Lustre для задержек менее миллисекунды и высокой пропускной способности для тесно связанных HPC- и медиа-нагрузок; FSx for Lustre может прозрачно связываться с S3 для создания долговечного репозитория данных. Выбирайте FSx for Windows, когда вам нужна семантика NTFS, списки контроля доступа AD (AD ACLs), пространства имен DFS или инструменты только для Windows; выбирайте FSx for Lustre для рендер-ферм и обучения ML, требующих высоких показателей IOPS и пропускной способности. Распространенные операционные ошибки включают предположение, что EFS автоматически справится с нагрузками с большим количеством метаданных (может потребоваться режим Provisioned throughput), слишком широкое открытие портов NFS/SMB в группах безопасности и пренебрежение опциями монтирования и таймаутами клиента. Оценивайте компромиссы: FSx имеет более высокую стоимость, но и более высокую производительность и более богатые функции протоколов; EFS проще в масштабировании и обеспечивает долговечность в нескольких зонах доступности. Сопоставляйте шаблоны ввода-вывода, параллелизм и потребности в пропускной способности рабочей нагрузки с выбранной системой и при необходимости настраивайте пропускную способность отдельно.

Гибридные и офлайн-сценарии передачи данных (Storage Gateway, DataSync, семейство Snow)

Гибридные архитектуры обычно требуют локального кэширования с низкой задержкой, бесшовного резервного копирования в облако или массовой миграции данных. AWS Storage Gateway предлагает три сценария: File Gateway предоставляет доступ к S3 как к NFS/SMB, чтобы локальные приложения могли записывать данные в S3; Volume Gateway предоставляет блочные тома для аварийного восстановления (DR); Tape Gateway заменяет физические ленты. AWS DataSync автоматизирует онлайн-перемещение данных (инкрементальное и параллельное) между локальной средой и AWS (S3, EFS, FSx) со встроенными средствами фильтрации, планирования и контроля пропускной способности; при соответствующей настройке он сохраняет метаданные POSIX. Для офлайн-передачи и очень больших объемов данных семейство Snow предлагает периферийные и транспортные устройства, включающие вычислительные мощности: Snowcone для небольших удаленных площадок, Snowball Edge для десятков и сотен ТБ с возможностью запуска Lambda/EC2 на устройстве и Snowmobile для импорта данных экзабайтного масштаба. Используйте DataSync для постоянных, автоматизированных передач данных, а Storage Gateway File Gateway — когда устаревшим приложениям необходимо видеть локальные точки монтирования NFS/SMB, при этом сохраняя данные в S3. Распространенные ошибки включают использование неправильного режима шлюза (cached или stored), недостаточное планирование пропускной способности сети, что приводит к длительным миграциям, пренебрежение ролями IAM и политиками эндпоинтов для безопасной передачи, а также недооценку времени загрузки/выгрузки данных с устройств Snow. Выбирайте DataSync для частых инкрементальных синхронизаций, Storage Gateway для совместимости с локальными протоколами и устройства Snow для массовых или удаленных передач данных, когда пропускная способность сети недостаточна.

Резервное копирование, репликация, контроль доступа и операционное управление

Выбор стратегии резервного копирования и репликации должен определяться целевыми показателями RTO/RPO, нормативными требованиями и стоимостью. Используйте AWS Backup для централизации политик резервного копирования для EBS, RDS, DynamoDB, EFS и FSx, а также настройте переходы жизненного цикла из теплого хранилища (warm vault) в холодное (cold storage) для экономии средств. Для баз данных предпочтительнее использовать нативные механизмы (снимки RDS, реплики чтения или DMS для гетерогенных миграций) в сочетании с межрегиональным копированием снимков и репликацией ключей KMS или отдельными политиками ключей. Для S3 включите версионирование, CRR/SRR и рассмотрите возможность использования Replication Time Control (RTC), когда требуется SLA на репликацию почти в реальном времени. Безопасные шаблоны доступа основаны на принципе наименьших привилегий в IAM, политиках бакетов, S3 Block Public Access, эндпоинтах шлюза/интерфейса VPC (VPC Gateway/Interface endpoints) с политиками эндпоинтов, а также KMS с гранулярными разрешениями (grants) для межаккаунтного доступа и копирования снимков. Выполняйте мониторинг с помощью CloudTrail, журналов доступа S3, метрик CloudWatch, правил AWS Config, а также используйте GuardDuty и Access Analyzer для обнаружения угроз и неправильных конфигураций IAM. Типичные ошибки включают отсутствие репликации или предоставления доступа к ключам KMS CMK между аккаунтами, оставление снимков незашифрованными или общедоступными, а также отказ от принудительного использования тегов или размещения ресурсов с помощью SCP и Tag Policies, что усложняет распределение затрат и восстановление. Принимайте решение на основе требований к отказоустойчивости: мультирегиональная конфигурация active-active для наименьшего RTO, pilot‑light/warm standby для экономичного аварийного восстановления (DR) и полное переключение (full failover) при необходимости минимального RTO.

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

Сценарий: Atlas Media управляет организацией AWS с несколькими аккаунтами, где производственная среда находится в us‑east‑1, а вторичный регион — в eu‑west‑1. У них есть локальный архив видеоматериалов объемом 150 ТБ, а художникам в Северной Америке и Европе требуется высокопроизводительное общее хранилище и безопасный доступ с низкой задержкой к текущим проектам.

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

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

1. Создать бакет S3 в us‑east‑1 в качестве канонического архива, включить версионирование, шифрование на стороне сервера с помощью AWS KMS (SSE‑KMS) и настроить межрегиональную репликацию (Cross‑Region Replication) в eu‑west‑1 с включенной репликацией маркеров удаления.
2. Использовать устройства AWS Snowball Edge (оптимизированные для хранения — storage‑optimized Snowball Edge) для импорта начальных 150 ТБ в S3, а затем запустить AWS DataSync для инкрементной синхронизации любых дельта-изменений и проверки целостности.
3. Для активных рабочих наборов данных развернуть Amazon FSx for Lustre в каждом регионе и связать файловую систему с бакетом S3 (интеграция с репозиторием данных — Data Repository Integration), чтобы художники получили высокую пропускную способность и низкую задержку, в то время как операции записи синхронизируются обратно в S3; рассмотреть возможность использования короткоживущих экземпляров FSx для пиковых нагрузок по проектам.
4. Обеспечить безопасный доступ с помощью VPC Interface Endpoints для S3 и FSx, ограничить доступ к бакету с помощью IAM-ролей и политик бакета, привязанных к принципалам организации, организовать публичную дистрибуцию через CloudFront и подписанные URL-адреса (signed URLs) для удаленных рецензентов, а также включить AWS Backup для FSx, межрегиональную репликацию S3 и правила жизненного цикла для перемещения холодных данных в Glacier Deep Archive.

Обоснование: Этот подход разделяет долговечное и недорогое архивное хранилище (S3 + Glacier) от производительного хранилища для проектов (FSx Lustre, связанный с S3), использует Snowball и DataSync для оптимизации начальной массовой загрузки и последующих дельта-изменений, а также обеспечивает строгую безопасность и межрегиональную отказоустойчивость, сбалансировав при этом стоимость, производительность и цели восстановления.

← Вычисления и Auto Scaling · Все домены · Базы данных и аналитика →

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

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