Миграция из Azure Web Services (AWS) Load Balancer на шлюз приложений Azure

Если в настоящее время вы используете Azure Application Load Balancer (ALB) и планируете перенести рабочую нагрузку в Azure, это руководство поможет вам понять процесс миграции, сопоставления функций и рекомендации. В Azure Azure Application Gateway предоставляет возможности балансировки нагрузки приложений для управления трафиком в ваши веб-приложения.

Это руководство проведёт вас через оценку вашей текущей среды AWS, сопоставление функций ALB с Application Gateway и выполнение миграции при сохранении доступности приложения.

То, что вы будете делать

Следуя этому руководству, вы получите следующее:

• Сопоставление функций ALB AWS с возможностями шлюза приложений
• Подготовка сред к успешной миграции
• Планирование и выполнение миграции с минимальным временем простоя
• Проверка соответствия перенесенной рабочей нагрузки требованиям к производительности и надежности
• Узнайте, как итерировать архитектуру для будущих улучшений

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

Пример сценария: миграция архитектуры микрослужб

В этом примере финансовая компания управляет рабочей нагрузкой микросервисов, которая использует AWS Application Load Balancer (ALB) для маршрутизации трафика между несколькими бэкэндами. Архитектура рабочей нагрузки включает службу проверки подлинности пользователей, запущенную в экземплярах EC2, и службу обработки транзакций, развернутую на контейнерах AWS Fargate. ALB выполняет маршрутизацию на основе путей, направляет /auth/* запросы к службе проверки подлинности и /transactions/* запросы к службе обработки контейнерных транзакций. Эта критически важная для бизнеса настройка поддерживает основную бизнес-функцию обработки безопасных финансовых транзакций с высоким уровнем доступности в нескольких зонах доступности.

Обзор архитектуры

Этот пример архитектуры демонстрирует распространённые функции балансировки нагрузки приложений в AWS и Azure, включая маршрутизацию на основе путей, распределение трафика между различными серверами и шаблоны многозонного развертывания. Цель — мигрировать эту архитектуру с AWS ALB на Application Gateway, сохраняя при этом эквивалентную функциональность и соответствуя ожиданиям по производительности, надёжности, безопасности и другим факторам. В архитектурной диаграмме — /service-a/* это /auth/* путь, а /service-b/* — /transactions/*.

Ниже приведена архитектура рабочей нагрузки в AWS:

Это архитектура для той же рабочей нагрузки, перенесенная в Azure:

Обе архитектуры обеспечивают эквивалентную функциональность, в том числе:

• Развертывание с высоким уровнем доступности: Ресурсы, распределенные между несколькими зонами доступности для отказоустойчивости

• Сетевая изоляция: Виртуальная сеть с выделенными подсетями для подсистемы балансировки нагрузки, уровней приложений и служб данных

• Маршрутизация на основе пути: Маршрутизация запросов на основе URL-адресов в разные внутренние службы (/auth/*, /transactions/*)

• Гибкость поддержки нескольких целевых платформ: Серверные службы, распределённые по различным вычислительным платформам и зонам доступности

• Поддержка смешанных вычислений: Сочетание виртуальных машин и контейнерных рабочих нагрузок

• Расширенная маршрутизация запросов: Сложные правила маршрутизации на основе шаблонов URL-адресов с настраиваемым мониторингом работоспособности

• Встроенная безопасность: Защита брандмауэра веб-приложения с наборами правил безопасности

• Элементы управления безопасностью сети: Группы безопасности и правила, управляющие потоком трафика между сетевыми уровнями

• Терминация на уровне безопасности сокетов (SSL) или безопасности транспортного уровня (TLS): Централизованное управление сертификатами и обработка HTTPS-конечных точек

• Возможности автомасштабирования: Автоматическое масштабирование на основе спроса на трафик и использования ресурсов

• Комплексный мониторинг: Подробные метрики, журналы доступа и мониторинг работоспособности для устранения неполадок и оптимизации

Рекомендации по рабочей среде

Эта миграция использует подход пересечения. С помощью этого подхода вы создаете инфраструктуру Azure параллельно с существующей настройкой AWS. Такой подход минимизирует сложность перемещения пользователей пакетами и поддерживает быстрый откат при возникновении проблем. Во время перехода DNS могут возникнуть короткие простои; Этот процесс минимизирует сбои пользователей.

Ожидаемое время простоя:

• Время распространения DNS: от 5 до 15 минут для 300-секундного TTL
• Нарушение сессий: Переключение может прервать существующие пользовательские сессии
• Доступность служб: отдельные службы остаются доступными во время миграции

Рекомендуемое время обслуживания:

• Продолжительность: от 1 до 2 часов в период с низким трафиком
• Буферное время: дополнительные 30 минут для непредвиденных проблем
• Время отката: 15–30 минут при необходимости

Шаг 1: Оцените архитектуру AWS ALB

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

Чтобы спланировать миграцию рабочей нагрузки AWS в Azure, см. раздел «Migrate networking from Amazon Web Services to Azure», где приведены примеры сценариев миграции, которые могут соответствовать вашему сценарию использования.

Сопоставление прямых возможностей

Возможности архитектуры микрослужб сопоставляют из AWS ALB с Шлюзом приложений следующим образом:

Несоответствия возможностей и стратегий

Если ваша рабочая нагрузка использует возможности AWS ALB или другие возможности, которые Application Gateway не может реализовать, рассмотрите следующие стратегии, чтобы всё же достичь сопоставимого результата.

• Прямая функциональная замена с использованием других сервисов Azure: заменить возможности AWS ALB на эквиваленты Application Gateway, сохраняя при этом основную функциональность. Этот подход определяет минимальные нарушения и использует собственные интеграции Azure для обеспечения безопасности, мониторинга и управления сертификатами. Например, Azure интегрирует автоматическое масштабирование иначе.

• Подход к улучшению архитектуры: Используйте миграцию как возможность модернизировать возможности AWS ALB, включив AKS в контроллер входящего трафика шлюза приложений, управление API Azure для расширенной маршрутизации и Azure Front Door для глобального распространения.

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

Интеграция с автоматическим масштабированием

Возможности AWS ALB: AWS ALB поддерживает интеграцию с группами автомасштабирования, где:

• AWS ALB автоматически регистрирует и снимает регистрацию экземпляров как целей при их запуске или завершении

• Проверка работоспособности ALB может активировать действия автоматического масштабирования для замены неработоспособных экземпляров

• Автоматическое масштабирование может использовать метрики ALB (количество запросов на целевой объект) для масштабирования емкости на основе спроса на трафик

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

• Масштабируемые наборы виртуальных машин: Настраивайте масштабируемые наборы как внутренние пулы Application Gateway с автоматической регистрацией экземпляров и автоматическим масштабированием по состоянию работоспособности

• AKS: Использование контроллера входящего трафика шлюза приложений (AGIC) с автомасштабированием подов по горизонтали для контейнерных рабочих нагрузок

• Интеграция Azure Monitor: Реализация пользовательских правил масштабирования на основе метрик шлюза приложений и работоспособности серверного пула

Шаг 2: Подготовьте ресурсы AWS и Azure к миграции

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

Конфигурация исходной службы

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

Документация по правилам маршрутизации на основе путей

• Задокументируйте существующие правила прослушивателя ALB AWS, чтобы обеспечить эквивалентные правила маршрутизации шлюза приложений. Используйте команды AWS CLI для подсистем балансировки нагрузки для сбора подробных сведений о конфигурации.

• Экспортируйте все конфигурации маршрутизации, настройки проверки состояния и конфигурации завершения SSL/TLS, используя документацию по правилам слушателя AWS ALB.

• Фиксируйте все конфигурации, чтобы избежать функциональных пробелов во время миграции, поскольку Application Gateway требует явной конфигурации правил маршрутизации.

Подготовка сертификата SSL/TLS

• Экспорт сертификатов SSL/TLS из AWS Certificate Manager для импорта Azure Key Vault.

• Преобразование сертификатов в формат PFX с закрытыми ключами, так как шлюз приложений требует этого формата для управления сертификатами. Следуйте руководству по интеграции с сертификатом Azure Key Vault.

  Замечание

  Проверьте, разрешает ли ACM экспортировать сертификат, который вы планируете экспортировать. Некоторые сертификаты, управляемые ACM (например, сертификаты, которыми AWS полностью управляет для определённых сервисов), нельзя экспортировать; Проверьте документацию ACM, прежде чем полагаться на экспорт сертификатов в рамках миграции.

  Замечание

  Этот подход предполагает, что вы используете одни и те же доменные имена и существующие сертификаты с внешним DNS-пересечением. Если миграция использует разные доменные имена, необходимо получить новые сертификаты.

Сопоставление конфигурации проверки работоспособности

Сопоставьте конфигурации проверки состояния AWS ALB с эквивалентами зонда состояния Application Gateway, используя руководство по конфигурации зонда состояния Application Gateway. Такое отображение гарантирует, что мониторинг состояния сервисов на сервере продолжает работать корректно после миграции.

Изменения зависимостей

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

Изменения серверного сервиса

• Если ваше приложение использует HTTP-заголовки, которые внедряет AWS ALB, обновите приложения для обработки специфичных для Azure HTTP-заголовков, следуя Rewrite HTTP и URL с помощью Application Gateway.

• Настройте конечные точки проверки работоспособности для проверок работоспособности Azure в соответствии с руководством по настройке серверного пула Application Gateway.

• Настройте интеграцию логирования с Azure Monitor, используя диагностические настройки Application Gateway для поддержания наблюдаемости.

Эти изменения обеспечивают правильную работу приложений с помощью возможностей обработки запросов и мониторинга шлюза приложений.

Изменения конфигурации DNS

• Уменьшите значения TTL DNS в записях DNS до 300 секунд для ускорения перехода.

• Если вы планируете использовать Azure DNS, создайте записи, указывающие на общедоступные IP-адреса шлюза приложений с помощью руководства по настройке TTL Azure DNS. Это изменение обеспечивает быстрое распространение изменений DNS в момент переключения при миграции.

Обновления серверного пула

• Настройте серверы внутреннего пула в нескольких зонах доступности и реализуйте автоматическое переключение при отказе.

• Используйте приложения контейнеров Azure для бессерверных серверных серверов или AKS с контроллером входящего трафика шлюза приложений для оркестрированных контейнеров.

Изменения окружающей среды

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

Подготовка ресурсов Azure

• Развертывайте Application Gateway, Виртуальные машины и Container Apps, используя Infrastructure as Code до перехода, следуя руководствам по развертыванию Application Gateway.

• Обеспечьте возможность тщательного тестирования и валидации перед переводом в промышленную эксплуатацию за счет предварительного развертывания.

Настройка безопасности сети

• Настройте группы безопасности сети, соответствующие правилам группы безопасности AWS.
• Поддержание состояния безопасности до, во время и после миграции.

Конфигурация мониторинга

• Настройте диагностические настройки Azure Monitor и Application Gateway, используя руководство по настройке диагностических настроек.

• Настройте эквивалентные панели управления и правила оповещений, соответствующие существующему мониторингу AWS CloudWatch, используя руководство по шлюзу приложений Azure Monitor.

• Обеспечение непрерывной наблюдаемости во время и после миграции.

Изменение последовательности и зависимостей

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

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

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

1. Развертывание инфраструктуры Azure — сначала развернуть Application Gateway и ресурсы бэкенда, так как последующие этапы конфигурации зависят от них.

2. Миграция серверной службы — перенос приложений на виртуальные машины Azure и приложения контейнеров. Запускайте эту миграцию параллельно с развертыванием инфраструктуры Azure, чтобы сэкономить время.

3. Migration сертификатов SSL/TLS — импорт сертификатов в Azure Key Vault с помощью руководства по интеграции сертификатов Key Vault. Этот шаг гарантирует правильное завершение SSL/TLS до применения правил маршрутизации.

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

5. Конфигурация правил маршрутизации — реализация правил маршрутизации на основе пути. Этот шаг крайне важен для того, чтобы Application Gateway правильно направлял запросы к соответствующим серверным сервисам на основе URL-путей.

6. Оптимизация серверного пула — настройка многозонного распределения. Этот шаг обеспечивает высокий уровень доступности.

7. Настройка мониторинга — настраивайте дашборды Azure Monitor и оповещения с помощью руководства по конфигурации Azure Monitor.

   Этот шаг обеспечивает видимость производительности и работоспособности шлюза приложений и внутренних служб.

8. Подготовка DNS — уменьшение значений TTL в текущей среде DNS и подготовка обновлений записей DNS. Запускайте эту подготовку параллельно с другими этапами, если только не обновите DNS-записи на Application Gateway до дня миграции. Этот шаг имеет решающее значение для обеспечения плавной переключения с минимальным временем простоя.

Как правило, процесс миграции включает развертывание и перенос ресурсов, а затем настройку правил маршрутизации, проб работоспособности и мониторинга.

Шаг 3: Определите критерии валидации и успеха

Для проверки критериев успеха используйте как автоматизированное, так и ручное тестирование. Такой подход гарантирует, что миграция соответствует всем стандартам функциональности и производительности. Проверьте ключевые области по исходной конфигурации AWS ALB, включая точность маршрутизации, завершение SSL/TLS, состояние бэкэнда, время отклика и обработку сессий. Используйте автоматические тесты для проверки повторяемых аспектов, таких как распределение трафика, пропускная способность и производительность проверки состояния. Используйте ручное тестирование для подтверждения более сложных поведений, таких как отображение пользовательских страниц ошибок, согласованность конфигурации и соответствие требованиям SLA. Сочетая эти подходы, вы можете уверенно проверить, соответствует ли среда Azure требуемым стандартам и отражает ожидаемое поведение из AWS.

Критерии проверки

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

Определение критериев успешности

Установите критерии валидации для каждой возможности AWS ALB, которую вы сопоставили с Application Gateway — маршрутизация на основе пути, зонды здоровья, завершение TLS, многозонное распределение и Брандмауэр веб-приложений (WAF):

Функциональные критерии

• Точность маршрутизации на основе путей: Запросы направляются в правильные серверные пулы на основе путей URL

• Функции SSL/TLS: Подключения HTTPS завершаются и повторно шифруются с помощью сертификатов Azure Key Vault.

• Состояние серверных служб: Все серверные службы имеют статус «Исправно» во всех зонах доступности

• Многозонное распределение: Трафик распределяется корректно с автоматическим переключением при отказе

• Обработка ошибок: Страницы ошибок отображаются правильно с правильным поведением отработки отказа. Если вы настроили пользовательские страницы ошибок в AWS ALB, реплицируйте их в Application Gateway.

• Обработка тайм-аута HTTP: Сопоставьте значения тайм-аута HTTP между AWS и Azure. Значения тайм-аута миграции as-is сохраняют ожидаемое поведение, особенно для сценариев загрузки и загрузки.

Критерии производительности

• Базовый план времени отклика: Среднее время отклика в пределах 10% базовых показателей AWS ALB

• Емкость пропускной способности: Обработка эквивалентных запросов в секунду с помощью AWS ALB

• Одновременные подключения: Поддержка одного числа одновременных пользователей

• Эффективность пробы работоспособности: Проверка работоспособности выполняется без влияния на производительность

Критерии надежности

• Управление сеансами: Сохраняйте привязку сеансов, где это настроено

• Дрейф конфигурации: Мониторить дрейф конфигурации в разных средах, чтобы избежать проблем с надежностью после миграции.

• Соответствие требованиям и выравнивание уровней обслуживания: Убедитесь, что перенесенное решение соответствует необходимым стандартам соответствия требованиям и соглашениям об уровне обслуживания Azure для обеспечения доступности и надежности.

Валидация мониторинга

Проверьте возможности мониторинга, соответствующие функциям AWS CloudWatch:

• Тенденции времени отклика, соответствующие ожидаемым шаблонам
• Диаграммы объема запросов с точным распределением трафика
• Мониторинг частоты ошибок с соответствующими триггерами оповещений
• Состояние работоспособности сервера, отражающее фактическое состояние работоспособности службы

Методы проверки

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

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

Автоматическое тестирование

• Создайте комплексные автоматизированные тесты, охватывающие все возможности, описанные в рекомендациях по тестированию шлюза приложений:
  • Проверка маршрутизации по путям для всех сервисов с использованием маршрутизации на основе URL-адресов Application Gateway
  • Тестирование производительности и нагрузочное тестирование по сравнению с базовыми метриками
  • Проверка и тестирование сертификатов SSL/TLS
  • Тестирование сценариев обработки ошибок и аварийного переключения

Контрольный список ручной проверки

• Тестируйте пользовательские сценарии во всех сервисах
• Проверка функций отправки и скачивания файлов
• Тестирование потоков проверки подлинности и управления сеансами
• Проверка взаимодействия с пользователем
• Тестирование функциональных возможностей API для всех служб
• Проверка сценариев ошибок и отображения страницы ошибок

Шаг 4: Выполните миграцию и пересечение DNS

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

Выполнение миграции

Выполнение миграции включает в себя ряд шагов, чтобы обеспечить плавный переход с AWS ALB на шлюз приложений. Этот процесс включает окончательную проверку, параллельное тестирование, переключение DNS, проверку после переключения и списание ресурсов AWS.

Окончательная проверка и тестирование

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

• Тестирование конечных точек HTTPS с допустимыми сертификатами
• Проверьте маршрутизацию на основе путей для всех сервисов
• Подтвердить распределение многозонального внутреннего пула и переключение при отказе
• Проверьте правила конфигурации и маршрутизации SSL-сертификатов с помощью тестовых доменов
• Выполнение тестов функциональных возможностей службы с помощью шлюза приложений
• Проверка функциональных возможностей микрослужб в нескольких зонах
• Проверьте сценарии высокой доступности и переключения при отказе
• Сравнение производительности с базовыми метриками AWS ALB

Выполнение переключения DNS

Выполните переключение DNS из AWS ALB в шлюз приложений. Обновите DNS-записи для указания на публичные IP-адреса Application Gateway и отслеживайте распространение DNS с помощью стандартных DNS-инструментов.

Проверка после переключения

На этапе после перехода вы подтверждаете успех миграции, обеспечивая правильную работу всех сервисов и соответствие производительности ожиданиям.

Функциональная проверка:

• Проверка правильности всех функций маршрутизации служб
• Проверка функциональных возможностей TLS/SSL-сертификата
• Проверка страниц ошибок и поведения при переключении на резерв
• Проверка поведения пробы работоспособности и работоспособности внутреннего сервера

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

• Мониторинг времени отклика для AWS ALB
• Проверьте, что пропускная способность соответствует требованиям

Списание ресурсов AWS

После успешной проверки выведите ресурсы AWS из эксплуатации:

• Мониторинг шлюза приложений в течение 24–48 часов
• Убедитесь, что трафик не маршрутизируется в AWS ALB
• Резервное копирование конфигурации AWS ALB для возможности отката
• Удалить AWS ALB и связанные ресурсы

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

Итеративная оптимизация

После миграции сосредоточьтесь на оптимизации конфигурации шлюза приложений и проверке точности маршрутизации, производительности и высокой доступности. Этот итеративный процесс совершенствования гарантирует, что перенесённая рабочая нагрузка соответствует всем критериям успеха, установленным на этапе оценки, следуя руководству по службе Application Gateway в Azure Well-Architected Framework.

Итеративный процесс улучшения

Процесс миграции является итеративным. Корректируйте его на основе отзывов и результатов тестирования, пока не достигнете критериев успеха:

Цикл оптимизации производительности

1. Базовое измерение: Сравнение метрик шлюза приложений с базовыми показателями AWS ALB

2. Идентификация узких мест: Определение пробелов в производительности при маршрутизации, завершении SSL или серверном подключении

3. Настройка конфигурации: Настройка параметров шлюза приложений, интервалов проверки серверной части или ограничений подключения

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

5. Корректировка мониторинга: Обновление пороговых значений мониторинга и правил генерации оповещений

Уточнение точности маршрутизации

1. Анализ шаблонов трафика: Мониторинг фактических шаблонов маршрутизации запросов и ожидаемых шаблонов

2. Оптимизация правил: Уточнение правил маршрутизации на основе путей для обработки пограничных вариантов

3. Анализ частоты ошибок: Определение и исправление правил маршрутизации, вызывающих ошибки

4. Проверка взаимодействия с пользователем: Обеспечение эффективной работы конечных пользователей между службами

Проверка высокого уровня доступности

1. Проверка распределения трафика: Проверка правильного распределения трафика между зонами доступности

2. Тестирование аварийного переключения: Проверьте автоматическое аварийное переключение между зонами

3. Возможность восстановления: Проверить быстрое восстановление после сбоя зоны

4. Точность проверки работоспособности: Убедитесь, что проверки работоспособности правильно определяют проблемы службы

Основные выводы

Миграция рабочей нагрузки, использующая Aws Application Load Balancer в Azure, требует тщательного планирования и систематического выполнения для получения эквивалентных функциональных возможностей или альтернативных подходов. К ключевым факторам успеха относятся следующие факторы:

Оценка и планирование: Сопоставление возможностей AWS ALB с эквивалентами Шлюза приложений в начале процесса. Обратите особое внимание на маршрутизацию на основе пути, проверки работоспособности и различия в управлении сертификатами.

Используйте интеграции Azure. Используйте Azure Key Vault для управления сертификатами, Azure Monitor для наблюдаемости и наборы масштабирования виртуальных машин для автомасштабирования.

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

Планируйте так, чтобы свести время простоя к минимуму. Уменьшите значения TTL DNS заранее и подготовьте всю инфраструктуру параллельно. Фактический переход включает только изменения DNS, минимизируя нарушение работы службы.

Мониторинг и оптимизация после миграции. Итеративный процесс улучшения позволяет точно настроить производительность, точность маршрутизации и высокий уровень доступности. Шлюз приложений предоставляет широкие возможности мониторинга для оптимизации конфигурации с течением времени.

Следующий шаг