Перенос шлюза API Amazon в службу управления API Azure

Если вы используете Шлюз API Amazon и хотите перенести рабочую нагрузку в Azure, это руководство поможет вам понять сопоставления функций, рекомендации и процесс миграции. В Azure служба "Управление API Azure" предоставляет возможности шлюза API. К этим возможностям относятся маршрутизация запросов и ответов API, авторизация и контроль доступа, мониторинг и управление, а также управление версиями API.

Что вы будете делать

В этом руководстве вы:

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

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

Организация в области здравоохранения использует Шлюз API Amazon для доступа к системе медицинских записей с несколькими серверными подсистемами. В этом примере сценария используется общая конфигурация шлюза API Amazon в среде Amazon Web Services (AWS). В ней показаны типичные интеграции со связанными службами Amazon и несколькими общими серверными службами API, включая лямбда-функции и HTTP или REST API.

Эта архитектура включает в себя:

• Проверка подлинности пользователей с помощью Amazon Cognito с веб-токенами JSON (JWTs).

• Фильтрация по безопасности запросов через брандмауэр Amazon Брандмауэр веб-приложений (WAF) до того, как они достигают шлюза API Amazon.

• Шлюз API Amazon, настроенный с помощью пользовательского домена и сертификата, хранящегося в диспетчере сертификатов.

• Мониторинг с помощью Amazon CloudWatch.

• Частное подключение через конечные точки Amazon Virtual Private Cloud (VPC) к трем частным подсетям.

• Серверные службы, в том числе:

  • Лямбда для запуска обновления записей пациентов.
  • Amazon Elastic Compute Cloud (EC2), в котором размещаются устаревшие службы за подсистемой балансировки нагрузки приложения.
  • Amazon Elastic Kubernetes Service (EKS) за балансировщиком нагрузки приложений для обработки данных с помощью микросервисов.

Ниже приведен пример архитектуры рабочей нагрузки, перенесенной в Azure. В этом сценарии управление API Azure развертывается на уровне "Премиум".

Эта архитектура включает в себя:

• Безопасная запись через шлюз приложений Azure с помощью брандмауэра веб-приложения (WAF). Брандмауэр перенаправит запросы с помощью JWT, добавленного для проверки подлинности.

• Управление API Azure, настроенное в виртуальной сети. Он использует идентификатор Microsoft Entra для проверки JWTs.

• Внутренняя подсистема балансировки нагрузки, которая направляет трафик в службу Azure Kubernetes (AKS) для внутренних серверных служб на основе микрослужб.

• Защита подключений через частные конечные точки к приложениям-функциям Azure и серверной части Microsoft Foundry.

• Мониторинг, обрабатываемый Azure Monitor.

• Сертификаты и домен, управляемые с помощью Azure Key Vault и зоны Azure DNS. Сертификат также настраивается в шлюзе приложений для завершения TLS.

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

В этом примере архитектуры показаны общие функции в Шлюзе API Amazon и управлении API Azure. К этим функциям относятся сетевая изоляция, управление трафиком и маршрутизация в различные внутренние API, авторизация и управление доступом, а также мониторинг.

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

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

• Пользовательские домены и сертификаты: платформы поддерживают пользовательские доменные имена с завершением TLS/SSL для безопасного обмена данными API.

• Сетевая изоляция: трафик к внутренним API изолирован в виртуальной сети.

• Фильтрация трафика: брандмауэр веб-приложения на границе сети фильтрует и помогает защитить входящий трафик.

• Поддержка рабочей нагрузки API: шлюзы действуют в качестве прокси-серверов для запросов к различным серверным системам, включая облачные вычислительные службы, микрослужбы на основе Kubernetes и пользовательские серверные серверы.

• Мониторинг API: встроенные сервисы платформы записывают активность API и предоставляют метрики сервиса.

• Модуляция API: службы поддерживают кэширование ответов, квоты запросов и ограничения скорости, конфигурацию общего доступа к ресурсам (CORS) и преобразования запросов и ответов.

• Проверка подлинности и авторизация API: шлюзы поддерживают несколько методов доступа, включая ключи, доступ на основе маркеров OAuth и политики на основе API.

Шаг 1. Оценка

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

Чтобы спланировать перенос рабочих нагрузок из AWS в Azure, см. статью Перенос сетевой инфраструктуры из Amazon Web Services в Azure, в которой приведены примеры сценариев миграции, которые могут соответствовать вашему сценарию использования.

Оценка возможностей инфраструктуры

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

• Интеграция WAF в Шлюзе API Amazon не имеет прямого соответствия в службе "Управление API Azure". В Шлюзе API Amazon правила WAF применяются непосредственно на этапах REST API. В службе управления API Azure настройка правил WAF обычно требует развертывания вышестоящего экземпляра шлюза приложений, перенаправления трафика и завершения TLS через шлюз. Кроме того, для сценариев с несколькими регионами используйте Azure Front Door перед управлением API Azure.
• Пользовательские домены поддерживаются в службе "Управление API Azure". Если вы используете шлюз приложений и брандмауэр веб-приложений Azure перед собой, необходимо также настроить личный домен и сертификат TLS на уровне шлюза приложений.
• Оптимизированные для периферии конечные точки в шлюзе API Amazon поддерживают географически распределенные клиентские приложения. Аналогичная возможность в службе управления API Azure требует развертывания дополнительных региональных шлюзов с дополнительными затратами.

Сравнение рабочих нагрузок API

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

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

• Бекенды Lambda поддерживаются изначально в API Gateway Amazon как HTTP API. Управление API Azure не обеспечивает встроенную интеграцию с сопоставимыми приложениями-функциями Azure. Управление API Azure должно вызывать приложения-функции по протоколу HTTP с помощью ключа функции или управляемого удостоверения.
• Спецификации OpenAPI , экспортированные из REST API шлюза API Amazon, содержат сведения, относящиеся к реализации внешнего интерфейса в шлюзе API Amazon, а не серверной службе. Необходимо удалить теги, относящиеся к AWS, и настроить сведения в спецификации (например, URL-адрес серверной службы) перед импортом в службу управления API Azure или во время миграции.
• Бэкенды микросервисов Kubernetes, такие как gRPC API, обрабатываются по-разному:
  • Шлюз API Amazon подключается к подсистеме балансировки нагрузки приложения в VPC, что, в свою очередь, обеспечивает входящий трафик к AWS EKS.
  • Служба управления API Azure обычно поддерживает gRPC и другие API микросервисов в кластерах Kubernetes через автономный шлюз.
  • Использование gRPC предотвращает использование шлюза приложений в качестве WAF.

Сравнение конфигураций API

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

В следующей таблице оцениваются конфигурации API в шлюзе API Amazon и эквивалентные конфигурации в службе управления API Azure:

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

• Лимиты квот и пропускной способности накладываются шлюзом API Amazon для каждой учетной записи AWS. В службе "Управление API Azure" наивысшая область действия — область "все интерфейсы API" для каждого экземпляра.

• Методы проверки подлинности и авторизации API в Шлюзе API Amazon, такие как разрешения IAM и лямбда-авторизации, не сопоставляют напрямую с управлением API Azure. Клиенты могут оценивать альтернативные методы проверки подлинности и авторизации, такие как использование идентификатора Microsoft Entra или внешнего поставщика удостоверений.

• Метрики, связанные с кэшем , в Шлюзе API Amazon не сопоставляют напрямую с метриками управления API Azure. Попадания и пропуски в кэше можно считать в журналах трассировки в системе "Управление API Azure".

Проверка ресурсов для миграции

• Сценарий развертывания управления API Azure

• Рекомендации по архитектуре для управления API Azure

• Проверка подлинности и авторизация API в службе "Управление API Azure"

• Azure для специалистов ПО AWS

• Microsoft Copilot в Azure для генерации политик управления API

• Документация AWS MCP сервера и сервер Microsoft Learn MCP

Кроме того, для рабочих нагрузок API:

• Перенос рабочих нагрузок AWS Lambda в Функции Azure

• Миграция из Службы Amazon Elastic Kubernetes в Службу Azure Kubernetes

Шаг 2. Подготовка

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

Планирование настройки инфраструктуры

Планирование входящего трафика и исходящего трафика, брандмауэров, сетевой изоляции и интеграции с точками входа сетевого трафика, такими как Шлюз приложений, Azure Front Door или диспетчер трафика Azure. Узнайте о последствиях частного по сравнению с общедоступным доступом к системе управления API Azure, особенно в отношении DNS и отслеживаемости.

Ознакомьтесь с рекомендациями в акселераторе целевой зоны управления API Azure и оцените сценарии, которые могут быть подходящими для миграции и серверной части API. Учитывайте, когда рабочие нагрузки изолированы достаточно, чтобы получить от этого выгоду.

Базовый сценарий, который можно использовать для первоначальной миграции и сборки в Azure, — это безопасный базовый план с примером рабочей нагрузки.

Планирование тестовых и рабочих экземпляров службы управления API

Выберите соответствующие уровни служб управления API Azure для тестовых и рабочих сред:

• Если вам нужна сетевая изоляция как входящего, так и исходящего трафика, а также вход трафика через Azure Front Door или Azure Application Gateway, мы в настоящее время рекомендуем премиум-уровень Управления API Azure. Если выбрать уровень "Премиум", вы можете использовать уровень разработчика (не поддерживается с соглашением об уровне обслуживания) для проверки концепции миграции. Уровень разработчика поддерживает сетевые возможности, которые также доступны на уровне "Премиум". Однако для рабочей среды не следует использовать уровень разработчика.

• В зависимости от требований к доступности, производительности и сетевой изоляции рассмотрите уровень "Стандартный" версии 2 или "Премиум" версии 2. Обе службы поддерживают интеграцию с изолированными от сети внутренними серверами. Уровень Premium версии 2 также поддерживает внедрение в виртуальную сеть для изоляции входящего трафика.

• В настоящее время уровень Premium версии 2 с возможностями изоляции входящего трафика находится в предварительной версии. Его можно использовать для миграции в зависимости от ваших временных планов реализации и доступной информации о выпуске и путях миграции для "Премиум v2".

Изучение и документирование исходных API, находящихся под вашим управлением

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

Определите все службы, интегрированные с Шлюзом API Amazon, такие как лямбда-авториторы, подсистемы балансировки нагрузки приложений, сетевые подсистемы балансировки нагрузки и рабочие нагрузки Kubernetes.

Для каталогизации API под управлением рекомендуется использовать Центр API Azure и синхронизацию API из шлюза API Amazon.

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

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

Экспорт конфигураций AWS по возможности

Экспорт конфигураций, таких как:

• Спецификации OpenAPI из серверных API; например, с помощью консоли AWS или AWS CLI. Если API были определены с помощью OpenAPI изначально, возможно, у вас уже есть эти спецификации.

• SSL/TLS-сертификаты, хранящиеся в диспетчере сертификатов AWS.

• Правила WAF путем экспорта в CloudFormation.

Захват артефактов, таких как шаблоны CloudFormation, которые можно экспортировать в Terraform с помощью внешних инструментов. Эти артефакты способны облегчить сопоставление с Azure (Bicep, Azure Resource Manager и шаблонами Terraform).

Планирование стратегии поэтапного перехода

Рекомендуется планировать поэтапную миграцию (API по API или домен за доменом). Обновите один набор доменов или конечных точек API в службе "Управление API Azure", а другие остаются в AWS, а затем постепенно переместите остальные. Эта стратегия может потребовать от клиентских приложений обрабатывать смешанные конечные точки или использовать уровень маршрутизации.

Шаг 3. Оценка

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

К критериям проверки относятся:

• Проверка инфраструктуры: сетевая инфраструктура задокументирована и доступна только в том виде, в чем она предназначена. Например, если он внедряется во внутреннюю виртуальную сеть, убедитесь, что никакие общедоступные IP-адреса не делают его доступным.

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

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

  • Подтвердите все необходимые конфигурации проверки подлинности и авторизации (ключи подписки, маркеры OAuth, сертификаты) для каждого API.

  • Убедитесь, что клиенты могут использовать API, как и раньше, без изменений (за исключением URL-адреса конечной точки, если имя домена изменилось).

  • Убедитесь, что ограничения скорости и квоты настроены в соответствующей области.

• Проверьте операционные метрики: отслеживайте производительность с помощью панелей мониторинга или других средств наблюдаемости в рабочей нагрузке. Просмотрите такие метрики, как средняя задержка и пропускная способность, и сравнивайте их с историческими данными из шлюза API Amazon. Проверьте метрики емкости, чтобы обеспечить правильное масштабирование экземпляра службы "Управление API Azure".

Шаг 4. Процесс

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

Полная базовая настройка

Если у вас еще нет клиента Azure и основной инфраструктуры (базовая сеть, входящий трафик, безопасность), создайте их перед переносом Шлюза API Amazon и API. Вы можете настроить среду с помощью архитектуры зоны размещения Azure, подходящей для вашей миграции.

Если акселератор целевой зоны управления API Azure подходит для миграции, реализуйте его для базового развертывания службы "Управление API Azure". Включите шлюз приложений и внутреннюю виртуальную сеть в службу управления API Azure. Хотя акселератор посадочной зоны использует уровень "Премиум" в системе "Управление API Azure", мы рекомендуем адаптировать шаблоны для использования уровня разработчика, чтобы доказать концепцию миграции.

Создайте и назначьте роли управления доступом на основе ролей Azure (RBAC), чтобы только авторизованные администраторы могли управлять экземпляром службы "Управление API Azure" и API.

Настройка параметров платформы управления API Azure

В новом экземпляре службы "Управление API Azure" настройте глобальные конфигурации, аналогичные этим в шлюзе API Amazon:

• Имя пользовательского узла: добавьте личный домен в службу управления API Azure, отправьте SSL-сертификат (или используйте ссылки Key Vault) и выполните проверку. Выполните эту задачу сейчас или непосредственно перед вводом в эксплуатацию. При использовании шлюза приложений (рекомендуется) настройте прослушиватель с пользовательским доменом и сертификатом, после чего направьте его на внутреннюю конечную точку управления API Azure. Настройка прослушивателя упрощает настройку, так как она не требует проверки домена.

• Сеть и безопасность. Убедитесь, что шлюз приложений (или другая точка входа Azure) настроен для пересылки запросов в службу управления API Azure. Настройте правила группы безопасности сети (NSG) или правила брандмауэра, чтобы управление API Azure могло иметь доступ к внутренним службам. Эти службы могут включать бекенды Azure или даже исходные бекенды AWS, если вы изначально направляете запросы на них.

• Управляемое удостоверение: Включите управляемое удостоверение в управлении API Azure для безопасного вызова служб Azure (например, Key Vault для сертификатов или функциональных приложений).

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

Импорт и повторное создание API в службе "Управление API Azure"

После готовности инфраструктуры начните перенос определений и конфигураций API:

• Начните с простого, низко рискованного API: используйте репрезентативный API для проверки основных функций шлюза в службе "Управление API Azure" перед повторной созданием API из Шлюза API Amazon.

• Импорт в службу управления API Azure: используйте портал Azure или скрипты для импорта определений OpenAPI из шлюза API Amazon или серверной части в качестве новых API в службе "Управление API Azure". Во время импорта управление API Azure автоматически создает структуру API и операций. Если у вас несколько этапов API в шлюзе API Amazon, создайте несколько версий API в службе "Управление API Azure".

  Изначально задайте внутренний URL-адрес для каждого API, чтобы он указывал на текущую серверную часть. (Сейчас текущая серверная часть по-прежнему может быть конечной точкой AWS или публичной конечной точкой.) Например, если шлюз Amazon API Gateway перенаправляет на AWS Lambda, вы можете задать серверную часть в службе управления API Azure как эквивалентный API в Amazon API Gateway или эквивалентное приложение-функцию Azure, если оно уже мигрировало. (Если вы настроили серверную часть службы управления API Azure эквивалентным API в Шлюзе API Amazon, вы измените эту конфигурацию позже при переносе лямбда-функции в Azure.) Если серверная часть была подсистемой балансировки нагрузки или конечной точкой приложения AWS, управление API Azure может вызвать его через Интернет.

  Если у вас есть большое количество API, вы можете использовать Центр API Azure для каталогизации API, перенесенных в управление API Azure со временем, и тех, которые остаются в Шлюзе API Amazon.

  Рассмотрите возможность переноса или рефакторинга внутренних служб (например, как функции приложений Azure или нагрузки в AKS) после проверки инфраструктуры. Ознакомьтесь с инструкциями в центре миграции Azure.

Настройка проверки подлинности и авторизации

• Подписки и продукты: если в Amazon API Gateway требуются ключи API (через x-api-key заголовок), решите, как вы будете обрабатывать это в Azure API Management. Один из способов заключается в том, чтобы сделать эти API доступными только для пользователей, имеющих подписку на продукт. Создайте начальные продукты в службе управления API Azure, которые соответствуют один к одному с планами использования AWS или организованы логически.

• Группы пользователей: Создайте группы пользователей в службе "Управление API Azure" для отражения общего использования API с разработчиками.

• Именованные значения: импортируйте все значения конфигурации (например, конечные точки или ключи API для внутренних служб), которые были в переменных этапа шлюза API Amazon в именованные значения управления API Azure. Для конфиденциальных значений используйте интеграцию Azure Key Vault.

• Получение маркера и проверка. Для проверки запросов API JWT настройте политики проверки в службе управления API Azure, которая разрешает доступ к API. Изначально можно использовать существующий поставщик удостоверений (например, AWS Cognito) и рассмотреть возможность миграции с течением времени на идентификатор Microsoft Entra.

  Настройте диспетчер учетных данных в службе "Управление API Azure" для управления маркерами в серверной части OAuth. Или настройте логику извлечения маркеров с помощью политик из репозитория фрагментов политики.

• Серверные серверы в службе управления API Azure: настройте серверные серверы в службе "Управление API Azure", чтобы зарегистрировать каждую серверную службу (с его URL-адресом, учетными данными и другими сведениями). Это действие предоставляет центральное место для обновления, если внутренний URL-адрес изменяется. Например, если вы изначально указываете на конечную точку AWS, но позже перейдете на серверную часть Azure, можно просто обновить конфигурацию серверной части управления API Azure.

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

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

  Azure API Management обрабатывает все импортированные API унифицировано, так что HTTP API Amazon API Gateway (более новый упрощенный тип) и REST API (классический тип) обрабатываются единообразно в Azure API Management. Различия, такие как отсутствие планов использования в API HTTP, являются спорными после того, как API находятся в службе управления API Azure, но убедитесь, что все ограничения, связанные с шлюзом API Amazon, устраняются.

Управление сопоставлением преобразований и политик

Репликация существующих конфигураций API в качестве политик управления API Azure, где применимо, особенно для авторизации и обратной совместимости.

Сопоставление конфигурации CORS в Шлюзе API Amazon с политикой CORS в службе "Управление API Azure".

Обрабатывайте преобразования (например, сопоставление схемы или обогащение) в каждом конкретном случае.

Средства искусственного интеллекта, такие как Microsoft Copilot в Azure на портале Azure и серверы MCP для документации AWS и Microsoft, могут помочь в сопоставлении конфигурации или другом преобразовании. Однако следует выполнить настройку политики вручную и отладку в службе "Управление API Azure".

Настройка наблюдаемости

Для первоначального мониторинга настройте Azure Monitor для сбора метрик и журналов API. Дополнительные решения для мониторинга или обозримости, такие как Application Insights, могут быть добавлены позже.

Выполнение тестирования

С помощью API, настроенных в службе управления API Azure, тщательное тестирование критически важно. Ожидается, что этот этап будет итеративным.

• Функциональное тестирование. Для каждого API вызовите новую конечную точку управления API Azure (с помощью тестовой консоли или клиентских средств портала Azure) и сравните ответы с конечной точкой шлюза API Amazon. Проверьте ожидаемые коды состояния, заголовки и текст. Если вы найдете различия, измените политики или конфигурацию управления API Azure соответствующим образом.

  Замечание

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

• Тестирование безопасности: Проверьте, что проверка подлинности и авторизация API работают. Например, указать действительный ключ JWT или подписку в Службе управления API Azure. Убедитесь, что служба "Управление API Azure" принимает запрос и что недопустимые учетные данные отклоняются с правильными кодами ошибок. Клиентам, которые передают маркеры для проверки JWT, может потребоваться авторизация с другим поставщиком удостоверений, если он был настроен во время миграции. Если вы используете ключи подписки, протестируйте как с ключом, так и без него.

• Базовые показатели производительности. Используйте средство для имитации нагрузки на конечные точки управления API Azure и убедитесь, что они могут обрабатывать ожидаемую пропускную способность. Сравните задержку вызовов с помощью службы "Управление API Azure" с задержкой через шлюз API Amazon. Управление API Azure в версии для разработчиков менее производительно, чем в версии "Премиум" или в отдельном экземпляре, поэтому интенсивное тестирование производительности может быть отложено до развертывания экземпляра уровня "Премиум".

Начало развертывания в эксплуатацию

Обновить до уровня "Премиум" или другого готового к эксплуатации уровня службы "Управление API Azure" в рабочей среде. Повторите или перенесите параметры импорта и конфигурации API, которые вы создали в предварительных средах. Вы можете использовать процессы APIOps для публикации API и управления конфигурациями API в разных средах.

Тренировка переключения в тестовой среде или с определённым подмножеством трафика. Например, выберите один некритичный API и переключите одно клиентское приложение на использование конечной точки Azure. Эта практика может выявить любые проблемы на стороне клиента или помочь проверить процесс изменения DNS. Если потребители API являются внутренними, можно имитировать изменения, изменяя файлы узлов или используя тестовую зону DNS, чтобы временно указать домен в службе управления API Azure.

• Переключение DNS: Наиболее распространенный подход — изменить запись DNS для пользовательского домена шлюза API Amazon, чтобы она указывала на новую конечную точку Azure. Например, если вы сопоставили домен api.example.com с Шлюзом API Amazon, обновите запись CNAME или A, чтобы указать имя узла управления API Azure или домен внешнего интерфейса (например, шлюз приложений).

• Время жизни (TTL) соображения: Понизьте TTL для DNS заранее, чтобы клиенты быстро применяли изменения. Когда вы будете готовы, измените DNS. Распространение может занять несколько минут до часов. В течение этого времени некоторые трафик может по-прежнему отправляться в AWS, пока некоторые отправляются в Azure. Если требуется немедленное сокращение, можно использовать альтернативный метод, например обратный прокси-сервер.

• Альтернативные методы переключения: иногда вместо DNS организации используют обратный прокси-сервер или перевернутый шлюз. Например, организация может сохранить общедоступный DNS тем же, но изначально перенаправит запросы шлюза приложений в шлюз API Amazon (по его URL-адресу). Во время переключения организация указывает шлюз приложений на службу управления API Azure внутренне. Этот подход более сложный, но он может достичь мгновенного переключения. Другой метод, если вы используете Azure Front Door или диспетчер трафика, — перенаправлять трафик из одной серверной части (AWS) в другую (Azure) постепенно.

• Мониторинг во время переключения: Как только произойдет переключение, следите за запросами к экземпляру Azure API Management и Amazon API Gateway. Отслеживайте метрики управления API Azure (запросы, задержка, ЦП, память емкости) в режиме реального времени с помощью портала Azure или любой панели мониторинга, настроенной вами. Также используйте Azure Monitor для отслеживания пиков ошибок, таких как ответы 4XX/5XX.

• План отката: определите, что активирует откат. Например, если частота ошибок превышает определенный процент или критически важные функциональные возможности нарушены, вы можете вернуться в течение 30 минут. Откат означает отмену любого сделанного вами переключения. Например, если переключателем был DNS, измените запись DNS так, чтобы она снова указывала на шлюз API Amazon. Из-за процесса распространения DNS откат может занять определенное время. Время отката подчеркивает важность низкого значения TTL и возможность одновременной работы обеих систем. Если вы использовали обратный прокси-сервер, переверните его обратно в AWS.

Вывод из эксплуатации шлюза API Amazon

Выведите из эксплуатации шлюз API Gateway Amazon после периода отсутствия трафика, если экземпляр службы Azure API Management соответствует критериям проверки. Как правило, параллельное выполнение обеих операций (при использовании Azure для всего трафика) выполняется по крайней мере через один полный рабочий цикл или пиковый период трафика, чтобы убедиться, что новая система справляется с этим.

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

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

Работа над недоработками функций

Некоторые функции шлюза API Amazon не имеют сопоставления "один к одному" в службе "Управление API Azure" и требуют обходных решений, как описано ранее в разделе "Оценка ". Рассмотрим пример.

• Брандмауэр веб-приложения: Управление API Azure автоматически не блокирует вредоносные данные, которые блокируются AWS WAF. Если вы настроили брандмауэр веб-приложений Azure, убедитесь, что управление API Azure доступно только через WAF и что правила WAF реплицируют ограничения AWS WAF.

• Потоки событий: если оповещения или события CloudWatch были привязаны к Шлюзу API Amazon (например, по определенным шаблонам ошибок), настройте эквивалентные оповещения в Azure Monitor для управления API Azure (например, оповещение о частоте управления API Azure 5XX).

• Автоматизация. Если у вас есть конвейеры непрерывной интеграции и непрерывной доставки (CI/CD), интегрируйте управление API Azure в них. Например, вы можете хранить конфигурации управления API Azure (API и политики) в системе управления версиями с помощью подходов к инфраструктуре как кода. Эти подходы могут включать в себя Azure Resource Manager, Bicep или шаблоны Terraform или методологию APIOps. Эта интеграция гарантирует, что будущие изменения API можно развертывать согласованно с управляемым управлением версиями.

Реализация рекомендаций

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

Со временем добавляйте больше возможностей, таких как:

• Внешнее кэширование.
• Возможности мониторинга за пределами Azure Monitor, такие как Application Insights или решения, отличные от Майкрософт, например Datadog.
• Политики в службе "Управление API Azure", недоступные в шлюзе API Amazon.

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

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

• Тщательная оценка. Провести подробную оценку существующей установки шлюза API Amazon, включая все API, интеграции служб и зависимости. Определите пробелы или различия в возможностях между Шлюзом API Amazon и управлением API Azure.

• Возможности модернизации: используйте миграцию как возможность модернизировать или перенести внутренние службы или улучшить проектирование API.

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

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

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

• Мониторинг и наблюдаемость. Настройте надежный мониторинг и наблюдаемость для нового экземпляра службы "Управление API Azure" для быстрого выявления и устранения любых проблем, возникающих во время миграции или после миграции.

• Итеративная оптимизация. После миграции непрерывно оптимизируйте настройку управления API Azure, устраняя пробелы функций и реализуя рекомендации.