Migración de Amazon API Gateway a Azure API Management

Si usa Amazon API Gateway y quiere migrar la carga de trabajo a Azure, esta guía le ayuda a comprender las asignaciones de características, los procedimientos recomendados y el proceso de migración. En Azure, Azure API Management proporciona funcionalidades de puerta de enlace de API. Estas funcionalidades incluyen el enrutamiento de solicitudes y respuestas de API, autorización y control de acceso, supervisión y gobernanza y administración de versiones de API.

Podrá:

En esta guía, podrá:

• Evalúe la implementación actual de Amazon API Gateway.
• Asigne las funcionalidades de Amazon API Gateway a las funcionalidades de Azure API Management.
• Prepare los entornos de Amazon y Azure para una migración correcta.
• Planee y ejecute una migración con un tiempo de inactividad mínimo.
• Compruebe que la carga de trabajo migrada cumple los requisitos de rendimiento y confiabilidad.
• Aprender cómo iterar en la arquitectura para futuras mejoras.

Escenario de ejemplo: sistema de registros de mantenimiento de varias instancias de back-end

Una organización de servicios de salud utiliza Amazon API Gateway para acceder a un sistema de registros de salud que tiene múltiples backends. En este escenario de ejemplo se incluye una configuración común de Amazon API Gateway en un entorno de Amazon Web Services (AWS). Muestra integraciones típicas con servicios relacionados de Amazon y varios backends de API comunes, incluidas las funciones Lambda proxied y las API REST o HTTP.

Esta arquitectura incluye:

• Autenticación de usuarios a través de Amazon Cognito con JSON Web Tokens (JWT).

• Filtrado de seguridad de solicitudes a través de Amazon Web Application Firewall (WAF) antes de llegar a Amazon API Gateway.

• Amazon API Gateway configurado con un dominio personalizado a través de un certificado almacenado en el Administrador de certificados.

• Supervisión a través de Amazon CloudWatch.

• Conectividad privada a través de puntos de conexión de la nube privada virtual (VPC) de Amazon a tres subredes privadas.

• Servicios back-end, incluidos:

  • Lambda para desencadenar actualizaciones de registros de pacientes.
  • Amazon Elastic Compute Cloud (EC2), que hospeda servicios heredados detrás de un equilibrador de carga de aplicaciones.
  • Amazon Elastic Kubernetes Service (EKS) detrás de un equilibrador de carga de aplicaciones para el procesamiento de datos a través de microservicios.

Esta es una arquitectura de ejemplo de la carga de trabajo migrada a Azure. En este escenario, Azure API Management se implementa en el nivel Premium.

Esta arquitectura incluye:

• Protección de la entrada a través de Azure Application Gateway con un firewall de aplicaciones web (WAF). El firewall reenvía las solicitudes con un JWT agregado para la autenticación.

• Azure API Management configurado dentro de una red virtual. Usa microsoft Entra ID para validar JWT.

• Equilibrador de carga interno que enruta el tráfico a Azure Kubernetes Service (AKS) para los back-end basados en microservicios.

• Proteja las conexiones a través de puntos de conexión privados a aplicaciones de funciones de Azure y back-end de Microsoft Foundry.

• Supervisión controlada por Azure Monitor.

• Certificados y un dominio administrados a través de Azure Key Vault y una zona dns de Azure. Un certificado también está configurado en Application Gateway para la terminación TLS.

Introducción a la arquitectura

En este ejemplo de arquitectura se muestran las características comunes de Amazon API Gateway y Azure API Management. Estas características incluyen aislamiento de red, administración del tráfico y enrutamiento a varias API de back-end, autorización y control de acceso y supervisión.

Ambas arquitecturas proporcionan una funcionalidad comparable:

• Implementación de alta disponibilidad: los recursos se distribuyen entre varias zonas de disponibilidad en una región para la tolerancia a errores, con opciones para una mayor disponibilidad mediante la implementación en varias regiones.

• Dominios y certificados personalizados: las plataformas admiten nombres de dominio personalizados con terminación TLS/SSL para la comunicación de API segura.

• Aislamiento de red: el tráfico a las API de back-end está aislado en una red virtual.

• Filtrado de tráfico: Un firewall de aplicaciones web en el perímetro filtra y ayuda a proteger el tráfico entrante.

• Compatibilidad con cargas de trabajo de API: Los gateways actúan como proxies para solicitudes hacia diversos sistemas de backend, incluidos los servicios de cómputo en la nube, los microservicios basados en Kubernetes y los backends personalizados.

• Supervisión de API: los servicios integrados de la plataforma registran la actividad de la API y exponen métricas de servicio.

• Modulación de API: los servicios admiten el almacenamiento en caché de respuestas, las cuotas de solicitud y los límites de velocidad, la configuración del uso compartido de recursos entre orígenes (CORS) y las transformaciones de solicitud y respuesta.

• Autenticación y autorización de API: las puertas de enlace admiten varios métodos de acceso, como claves, acceso basado en tokens de OAuth y directivas basadas en API.

Paso 1: Evaluación

Antes de migrar de Amazon API Gateway a Azure API Management, evalúe las características de infraestructura existentes, las cargas de trabajo de API y las configuraciones de API. Identificar las funcionalidades que se van a asignar o reemplazar. Esta evaluación ayuda a garantizar una migración sin problemas y mantiene la funcionalidad de las aplicaciones.

Evaluación de las funcionalidades de infraestructura

Errores de coincidencia de funcionalidades y estrategias

• La integración de WAF en Amazon API Gateway no tiene una coincidencia directa en Azure API Management. En Amazon API Gateway, las reglas de WAF se aplican directamente en las fases de la API REST. En Azure API Management, la configuración de las reglas de WAF normalmente requiere la implementación de una instancia ascendente de Application Gateway, el reenvío del tráfico y la terminación de TLS a través de la puerta de enlace. Como alternativa, para escenarios activos o activos de varias regiones, use Azure Front Door delante de Azure API Management.
• Los dominios personalizados se admiten en Azure API Management. Si usa Application Gateway y Azure Web Application Firewall delante, también deberá configurar el dominio personalizado y el certificado TLS en la capa de Application Gateway.
• Los puntos de conexión optimizados para edge en Amazon API Gateway admiten clientes distribuidos geográficamente. La funcionalidad similar en Azure API Management requiere la implementación de puertas de enlace regionales adicionales a un costo adicional.

Comparación de cargas de trabajo de API

Como parte de la evaluación, considere si se deben conservar o reemplazar los servicios existentes. Evalúe si la migración es una oportunidad para modernizar o consolidar servicios.

Errores de coincidencia de funcionalidades y estrategias

• Los back-end lambda se admiten de forma nativa en Amazon API Gateway como API HTTP. Azure API Management no proporciona integración nativa con las aplicaciones de funciones de Azure comparables. Azure API Management debe llamar a las aplicaciones de funciones a través de HTTP mediante una clave de función o una identidad administrada.
• Las especificaciones de OpenAPI exportadas desde una API REST de Amazon API Gateway contienen detalles específicos de la implementación de front-end en Amazon API Gateway, no el servicio back-end. Debe quitar etiquetas específicas de AWS y configurar los detalles de la especificación (como la dirección URL del servicio back-end) antes de importar a Azure API Management o durante el proceso de migración.
• Los back-end de microservicios de Kubernetes , como las API de gRPC, se controlan de forma diferente:
  • Amazon API Gateway se conecta al equilibrador de carga de la aplicación en VPC, que a su vez proporciona entrada a AWS EKS.
  • Azure API Management admite las API de gRPC en clústeres de Kubernetes a los que solo se accede a través de la puerta de enlace autohospedada.
  • El uso de gRPC impide el uso de Application Gateway como WAF.

Comparación de configuraciones de API

El enfoque de migración para las configuraciones de API debe tener en cuenta el ámbito de la configuración en Amazon API Gateway. En un nivel alto, los ámbitos de API se asignan de la manera siguiente de Amazon API Gateway a Azure API Management:

En la tabla siguiente se evalúan las configuraciones de API en Amazon API Gateway y configuraciones equivalentes en Azure API Management:

Errores de coincidencia de funcionalidades y estrategias

• Cuotas y límites de restricciones son impuestos por Amazon API Gateway por cada cuenta de AWS. En Azure API Management, el ámbito más alto es el ámbito "todas las API" por instancia.

• Los métodos de autenticación y autorización de API en Amazon API Gateway, como los permisos de IAM y los autorizados de Lambda, no se asignan directamente a Azure API Management. Los clientes pueden evaluar métodos alternativos de autenticación y autorización, como el uso de Microsoft Entra ID o un proveedor de identidades externo.

• Las métricas relacionadas con la caché de Amazon API Gateway no se asignan directamente a las métricas de Azure API Management. Los aciertos y errores de caché se pueden contar en los registros de seguimiento en Azure API Management.

Revisión de recursos para la migración

• Zona de aterrizaje de Azure API Management

• Procedimientos recomendados de arquitectura para Azure API Management

• Autenticación y autorización de API en Azure API Management

• Azure para profesionales de AWS

• ** Microsoft Copilot en Azure para la generación de directivas de Gestión de API

• Servidor MCP de documentación de AWS y servidor MCP de Microsoft Learn

Además, para cargas de trabajo de API:

• Migración de cargas de trabajo de AWS Lambda a Azure Functions

• Migración de Amazon Elastic Kubernetes Service a Azure Kubernetes Service

Paso 2: Preparación

En la fase de preparación, planee la infraestructura de Azure, seleccione los niveles de API Management adecuados para pruebas y producción y documente exhaustivamente las API de origen y los servicios integrados. Exporte las configuraciones de AWS pertinentes y diseñe una estrategia de migración por fases para garantizar una transición sin problemas.

Planear la configuración de la infraestructura

Planee la entrada y salida, firewalls, aislamiento de red e integración con puntos de entrada de tráfico de red, como Application Gateway, Azure Front Door o Azure Traffic Manager. Comprenda las implicaciones de la exposición privada frente a pública del sistema de Azure API Management de destino, especialmente en torno a DNS y rastreabilidad.

Revise las instrucciones del acelerador de zonas de aterrizaje de Azure API Management y evalúe los escenarios que podrían ser apropiados para la migración y los backends de API. Tenga en cuenta cuándo las cargas de trabajo están lo suficientemente aisladas como para beneficiarse de ellas.

Un escenario básico que puede usar para la migración inicial y la compilación en Azure es una línea base segura con una carga de trabajo de ejemplo.

Planeación de instancias de API Management de prueba y producción

Elija los niveles de servicio de Azure API Management adecuados para entornos de prueba y producción:

• Si necesita aislamiento de red del tráfico entrante y saliente, junto con la entrada de tráfico a través de Azure Front Door o Application Gateway, actualmente se recomienda el nivel Premium de Azure API Management. Si selecciona el nivel Premium, puede usar el nivel Desarrollador (no compatible con un contrato de nivel de servicio) para migraciones de prueba de concepto. El nivel Desarrollador admite funcionalidades de red que también están disponibles en el nivel Premium. Sin embargo, no debe usar el nivel Desarrollador para producción.

• En función de los requisitos de disponibilidad, rendimiento y aislamiento de red, tenga en cuenta el nivel Estándar v2 o Premium v2. Ambos admiten la integración con backends aislados de la red. El nivel Premium v2 también admite la inserción en una red virtual para aislar el tráfico entrante.

• Actualmente, el nivel Premium v2 con funcionalidades para aislar el tráfico entrante está en versión preliminar. Puede considerar su uso para migraciones, dependiendo de sus plazos de implementación en relación con la información disponible sobre la versión Premium v2 y las rutas de migración.

Descripción y documentación de las API de origen en administración

Capture configuraciones de API, incluidos los flujos de autenticación y autorización, la transformación y los mecanismos de almacenamiento en caché.

Identifique todos los servicios integrados con Amazon API Gateway, como los autorizadores Lambda, los balanceadores de carga de aplicaciones, los balanceadores de carga de red y los workloads de Kubernetes.

Para catalogar las API bajo administración, considere la posibilidad de usar El Centro de API de Azure y la sincronización de las API desde Amazon API Gateway.

Use herramientas de detección como AWS Resource Explorer siempre que sea posible. Pero se espera confiar en gran medida en la información recopilada manualmente, la documentación interna y las listas de comprobación.

Documente flujos de datos, topología de red y diagramas arquitectónicos, incluso si son aproximados.

Exportación de configuraciones de AWS siempre que sea posible

Exportar configuraciones como:

• Especificaciones de OpenAPI de las API de back-end; por ejemplo, mediante la consola de AWS o la CLI de AWS. Si las API se definieron originalmente a través de OpenAPI, es posible que ya tenga esas especificaciones.

• Certificados SSL/TLS almacenados en AWS Certificate Manager.

• Puedes exportar las reglas de WAF a CloudFormation.

Capture artefactos, incluyendo las plantillas de CloudFormation, que podrían ser exportadas a Terraform a través de herramientas externas. Estos artefactos pueden facilitar el mapeo a Azure (plantillas de Azure Bicep, Azure Resource Manager y Terraform).

Planear una estrategia de fases

Se recomienda planear una migración por fases (API por API o dominio por dominio). Actualice un conjunto de dominios o puntos de conexión de API a Azure API Management, mientras que otros permanecen en AWS y, a continuación, muevan gradualmente el resto. Esta estrategia puede requerir que las aplicaciones cliente controle puntos de conexión mixtos o usen una capa de enrutamiento.

Paso 3: Evaluación

La migración se considera correcta cuando el sistema migrado cumple los criterios de validación y cuando Azure API Management atiende todo el tráfico de producción sin una regresión significativa en la funcionalidad o el rendimiento.

Los criterios de validación incluyen:

• Validar infraestructura: la infraestructura de red de comunicaciones está documentada y es accesible únicamente según lo previsto. Por ejemplo, si se inserta en una red virtual interna, confirme que no hay direcciones IP públicas que lo exponga.

  La instancia de Azure API Management puede llegar a las redes o dependencias necesarias para las operaciones.

• Validar la funcionalidad de API para todos los puntos de conexión: todos los puntos de conexión de API funcionan según lo previsto con escenarios reales, incluidas las solicitudes y cargas válidas y no válidas. Asegúrese de que se realicen las transformaciones de solicitud o respuesta en las directivas configuradas:

  • Confirme todas las configuraciones de autenticación y autorización necesarias (claves de suscripción, tokens de OAuth, certificados) para cada API.

  • Confirme que los clientes pueden usar las API como antes sin cambios (excepto posiblemente la dirección URL del punto de conexión, si el nombre de dominio cambió).

  • Confirme que los límites de tasa y las cuotas están configurados en el ámbito adecuado.

• Validar métricas operativas: supervise el rendimiento mediante paneles u otras herramientas de observabilidad bajo carga de producción. Revise las métricas, como la latencia media y el rendimiento, y compárelas con los datos históricos de Amazon API Gateway. Revise las métricas de capacidad para asegurarse de que la instancia de Azure API Management se escala correctamente.

Paso 4: Proceso

Espere que el proceso de migración tarde varias semanas o meses, en función de la complejidad de la infraestructura de servicio y el número y la complejidad de las API que se van a migrar.

Configuración básica completa

Si aún no tiene el inquilino de Azure y la infraestructura clave (redes centrales, entrada y seguridad) establecidos, créelos antes de migrar la puerta de enlace de API de Amazon y las API. Puede configurar el entorno mediante una arquitectura de zona de aterrizaje de Azure que sea adecuada para la migración.

Si un acelerador de la zona de aterrizaje de infraestructura como código de Azure API Management es adecuado para la migración, implemente uno para la implementación base de Azure API Management. Incluya Application Gateway y redes virtuales internas en Azure API Management. Aunque el acelerador de zona de aterrizaje usa el nivel Premium de Azure API Management, se recomienda adaptar las plantillas para usar el nivel Desarrollador para la migración de prueba de concepto.

Cree y asigne roles de control de acceso basado en rol (RBAC) de Azure para que solo los administradores autorizados puedan administrar la instancia de Azure API Management y las API.

Configuración de la plataforma Azure API Management

En la nueva instancia de Azure API Management, configure configuraciones globales similares a las de Amazon API Gateway:

• Nombre de host personalizado: agregue el dominio personalizado a Azure API Management, cargue el certificado SSL (o use referencias de Key Vault) y realice la validación. Realice esta tarea ahora o justo antes de la transición de producción. Cuando use Application Gateway (recomendado), configure un agente de escucha con el dominio y el certificado personalizados y, a continuación, apunte al punto de conexión interno de Azure API Management. La configuración del agente de escucha simplifica la configuración porque no requiere validación de dominio.

• Redes y seguridad: asegúrese de que Application Gateway (u otro punto de entrada de Azure) esté configurado para reenviar solicitudes a Azure API Management. Configure reglas de grupo de seguridad de red (NSG) o reglas de firewall para que Azure API Management pueda acceder a los servicios de back-end. Estos servicios pueden incluir los back-end de Azure o incluso los back-end de AWS originales si se apunta inicialmente a ellos.

• Identidad administrada: habilite una identidad administrada en Azure API Management para llamar a servicios de Azure de forma segura (como Key Vault para certificados o aplicaciones de funciones).

Al final de esta fase, debe tener un shell de trabajo de Azure API Management en Azure con conectividad y el marco básico listo para empezar a importar las API.

Importación y re-creación de API en Azure API Management

Con la infraestructura lista, comience a migrar las definiciones y configuraciones de API:

• Comience con una API sencilla y de bajo riesgo: use una API representativa para validar la funcionalidad de puerta de enlace básica en Azure API Management antes de volver a crear API desde Amazon API Gateway.

• Importación en Azure API Management: use Azure Portal o scripts para importar definiciones de OpenAPI desde la puerta de enlace de API de Amazon o back-end como nuevas API en Azure API Management. Durante la importación, Azure API Management crea automáticamente la estructura de las API y las operaciones. Si tiene varias fases de API en Amazon API Gateway, cree varias versiones de API en Azure API Management.

  Inicialmente, establezca la dirección URL de back-end de cada API para que apunte al back-end actual. (Por ahora, el back-end actual podría seguir siendo un punto de conexión de AWS o un punto de conexión público). Por ejemplo, si Amazon API Gateway se reenvía a Lambda, puede establecer el back-end de Azure API Management en la API equivalente de Amazon API Gateway o en una aplicación de funciones de Azure equivalente si ya está migrada. (Si establece el back-end de Azure API Management en la API equivalente de Amazon API Gateway, cambiará esta configuración más adelante si migra la función Lambda a Azure). Si el back-end era un equilibrador de carga o un punto de conexión de aplicación de AWS, Azure API Management puede llamarlo a través de Internet.

  Si tiene un gran número de API, puede usar el Centro de API de Azure para catalogar las API que se migran a Azure API Management a lo largo del tiempo y las que permanecen en Amazon API Gateway.

  Considere la posibilidad de migrar o refactorizar servicios back-end (por ejemplo, como aplicaciones de funciones de Azure o cargas de trabajo de AKS) después de validar la infraestructura. Consulte las instrucciones del centro de migración de Azure.

Configuración de la autenticación y autorización

• Suscripciones y productos: si las API requieren claves de API en Amazon API Gateway (a través del x-api-key encabezado), decida cómo controlarlo en Azure API Management. Un enfoque consiste en hacer que esas API sean accesibles solo para los usuarios que tienen una suscripción a un producto. Cree productos iniciales en Azure API Management, ya sea de manera correspondiente uno a uno con los planes de uso de AWS o reorganizados de manera lógica.

• Grupos de usuarios: cree grupos de usuarios en Azure API Management para reflejar cómo compartir las API con los desarrolladores.

• Valores con nombre: importe los valores de configuración (como puntos de conexión o claves de API para los servicios de back-end) que se encontraban en las variables de fase de Amazon API Gateway en valores con nombre de Azure API Management. Para los valores confidenciales, use la integración de Azure Key Vault.

• Recuperación y validación de tokens: para la validación de JWT de solicitudes de API, configure directivas de validación en Azure API Management que autoricen el acceso a la API. Puede usar inicialmente el proveedor de identidades existente (como AWS Cognito) y considerar la migración a lo largo del tiempo a Microsoft Entra ID.

  Configure el administrador de credenciales en Azure API Management para administrar tokens en back-end de OAuth. O bien, configure la lógica de recuperación de tokens mediante directivas del repositorio de Policy snippets.

• Backends en Azure API Management: Configura los backends en el Azure API Management para registrar cada servicio backend (con su dirección URL, credenciales y otra información). Esta acción proporciona un lugar central para actualizar si cambia la dirección URL de back-end. Por ejemplo, si inicialmente apunta a un endpoint de AWS, pero más adelante cambia a un backend de Azure, simplemente puede actualizar la configuración del backend de Azure API Management.

• Verificación de paridad de funciones: Recorra la lista de funciones que usa cada API y asegúrese de que se aborden.

  Por ejemplo, pruebe las API que tratan con cargas binarias (imágenes y archivos) o cargas grandes. Asegúrese de que Azure API Management está configurado con la configuración adecuada de tiempo de espera, tamaño o validación de contenido para esos escenarios.

  Azure API Management trata todas las API importadas de forma bastante uniforme, de modo que las API HTTP de Amazon API Gateway (el tipo ligero más reciente) frente a las API REST (el tipo clásico) se administran de forma coherente en Azure API Management. Las diferencias como la falta de planes de uso en las APIs HTTP son irrelevantes después de que las APIs estén en Azure API Management, pero asegúrese de que se aborden las restricciones específicas de Amazon API Gateway.

Gestión de la transformación y el mapeo de políticas

Replique las configuraciones de API existentes como directivas de Azure API Management cuando corresponda, especialmente para la autorización y la compatibilidad con versiones anteriores.

Asignación de la configuración de CORS en Amazon API Gateway a una directiva de CORS en Azure API Management.

Controle las transformaciones (como la asignación de esquemas o el enriquecimiento) caso por caso.

Las herramientas de IA, como Microsoft Copilot in Azure en Azure Portal y los servidores MCP para AWS y la documentación de Microsoft le ayudarán con la asignación de la configuración u otra transformación. Sin embargo, espere tener que configurar manualmente políticas y depurar en Azure API Management.

Configuración de la observabilidad

Para la supervisión inicial, configure Azure Monitor para recopilar métricas y registros de API. Más soluciones de supervisión o observabilidad, como Application Insights, se pueden superponer más adelante.

Realización de pruebas

Con las API configuradas en Azure API Management, las pruebas exhaustivas son críticas. Espere que esta fase sea iterativa.

• Pruebas funcionales: para cada API, llame al nuevo punto de conexión de Azure API Management (a través de la consola de prueba o las herramientas de cliente de Azure Portal) y compare las respuestas al punto de conexión de Amazon API Gateway. Compruebe si hay códigos de estado, encabezados y cuerpo esperados. Si encuentra diferencias, ajuste las directivas de Azure API Management o la configuración en consecuencia.

  Nota:

  Si la instancia de API Management está en una configuración de red virtual interna, la consola de prueba no funcionará. Puede probar las API mediante otras herramientas de cliente implementadas en la red o mediante el portal para desarrolladores de API Management (si lo habilita para la instancia).

• Pruebas de seguridad: valide que la autenticación de API y la autorización funcionen. Por ejemplo, presente una clave de suscripción o JWT válida en Azure API Management. Asegúrese de que Azure API Management acepta la solicitud y que las credenciales no válidas se rechazan con códigos de error adecuados. Es posible que los clientes que pasen tokens para la validación de JWT necesiten autenticarse con otro proveedor de identidad si configuró uno durante la migración. Si usa claves de suscripción, pruebe con y sin la clave.

• Línea base de rendimiento: use una herramienta para simular la carga en los puntos de conexión de Azure API Management y comprobar que pueden controlar el rendimiento esperado. Compare la latencia de las llamadas a través de Azure API Management con la latencia a través de Amazon API Gateway. Azure API Management en el nivel Desarrollador es menos eficaz que el nivel Premium y la instancia única, por lo que es posible que las pruebas de rendimiento intensivas esperen hasta que implemente una instancia de Azure API Management de nivel Premium.

Inicio de la implementación de producción

Actualice al nivel Premium u otro nivel listo para producción de Azure API Management en el entorno de producción. Repita o migre las opciones de importación y configuración de API que creó en entornos de preproducción. Puede usar procesos de APIOps para publicar API y administrar configuraciones de API en entornos.

Ensaya la transición en un entorno de pruebas o con un subconjunto de tráfico. Por ejemplo, seleccione una API no crítica y haga que una aplicación cliente cambie a mediante el punto de conexión de Azure. Esta práctica puede revelar cualquier problema del lado cliente o ayudar a validar el proceso de cambio de DNS. Si los consumidores de API son internos, puede simular un cambio editando archivos de host o mediante una zona DNS de prueba para apuntar temporalmente el dominio a Azure API Management.

• Conmutador DNS: el enfoque más común es cambiar la entrada DNS del dominio personalizado de Amazon API Gateway para que apunte al nuevo punto de conexión de Azure. Por ejemplo, si ha asignado el dominio api.example.com a Amazon API Gateway, actualice su registro CNAME o A para que apunte al nombre de host de Azure API Management o al dominio front-end (como Application Gateway).

• Consideraciones sobre el período de vida (TTL): reduzca el TTL de DNS por adelantado para que los clientes capten los cambios rápidamente. Cuando esté listo, cambie el DNS. La propagación puede tardar minutos en horas. Durante ese tiempo, es posible que algún tráfico vaya a AWS mientras algunos van a Azure. Si necesitase un corte inmediato, use un método alternativo, como un proxy inverso.

• Métodos alternativos de transición: A veces, en lugar de DNS, las organizaciones usan un proxy inverso o un cambio de puerta de enlace. Por ejemplo, una organización podría mantener el DNS público igual, pero inicialmente hacer que Application Gateway reenvíe las solicitudes a Amazon API Gateway (a través de su dirección URL). Durante la conmutación, la organización dirige internamente Application Gateway hacia Azure API Management. Este enfoque es más complejo, pero puede realizar un cambio instantáneo. Otro método, si usa Azure Front Door o Traffic Manager, es ajustar el peso del tráfico desde un backend (AWS) hacia otro (Azure) gradualmente.

• Supervisión durante la migración: en cuanto se produce el cambio, supervise detenidamente las solicitudes a la instancia de Azure API Management y a Amazon API Gateway. Supervise las métricas de Azure API Management (solicitudes, latencia, CPU, memoria de capacidad) en tiempo real a través de Azure Portal o cualquier panel que configure. Use también Azure Monitor para ver los picos de errores, como las respuestas 4XX/5XX.

• Plan de reversión: decida qué desencadena una reversión. Por ejemplo, si la tasa de errores supera un porcentaje determinado o se interrumpe una funcionalidad crítica, puede revertir en un plazo de 30 minutos. Una reversión significa deshacer cualquier cambio realizado. Por ejemplo, si el cambio fue en DNS, cambie el registro DNS para que vuelva a apuntar a Amazon API Gateway. Debido a la propagación de DNS, la reversión puede tardar algún tiempo. El tiempo de reversión destaca la importancia de un TTL bajo y, posiblemente, de mantener ambos sistemas en ejecución. Si usó un proxy inverso, cámbielo de nuevo a AWS.

Desmantelamiento de Amazon API Gateway

Retirar Amazon API Gateway después de un período cuando recibe cero tráfico y la instancia de Azure API Management cumple los criterios de validación. Normalmente, se ejecutan en paralelo (con Azure tomando todo el tráfico) a través de al menos un ciclo de negocio completo o un período de tráfico máximo para asegurarse de que el nuevo sistema lo controla.

Optimización iterativa

Después de la migración, céntrese en optimizar la configuración de API Management de forma iterativa mediante el cierre de brechas de características y la implementación de procedimientos recomendados. Este proceso de mejora iterativa garantiza que la carga de trabajo migrada cumpla todos los criterios de éxito que estableció durante el paso de evaluación. También garantiza que la carga de trabajo migrada siga los procedimientos recomendados de arquitectura para API Management.

Iterar sobre las deficiencias de características

Algunas características de Amazon API Gateway no tienen una asignación uno a uno en Azure API Management y requieren soluciones alternativas, como se ha descrito anteriormente en la sección Evaluación . Por ejemplo:

• Firewall de aplicaciones web: Azure API Management no bloquea automáticamente las cargas incorrectas que aws WAF bloquea. Si configura Azure Web Application Firewall, asegúrese de que Azure API Management solo sea accesible a través del WAF y de que las reglas de WAF repliquen restricciones de AWS WAF.

• Flujos de eventos: Si las alarmas o eventos de CloudWatch estaban asociados a Amazon API Gateway (por ejemplo, ante ciertos patrones de error), configure alertas equivalentes en Azure Monitor para Azure API Management (por ejemplo, una alerta sobre la tasa de 5XX en Azure API Management).

• Automatización: si tiene canalizaciones de integración continua y entrega continua (CI/CD), integre Azure API Management en ellas. Por ejemplo, puede almacenar las configuraciones de Azure API Management (APIs y directivas) en el control de código fuente mediante enfoques de infraestructura-como-código. Estos enfoques pueden incluir plantillas de Azure Resource Manager, Bicep o Terraform o una metodología de APIOps. Esta integración garantiza que los cambios futuros en las API se puedan implementar de forma coherente con el control de versiones.

Implementación de procedimientos recomendados

Implemente de forma iterativa los procedimientos recomendados, incluida la optimización de costos, la protección de la seguridad y las mejoras operativas. Revise e implemente los procedimientos recomendados de arquitectura para Azure API Management a lo largo de los pilares de confiabilidad, seguridad, excelencia operativa, administración de costos y rendimiento. Solucione las recomendaciones de Azure Advisor para la instancia de Azure API Management.

Con el tiempo, incorpora más capacidades, como:

• Almacenamiento en caché externo.
• Funcionalidades de supervisión más allá de Azure Monitor, como Application Insights o soluciones que no son de Microsoft, como Datadog.
• Directivas de Azure API Management que no están disponibles en Amazon API Gateway.

Conclusiones clave

La migración de Amazon API Gateway a Azure requiere una planeación cuidadosa y ejecución sistemática para obtener funcionalidades equivalentes o enfoques alternativos. Entre los principales factores de éxito se incluyen:

• Evaluación exhaustiva: realice una evaluación detallada de la configuración de Amazon API Gateway existente, incluidas todas las API, las integraciones de servicios y las dependencias. Identifique brechas o diferencias en las funcionalidades entre Amazon API Gateway y Azure API Management.

• Oportunidades de modernización: use la migración como una oportunidad para modernizar o migrar servicios back-end o mejorar el diseño de la API.

• Preparación completa: prepare el entorno de Azure, incluidas las redes, la seguridad y la configuración de la infraestructura. Documente todas las configuraciones y planee los cambios necesarios en los servicios back-end.

• Migración incremental: planee un enfoque de migración incremental, empezando por API o servicios menos críticos. Este enfoque permite probar y validar la nueva configuración antes de comprometerse totalmente con el cambio.

• Validación y pruebas: implemente procesos completos de prueba y validación para asegurarse de que la instancia de Azure API Management cumple todos los requisitos funcionales y de rendimiento. Este esfuerzo incluye pruebas de carga, pruebas de seguridad y pruebas de aceptación de usuarios.

• Supervisión y observabilidad: configure una supervisión y observabilidad sólidas para la nueva instancia de Azure API Management para identificar y solucionar rápidamente los problemas que surjan durante o después de la migración.

• Optimización iterativa: después de la migración, optimice continuamente la configuración de Azure API Management mediante la resolución de brechas de características y la implementación de procedimientos recomendados.