Migrer amazon API Gateway vers Gestion des API Azure

Si vous utilisez Amazon API Gateway et souhaitez migrer votre charge de travail vers Azure, ce guide vous aide à comprendre les mappages de fonctionnalités, les meilleures pratiques et le processus de migration. Sur Azure, Gestion des API Azure fournit des fonctionnalités de passerelle d’API. Ces fonctionnalités incluent le routage des demandes et des réponses d’API, le contrôle d’autorisation et d’accès, la supervision et la gouvernance, ainsi que la gestion des versions des API.

Ce que vous allez faire

Dans ce guide, vous allez :

• Évaluez votre déploiement actuel de la passerelle d’API Amazon.
• Mappez les fonctionnalités amazon API Gateway aux fonctionnalités de gestion des API Azure.
• Préparez vos environnements Amazon et Azure pour une migration réussie.
• Planifiez et exécutez une migration avec un temps d’arrêt minimal.
• Vérifiez que votre charge de travail migrée répond aux exigences de performances et de fiabilité.
• Découvrez comment itérer sur l’architecture pour des améliorations futures.

Exemple de scénario : système de dossiers de santé à plusieurs systèmes de backend

Une organisation de services de santé utilise Amazon API Gateway pour accéder à un système de dossiers de santé qui a plusieurs back-ends. Cet exemple de scénario présente une configuration courante d’Amazon API Gateway dans un environnement Amazon Web Services (AWS). Il présente des intégrations classiques avec les services Amazon associés et plusieurs back-ends d’API courants, notamment les fonctions lambda proxiées et les API HTTP ou REST.

Cette architecture inclut les éléments suivants :

• Authentification utilisateur via Amazon Cognito avec des jetons web JSON (JWTs).

• Filtrage de sécurité des requêtes via le pare-feu d’applications web Amazon (WAF) avant d’atteindre Amazon API Gateway.

• Amazon API Gateway configuré avec un domaine personnalisé via un certificat stocké dans Certificate Manager.

• Surveillance via Amazon CloudWatch.

• Connectivité privée via des points de terminaison de cloud privé virtuel Amazon (VPC) vers trois sous-réseaux privés.

• Services principaux, notamment :

  • Lambda pour déclencher les mises à jour des enregistrements des patients.
  • Amazon Elastic Compute Cloud (EC2), qui héberge les services hérités derrière un équilibreur de charge d’application.
  • Amazon Elastic Kubernetes Service (EKS) derrière un équilibreur de charge d’application pour le traitement des données via des microservices.

Voici un exemple d’architecture de la charge de travail migrée vers Azure. Dans ce scénario, Gestion des API Azure est déployée dans le niveau Premium.

Cette architecture inclut les éléments suivants :

• Entrée sécurisée via Azure Application Gateway avec un pare-feu d’applications web (WAF). Le pare-feu transfère les demandes avec un JWT ajouté pour l’authentification.

• Gestion des API Azure configurée à l’intérieur d’un réseau virtuel. Il utilise l’ID Microsoft Entra pour valider les JWT.

• Équilibreur de charge interne qui route le trafic vers Azure Kubernetes Service (AKS) pour les back-ends basés sur des microservices.

• Sécuriser les connexions via des points de terminaison privés vers des applications de fonction Azure et des back-ends Microsoft Foundry.

• Supervision gérée par Azure Monitor.

• Certificats et domaine gérés via Azure Key Vault et une zone Azure DNS. Un certificat est également configuré sur Application Gateway pour l’arrêt TLS.

Vue d’ensemble de l’architecture

Cet exemple d’architecture présente les fonctionnalités courantes dans Amazon API Gateway et Gestion des API Azure. Ces fonctionnalités incluent l’isolation réseau, la gestion du trafic et le routage vers diverses API back-end, le contrôle d’autorisation et d’accès et la surveillance.

Les deux architectures offrent des fonctionnalités comparables :

• Déploiement à haute disponibilité : les ressources sont distribuées entre plusieurs zones de disponibilité dans une région pour la tolérance de panne, avec des options pour une disponibilité plus élevée en fonction du déploiement dans plusieurs régions.

• Domaines et certificats personnalisés : les plateformes prennent en charge les noms de domaine personnalisés avec l’arrêt TLS/SSL pour la communication d’API sécurisée.

• Isolation du réseau : le trafic vers les API back-end est isolé dans un réseau virtuel.

• Filtrage du trafic : un pare-feu d’applications web au niveau de la périphérie filtre et aide à protéger le trafic entrant.

• Prise en charge des charges de travail d’API : les passerelles agissent en tant que proxys pour les demandes adressées à différents systèmes principaux, notamment les services de calcul cloud, les microservices basés sur Kubernetes et les back-ends personnalisés.

• Surveillance des API : Les services intégrés de la plateforme enregistrent l'activité de l'API et exposent les métriques de service.

• Modulation d’API : les services prennent en charge la mise en cache des réponses, les quotas de requête et les limites de débit, la configuration de partage de ressources inter-origines (CORS) et les transformations de requête/réponse.

• Authentification et autorisation de l’API : les passerelles prennent en charge plusieurs méthodes d’accès, notamment les clés, l’accès basé sur les jetons OAuth et les stratégies basées sur les API.

Étape 1 : évaluation

Avant de migrer d’Amazon API Gateway vers Gestion des API Azure, évaluez les fonctionnalités d’infrastructure existantes, les charges de travail d’API et les configurations d’API. Identifiez les fonctionnalités à mapper ou à remplacer. Cette évaluation permet de garantir une migration fluide et de gérer les fonctionnalités de vos applications.

Évaluer les fonctionnalités d’infrastructure

Incompatibilités et stratégies de capacité

• L’intégration de WAF dans Amazon API Gateway n’a pas de correspondance directe dans Gestion des API Azure. Dans Amazon API Gateway, les règles WAF sont directement appliquées aux étapes de l’API REST. Dans Gestion des API Azure, la configuration des règles WAF nécessite généralement le déploiement d’une instance Application Gateway en amont, le transfert de trafic et l’arrêt TLS via la passerelle. Pour les scénarios multirégions actifs/actifs, vous pouvez également utiliser Azure Front Door en amont de la gestion des API Azure.
• Les domaines personnalisés sont pris en charge dans Gestion des API Azure. Si vous utilisez Application Gateway et le pare-feu d’applications web Azure en face, vous devez également configurer le domaine personnalisé et le certificat TLS au niveau de la couche Application Gateway.
• Les points de terminaison optimisés pour la périphérie dans Amazon API Gateway prennent en charge les clients distribués géographiquement. La fonctionnalité similaire dans Gestion des API Azure nécessite le déploiement de passerelles régionales supplémentaires à un coût supplémentaire.

Comparer les charges de travail d’API

Dans le cadre de l’évaluation, déterminez s’il faut conserver ou remplacer les services existants. Évaluez si la migration est l’occasion de moderniser ou de consolider les services.

Incompatibilités et stratégies de capacité

• Les back-ends lambda sont pris en charge en mode natif dans Amazon API Gateway en tant qu’API HTTP. Gestion des API Azure ne fournit pas d’intégration native avec les applications de fonction Azure comparables. La solution Azure API Management doit appeler des applications fonction via HTTP à l’aide d’une clé de fonction ou d’une identité managée.
• Les spécifications OpenAPI exportées à partir d’une API REST Amazon API Gateway contiennent des détails spécifiques à l’implémentation frontale dans Amazon API Gateway, et non le service principal. Vous devez supprimer des balises spécifiques à AWS et configurer des détails dans la spécification (par exemple, l’URL du service principal) avant d’importer dans Gestion des API Azure ou pendant le processus de migration.
• Les back-ends de microservices Kubernetes , tels que les API gRPC, sont gérés différemment :
  • Amazon API Gateway se connecte à l’équilibreur de charge de l’application dans le VPC qui fournit à son tour une entrée dans AWS EKS.
  • La Gestion des API Azure prend en charge les API gRPC sur les clusters Kubernetes, accessibles uniquement par la passerelle auto-hébergée.
  • L’utilisation de gRPC empêche l’utilisation d’Application Gateway en tant que WAF.

Comparer les configurations d’API

L’approche de migration pour les configurations d’API doit prendre en compte l’étendue de la configuration dans Amazon API Gateway. À un niveau élevé, les étendues d’API sont mappées comme suit de Amazon API Gateway à Gestion des API Azure :

Le tableau suivant évalue les configurations d’API dans Amazon API Gateway et les configurations équivalentes dans Gestion des API Azure :

Incompatibilités et stratégies de capacité

• Les limites de quota et de régulation sont imposées par Amazon API Gateway pour chaque compte AWS. Dans Gestion des API Azure, la portée la plus élevée est l’étendue « toutes les API » par instance.

• Les méthodes d’authentification et d’autorisation d’API dans Amazon API Gateway, telles que les autorisations IAM et les autorisations Lambda, ne sont pas mappées directement à Gestion des API Azure. Les clients peuvent évaluer d’autres méthodes d’authentification et d’autorisation, telles que l’utilisation de l’ID Microsoft Entra ou d’un fournisseur d’identité externe.

• Les métriques liées au cache dans Amazon API Gateway ne sont pas mappées directement aux métriques gestion des API Azure. Les succès et les échecs du cache peuvent être comptabilisés dans les journaux de suivi dans Azure API Management.

Passer en revue les ressources pour la migration

• Zone d’atterrissage Gestion des API Azure

• Meilleures pratiques en matière d’architecture pour Gestion des API Azure

• Authentification et autorisation d’API dans Gestion des API Azure

• Azure pour les professionnels d'AWS

• Microsoft Copilot dans Azure pour la génération de stratégie Gestion des API

• Serveur MCP de documentation AWS et serveur Microsoft Learn MCP

En outre, pour les charges de travail d’API :

• Migrer des charges de travail AWS Lambda vers Azure Functions

• Migrer d’Amazon Elastic Kubernetes Service vers Azure Kubernetes Service

Étape 2 : préparation

Dans la phase de préparation, planifiez votre infrastructure Azure, sélectionnez les niveaux de gestion des API appropriés pour les tests et la production, puis documentez soigneusement vos API sources et vos services intégrés. Exportez les configurations AWS pertinentes et concevez une stratégie de migration par phases pour garantir une transition fluide.

Planifier la configuration de l’infrastructure

Planifiez l’entrée et la sortie, les pare-feu, l’isolation réseau et l’intégration à des points d’entrée de trafic réseau tels qu’Application Gateway, Azure Front Door ou Azure Traffic Manager. Comprendre les implications de l’exposition privée et publique du système de gestion des API Azure cible, en particulier autour du DNS et de la traçabilité.

Passez en revue les conseils dans l’accélérateur de zone d'atterrissage pour la gestion des API Azure et évaluez les scénarios qui pourraient être adaptés à vos API et back-ends de migration. Tenez compte du moment où les charges de travail sont suffisamment isolées pour en tirer parti.

Un scénario de base que vous pouvez utiliser pour la migration initiale et la génération dans Azure est une base de référence sécurisée avec un exemple de charge de travail.

Planifier les instances de gestion des API de test et de production

Choisissez les niveaux de service Gestion des API Azure appropriés pour les environnements de test et de production :

• Si vous avez besoin d’une isolation réseau du trafic entrant et sortant, ainsi que de l’entrée de trafic via Azure Front Door ou Application Gateway, nous vous recommandons actuellement le niveau Premium Gestion des API Azure. Si vous sélectionnez le niveau Premium, vous pouvez utiliser le niveau Développeur (non pris en charge avec un contrat de niveau de service) pour les migrations de preuve de concept. Le niveau Développeur prend en charge les fonctionnalités de mise en réseau qui sont également disponibles dans le niveau Premium. Toutefois, vous ne devez pas utiliser le niveau Développeur pour la production.

• Selon vos besoins en matière de disponibilité, de performances et d’isolation réseau, tenez compte du niveau Standard v2 ou Premium v2. Les deux prennent en charge l’intégration avec des systèmes dorsaux isolés du réseau. Le niveau Premium v2 prend également en charge l’injection dans un réseau virtuel pour isoler le trafic entrant.

• Actuellement, le niveau Premium v2 avec des fonctionnalités permettant d’isoler le trafic entrant est en préversion. Vous pouvez envisager de l’utiliser pour les migrations, en fonction de vos chronologies d’implémentation par rapport aux informations disponibles sur la version Premium v2 et les chemins de migration.

Comprendre et documenter les API sources sous gestion

Capturez les configurations d’API, notamment les flux d’authentification et d’autorisation, la transformation et les mécanismes de mise en cache.

Identifiez tous les services intégrés à Amazon API Gateway, tels que les autorisations Lambda, les équilibreurs de charge d’application, les équilibreurs de charge réseau et les charges de travail Kubernetes.

Pour le catalogage des API sous gestion, envisagez d’utiliser le Centre des API Azure et de synchroniser les API à partir d’Amazon API Gateway.

Utilisez des outils de découverte tels que AWS Resource Explorer dans la mesure du possible. Mais vous prévoyez de vous appuyer fortement sur les informations collectées manuellement, la documentation interne et les listes de contrôle.

Flux de données de document, topologie réseau et diagrammes architecturaux, même s’ils sont approximatifs.

Exporter des configurations AWS si possible

Exportez des configurations telles que :

• Spécifications OpenAPI à partir des API principales ; par exemple, à l’aide de la console AWS ou de l’interface CLI AWS. Si les API ont été définies via OpenAPI à l’origine, vous pouvez déjà avoir ces spécifications.

• Certificats SSL/TLS stockés dans AWS Certificate Manager.

• Règles WAF, en exportant vers CloudFormation.

Capturez des artefacts, y compris des modèles CloudFormation, qui peuvent être exportés vers Terraform via des outils externes. Ces artefacts peuvent faciliter le mappage vers Azure (Modèles Bicep, Azure Resource Manager et Terraform).

Planifier une stratégie de phase

Nous vous recommandons de planifier une migration par phases (API par API ou domaine par domaine). Mettez à jour un ensemble de domaines ou de points de terminaison d’API vers Gestion des API Azure, tandis que d’autres restent sur AWS, puis déplacez progressivement le reste. Cette stratégie peut nécessiter que vos applications clientes gèrent des points de terminaison mixtes ou utilisent une couche de routage.

Étape 3 : évaluation

La migration est considérée comme réussie lorsque le système migré répond aux critères de validation et quand Azure API Management sert tout le trafic de production sans régression significative dans les fonctionnalités ou les performances.

Les critères de validation sont les suivants :

• Valider l’infrastructure : l’infrastructure réseau est documentée et accessible uniquement comme prévu. Par exemple, si elle est injectée dans un réseau virtuel interne, vérifiez qu’aucune adresse IP publique ne l’expose.

  L’instance Gestion des API Azure peut atteindre tous les réseaux ou dépendances requis pour les opérations.

• Valider la fonctionnalité d’API pour tous les points de terminaison : tous les points de terminaison d’API s’exécutent comme prévu avec des scénarios réels, notamment des requêtes et charges utiles valides et non valides. Vérifiez que toutes les transformations de requête ou de réponse dans les stratégies configurées ont lieu :

  • Vérifiez toutes les configurations d’authentification et d’autorisation requises (clés d’abonnement, jetons OAuth, certificats) pour chaque API.

  • Vérifiez que les clients peuvent utiliser des API comme avant sans aucune modification (sauf éventuellement l’URL du point de terminaison, si le nom de domaine a changé).

  • Vérifiez que les limites de débit et les quotas sont configurés au niveau de l’étendue appropriée.

• Valider les métriques opérationnelles : surveillez les performances à l’aide de tableaux de bord ou d’autres outils d’observabilité sous charge de production. Passez en revue les métriques telles que la latence et le débit moyens, et comparez-les aux données historiques d’Amazon API Gateway. Passez en revue les métriques de capacité pour vous assurer que l’instance Gestion des API Azure est correctement mise à l’échelle.

Étape 4 : processus

Attendez-vous que le processus de migration prenne plusieurs semaines ou mois, en fonction de la complexité de l’infrastructure de service et du nombre et de la complexité des API à migrer.

Configuration de base complète

Si vous n’avez pas encore le locataire Azure et l’infrastructure de base (réseau principal, entrée, sécurité) en place, générez-les avant de migrer Amazon API Gateway et les API. Vous pouvez configurer l’environnement à l’aide d’une architecture de zone d’atterrissage Azure adaptée à votre migration.

Si un accélérateur de zone d'atterrissage d'infrastructure en tant que code pour Azure API Management convient à votre migration, implémentez-en un pour votre déploiement de base de Gestion des API Azure. Incluez Application Gateway et la mise en réseau virtuelle interne dans Gestion des API Azure. Bien que l’accélérateur de zone d’atterrissage utilise le niveau Premium de Gestion des API Azure, nous vous recommandons d’adapter les modèles pour utiliser le niveau Développeur pour la migration de preuve de concept.

Créez et attribuez des rôles de contrôle d’accès en fonction du rôle Azure (RBAC) afin que seuls les administrateurs autorisés puissent gérer l’instance Gestion des API Azure et les API.

Configurer les paramètres de la plateforme Gestion des API Azure

Dans la nouvelle instance Gestion des API Azure, configurez des configurations globales similaires à celles de Amazon API Gateway :

• Nom d’hôte personnalisé : ajoutez votre domaine personnalisé à Gestion des API Azure, chargez le certificat SSL (ou utilisez les références Key Vault) et effectuez la validation. Effectuez cette tâche maintenant ou juste avant le basculement de production. Lorsque vous utilisez Application Gateway (recommandé), configurez un écouteur avec le domaine et le certificat personnalisés, puis pointez-le vers le point de terminaison interne de Gestion des API Azure. La configuration de l’écouteur simplifie la configuration, car elle ne nécessite pas de validation de domaine.

• Mise en réseau et sécurité : assurez-vous qu’Application Gateway (ou un autre point d’entrée Azure) est configuré pour transférer des demandes à Gestion des API Azure. Configurez des règles de groupe de sécurité réseau (NSG) ou des règles de pare-feu pour permettre à Gestion des API Azure d’atteindre les services principaux. Ces services peuvent inclure vos back-ends Azure ou même les back-ends AWS d'origine si vous les ciblez initialement.

• Identité managée : activez une identité managée sur Gestion des API Azure pour appeler des services Azure en toute sécurité (comme Key Vault pour les certificats ou les applications de fonction).

À la fin de cette phase, vous devez disposer d’un interpréteur de commandes de Gestion des API Azure dans Azure avec une connectivité et l’infrastructure de base prête à commencer à importer des API.

Importer et recréer des API dans Gestion des API Azure

Une fois l’infrastructure prête, commencez à migrer les définitions et configurations d’API :

• Commencez par une API simple à faible risque : utilisez une API représentative pour valider les fonctionnalités de passerelle de base dans Gestion des API Azure avant de recréer des API à partir d’Amazon API Gateway.

• Importer dans Gestion des API Azure : utilisez le portail Azure ou les scripts pour importer des définitions OpenAPI à partir d’Amazon API Gateway ou de back-ends en tant que nouvelles API dans Gestion des API Azure. Lors de l’importation, Gestion des API Azure crée automatiquement la structure des API et des opérations. Si vous avez plusieurs étapes d’API dans Amazon API Gateway, créez plusieurs versions d’API dans Gestion des API Azure.

  Initialement, définissez l’URL du back-end pour chaque API pour qu’elle pointe vers le back-end actuel. (Pour l’instant, le serveur principal actuel peut toujours être un point de terminaison AWS ou un point de terminaison public.) Par exemple, si Amazon API Gateway a été transférée à Lambda, vous pouvez définir le back-end Gestion des API Azure sur l’API équivalente dans Amazon API Gateway ou vers une application de fonction Azure équivalente si elle est déjà migrée. (Si vous définissez le back-end Gestion des API Azure sur l’API équivalente dans Amazon API Gateway, vous allez modifier cette configuration ultérieurement si vous migrez la fonction Lambda vers Azure.) Si le serveur principal était un équilibreur de charge ou un point de terminaison d’application AWS, Gestion des API Azure peut l’appeler via Internet.

  Si vous avez un grand nombre d’API, vous pouvez utiliser le Centre des API Azure pour cataloguer les API migrées vers Gestion des API Azure au fil du temps et celles qui restent dans Amazon API Gateway.

  Envisagez de migrer ou de refactoriser les services principaux (par exemple, en tant qu’applications de fonction Azure ou charges de travail AKS) après avoir validé l’infrastructure. Consultez les conseils du hub de migration Azure.

Configurer l’authentification et l’autorisation

• Abonnements et produits : si vos API ont besoin de clés API dans Amazon API Gateway (via l’en-tête x-api-key ), décidez comment gérer cela dans Gestion des API Azure. Une approche consiste à rendre ces API accessibles uniquement aux utilisateurs qui ont un abonnement à un produit. Créez des produits initiaux dans Azure API Management, correspondant un à un aux plans d’utilisation AWS ou réorganisés logiquement.

• Groupes d’utilisateurs : créez des groupes d’utilisateurs dans Gestion des API Azure pour mettre en miroir la façon dont vous partagez des API avec les développeurs.

• Valeurs nommées : importez toutes les valeurs de configuration (comme les points de terminaison ou les clés API pour les services principaux) qui étaient dans les variables d’étape de la passerelle API Amazon dans les valeurs nommées Gestion des API Azure. Pour les valeurs sensibles, utilisez l’intégration d’Azure Key Vault.

• Récupération et validation des jetons : pour la validation JWT des demandes d’API, configurez des stratégies de validation dans Gestion des API Azure qui autorisent l’accès aux API. Vous pouvez initialement utiliser votre fournisseur d’identité existant (par exemple AWS Cognito) et envisager la migration au fil du temps vers l’ID Microsoft Entra.

  Configurez le gestionnaire d’informations d’identification dans Gestion des API Azure pour gérer les jetons sur les back-ends OAuth. Vous pouvez également configurer la logique de récupération de jeton à l’aide des polices à partir du référentiel d’extraits de politiques.

• Back-ends dans Gestion des API Azure : configurez les back-ends dans Gestion des API Azure pour inscrire chaque service principal (avec son URL, ses informations d’identification et d’autres informations). Cette action fournit un emplacement central à mettre à jour si l’URL principale change. Par exemple, si vous pointez initialement vers un point de terminaison AWS, mais que vous basculez ultérieurement vers un back-end Azure, vous pouvez simplement mettre à jour la configuration du back-end Gestion des API Azure.

• Vérifications de parité des fonctionnalités : parcourez la liste des fonctionnalités que chaque API utilise et assurez-vous qu’elles sont traitées.

  Par exemple, les API de test qui traitent des charges utiles binaires (images et fichiers) ou des charges utiles volumineuses. Assurez-vous que La gestion des API Azure est configurée avec des paramètres de validation de contenu, de taille ou de délai d’expiration adéquats pour ces scénarios.

  Gestion des API Azure traite toutes les API importées de manière assez uniforme, de sorte que les API HTTP Amazon API Gateway (le type léger plus récent) et les API REST (le type classique) soient gérées de manière cohérente dans Gestion des API Azure. Les différences telles que l'absence de plans d'utilisation dans les API HTTP deviennent insignifiantes une fois que les API se trouvent dans la gestion des API Azure, mais assurez-vous que les contraintes spécifiques à la passerelle API Amazon sont traitées.

Gérer la transformation et le mappage de stratégie

Répliquez les configurations d’API existantes en tant que stratégies de gestion des API Azure le cas échéant, en particulier pour l’autorisation et la compatibilité descendante.

Mapper la configuration CORS dans Amazon API Gateway à une stratégie CORS dans Gestion des API Azure.

Gérez les transformations (telles que le mappage de schéma ou l’enrichissement) par cas.

Les outils d'IA tels que Microsoft Copilot dans le portail Azure et les serveurs MCP pour AWS et la documentation Microsoft peuvent vous aider à effectuer un mappage de configuration ou d'autres transformations. Cependant, attendez-vous à devoir configurer et déboguer manuellement les stratégies dans le service Azure API Management.

Configurer l’observabilité

Pour la supervision initiale, configurez Azure Monitor pour collecter les métriques et les journaux d’activité de l’API. Des solutions de surveillance ou d’observabilité supplémentaires, telles que Application Insights, peuvent être superposées ultérieurement.

Effectuer des tests

Avec les API configurées dans Gestion des API Azure, des tests approfondis sont essentiels. Attendez-vous à ce que cette phase soit itérative.

• Test fonctionnel : pour chaque API, appelez le nouveau point de terminaison Gestion des API Azure (via la console de test ou les outils clients du portail Azure) et comparez les réponses au point de terminaison Amazon API Gateway. Vérifiez les codes d'état, les en-têtes et le corps attendus. Si vous trouvez des différences, ajustez les stratégies ou la configuration de gestion des API Azure en conséquence.

  Note

  Si l’instance Gestion des API se trouve dans une configuration de réseau virtuel interne, la console de test ne fonctionnera pas. Vous pouvez tester les API à l’aide d’autres outils clients déployés dans le réseau ou à l’aide du portail des développeurs Gestion des API (si vous l’activez pour votre instance).

• Test de sécurité : vérifiez que l’authentification et l’autorisation de l’API fonctionnent. Par exemple, présentez une clé JWT ou d’abonnement valide à Gestion des API Azure. Vérifiez que Gestion des API Azure accepte la demande et que les informations d’identification non valides sont rejetées avec des codes d’erreur appropriés. Les clients qui passent des jetons pour la validation JWT peuvent avoir besoin de s’authentifier auprès d’un autre fournisseur d’identité si vous en avez configuré un lors de la migration. Si vous utilisez des clés d’abonnement, testez avec et sans la clé.

• Base de référence des performances : utilisez un outil pour simuler la charge sur les points de terminaison gestion des API Azure et vérifier qu’ils peuvent gérer le débit attendu. Comparez la latence des appels via Gestion des API Azure à la latence via Amazon API Gateway. La gestion des API Azure dans le niveau Développeur est moins performante que le niveau Premium et l’instance unique. Les tests de performances lourds peuvent donc attendre que vous déployiez une instance Gestion des API Azure de niveau Premium.

Commencer le déploiement de production

Effectuez une mise à niveau vers le niveau Premium ou un autre niveau prêt pour la production de Gestion des API Azure dans l’environnement de production. Répétez ou migrez les paramètres d’importation et de configuration de l’API que vous avez créés dans des environnements de préproduction. Vous pouvez utiliser des processus APIOps pour publier des API et gérer des configurations d’API dans les environnements.

Simulez le basculement dans un environnement de niveau inférieur ou à l’aide d’un sous-ensemble de trafic. Par exemple, sélectionnez une API non critique et utilisez un commutateur d’application cliente pour utiliser le point de terminaison Azure. Cette pratique peut révéler tous les problèmes côté client ou aider à valider votre processus de modification DNS. Si vos consommateurs d’API sont internes, vous pouvez simuler une modification en modifiant des fichiers hôtes ou en utilisant une zone DNS de test pour pointer temporairement le domaine vers Gestion des API Azure.

• Commutateur DNS : L’approche la plus courante consiste à basculer l’entrée DNS de votre domaine Amazon API Gateway personnalisé pour pointer vers le nouveau point de terminaison Azure. Par exemple, si vous avez mappé votre domaine api.example.com à Amazon API Gateway, mettez à jour son enregistrement CNAME ou A pour pointer vers le nom d’hôte Gestion des API Azure ou vers le domaine frontal (comme Application Gateway).

• Considérations relatives à la durée de vie (TTL) : réduisez la durée de vie DNS au préalable afin que les clients récupèrent rapidement les modifications. Lorsque vous êtes prêt, modifiez le DNS. La propagation peut prendre des minutes à heures. Pendant ce temps, certains trafics peuvent toujours aller à AWS, tandis que certains vont à Azure. Si vous avez besoin d’une coupe immédiate, vous pouvez utiliser une autre méthode telle qu’un proxy inverse.

• Autres méthodes de basculement : Parfois, au lieu de DNS, les organisations utilisent un proxy inverse ou un retournement de passerelle. Par exemple, une organisation peut conserver le DNS public identique, mais faire en sorte qu'initialement Application Gateway transfère des requêtes vers Amazon API Gateway (via son URL). Pendant la redirection, l'organisation dirige Application Gateway vers Azure API Management en interne. Cette approche est plus complexe, mais elle peut permettre un changement instantané. Une autre méthode, si vous utilisez Azure Front Door ou Traffic Manager, consiste à rééployer le trafic d’un back-end (AWS) vers un autre (Azure) progressivement.

• Supervision pendant le basculement : dès que le basculement se produit, surveillez étroitement les demandes à la fois pour l’instance de gestion des API Azure et la passerelle API Amazon. Surveillez les métriques gestion des API Azure (demandes, latence, processeur, mémoire de capacité) en temps réel via le portail Azure ou le tableau de bord que vous avez configuré. Utilisez également Azure Monitor pour surveiller les pics d’erreurs, tels que les réponses 4XX/5XX.

• Plan de restauration : déterminez ce qui déclenche une restauration. Par exemple, si le taux d’erreur dépasse un certain pourcentage ou qu’une fonctionnalité critique est rompue, vous pouvez revenir dans les 30 minutes. Une réversion signifie annuler toute modification que vous avez effectuée. Par exemple, si le commutateur était DNS, rétablissez l’enregistrement DNS pour qu’il pointe vers Amazon API Gateway. En raison de la propagation DNS, la restauration peut prendre un certain temps. Le temps de restauration met en évidence l’importance d’une durée de vie (TTL) faible et éventuellement du bon fonctionnement des deux systèmes. Si vous avez utilisé un proxy inverse, revenez à AWS.

Désaffecter Amazon API Gateway

Désaffectez Amazon API Gateway après une période où elle reçoit zéro trafic et que l’instance Gestion des API Azure répond aux critères de validation. En règle générale, vous exécutez les deux en parallèle (avec Azure prenant tout le trafic) via au moins un cycle d’activité complet ou une période de trafic de pointe pour vous assurer que le nouveau système le gère.

Optimisation itérative

Après la migration, concentrez-vous sur l’optimisation de la configuration gestion des API de manière itérative en fermant les lacunes des fonctionnalités et en implémentant les meilleures pratiques. Ce processus d’amélioration itérative garantit que la charge de travail migrée répond à tous les critères de réussite que vous avez établis pendant l’étape d’évaluation. Elle garantit également que la charge de travail migrée suit les meilleures pratiques d’architecture pour gestion des API.

Itérer sur les lacunes des fonctionnalités

Certaines fonctionnalités amazon API Gateway n’ont pas de mappage un-à-un dans Gestion des API Azure et nécessitent des solutions de contournement, comme décrit précédemment dans la section Évaluation . Par exemple:

• Pare-feu d’applications web : Gestion des API Azure ne bloque pas automatiquement les charges utiles incorrectes bloquées par AWS WAF. Si vous configurez le pare-feu d’applications web Azure, assurez-vous que la gestion des API Azure est accessible uniquement par le biais du WAF et que les règles WAF répliquent les restrictions DU WAF AWS.

• Flux d’événements : si les alarmes ou événements CloudWatch étaient liés à Amazon API Gateway (par exemple, sur certains modèles d’erreur), configurez des alertes équivalentes dans Azure Monitor pour Gestion des API Azure (par exemple, une alerte sur un taux 5XX de gestion des API Azure).

• Automatisation : si vous avez des pipelines d’intégration continue et de livraison continue (CI/CD), intégrez Gestion des API Azure dans ces pipelines. Par exemple, vous pouvez stocker vos configurations de gestion des API Azure (API et stratégies) dans le contrôle de code source à l’aide d’approches infrastructure-as-code. Ces approches peuvent inclure des modèles Azure Resource Manager, Bicep ou Terraform, ou une méthodologie APIOps. Cette intégration garantit que les futures modifications apportées aux API peuvent être déployées de manière cohérente avec le contrôle de versioning.

Implémenter les meilleures pratiques

Implémentez de manière itérative les meilleures pratiques, notamment l’optimisation des coûts, le renforcement de la sécurité et les améliorations opérationnelles. Passez en revue et implémentez les meilleures pratiques d’architecture pour La gestion des API Azure le long des piliers de la fiabilité, de la sécurité, de l’excellence opérationnelle, de la gestion des coûts et des performances. Résolvez les recommandations d’Azure Advisor pour votre instance Gestion des API Azure.

Au fil du temps, intégrez progressivement d'autres fonctionnalités telles que :

• Mise en cache externe.
• Fonctionnalités de supervision au-delà d’Azure Monitor, telles que Application Insights ou des solutions non-Microsoft telles que Datadog.
• Stratégies dans Gestion des API Azure qui ne sont pas disponibles dans Amazon API Gateway.

Points clés à prendre

La migration d’Amazon API Gateway vers Azure nécessite une planification minutieuse et une exécution systématique pour obtenir des fonctionnalités équivalentes ou d’autres approches. Les principaux facteurs de réussite sont les suivants :

• Évaluation approfondie : effectuez une évaluation détaillée de la configuration existante d’Amazon API Gateway, y compris toutes les API, intégrations de service et dépendances. Identifiez les lacunes ou les différences dans les fonctionnalités entre Amazon API Gateway et Gestion des API Azure.

• Opportunités de modernisation : utilisez la migration comme opportunité de moderniser ou de migrer des services principaux ou d’améliorer la conception des API.

• Préparation complète : Préparez l’environnement Azure, notamment la mise en réseau, la sécurité et la configuration de l’infrastructure. Documentez toutes les configurations et planifiez les modifications nécessaires apportées aux services principaux.

• Migration incrémentielle : planifiez une approche de migration incrémentielle, en commençant par des API ou des services moins critiques. Cette approche permet de tester et de valider la nouvelle configuration avant de valider entièrement le commutateur.

• Validation et test : implémentez des processus de test et de validation complets pour vous assurer que l’instance Gestion des API Azure répond à toutes les exigences fonctionnelles et de performances. Cet effort inclut les tests de charge, les tests de sécurité et les tests d’acceptation des utilisateurs.

• Surveillance et observabilité : configurez une surveillance et une observabilité robustes pour la nouvelle instance gestion des API Azure pour identifier et résoudre rapidement les problèmes qui surviennent pendant ou après la migration.

• Optimisation itérative : après la migration, optimisez en permanence la configuration de Gestion des API Azure en répondant aux lacunes des fonctionnalités et en implémentant les meilleures pratiques.