En utilisant AWS re:Post, vous acceptez les AWS re:Post Conditions d’utilisation

Comment puis-je résoudre les problèmes liés aux ressources personnalisées dans AWS CloudFormation ?

Lecture de 5 minute(s)
0

Je souhaite résoudre les erreurs liées aux ressources personnalisées dans AWS CloudFormation.

Brève description

Les échecs liés aux ressources personnalisées appartiennent aux deux catégories suivantes :

  • L'opération a échoué car la fonction AWS Lambda a rencontré une erreur : Cet échec se produit lorsque la ressource personnalisée renvoie un signal ÉCHEC à CloudFormation. L'échec indique généralement que la fonction AWS Lambda, qui sauvegarde la ressource personnalisée, a rencontré une erreur lors de son exécution.
  • Échec du délai d'expiration : Cela se produit lorsque CloudFormation ne reçoit aucune réponse de la part de la ressource personnalisée dans les délais prévus, ce qui entraîne un délai d'expiration.

Résolution

Pour résoudre ce problème, procédez comme suit :

Consulter les métriques Amazon CloudWatch

Dans un premier temps, pour les deux types d’échecs, consultez les journaux Amazon CloudWatch pour AWS Lambda :

  1. Dans la console CloudFormation, choisissez la pile d’échecs. Puis, sélectionnez l’onglet Ressources pour trouver l'ID physique de la fonction Lambda qui appuie la ressource personnalisée.
  2. Choisissez la fonction Lambda que vous souhaitez ouvrir dans une nouvelle fenêtre.
  3. Sélectionnez l’onglet Surveiller. Puis, cliquez sur le bouton Afficher les journaux CloudWatch. Les journaux de la fonction Lambda permettant de résoudre les erreurs s’affichent.

La fonction Lambda a peut-être été supprimée lors de la restauration de CloudFormation. Cependant, le groupe de journaux peut toujours conserver les journaux CloudWatch. Pour trouver les journaux, procédez comme suit :

  1. Accédez à la console CloudWatch.

  2. Dans le menu de gauche, sélectionnez Groupes de journaux.

  3. Dans la zone de recherche, saisissez :

    /aws/lambda/<LambdaPhysicalName>

    Remarque : Le LambdaPhysicalName se trouve dans les ressources CloudFormation.

    Si les journaux CloudWatch sont introuvables, redéployez la pile en désactivant la fonction de restauration. Cela vous permet d'étudier le comportement de la fonction Lambda et les problèmes potentiels.

Explorez chaque type d’échec et ses causes potentielles

Gérer le signal ÉCHEC

L'erreur suivante peut s'afficher : « Received response status FAILED from custom resource. Message returned: <reason here>. »

Ce message suggère que la fonction Lambda qui sauvegarde la ressource personnalisée a rencontré une erreur et a mis en place une logique de gestion des exceptions.

Pour corriger l'erreur, procédez comme suit :

  • Vérifiez le message d'erreur, si la réponse inclut une raison. Ces raisons sont généralement descriptives et apparaissent directement dans le message d'erreur de l'événement CloudFormation.
  • Consultez les journaux CloudWatch pour Lambda. Parfois, le message d'erreur n'est pas clair ou la raison de l'erreur n'est pas indiquée.

CloudFormation ne reçoit pas de réponse

La pile échoue en raison d'un délai d'expiration, car CloudFormation ne reçoit aucune réponse de la ressource personnalisée. Plusieurs causes peuvent être à l'origine de ce problème. Passez en revue les options suivantes pour identifier la cause de l'échec :

Assurez-vous d'utiliser correctement le module cfn-response module : Vous pouvez utiliser le module cfn-response dans la fonction Lambda de votre ressource personnalisée pour renvoyer un signal à la pile CloudFormation. Si le module n'est pas utilisé correctement dans le code, CloudFormation n'obtient pas la réponse requise.

Consultez les journaux CloudWatch : Vérifiez les journaux CloudWatch pour savoir si des erreurs surviennent lors de l'exécution du code. Ces erreurs peuvent empêcher la fonction d'envoyer le signal à CloudFormation, en particulier si le code ne dispose pas d'une logique de gestion des exceptions.

Vérifiez le délai d'exécution de Lambda : Assurez-vous que le délai d'expiration de votre fonction Lambda est suffisamment long pour terminer sa tâche. N'oubliez pas que la limite maximale d'une fonction Lambda est de 15 minutes.

Vérifiez l'accès au point de terminaison Amazon Simple Storage Service (Amazon S3) : Pour que CloudFormation reçoive un signal, les ressources personnalisées doivent accéder à une URL Amazon Simple Storage Service (Amazon S3) présignée. Si votre fonction Lambda se trouve dans un cloud privé virtuel, assurez-vous qu'elle se trouve dans un sous-réseau. Le sous-réseau doit autoriser le trafic sortant via une passerelle NAT et disposer d'un routage approprié pour l'accès aux terminaux Amazon S3.

Tenez compte des problèmes de simultanéité de Lambda : Si vos journaux Lambda indiquent un signal envoyé après un délai d’expiration, examinez la simultanéité Lambda pour en déterminer la cause potentielle. Un délai d'expiration se produit lorsqu'un grand nombre de fonctions Lambda s'exécutent simultanément dans la même région. Surveillez les métriques Lambda pour détecter les exécutions simultanées. Pour réduire les délais d'expiration, utilisez la simultanéité réservée pour votre fonction.

Supprimez manuellement la pile de l’état IN_PROGRESS : Dans cette erreur, CloudFormation reste *_IN_PROGRESS jusqu'à ce que la ressource personnalisée atteigne son délai d'expiration. Cela peut prendre un certain temps avant que la ressource ne soit marquée comme ÉCHEC. Pour stabiliser rapidement la ressource personnalisée, utilisez cURL pour effectuer une requête HTTP directe. Cette action permet parfois d’ignorer le retard et d'empêcher un délai d'expiration. Notez que vous devez disposer des détails de l'objet de la requête pour recueillir les informations nécessaires à la présentation de cette requête.

Par exemple :

$ curl -H 'Content-Type: ''' -X PUT -d '{    "Status": "SUCCESS",
    "PhysicalResourceId": "test-CloudWatchtrigger-1URTEVUHSKSKDFF",
    "StackId": "arn:aws:cloudformation:us-east-1:111122223333:stack/awsexamplecloudformation/33ad60e0-5f25-11e9-a734-0aa6b80efab2
  ",
    "RequestId": "e2fc8f5c-0391-4a65-a645-7c695646739",
    "LogicalResourceId": "CloudWatchtrigger"
  }' 'https://cloudformation-custom-resource-response-useast1.s3.us-east-1.amazonaws.com/arn%3Aaws%3Acloudformation%3Aus-east-1%3A111122223333%3Astack/awsexamplecloudformation/33ad60e0-5f25-11e9-a734-0aa6b80efab2%7CMyCustomResource%7Ce2fc8f5c-0391-4a65-a645-7c695646739?X-Amz-Algorithm=AWS4-HMAC-SHA256&X-Amz-Date=20170313T0212304Z&X-Amz-SignedHeaders=host&X-Amz-Expires=7200&X-Amz-Credential=QWERTYUIOLASDFGBHNZCV%2F20190415%2Fus-east-1%2Fs3%2Faws4_request&X-Amz-Signature=dgvg36bh23mk44nj454bjb54689bg43r8v011uerehiubrjrug5689ghg94hb
  '

Vous pouvez trouver le RequestID et l'URL présignée S3 dans CloudWatch Logs, à condition que l'objet de la requête ait été correctement journalisé. Comment puis-je supprimer une ressource personnalisée appuyée par Lambda qui est bloquée dans l’état DELETE_FAILED ou DELETE_IN_PROGRESS dans CloudFormation ?

Informations connexes

Quelles sont les bonnes pratiques pour implémenter des ressources personnalisées appuyées par Lambda avec CloudFormation ?

AWS OFFICIEL
AWS OFFICIELA mis à jour il y a 9 mois