Équilibreurs de charge d'application vs passerelle API
AWS est fourni avec un service appelé Application Load Balancer et cela pourrait être un déclencheur pour une fonction lambda. La façon d'appeler une telle fonction lambda consiste à envoyer une requête HTTP/HTTPS à ALB.
Maintenant, ma question est de savoir comment cela est différent de l'utilisation de la passerelle API? Et quand doit-on utiliser ALB sur API Gateway (ou l'inverse)?
L'une des principales raisons pour lesquelles nous utilisons une passerelle API devant nos fonctions lambda au lieu d'utiliser un ALB est l'intégration native IAM (Identity and Access Management) de l'API GW. Nous n'avons pas à effectuer nous-mêmes le travail d'identité, tout est délégué à IAM, et en plus de cela, API GW a une validation de demande intégrée, y compris la validation des paramètres de chaîne de requête et des en-têtes. En un mot, il y a tellement d'intégrations prêtes à l'emploi qui viennent avec API GW, vous vous retrouvez à devoir faire beaucoup plus de travail si vous suivez la voie de l'utilisation d'un ALB.
C'est un long débat. quand nous devrions utiliser ALB sur la passerelle API. Consultez cet article pour connaître les différences détaillées d'utilisation des deux services avec lambda.
https://serverless-training.com/articles/api-gateway-vs-application-load-balancer-technical-details/
Il semble que la limite de demande/réponse soit inférieure lors de l'utilisation d'ALB et que les WebSockets ne sont pas pris en charge:
La taille maximale du corps de la demande que vous pouvez envoyer à une fonction Lambda est de 1 Mo. Pour les limites de taille associées, voir Limites d'en-tête HTTP.
La taille maximale du JSON de réponse que la fonction Lambda peut envoyer est de 1 Mo.
Les WebSockets ne sont pas pris en charge. Les demandes de mise à niveau sont rejetées avec un code HTTP 400.
Voir: https://docs.aws.Amazon.com/elasticloadbalancing/latest/application/lambda-functions.html
La limite de charge utile avec API Gateway est discutée ici: Demande de limite de charge utile avec AWS API Gateway
L'article déjà mentionné par @matesio fournit également des informations sur des éléments supplémentaires à prendre en compte lors du choix entre ALB et API Gateway.
Tweet notable référencé dans l'article mentionné:
Si vous créez une API et souhaitez tirer parti d'AuthN/Z, demandez la validation, la limitation de débit, la génération de SDK, le backend de service AWS direct, utilisez #APIGateway. Si vous souhaitez ajouter Lambda à une application Web existante derrière ALB, vous pouvez maintenant simplement l'ajouter à l'itinéraire requis.
(De: Dougal Ballantyne, chef de produit pour Amazon API Gateway)