AWS API Gateway

Ce que couvre le produit

Amazon API Gateway est le service managé d’AWS pour exposer des API. La documentation d’accueil distingue principalement les API REST, les API HTTP et les API WebSocket. Le service reçoit les appels, autorise, limite, journalise et transmet à une intégration : fonction Lambda, endpoint HTTP, service AWS ou autre cible prise en charge. La comparaison officielle entre API HTTP et API REST est documentée à part : HTTP API versus REST API.

Le service se place dans un compte et une région AWS. Les capacités évoluent avec le type d’API choisi. Une étude commence donc par ce choix, pas par une liste générique de fonctions « API Gateway ».

Architecture typique

Une API est publiée sur un nom de domaine, par étape (stage) pour les API REST, avec des routes et des intégrations. Un mécanisme d’autorisation vérifie l’appel : IAM, groupe d’utilisateurs Cognito, ou un autoriseur Lambda qui applique une règle propre au contexte. Des plans d’utilisation et des clés d’API existent sur les API REST. Les API HTTP couvrent un sous-ensemble de fonctions, avec une mise en œuvre plus directe et, en général, de quoi traiter un trafic HTTP simple devant Lambda ou un backend HTTP.

Le service ne se présente pas comme une suite complète avec portail développeur intégré au sens d’Azure API Management ou d’Apigee. La documentation des API se publie par d’autres moyens : export OpenAPI, site de documentation, portail construit à côté. Le dire tôt évite de promettre un catalogue d’abonnements que le service ne porte pas seul.

Les journaux partent vers CloudWatch, les traces vers X-Ray lorsque cette option est activée, et le contrôle d’accès du service lui-même passe par IAM. La passerelle et les backends du même compte partagent ainsi le modèle de droits AWS. Les backends hors d’AWS se raccordent en HTTP, avec les délais et les contrôles de certificat à régler explicitement.

Points forts et limites

Le service retire l’exploitation du processus de proxy. Il se raccorde nativement à Lambda, IAM et aux journaux du compte. Les API HTTP suffisent souvent pour un backend simple. Les API REST ajoutent la validation de requête, les plans d’utilisation et des transformations que les API HTTP ne reprennent pas toutes. Les API WebSocket couvrent un canal maintenu, distinct du requête-réponse.

Les limites viennent de ce découpage. Choisir une API HTTP puis découvrir qu’il faut un plan d’utilisation ou une transformation non disponible oblige à recréer l’API dans l’autre modèle. Le plan de contrôle est AWS : régions, quotas du service et modèle de prix suivent le compte. Il n’y a pas de mode d’installation autonome de cette passerelle dans un autre centre de calcul. L’absence d’un portail intégré est une limite dès que des partenaires externes doivent découvrir les API, s’abonner et gérer leurs clés sans accès à la console AWS.

Quand le retenir

AWS API Gateway convient lorsque les backends sont déjà dans AWS, en particulier Lambda ou des services privés du compte, et lorsque l’équipe accepte de publier la documentation par un canal séparé. Il convient pour un besoin de proxy managé, d’autorisation et de limite de débit, sans plateforme d’API management plus large.

Il convient moins lorsqu’il faut un portail, des produits d’API et un cycle de vie dans le même outil, ou lorsque la passerelle doit s’exécuter dans un réseau que l’organisation contrôle entièrement. On regarde alors Azure API Management, Apigee, Kong ou WSO2 API Manager. Le comparatif pose ces différences sans les classer.

Migration et intégration

Une définition OpenAPI peut servir de base d’import, puis chaque intégration est reliée à la cible réelle. Les autoriseurs se réécrivent. Les clés d’API et les plans d’utilisation, s’ils sont retenus, sont de nouveaux secrets à distribuer. Les noms de domaine personnalisés et les certificats se préparent avant la bascule, de même que l’association éventuelle à AWS WAF.

Les étapes séparent développement, test et production. Les variables d’étape évitent de dupliquer toute l’API pour changer une URL de backend, à condition de ne pas y placer de secret en clair. Les nouvelles tentatives restent sous le contrôle de l’application appelante lorsque l’opération n’est pas idempotente. La passerelle journalise le résultat. Elle ne répare pas un doublon métier.

Depuis l’extérieur du compte, l’intégration se limite à ce que le réseau autorise : API publique, lien privé, VPC link selon le type d’API. Ce choix de réseau fait partie du cadrage, au même titre que le modèle REST ou HTTP.

Les journaux d’exécution se limitent à ce qui aide à comprendre un échec : identifiant de requête, route, code renvoyé, latence et intégration cible. Les corps complets, les jetons et les paramètres de carte n’y ont pas leur place. Une journalisation trop large augmente le coût du service de logs et expose des données qui n’étaient pas destinées à quitter le backend. On la règle par étape, plus bavarde en développement, plus stricte en production.

Ce que Technocify peut prendre en charge

L’audit identifie le type d’API, les intégrations, le mécanisme d’autorisation et le besoin réel de portail. La conception fixe les étapes, les journaux, les noms de domaine et la frontière entre ce que fait la passerelle et ce que fait le backend. La mise en œuvre publie les premières routes et vérifie l’autorisation. Le run suit les erreurs d’intégration, les quotas du service et les changements de contrat exportés en OpenAPI.

Les équipes Technocify s’appuient sur une pratique de l’intégration et des API depuis 2009. Nos consultants sont certifiés WSO2 API Manager Practitioner V4 (2023), WSO2 API Manager Developer V3 (2021), MuleSoft Developer V4 (2022), Workato Automation Pro I, II, III (2025, valides jusqu’en 2027) et ITIL V4 (2020). Voir À propos.

Le périmètre voisin est décrit dans plateformes API et cloud, DevSecOps et cybersécurité.