Amazon SAA-C03: Передача и миграция данных — Руководство по подготовке

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

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

Пропускная способность или физическая доставка: как принять решение

Любая миграция начинается с арифметики. Прежде чем выбрать инструмент, рассчитайте теоретическое время передачи данных:

Transfer days = (Dataset size in bits) / (Usable bandwidth in bps × 86,400)
Usable bandwidth = Link speed × Allowed utilization %

Цифры неумолимы. При стабильной скорости 100 Мбит/с передача 1 ТБ занимает примерно 24 часа; при 1 Гбит/с — около 2,5 часов. Канал в 15 Мбит/с с загрузкой, ограниченной 70%, позволяет передать лишь ~113 ГБ в день, поэтому для 20 ТБ потребуется более 175 дней. Передача 150 ТБ за ночь (10 часов при 80% от 100 Мбит/с) даст ~360 ГБ за ночь, или 10,5 ТБ в месяц — что и близко не соответствует 30-дневному сроку. Даже при полной загрузке 24/7 канал в 100 Мбит/с позволяет передавать лишь ~1 ТБ/день, поэтому для 150 ТБ потребуется минимум 150 дней. В петабайтном масштабе картина ухудшается: канал в 500 Мбит/с с реальной эффективностью обеспечивает теоретическую пропускную способность около 5,4 ТБ/день. Это означает, что для 10 ПБ потребуется более пяти лет непрерывной передачи — дольше, чем занимает выделение большинства каналов Direct Connect.

Разумное практическое правило:

Самый распространенный неверный ответ в сценариях миграции — выбор передачи по WAN, которая математически не может завершиться в установленные сроки. Связанная с этим ловушка — «мы просто будем запускать передачу по WAN каждую ночь» — не просто медленнее. Это потребляет рабочую пропускную способность, создает риск частичной или поврежденной передачи, требующей повторной загрузки, и обычно обходится дороже, если учесть плату за трафик и время инженеров. Плата за устройство Snowball и его доставку — это фиксированная, предсказуемая статья расходов.

Семейство Snow для офлайн-передачи больших объемов данных

Устройства Snowball Edge поставляются в двух вариантах:

Snowcone — это устройство малого форм-фактора (~8 ТБ SSD), защищенное и пригодное для курьерской доставки, полезное для площадок с ограниченным пространством и с предустановленными агентами DataSync для периферийной синхронизации. Snowmobile — 45-футовый контейнер, перевозящий до 100 ПБ — предназначался для эвакуации дата-центров экзабайтного масштаба, но в большинстве регионов был выведен из эксплуатации в пользу параллельного использования парка устройств Snowball Edge. Выбор Snowmobile для объемов менее петабайта — это заведомо неверный вариант.

Вариант Compute — это не просто накопитель большего объема. Он локально запускает AMI EC2, функции Lambda и рабочие нагрузки Greengrass, что делает его правильным выбором, когда данные необходимо преобразовать, отфильтровать или удалить из них персональную информацию (PII) перед загрузкой; когда рабочая нагрузка должна немедленно возобновиться в AWS после загрузки; или когда площадка отключена от сети или имеет прерывистое подключение (корабли, удаленная добыча полезных ископаемых, тактические развертывания, удаленные исследования). Выбирайте Compute Optimized, когда требуется обработка на самом устройстве; выбирайте Storage Optimized, когда задача сводится к простому копированию больших объемов данных.

Каждое устройство Snow выполняет 256-битное шифрование хранимых данных (at rest) с помощью ключей KMS, которые никогда не покидают AWS. Корпуса защищены от вскрытия, имеют транспортную этикетку на основе E Ink и аппаратный модуль Trusted Platform Module. Данные на устройство записываются с помощью клиента Snowball, S3-совместимой конечной точки или через NFS-подключение; TLS защищает данные при передаче (in transit) во время загрузки и обмена транспортными манифестами. По возвращении содержимое загружается в S3, а данные на устройстве криптографически стираются в соответствии со стандартом NIST 800-88.

Для задач с петабайтными объемами на одной площадке стандартным подходом является распараллеливание. Офису с каналом 1–2 Гбит/с все равно потребуются месяцы непрерывной полной загрузки для передачи 1 ПБ по сети; парк из ~13 устройств Storage Optimized на площадку (каждое по 80 ТБ), отправленных параллельно, позволяет уложиться в четырехнедельный срок, не занимая интернет-канал офиса. Для задачи по передаче 600 ТБ за две недели по загруженному каналу в 100 Мбит/с единственно верным решением является использование небольшого парка устройств в параллельном режиме. Даже если не учитывать стоимость, законы физики делают невозможным использование DataSync или нового подключения Direct Connect.

DataSync для онлайн-, инкрементальной передачи данных с проверкой целостности

DataSync — это подходящий инструмент, когда пропускной способности достаточно, но характеристики рабочей нагрузки — миллионы мелких файлов, глубокие деревья каталогов, постоянные инкрементальные синхронизации или миграция между файловыми системами — могут парализовать работу простых утилит. Копирование каталога с 20 миллионами файлов по 4 КБ с помощью aws s3 cp упирается в задержку кругового пути (round-trip latency), а не в пропускную способность; каждый вызов PutObject влечет за собой полный цикл TLS/HTTP и плату за API-запрос. Объединение в архивы работает, но лишает возможности обращаться к отдельным файлам. Агент DataSync распараллеливает передачу по множеству TCP-потоков, нативно обрабатывает метаданные, проверяет контрольную сумму каждого файла от начала до конца с помощью SHA-256, прозрачно выполняет повторные попытки и отправляет отчеты в CloudWatch, достигая скорости до ~10 Гбит/с на одного агента с предсказуемой ценой за гигабайт.

Источники и назначения охватывают NFS, SMB, HDFS, самоуправляемые объектные хранилища, S3, EFS, FSx for Windows File Server, FSx for Lustre, FSx for OpenZFS и FSx for NetApp ONTAP. При передаче используется TLS 1.2, и трафик может проходить через интерфейсные эндпоинты VPC, чтобы не выходить в публичный интернет.

Критически важная деталь: для локальных (on-premises) источников NFS/SMB DataSync требует установки агента. Агент запускается как виртуальная машина на VMware, Hyper-V или KVM, на инстансе EC2 или на устройстве Snowcone. Считать, что DataSync не требует агента для локальной инфраструктуры — распространенная ошибка. Он работает без агента только тогда, когда обе конечные точки являются нативными сервисами AWS.

Минимальное развертывание:

# Activate the on-prem agent
aws datasync create-agent \
  --activation-key ABCDE-12345-FGHIJ-67890-KLMNO \
  --agent-name onprem-nfs-agent \
  --vpc-endpoint-id vpce-0a1b2c3d

# Define source (NFS) and destination (S3)
aws datasync create-location-nfs \
  --server-hostname 10.0.5.20 \
  --subdirectory /export/video \
  --on-prem-config AgentArns=arn:aws:datasync:...:agent/agent-0abc

aws datasync create-location-s3 \
  --s3-bucket-arn arn:aws:s3:::video-archive \
  --s3-config BucketAccessRoleArn=arn:aws:iam::111122223333:role/DataSyncS3Role

# Task with bandwidth cap, verification, and a nightly schedule
aws datasync create-task \
  --source-location-arn <nfs-arn> \
  --destination-location-arn <s3-arn> \
  --options VerifyMode=POINT_IN_TIME_CONSISTENT,BytesPerSecond=104857600,PreserveDeletedFiles=PRESERVE,PosixPermissions=PRESERVE \
  --schedule ScheduleExpression="cron(0 2 * * ? *)"

Важны две операционные функции. Ограничение пропускной способности (BytesPerSecond) предотвращает перегрузку общего канала связи — это прямой ответ на сценарии вроде «канал 1 Гбит/с используется совместно с другими отделами». Фильтрация и планирование позволяют выполнять синхронизацию в нерабочее время и исключать временные файлы. При использовании Direct Connect на 10 Гбит/с, когда пользователи продолжают чтение и запись, каноническим шаблоном является планирование повторяющихся задач: начальный проход переносит основной объем данных, последующие инкрементальные запуски захватывают изменения (дельты), и перенос 700 ТБ может быть выполнен значительно меньше чем за неделю даже при частичной утилизации канала.

Более тонкая ловушка связана с точностью сохранения метаданных. DataSync сохраняет определенный набор атрибутов POSIX или SMB — UID/GID/mode/timestamps для NFS, права владения и DACL для SMB — но он не захватывает все проприетарные атрибуты NAS. Специфичные для вендора ACL, расширенные атрибуты, выходящие за рамки протокола, снэпшоты и метаданные дедупликации остаются за пределами его возможностей. Когда требования соответствия (compliance) предписывают создание точной реплики NAS, включая функции вендора, одного DataSync недостаточно; требуется решение, совместимое с NetApp, такое как FSx for ONTAP со SnapMirror, или миграция lift-and-shift через Storage Gateway.

DataSync также дополняет Snowball: Snowball переносит начальные 150 ТБ, а DataSync затем обрабатывает еженедельные инкрементальные изменения рабочего набора данных объемом 500 ГБ.

Storage Gateway: гибридное представление данных, а не миграция

Storage Gateway — это не инструмент миграции, а уровень гибридного представления данных. Локальные приложения продолжают взаимодействовать по протоколам NFS, SMB, iSCSI или iSCSI-VTL, в то время как данные попадают в S3, S3 Glacier или в виде снэпшотов EBS. Путаница между Storage Gateway и DataSync — частая ошибка: File Gateway не предназначен для быстрой передачи 70 ТБ, а DataSync не предоставляет постоянный файловый ресурс (share) для локальных клиентов.

File Gateway — это «рабочая лошадка». Запись файла \\gateway\share\reports\2024\report.pdf создает объект s3://bucket/reports/2024/report.pdf, который можно нативно использовать в Athena, Lambda, EMR или любом другом S3-клиенте. Это сопоставление «один файл — один объект» является серьезным преимуществом по сравнению с целевыми хранилищами резервных копий типа «черный ящик». Локальное кэширование означает, что «горячие» файлы доступны со скоростью локальной сети; «холодные» файлы подгружаются из S3 по запросу.

Кэш — это ключевой элемент устройства. Чтение «горячих» данных обслуживается локально; запись сначала происходит на локальный диск и асинхронно выгружается в облако. Распространенная ошибка проектирования — предполагать, что хранение данных в S3 означает задержку интернет-канала при каждом чтении. Это не так, если рабочий набор данных помещается в кэш. И наоборот, недостаточный размер кэша приводит к постоянным промахам кэша (cache misses), и рабочая нагрузка кажется «медленной». Эмпирическое правило: размер кэша = 20% от общего объема данных или 100% от «горячего» рабочего набора, в зависимости от того, что больше.

Ловушка «режим кэширования против режима хранения» заслуживает особого внимания. В режиме кэширования (Cached) основная копия хранится в S3, а «горячие» блоки — локально. Это дешево, эластично, но промах кэша означает полный цикл обмена данными через WAN. В режиме хранения (Stored) основная копия хранится на локальном диске с асинхронным созданием снэпшотов в S3 (в виде снэпшотов EBS). Каждое чтение является локальным и с низкой задержкой, но весь набор данных должен помещаться в локальной инфраструктуре. Для требования по замене системы резервного копирования «локальный доступ ко всем данным, пока они копируются в AWS», правильным выбором будет режим Stored; режим Cached нарушит это требование. Выбор режима Cached для рабочей нагрузки, которой требуется доступ ко всему набору данных с низкой задержкой, сводит на нет всю идею; выбор режима Stored, когда на площадке невозможно разместить полный набор данных, невозможен по определению.

Tape Gateway отвечает на очень специфический запрос: вывод из эксплуатации физической ленточной библиотеки с сохранением существующих рабочих процессов Veeam, NetBackup или Commvault путем предоставления виртуальной ленточной библиотеки (VTL) по протоколу iSCSI, при этом данные перемещаются по жизненному циклу из S3 в Glacier или Deep Archive. Этот шлюз незаменим, когда нормативные требования к хранению данных определены в терминах ленточных носителей, а существующее ПО для резервного копирования изменить нельзя.

AWS Transfer Family

Transfer Family предоставляет полностью управляемые конечные точки SFTP, FTPS, FTP и AS2, использующие S3 или EFS в качестве хранилища. Основное преимущество — сохранение существующих протокольных контрактов с партнерами: системы поставщиков, которые отправляют файлы только по SFTP, продолжают работать без изменений, в то время как принимающей стороной становится нативный S3 — с политиками жизненного цикла, триггерами Lambda и интеграцией с аналитическими сервисами.

Ловушка здесь — предполагать, что устаревший поставщик может «просто перейти на API S3». Многие системы поставщиков — это аппаратные устройства, потоки данных HL7 из больниц, банковские системы пакетной обработки или B2B-конвейеры EDI, SFTP-клиент которых встроен в прошивку или подписанные бинарные файлы. Затраты на управление изменениями, аудит безопасности и повторную сертификацию при их модификации часто превышают стоимость всей миграции в AWS. Transfer Family полностью обходит эту проблему. Поддержка AS2 дополнительно позволяет работать с нагрузками EDI, используя уведомления о доставке (MDN), подписание и шифрование сообщений для соответствия требованиям B2B.

Аутентификация поддерживает пользователей, управляемых сервисом, AWS Directory Service (Managed Microsoft AD или AD Connector для локального AD) или кастомного поставщика удостоверений через API Gateway/Lambda, позволяя использовать существующие корпоративные учетные данные в качестве источника истины. Авторизатор Lambda может возвращать IAM-роли для каждого пользователя, сопоставления домашних каталогов и сессионные политики, обеспечивая изоляцию для каждого поставщика без создания отдельной инфраструктуры для каждого из них.

Type: AWS::Transfer::Server
Properties:
  Protocols: [SFTP]
  IdentityProviderType: AWS_DIRECTORY_SERVICE
  IdentityProviderDetails:
    DirectoryId: d-9067f4a1c2
  Domain: S3
  EndpointType: VPC
  EndpointDetails:
    VpcId: vpc-0abc123
    SubnetIds: [subnet-0a, subnet-0b]
    SecurityGroupIds: [sg-0sftp]

Amazon AppFlow

AppFlow — это управляемый интеграционный слой для перемещения данных из SaaS в AWS: Salesforce, ServiceNow, Google Analytics, Slack, Marketo, SAP OData, Zendesk и десятков других с передачей в S3, Redshift или Snowflake. Он обрабатывает пагинацию, инкрементальное извлечение, сопоставление полей, фильтрацию, маскирование и валидацию без необходимости создавать ETL-процесс вручную.

Критически важная для безопасности функция — интеграция с PrivateLink для поддерживаемых коннекторов (в частности, Salesforce). Вместо выхода в публичный интернет для доступа к тенанту SaaS и возвращения в AWS, поток проходит через приватную конечную точку VPC, устраняя передачу извлекаемых данных через публичный интернет и упрощая аудит для нагрузок, связанных со здравоохранением, финансами и персональными данными (PII). Потоки можно запускать по расписанию, по событию изменения записи в SaaS или по требованию; они поддерживают до 100 ГБ данных за один запуск.

AppFlow работает на более высоком уровне, чем DataSync или Storage Gateway: это подходящий инструмент, когда источником является SaaS-платформа с API, а не файловая система или база данных.

Миграция баз данных: DMS и SCT

AWS Database Migration Service реплицирует данные между исходной и целевой базами данных, пока исходная база остается в полностью рабочем состоянии. Он поддерживает гомогенные (MySQL → RDS MySQL, Oracle → RDS Oracle) и гетерогенные (Oracle → Aurora PostgreSQL, SQL Server → MySQL) миграции, а в качестве целевых систем могут выступать не только RDS, но и Aurora, Redshift, S3, DynamoDB и Kinesis. Источниками могут быть Oracle, SQL Server, MySQL, PostgreSQL, MongoDB и Db2.

Задача работает в одном из трех режимов:

Движущей силой переключения с минимальным простоем является Change Data Capture (захват измененных данных). Во время полной загрузки с CDC, DMS массово копирует существующие строки, одновременно анализируя журнал транзакций источника — redo log в Oracle, binlog в MySQL, MS-CDC или MS-Replication в SQL Server. После завершения полной загрузки CDC применяет изменения из очереди и поддерживает целевую базу в актуальном состоянии до момента переключения приложения. Не включить CDC, когда приложение должно оставаться доступным для записи, — распространенная архитектурная ошибка: режим только полной загрузки делает целевую базу устаревшей сразу после завершения.

{
  "MigrationType": "full-load-and-cdc",
  "ReplicationTaskSettings": {
    "TargetMetadata": { "ParallelLoadThreads": 8 },
    "ChangeProcessingTuning": { "BatchApplyEnabled": true }
  }
}

Для гетерогенных миграций AWS Schema Conversion Tool (или его облачный аналог DMS Schema Conversion) преобразует DDL, хранимые процедуры, представления и функции, помечая элементы, требующие ручной доработки. DMS перемещает данные; SCT преобразует схему. Игнорирование отчета об оценке SCT — верный способ провалить миграцию за три дня до переключения.

Специфичные для движков баз данных предварительные требования и ограничения могут создать серьезные проблемы, если их игнорировать. Для LOB-объектов Oracle размером более 64 КБ требуется режим ограниченной обработки LOB (limited LOB mode) с фиксированным максимумом; для LONG RAW есть свои нюансы. Для PostgreSQL требуется wal_level=logical и роль для репликации. Для MySQL требуется бинарный лог в формате ROW с достаточным значением binlog_row_image и расширенными привилегиями для CDC (REPLICATION CLIENT, REPLICATION SLAVE). Oracle Spatial, специфичное для RAC поведение и сборки CLR в SQL Server обычно не поддерживаются. Между экземпляром репликации и конечными точками принудительно используется TLS с режимами SSL require, verify-ca или verify-full.

DMS Serverless — правильный выбор, когда профиль нагрузки непредсказуем или имеет пиковый характер — например, для локальной системы Oracle с пиками нагрузки днем и затишьем ночью. Вы определяете MinCapacityUnits и MaxCapacityUnits в единицах DCU (DMS Capacity Units), и DMS масштабирует мощность репликации в зависимости от нагрузки на CPU и память:

ReplicationConfigIdentifier: oracle-to-rds-cdc
ReplicationType: full-load-and-cdc
SourceEndpointArn: arn:aws:dms:...:endpoint:oracle-onprem
TargetEndpointArn:  arn:aws:dms:...:endpoint:rds-oracle
ComputeConfig:
  MinCapacityUnits: 4
  MaxCapacityUnits: 64
  MultiAZ: true

Частая ловушка — предполагать, что подготовленный (provisioned) экземпляр DMS (например, dms.c5.4xlarge) будет автоматически масштабироваться. Этого не произойдет — подготовленные экземпляры являются хостами EC2 фиксированного размера. Если пропускная способность превышает мощность, отставание репликации (replication lag) растет, и вам придется вручную изменять класс экземпляра, перезапуская задачи. Подготовленный DMS подходит для миграций со стабильной, известной пропускной способностью; Serverless — для непредсказуемых.

Для миграции 20 ТБ MySQL с окном в две недели и жесткими требованиями к простою, DMS с полной загрузкой и CDC в Aurora MySQL или RDS MySQL является наиболее экономически эффективным решением. Восстановление с помощью нативных утилит mysqldump/mysqlpump приводит к неприемлемому простою; Snowball добавляет задержки на доставку и периоды офлайна.

DMS Fleet Advisor обнаруживает инвентарь локальных баз данных, что полезно для планирования миграции по этапам (wave planning).

Миграция серверов: AWS Application Migration Service (MGN)

AWS Application Migration Service — это основной сервис для миграции по типу lift-and-shift («рехостинг»), который в большинстве сценариев заменил CloudEndure Migration и Server Migration Service. MGN устанавливает легковесный AWS Replication Agent на каждый исходный сервер (физический, VMware, Hyper-V или в другом облаке). Агент выполняет первоначальный снимок на блочном уровне в недорогую промежуточную (staging) область в целевом VPC — небольшие инстансы T3 с подключенными томами EBS — а затем постоянно и асинхронно реплицирует изменения на блочном уровне. Поскольку репликация является непрерывной и происходит на блочном уровне, переключение занимает считанные минуты: в момент переключения MGN преобразует промежуточные тома в рабочие инстансы EC2 целевого типа.

1. Install replication agent on each source (or use agentless for vCenter)
2. Configure launch template (instance type, subnet, IAM role, tags)
3. Run "Test" launches → validate → "Cutover" launch → decommission source

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

Неправильный подход — это ручной экспорт ВМ в формат OVF, загрузка через aws ec2 import-image и переустановка приложений на свежесозданных инстансах EC2. Это медленно, чревато ошибками, требует простоя для каждой ВМ на время экспорта, не обеспечивает дельта-репликацию и не предлагает возможности для тестирования без прерывания работы. MGN устраняет все эти недостатки — исходный сервер продолжает работать до последней секунды перед финальным переключением, а расхождение между источником и целевой системой практически равно нулю.

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

Гибридное подключение: Direct Connect и VPN

AWS Direct Connect предоставляет выделенный канал второго уровня (L2) от локального маршрутизатора до точки подключения Direct Connect, предлагая стабильную пропускную способность (1, 10, 100 Гбит/с выделенные; до 1 Гбит/с через партнерские hosted connections) и предсказуемую задержку. Виртуальные интерфейсы (VIF) разделяют канал:

• Private VIF — доступ к одному VPC через Virtual Private Gateway.
• Transit VIF — доступ ко многим VPC через Direct Connect Gateway, подключенный к Transit Gateway. Это канонический паттерн для крупных сред с множеством VPC и площадок.
• Public VIF — доступ к публичным конечным точкам сервисов AWS (S3, DynamoDB) без использования интернета.

Сам по себе DX не является высокодоступным: один канал в одной точке подключения DX зависит от одного оптоволоконного пути. Важны два паттерна обеспечения отказоустойчивости:

1. DX + резервный Site-to-Site VPN через интернет — это минимально жизнеспособный вариант для обеспечения высокой доступности. BGP управляет автоматическим переключением при сбое с помощью AS-path prepending, MED или local-pref, чтобы в штатном режиме предпочтение отдавалось DX.
2. Два канала DX в разных точках подключения DX — это паттерн максимальной отказоустойчивости для критически важных рабочих нагрузок, который также является требованием для SLA на DX.

Отсутствие какого-либо резервного пути — это хорошо известная ловушка: когда DX выходит из строя, а VPN-подключения нет, гибридные приложения, задания DataSync и выгрузки через Storage Gateway останавливаются на все время ремонта у оператора связи. Использование только VPN приемлемо для нагрузок с невысокими требованиями к пропускной способности или в качестве временного решения, пока настраивается DX, что может занять недели.

On-prem Router ──── DX (primary, BGP MED=100) ────┐
                                                   ├── VGW/DXGW ── VPC
On-prem Router ──── VPN over Internet (backup) ────┘

# Multi-VPC access via DX Gateway
DirectConnectGateway:
  Associations:
    - TransitGateway: tgw-corp
    - VirtualPrivateGateway: vgw-prod-vpc
  AllowedPrefixes:
    - 10.0.0.0/8

Если требуется шифрование на физическом уровне, выбирайте подключение DX с поддержкой MACsec. Комбинация DX для пропускной способности, DataSync для оркестрации и Storage Gateway для сохранения локального доступа является каноническим гибридным паттерном для больших, активно используемых наборов данных, которые не допускают окна простоя.

AWS Outposts для локальной инфраструктуры AWS

Outposts расширяет инфраструктуру AWS на площадку клиента в виде полностью управляемой стойки (или серверов Outposts 1U/2U). Он запускает определенный набор сервисов локально — EC2, EBS, ECS, EKS, RDS, S3 on Outposts, EMR — с теми же API, что и в родительском регионе. Управляющие операции (control-plane) передаются в родительский регион через service link по резервированным зашифрованным туннелям; сбой в WAN временно не позволяет запускать новые инстансы, но не останавливает уже запущенные рабочие нагрузки.

Разделение ответственности — это ловушка, в которую попадают инженеры. AWS поставляет и обслуживает оборудование, гипервизор и управляемые сервисы. Клиент несет ответственность за:

• Физическое пространство, электропитание, охлаждение и сетевое подключение, соответствующие спецификациям Outposts (резервные источники питания, вышестоящие коммутаторы, соответствующие блоки распределения питания).
• Физическую безопасность объекта.
• Конфигурацию локальной сети — Local Gateway (LGW) для локального трафика и исходящее подключение для service link.
• Вопросы, связанные с ОС и приложениями на рабочих нагрузках, точно так же, как и в регионе.
• Достаточную пропускную способность WAN-канала до родительского региона.

Outposts не устраняет операционную деятельность — он смещает уровень абстракции. Предполагать, что AWS несет ответственность за электропитание дата-центра или вышестоящую сеть, — это фундаментально неверное понимание. Также это не означает «запускать любой сервис AWS локально»: список поддерживаемых сервисов ограничен, а такие сервисы, как Route 53 или IAM, остаются в регионе.

Для модернизации Hadoop/Spark, где данные должны оставаться локально по нормативным требованиям, правильным паттерном является EMR on Outposts — управляемые, эластичные кластеры Spark с инструментами из региона и локальной резидентностью данных. Storage Gateway или DataSync не удовлетворяют требованию к резидентности; lift-and-shift в EMR в регионе нарушает требования соответствия.

Распространение контента на периферийные парки устройств

Когда серверы Outposts, розничные магазины или периферийные устройства многократно загружают одни и те же большие данные — например, ночной релиз ПО — загрузка напрямую из бакета S3 в одном регионе перегружает каналы связи и увеличивает время развертывания. Правильным шаблоном является CloudFront с источником в S3 и подписанными URL-адресами:

S3 bucket (ap-northeast-1)  ← Origin Access Control
        │
   CloudFront distribution (global edge PoPs)
        │
   Signed URLs (short expiry, per-server or per-release)
        │
   Edge devices download from nearest PoP

Первое устройство в регионе «прогревает» периферийный кэш; каждое последующее устройство загружает данные с задержкой, характерной для периферийной сети. Подписанные URL-адреса предотвращают несанкционированные загрузки без необходимости использовать IAM-учетные данные для каждого устройства, и при этом не нужно управлять парком региональных реплик.

Два антипаттерна, которых следует избегать: размещение релиза на одном веб-сервере EC2 (катастрофа с точки зрения масштабирования и задержек) и репликация бакета S3 в каждый регион с помощью Cross-Region Replication только для уменьшения задержки загрузки (ненужные затраты на хранение и операционная сложность, которую кэширование CloudFront решает бесплатно).

Итоговая таблица решений

← Хранилища и жизненный цикл данных · Все домены · Сети и подключения →

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

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