Comment résoudre les problèmes d'intégration d'API Gateway pour les fonctions Lambda ?

Résolution

Activer la journalisation des API

Procédez comme suit :

1. Ouvrez la console API Gateway.
2. Dans le volet de navigation, sélectionnez API, puis votre API.
3. Dans le volet de navigation, sélectionnez Étapes, puis sélectionnez votre étape.
4. Sous Journaux et suivi, sélectionnez Modifier.
5. Dans CloudWatch Logs, sélectionnez un niveau dans le menu déroulant.<br id=hardline_break/> Remarque : pour accéder à l'intégralité des journaux de requêtes et de réponses, sélectionnez l'option Suivi des données avec le niveau de journalisation défini sur Journaux d'erreurs et d'informations. Il est recommandé de ne pas activer Suivi de données pour les API de production, car le suivi de données peut journaliser des données sensibles.
6. Sélectionnez Métriques détaillées.
7. Sous Journalisation des accès personnalisée, effectuez les étapes suivantes :<br id=hardline_break/> Sélectionnez Activer la journalisation des accès.<br id=hardline_break/> Dans ARN de destination du journal d'accès, saisissez l’Amazon Resource Name (ARN) d'un Amazon Data Firehose ou d'un groupe de journaux CloudWatch.<br id=hardline_break/> Remarque : seules les API REST prennent en charge l'ARN Firehose.
8. Saisissez un format de journal.
9. Sélectionnez Enregistrer.

Déterminer les types d'intégration, vérifier les erreurs et prendre les mesures suivantes pour les résoudre

Procédez comme suit :

1. Déterminez si une intégration de proxy Lambda ou une intégration personnalisée Lambda est configurée dans API Gateway. Pour vérifier le type d'intégration, vérifiez la valeur d'intégration du proxy Lambda sous Requête d’intégration.

2. Vérifiez que les erreurs dans API Gateway correspondent aux erreurs dans Lambda. Exécutez la requête CloudWatch Logs Insights suivante pour rechercher un code d'état d'erreur pendant une période spécifiée :

   parse @message '(*) *' as reqId, message
       | filter message like /Method completed with status: \d\d\d/
       | parse message 'Method completed with status: *' as status
       | filter status != 200
       | sort @timestamp asc
       | limit 50

3. Exécutez la requête CloudWatch Logs Insights suivante pour rechercher les journaux d'erreurs Lambda au cours de la même période :

   fields @timestamp, @message
       | filter @message like /(?i)(Exception|error|fail)/
       | sort @timestamp desc
       | limit 20

4. En fonction du type d'erreur que vous identifiez dans vos journaux, choisissez l'une des options suivantes :<br id=hardline_break/> Si le message d'erreur suivant s'affiche, suivez les étapes décrites dans la section Résoudre les problèmes de simultanéité.

   (#####) Lambda invocation failed with status: 429. Lambda request id: ##########
   () Execution failed due to configuration error: Rate Exceeded.
   (#####) Method completed with status: 500

   Si l'une des erreurs suivantes s'affiche, suivez les étapes décrites dans la section Résoudre les problèmes de délai d'attente.<br id=hardline_break/> Pour une intégration personnalisée Lambda :

   < Integration timeout:
   (#####) Method response body after transformations: {"errorMessage":"2019-08-14T02:45:14.133Z ########-####-####-####-############ Task timed out after ##.01 seconds"}
   > Integration timeout:
   (#####) Execution failed due to a timeout error

   Pour une intégration de proxy Lambda :

   < Integration timeout:
   (#####) Endpoint response body before transformations: {"errorMessage":"2019-08-14T02:50:25.865Z ########-####-####-####-############ Task timed out after ##.01 seconds"}
   > Integration timeout:
   (#####) Execution failed due to a timeout error

   Si le message d'erreur suivant s'affiche, suivez les étapes de la section Résoudre les erreurs de fonction.

   (#####) Execution failed due to configuration error: Malformed Lambda proxy response
   (#####) Method response body after transformations: {"errorMessage": "Syntax error in module 'lambda_function'"}

Résoudre les problèmes de simultanéité

Vous recevez 429 erreurs de limitation, soit 500 erreurs, lorsque des requêtes supplémentaires arrivent d'API Gateway plus rapidement que ne peut évoluer votre fonction Lambda.

Pour résoudre ces erreurs, analysez les métriques CloudWatch suivantes : Nombre (API Gateway), Limitations (Lambda) et ConcurrentExecutions (Lambda). Tenez compte des points suivants :

• Nombre (API Gateway) correspond au nombre total de requêtes d'API au cours d'une période spécifiée.
• Limitations (Lambda) correspond au nombre de requêtes d'invocation limitées. Lorsque toutes les instances de fonction traitent des requêtes et qu'aucune simultanéité n'est disponible pour la mise à l'échelle, Lambda rejette les requêtes supplémentaires avec l'erreur TooManyRequestsException. Les requêtes limitées et autres erreurs d'invocation ne sont pas considérées comme des invocations ou des erreurs.
• ConcurrentExecutions (Lambda) correspond au nombre d'instances de fonction qui traitent des événements. Si ce nombre atteint votre quota d'exécutions simultanées pour la région AWS, les requêtes d'invocation supplémentaires seront limitées. Lambda limite également les requêtes d'invocation lorsque le nombre d'instances de fonction atteint la limite de simultanéité réservée que vous avez configurée pour la fonction.

Remarque : pour plus d'informations, consultez les sections Métriques d'API Gateway et Utilisation des métriques CloudWatch avec Lambda.

Si vous définissez une simultanéité de réserve pour votre fonction Lambda, augmentez la valeur de simultanéité de réserve. Vous pouvez également supprimer la valeur de simultanéité inverse de la fonction Lambda. La fonction puise ensuite dans le pool d'exécutions simultanées non réservées.

Si vous ne définissez pas la simultanéité de réserve dans la fonction Lambda, vérifiez la métrique ConcurrentExecutions pour en connaître l'utilisation. Pour plus d’informations, consultez la section Quotas Lambda.

Résoudre les problèmes de délai d’attente

La limite de délai d'intégration par défaut est de 29 secondes pour toutes les intégrations API Gateway. Vous pouvez soumettre une demande de quota pour augmenter le quota de limite de délai d'intégration par défaut à plus de 29 secondes pour les API régionales et les API privées. Toutefois, une augmentation du délai d’attente d'intégration peut entraîner une réduction du quota d'accélération au niveau de la région pour votre compte AWS.

Remarque : si vous augmentez la limite de délai d'intégration, assurez-vous de remplacer la valeur de délai par défaut de 29 secondes par la nouvelle valeur. Par exemple, modifiez la valeur de délai d'expiration par défaut de 29 secondes dans les intégrations auxquelles vous souhaitez appliquer l'augmentation. Puis, redéployez l'API pour que la nouvelle limite de délai d'intégration entre en vigueur.

Lorsque vous créez une API API Gateway avec intégration Lambda, vous pouvez être confronté à l'un des scénarios suivants :

• La valeur du délai d'attente est inférieure à la valeur du délai d'intégration.
• La valeur du délai d'attente est supérieure à la valeur du délai d'intégration.

Si le délai d'expiration de votre fonction Lambda est inférieur à 29 secondes, consultez vos journaux Lambda pour étudier ce problème. Si votre fonction Lambda doit s'exécuter au bout de 29 secondes, invoquez-la de manière asynchrone.

Pour l'intégration personnalisée de l'invocation asynchrone Lambda, procédez comme suit :

1. Ouvrez la console API Gateway.
2. Dans le volet de navigation, choisissez API, puis choisissez votre API.
3. Choisissez Ressources, puis choisissez votre méthode.
4. Sélectionnez Requête d’intégration.
5. Choisissez Requête de méthode.
6. Développez En-têtes de requête HTTP.
7. Sélectionnez Ajouter un en-tête.
8. Dans Nom, saisissez le nom de votre en-tête. Exemple : X-Amz-Invocation-Type<br id=hardline_break/> Important : vous devez mapper votre en-tête depuis 'Événement'. Vous devez utiliser des guillemets simples.

Pour l'intégration du proxy Lambda, utilisez deux fonctions Lambda : la fonction A et la fonction B. API Gateway invoque d'abord la fonction A de manière synchrone. Ensuite, la fonction A invoque la fonction B. La fonction A peut renvoyer une réponse réussie à API Gateway lorsque la fonction B est invoquée de manière asynchrone.

Si vous utilisez une intégration de proxy Lambda, vous pouvez la remplacer par une intégration personnalisée. Toutefois, pour transformer la requête ou la réponse dans votre format spécifique, vous devez configurer les modèles de mappage. Pour plus d'informations, consultez la section Configurer l'invocation asynchrone de la fonction Lambda dorsale.

Remarque : comme une fonction Lambda asynchrone s'exécute en arrière-plan, votre client ne peut pas recevoir directement de données d'une fonction Lambda. Vous devez disposer d'une base de données intermédiaire pour stocker des données persistantes.

Résoudre des erreurs de fonction

Si vous recevez une erreur de fonction lorsque vous appelez votre API, vérifiez que votre fonction Lambda ne contient pas d'erreur de syntaxe. Cette erreur apparaît également si votre fonction Lambda n'a pas renvoyé un objet JSON valide attendu par API Gateway pour les intégrations de proxy.

À partir des journaux d'exécution d'API Gateway, vous pouvez consulter la valeur de ID de la requête de point de terminaison de l’intégration AWS dans les journaux :

(#####) AWS Integration Endpoint RequestId : YYYYYYYY-YYYY-YYYY-YYYY-YYYYYYYYYYYY

Vous pouvez ensuite exécuter la requête CloudWatch Logs Insights suivante pour rechercher des journaux Lambda au cours de la même période spécifique :

fields @timestamp, @message, @requestId, @logStream
| filter @requestId = 'YYYYYYYY-YYYY-YYYY-YYYY-YYYYYYYYYYYY'
| sort @timestamp asc

Pour résoudre cette erreur, suivez les étapes décrites dans la section Activer la journalisation pour votre API et votre étape.

Remplacer les réponses incorrectes au code d'état de l'API REST

Si API Gateway renvoie un code d'état incorrect, créez un modèle de mappage pour remplacer le code d'état incorrect par le code d'état correct. Vous pouvez remplacer les réponses au code d'état dans les intégrations sans proxy avec les API REST.

Remarque : cette configuration de modèle de mappage s'applique uniquement aux API REST. Pour les API REST, consultez la section Comment puis-je mapper les codes d’état de réponse pour les intégrations d’API Gateway dans les API HTTP ?

Par exemple, si API Gateway renvoie un code d'état 200 au lieu d'un 4## ou d'un 5## à partir d'une fonction Lambda, procédez comme suit :

1. Ouvrez la console API Gateway et, dans le volet de navigation, choisissez API.

2. Choisissez votre API REST, puis choisissez l'onglet Réponse d’intégration.

3. Dans Paramètres des réponses d'intégration, choisissez Modifier.

4. Développez Modèles de mappage, puis choisissez Ajouter un modèle de mappage.

5. Dans Type de contenu, saisissez application/json.

6. Dans l'éditeur de modèles de mappage, saisissez le code suivant :

   #set($inputRoot = $input.path('$'))
   $input.json("$")
   #if($inputRoot.toString().contains("error"))
   #set($context.responseOverride.status = 400)
   #end

7. Sélectionnez Enregistrer.

Le paramètre $context.responseOverride.status remplace le code d'état par 400 au lieu du mappage par défaut dans le volet de réponse de l'intégration.

Pour plus d'informations, consultez la section Remplacer les paramètres de requête et de réponse et les codes d'état de votre API REST dans API Gateway.

Configurer vos intégrations d’API REST pour renvoyer les en-têtes CORS requis

Pour renvoyer les en-têtes CORS requis dans sa réponse, configurez votre fonction Lambda dorsale ou votre serveur proxy HTTP. Vous devez inclure les domaines autorisés dans la valeur d’en-tête Access-Control-Allow-Origin sous forme de liste.

Dans Intégrations de proxy, vous ne pouvez pas configurer de réponse d’intégration dans API Gateway pour modifier les paramètres de réponse renvoyés par le backend de votre API. Dans une intégration de proxy, API Gateway transmet la réponse du backend directement au client. Vous devez configurer votre fonction Lambda ou votre intégration HTTP pour renvoyer les en-têtes CORS requis.

Dans Intégrations sans proxy, vous devez configurer manuellement une réponse d’intégration dans API Gateway pour renvoyer les en-têtes CORS requis. Utilisez la console API Gateway pour configurer CORS. La console ajoute automatiquement les en-têtes CORS requis à la ressource configurée.

Pour plus d'informations, consultez la section Comment résoudre les erreurs CORS provenant de mon API API Gateway ?

Intégrations de proxy Lambda aux données utiles binaires

Les données utiles binaires sont différentes des données utiles de texte. Par exemple, les données utiles binaires peuvent être un fichier .jpeg, un fichier .gzip, etc. Cela inclut les données binaires génériques comme celles d'une application .pdf, d'une image .jpeg ou d'une application .zip.

Pour gérer les données utiles binaires pour les intégrations de proxy Lambda, vous devez encoder la réponse de votre fonction en base64 et configurer les binaryMediaTypes pour votre API. Pour gérer les données utiles binaires pour les intégrations sans proxy, vous devez ajouter les types de supports à la liste binaryMediaTypes de la ressource RestApi.

Pour plus d'informations, consultez la section Types de supports binaires pour les API REST dans API Gateway.

Informations connexes

Gestion des erreurs Lambda standard dans API Gateway

Gestion des erreurs Lambda personnalisées dans API Gateway