Agence web » Actualités du digital » Comment utiliser la passerelle API d'AWS comme interface pour les fonctions Lambda

Comment utiliser la passerelle API d'AWS comme interface pour les fonctions Lambda

API Gateway est un service entièrement géré pour la création, le test et l'hébergement d'API de production. Plutôt que de louer un serveur EC2 et de gérer vous-même votre serveur API, API Gateway peut le gérer pour vous et rationaliser l'ensemble du processus.

Qu'est-ce que l'API Gateway?

API Gateway est essentiellement un proxy inverse, récupérant les données d'autres services et les renvoyant de manière structurée. Plutôt que de le gérer vous-même, le fardeau de la gestion du trafic et de l'infrastructure est transféré à AWS, qui peut le faire pour beaucoup moins cher.

Cela permet essentiellement à API Gateway d'agir comme une «porte d'entrée» pour de nombreux autres services AWS. Par exemple, en le connectant à AWS Lambda, vous pouvez créer un backend de microservices sans utiliser de serveurs EC2. La fonction Lambda peut être configurée pour la connexion.

API Gateway fait un excellent travail en tant que frontal de base pour les API HTTP à usage général, mais il est également très utile pour gérer la structure globale et le schéma des API REST. Lorsque vous créez des API REST, vous êtes en mesure de définir parfaitement toutes les routes et méthodes et de les connecter à n'importe quel service AWS que vous souhaitez.

API GateWay peut également être utilisé pour gérer les API WebSocket, qui sont utilisées pour une communication rapide en temps réel en ouvrant une connexion directe du serveur au client.

Combien coûte la passerelle API?

Pour les API HTTP génériques, API Gateway coûte simplement 1,00 $ par million de demandes, une fois que vous avez dépassé le premier million fourni avec le niveau gratuit.

Pour les API REST, le prix est plus élevé à 3,50 $ par million de demandes. Facultativement, vous pouvez également choisir d'activer la mise en cache pour votre API REST, ce qui améliorera les performances au prix d'une redevance horaire en fonction de la taille de votre cache.

Pour les API WebSocket, la tarification est un peu différente. Parce qu'ils sont destinés à des messages courts du serveur au client, vous ne payez que 1 $ par milliard demandes, 1000 est bon marché par demande comme les deux autres. Cependant, vous êtes limité à 128 Ko de charges utiles et vous facturez également 0,25 $ par million de minutes de connexion. Si vous avez régulièrement de nombreux clients connectés à l'API WebSocket, vous paierez pour chacun d'eux.

Une chose à noter, cependant, est que bien qu'il n'y ait pas de frais spécifiques pour le transfert de données, les API HTTP sont mesurées par incréments de 512 Ko. Par exemple, une seule demande d'API qui a renvoyé une réponse de 1,5 Mo serait facturée comme trois demandes d'API. Les API WebSocket sont facturées par incréments de 32 Ko. Cela peut facilement doubler les coûts de votre passerelle API si vos charges utiles sont particulièrement importantes.

Bien sûr, si vous vous connectez à un autre service AWS, vous devrez payer tous les coûts associés à ces services (tels que les frais pour les appels de la fonction Lambda) ainsi que les frais de transfert de données pour le déplacement de données hors d'AWS.

Configuration d'une API HTTP pour se connecter à Lambda

Bien que les API REST offrent davantage d'outils d'organisation pour gérer l'API elle-même, elles sont beaucoup plus compliquées et leur démarrage coûte beaucoup plus cher. À la place, nous utiliserons les API HTTP de base, qui sont plus faciles à créer et à connecter à Lambda.

Choisissez de créer une «API HTTP» dans le menu de création. La première chose que vous devrez configurer est vos intégrations; Les API HTTP prennent en charge les points de terminaison HTTP et les fonctions Lambda. Vous pouvez ajouter plusieurs intégrations, ce qui peut être utile si vous souhaitez qu'une fonction Lambda distincte gère chaque route de votre API.

Ensuite, vous allez configurer les itinéraires pour l'API. Ceux-ci peuvent être placés sur des sous-URL comme /userset appellera différentes cibles d'intégration en fonction de la méthode avec laquelle un client se connecte. Par exemple, GET /messages peut renvoyer une liste de messages, mais POST /messages pourrait télécharger un nouveau message.

Vous souhaiterez probablement un moyen de faire la distinction entre les API de développement et de production. Vous pouvez créer plusieurs environnements sous la forme de «étapes», qui serviront cet objectif. Par défaut, le $default l'environnement est automatiquement mis à jour avec toutes les modifications et sert d'étape de développement. Vous souhaiterez probablement créer une étape "Production" que vous pourrez utiliser pour $default à.

Après cela, votre API doit être configurée et prête à l'emploi. Sous "Étapes", vous trouverez l'URL d'invocation de votre API. Ceci est lié à l'étape de déploiement de l'API elle-même et restera statique. Il devrait ressembler à ceci:

https://api_id.execute-api.us-east-1.amazonaws.com

Si vous souhaitez l'utiliser avec un nom de domaine personnalisé, vous devrez générer un certificat ACM pour lier la passerelle API en toute sécurité à votre domaine et modifier votre configuration DNS pour pointer vers la passerelle elle-même. Si vous utilisez Route 53, ce processus est un peu simplifié.

Sous l'onglet "Autorisation", vous trouverez les paramètres de configuration de votre API avec l'authentification JWT. C'est actuellement la seule méthode prise en charge avec les API HTTP.

★★★★★