AWS → Azure: миграция EC2, RDS, S3 и EKS

Перенос AWS в Azure начинают с карты приложения: виртуальные машины EC2, базы RDS, объекты S3, контейнеры EKS, доступы и внешние интеграции требуют разных маршрутов. Поддерживаемые EC2 можно переносить через Azure Migrate как физические серверы. Остальные компоненты проверяют отдельно; безопасное переключение требует остановки записей, проверки данных и заранее подготовленного плана возврата.

Основная проверка технических источников выполнена 6 сентября 2026 года; дополнительные ограничения и сценарии возврата уточнены 8 сентября 2026 года. Перед реализацией сверяйте требования выбранных инструментов с актуальной документацией.

Что именно переносить из AWS и где заканчивается миграция серверов?

Рабочий комплект для миграции.

Скачать шаблон миграции в Excel

Ресурсы, зависимости, переключение и откат — три заполняемых листа, версия от 8 сентября 2026 года. Доступен без заявки.

Запишите владельцев, RPO/RTO, источники записи и условия возврата. После появления новых данных в Azure одного изменения DNS недостаточно: в плане предусмотрены обратная передача, сверка внешних действий или согласованный альтернативный способ восстановления.

Единицей планирования лучше сделать бизнес-сервис: личный кабинет, систему обработки заказов, внутренний портал. Список EC2 полезен для оценки ресурсов, но не показывает, сможет ли сотрудник завершить рабочую операцию после переезда. Например, перенесённый веб-сервер может открывать главную страницу и одновременно терять загрузки файлов, потому что приложение продолжает обращаться к S3 с прежней ролью.

Для каждого сервиса составьте краткую карточку: владелец, пользователи, критичные операции, допустимый простой, допустимая потеря данных, режим нагрузки, зависимости и порядок запуска. Запишите, кто принимает результат. Разработчик подтверждает корректность интеграций, специалист по данным проверяет транзакции, бизнес-владелец выполняет реальный сценарий. Статус виртуальной машины «работает» не заменяет эти проверки.

Разделите зависимости на четыре группы. Первая — вычисления и локальные диски. Вторая — состояние: базы, файлы, очереди, кэш, который фактически используется как долговременное хранилище. Третья — идентификация, сертификаты, ключи и политики доступа. Четвёртая — внешние связи: платёжные системы, почтовые сервисы, партнёрские API, IP-списки разрешений и обратные вызовы. Именно последние две группы часто определяют трудоёмкость.

Компонент AWS	Что рассматривают в Azure	Что нужно доказать до переноса
EC2 с поддерживаемой гостевой ОС	Azure VM через Azure Migrate	Поддержку ОС, загрузки, дисков, сети и приложения
RDS или Aurora	Целевую службу БД либо БД на VM	Совместимость конкретного движка, версии, расширений и метода переноса
Объекты S3	Azure Blob Storage	Доступность объектов, сохранность нужных метаданных, новый способ доступа
Приложение в EKS	Новый кластер AKS или иной подходящий контейнерный сервис	Адаптацию манифестов, идентификации, сети и постоянных данных
IAM, сетевые правила, очереди, события	Спроектированные механизмы Azure	Эквивалентность необходимых действий и ограничений, а не названий сервисов

Это карта решений, а не обещание автоматической конвертации. Иногда экономически разумнее сначала перенести VM и сохранить приложение, а модернизацию выполнить отдельной волной. Если система тесно зависит от AWS API, перенос вычислений без изменения кода лишь создаст связь между двумя облаками. Общие критерии размещения разобраны в материале об облачных технологиях для бизнеса.

Текстовое пояснение схемы

1. Зависимости. EC2, RDS, Aurora; S3, EKS, IAM; Внешние сервисы.
2. Маршруты. EC2: Migrate; Базы: отдельно; S3 и EKS: отдельно.
3. Проверка. Совместимость ОС; Полнота данных; Работа приложения.
4. Переключение. Остановка записи; Финальная дельта; Приёмка в Azure.

Azure Migrate не переносит все сервисы AWS. Для RDS, Aurora, S3 и EKS нужен отдельный план. Новые записи в Azure не возвращаются в AWS сменой DNS.

Как перенести EC2 через Azure Migrate и какие ограничения проверить?

Microsoft документирует перенос EC2 в Azure как физических серверов. Здесь «физический сервер» обозначает используемый процесс миграции, а не тип оборудования AWS. Источником остаётся виртуальная машина EC2, но процесс использует агентную репликацию, а не управление гипервизором AWS.

Для репликации нужен отдельный replication appliance. В инструкции Microsoft по переносу EC2, проверенной 6 сентября 2026 года, он развёртывается на выделенной машине с Windows Server 2022. Это машина компонента репликации, а не ещё один переносимый сервер; компонент обнаружения и оценки её не заменяет. Для бюджета и расписания важно разделять эти роли: обнаружение ресурсов ещё не означает готовности среды к репликации. Требования к ОС и размещению компонентов сверяйте с актуальной инструкцией перед установкой.

Для новых агентных миграций Microsoft требует simplified appliance — актуальный вариант того же компонента репликации. В руководстве по переносу физических серверов 30 сентября 2026 года указано как дата прекращения поддержки classic appliance. Перед проектом проверьте текущий статус и используйте действующий процесс установки; сохранённая инструкция для старого appliance не является подходящим шаблоном.

Между исходными серверами и replication appliance должна быть сетевая доступность. В AWS-инструкции указаны HTTPS 443 для управления и TCP 9443 для передачи данных на appliance; далее appliance обращается к Azure по HTTPS 443. Конкретные правила ограничивают согласованными адресами и направлениями. Не превращайте перечень портов в разрешение доступа из всего интернета. Дополнительно проверяют требуемые Azure URL, прокси, DNS и правила исходящего трафика.

На переносимой машине нужен Mobility Agent. До запуска репликации сверяют поддерживаемую ОС и ядро, схему загрузки, диски и требования целевой VM. Возможны изменения гостевой системы, без которых копия не загрузится в Azure. AWS-специфичные действия cloud-init и паравиртуализированные конфигурации требуют отдельного внимания. Сначала проверяют тестовую копию и документируют изменения, затем распространяют их на согласованную волну.

Особый случай — Amazon Linux. В указанном руководстве Microsoft прямо отмечено, что такие VM нельзя переносить как есть: нужен перенос рабочей нагрузки на поддерживаемую целевую ОС. Это может означать новую сборку пакетов, перенос конфигурации, проверку библиотек, путей и системных служб. Не обещайте клиенту одинаковую процедуру для Amazon Linux и уже поддерживаемого Linux-дистрибутива.

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

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

Можно ли просто экспортировать EC2 в VHD и загрузить в Azure?

Иногда экспорт образа уместен, но его нельзя считать универсальным запасным маршрутом. AWS публикует отдельные ограничения VM Import/Export. В частности, описанный instance export недоступен для ряда образов с программным обеспечением, предоставленным AWS, включая Windows и SQL Server, а также для экземпляров, созданных из AWS Marketplace. Есть ограничения для зашифрованных EBS snapshots, нескольких виртуальных дисков и нескольких сетевых интерфейсов.

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

Рассматривая экспорт, опишите все диски, происхождение образа, способ шифрования и предполагаемый формат. После получения файла всё равно остаются подготовка гостевой ОС, настройка сети, проверка загрузки и тестирование приложения. Сам по себе VHD не содержит бизнес-решения о переносе секретов, разрешений IAM, управляемой базы или зависимостей от метаданных EC2.

Если ограничения экспортного маршрута делают его ненадёжным, разумный следующий шаг — оценить документированную агентную миграцию либо повторное развёртывание приложения на новой ОС. Это инженерный выбор, который проверяется пилотом. Для систем с Microsoft SQL Server дополнительно разберите лицензирование и варианты развёртывания SQL Server до покупки целевой мощности.

Почему RDS и Aurora требуют отдельного плана переноса базы?

RDS нельзя включить в список EC2 и ожидать, что репликация диска приложения перенесёт управляемую базу. План зависит от движка, версии, доступных прав, расширений, хранимых процедур, настроек кодировки и интеграций. Aurora также требует проверки именно используемых возможностей, а не только совместимости на уровне привычного клиентского протокола.

Начните с каталога объектов и поведения приложения. Какие таблицы постоянно изменяются? Используются ли расширения, фоновые задания, реплики для чтения, особые настройки транзакций, внешние функции? Кто выполняет резервное копирование и восстановление? Как приложение получает пароль и обновляет подключения? Эти вопросы определяют выбор целевой службы и инструментов сильнее, чем размер базы в гигабайтах.

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

Для PostgreSQL есть конкретная документированная отправная точка: служба миграции Azure Database for PostgreSQL перечисляет Amazon RDS for PostgreSQL и Amazon Aurora PostgreSQL среди источников для онлайн- и офлайн-миграции. Онлайн-процесс включает первичную копию, репликацию изменений и переключение; обзор требует первичных ключей во всех таблицах для этого режима. Это подтверждает наличие маршрута, но не совместимость каждой версии, расширения или настройки. Проверьте предварительные условия именно своего источника и влияние копирования на его ресурсы.

Критерии проверки базы должны отражать бизнес. Сравнение числа строк полезно, но одинаковое количество строк не доказывает совпадение сумм, статусов заказов, последовательностей и связей. Добавьте контрольные запросы, выборочную проверку содержимого, операции записи и чтения, ограничения доступа и поведение при переподключении. Отдельно проверьте восстановление из резервной копии на Azure: успешно перенесённая база должна оставаться восстанавливаемой после окончания проекта.

Не совмещайте без необходимости перенос провайдера, смену движка, крупное обновление версии и изменение схемы. Каждое изменение расширяет пространство возможных причин ошибки. Если модернизация необходима, обозначьте её отдельным этапом с собственными критериями приёмки. Такой подход облегчает диагностику и делает график более предсказуемым.

Как перенести S3 и не потерять смысл объектов?

Для объектов S3 Microsoft описывает копирование в Azure Blob Storage с помощью AzCopy. Данные передаются непосредственно между сервисами хранения через Put Block From URL; компьютер с AzCopy управляет процессом, а не обязательно прокачивает через себя весь объём. В документированном маршруте используются AWS access key и secret access key, а на стороне Azure — Microsoft Entra ID либо SAS.

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

Главная проверка — не только количество скопированных байтов. S3 и Azure Blob Storage различаются правилами имён и метаданных. В AzCopy значение ExcludeIfInvalid по умолчанию исключает несовместимые метаданные с предупреждением. FailIfInvalid приводит к ошибке копирования соответствующего объекта, а RenameIfInvalid изменяет несовместимые ключи. Если приложение использует метаданные для обработки документов, предупреждение может означать функциональную потерю при внешне успешном переносе файла.

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

Копирование объектов не следует описывать как автоматический перенос всей конфигурации bucket. Версионирование, правила хранения, юридическое удержание, политики доступа, уведомления и подписанные ссылки нужно включить в отдельную карту требований. Если приложение хранит готовые S3 URL в базе, смена endpoint в конфигурации может оказаться недостаточной: понадобятся преобразование ссылок либо предусмотренная совместимость на уровне приложения.

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

Что меняется при переносе приложения из EKS в AKS?

Официальный раздел AKS для специалистов Amazon EKS рассматривает идентификацию нагрузок, мониторинг, доступ к API, хранение, управление узлами и правила эксплуатации. Он также выделяет перенос образов, адаптацию Kubernetes-манифестов и миграцию данных. Поэтому перенос EKS следует планировать как развёртывание приложения на целевой платформе, а не как копирование EC2-узлов кластера.

Сначала отделите переносимый код от облачных привязок. Образы контейнеров и часть декларативных описаний можно использовать как исходный материал. Аннотации балансировщиков, классы хранения, привязки ролей, интеграции с секретами и автоматическое масштабирование требуют сверки с выбранной архитектурой AKS. Наличие общих объектов Kubernetes не гарантирует одинакового поведения контроллеров и внешних сервисов.

Особенно внимательно проверьте идентификацию приложения. Доступ pod к S3 или RDS мог предоставляться через AWS-специфичный механизм. На новой платформе нужно доказать, что нагрузка получает только нужные разрешения к выбранным ресурсам. Копирование долгоживущих ключей во все контейнеры не должно становиться архитектурой по умолчанию. Разницу между пользователями, приложениями и ролями полезно разобрать вместе с основами Microsoft Entra ID.

Для stateful-компонентов укажите владельца постоянных данных и способ восстановления. Отдельно испытайте плановое обновление, потерю pod, повторное подключение тома и восстановление обработки очереди. Для stateless-приложения проверьте, действительно ли сессии и временные файлы вынесены наружу. Заявление разработчика «у нас всё stateless» должно подтверждаться наблюдением и тестом.

Создайте воспроизводимый процесс сборки и выпуска, чтобы исправление после пилота не зависело от ручного редактирования работающего кластера. Практические принципы такого процесса изложены в руководстве по Azure DevOps для команд. Переезд считается завершённым, когда команда умеет безопасно обновлять приложение, видеть ошибки и восстанавливать его, а не только один раз запустила контейнеры.

Для каждого постоянного тома EKS зафиксируйте CSI-драйвер, storage class, зону, режим доступа и способ получения согласованной копии. На выбранном классе хранения AKS проверьте восстановление, подключение тома и работу приложения; копирование манифеста не переносит данные и свойства исходного хранилища. Отдельно сопоставьте IRSA или другую исходную модель доступа с выбранной моделью AKS и Microsoft Entra, подтвердив минимальные права приложения.

Как переключить трафик и что означает откат после новых записей?

У Azure Migrate нет встроенного отката после финальной миграции и остановки источника. Обратная передача данных — отдельный механизм, который проектируют и испытывают заранее. Сохранённая исходная VM и Excel-план сами по себе его не создают. После первых рабочих записей в Azure нужен проверенный обратный путь либо согласованный сценарий восстановления с явно принятым RPO; исправление на целевой стороне также может быть выбранной стратегией.

До окна назначьте владельцев DNS и TLS/mTLS-сертификатов, подтвердите возможность их переноса или перевыпуска и обновления разрешённых исходящих IP у партнёров. После переключения проверьте долгоживущие соединения, пулы приложения, клиентские кэши и обращения к старым адресам. Эти проверки дополняют изменение DNS, а не заменяются истечением TTL.

Назначьте владельца решения о переключении и его заместителя. Разработчики, эксплуатация и бизнес должны одинаково понимать критерии приёмки, порядок связи и полномочия остановить перенос. Перед началом окна проверьте доступность участников и актуальность инструкции: смена дежурной команды не должна менять смысл согласованного плана.

План переключения готовят до первой производственной репликации. Он должен содержать порядок действий, ответственных, критерии остановки и последнюю точку безопасного возврата. Проверяйте этот план на пилоте с участием тех, кто будет выполнять ночное окно. Непроверенная инструкция из нескольких слов «переключить DNS, проверить сайт» оставляет самые сложные решения на момент аварии.

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

После появления новых записей в Azure ситуация меняется. Возврат DNS в AWS не переносит новые заказы, документы и изменения статусов обратно. Для такого отката нужен заранее испытанный способ обратной передачи данных, разрешения конфликтов и проверки внешних эффектов. Если его нет, команда должна рассмотреть исправление на Azure либо восстановление по согласованному сценарию с явно принятой потерей данных. Скрывать эту развилку за словом «rollback» опасно.

Практический порядок переключения включает остановку пользовательских записей и фоновых производителей, завершение или контролируемое удержание очередей, финальное согласование состояния, запуск проверки на Azure и только затем открытие записи и изменение маршрутизации. Конкретная последовательность зависит от приложения; это инженерная рекомендация, а не универсальная автоматическая функция Azure Migrate.

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

План возврата и долгосрочный DR решают разные задачи. Первый защищает конкретное изменение, второй описывает восстановление сервиса после инцидента уже в новой среде. Эти решения стоит согласовать с материалом о резервном копировании и аварийном восстановлении Azure, не считая резервную копию заменой проверенного восстановления.

Как выглядит пилот и что влияет на бюджет в Казахстане и регионе?

Рассмотрим условный учебный пример, а не кейс клиента. Компания использует две EC2 для портала, PostgreSQL в RDS, S3 для документов и отдельного обработчика сообщений. Цель — перенести портал в Azure с согласованным окном обслуживания. Эти числа нужны только для объяснения последовательности и не являются оценкой типичного проекта.

Команда начинает с наблюдения за созданием заказа: веб-приложение записывает данные в базу, кладёт документ в S3 и отправляет сообщение обработчику. Значит, проверять только VM недостаточно. Для пилота выбирают небольшой набор обезличенных заказов, собирают отдельный Azure-контур и запрещают ему обращаться к производственному платёжному API. Затем проверяют целостность связки «запись — документ — результат обработки».

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

До производственного окна владелец сервиса подтверждает контрольный сценарий, инженер данных фиксирует способ финального согласования, эксплуатация проверяет мониторинг и восстановление. Финансовая оценка учитывает исходящий трафик AWS, операции хранилища, временное одновременное содержание сред, appliance, резервные копии и сохранённые договорные обязательства. Снижение ежемесячной стоимости нельзя обещать без этих данных.

Для Казахстана, Центральной Азии и Кавказа выбирайте размещение по конкретным требованиям бизнеса и категориям информации. Проверьте доступность нужных Azure-сервисов в выбранном регионе, задержку до пользователей, местонахождение резервных копий и журналов, договорные условия и правила трансграничной передачи. Из доступности Azure нельзя автоматически вывести соответствие любой местной норме или размещение данных внутри Казахстана.

Исходные вопросы собраны в руководстве по Azure migration, data residency и FinOps. Если проект проходит закупку, включите результат обследования и критерии приёмки в техническое задание и RFP для Microsoft-проекта. По доступам используйте принципы Zero Trust: перенос инфраструктуры не должен расширять права ради удобства миграции.

Для других исходных платформ доступны отдельные разборы: Google Cloud → Azure и Oracle Cloud → Azure. Проверяйте маршрут для конкретного провайдера: ограничения одной платформы не переносятся автоматически на другую.