Bonnes pratiques d'utilisation des AWS Lambda fonctions

Les bonnes pratiques suivantes sont recommandées pour l’utilisation d’ AWS Lambda :

Code de fonction

• Tirez parti de la réutilisation de l’environnement d’exécution pour améliorer les performances de votre fonction. Initialisez les clients SDK et les connexions à la base de données en dehors du gestionnaire de fonctions et mettez en cache les actifs statiques localement dans le répertoire /tmp. Les invocations ultérieures traitées par la même instance de votre fonction peuvent réutiliser ces ressources. Cela permet d’économiser des coûts, tout en réduisant le temps d’exécution de la fonction.

  Pour éviter des éventuelles fuites de données entre les invocations, n’utilisez pas l’environnement d’exécution pour stocker des données utilisateur, des événements ou d’autres informations ayant un impact sur la sécurité. Si votre fonction repose sur un état réversible qui ne peut pas être stocké en mémoire dans le gestionnaire, envisagez de créer une fonction distincte ou des versions distinctes d’une fonction pour chaque utilisateur.

• Utilisez une directive keep-alive pour maintenir les connexions persistantes. Lambda purge les connexions inactives au fil du temps. Si vous tentez de réutiliser une connexion inactive lorsque vous invoquez une fonction, cela entraîne une erreur de connexion. Pour maintenir votre connexion persistante, utilisez la directive Keep-alive associée à votre environnement d’exécution. Pour obtenir un exemple, consultez Réutilisation des connexions avec Keep-Alive dans Node.js.

• Utilisez des variables d’environnement pour transmettre des paramètres opérationnels à votre fonction. Par exemple, si vous écrivez dans un compartiment Amazon S3 au lieu de coder en dur le nom du compartiment dans lequel vous écrivez, configurez le nom du compartiment comme variable d’environnement.

• Évitez d’utiliser des invocations récursives dans votre fonction Lambda, lorsque la fonction s’invoque elle-même ou démarre un processus susceptible de l’invoquer à nouveau. Cela peut entraîner un volume involontaire d’invocations de fonction et des coûts accrus. Si vous constatez un volume involontaire d’invocations, définissez immédiatement la simultanéité réservée à la fonction sur 0 afin de limiter toutes les invocations de la fonction, pendant que vous mettez à jour le code.

• N'utilisez pas de code non documenté ni public APIs dans votre code de fonction Lambda. Pour les AWS Lambda environnements d'exécution gérés, Lambda applique régulièrement des mises à jour de sécurité et fonctionnelles aux applications internes de Lambda. APIs Ces mises à jour internes de l'API peuvent être rétroincompatibles, ce qui peut entraîner des conséquences imprévues, telles que des échecs d'invocation si votre fonction dépend de ces mises à jour non publiques. APIs Consultez la référence de l'API pour obtenir une liste des API accessibles au public APIs.

• Écriture du code idempotent. L’écriture de code idempotent pour vos fonctions garantit ne gestion identique des événements dupliqués. Votre code doit valider correctement les événements et gérer correctement les événements dupliqués. Pour de plus amples informations, veuillez consulterComment faire en sorte que ma fonction Lambda soit idempotente ?.

Pour connaître les pratiques exemplaires en matière de code spécifiques à chaque langage, reportez-vous aux sections suivantes :

• Pratiques exemplaires en matière de code pour les fonctions Lambda Node.js

• Pratiques exemplaires de codage pour les fonctions Lambda TypeScript

• Pratiques exemplaires en matière de code pour les fonctions Lambda Python

• Pratiques exemplaires en matière de code pour les fonctions Lambda Ruby

• Pratiques exemplaires en matière de code pour les fonctions Lambda Java

• Pratiques exemplaires en matière de code pour les fonctions Lambda Go

• Pratiques exemplaires de codage pour les fonctions Lambda C#

• Pratiques exemplaires en matière de code pour les fonctions Lambda Rust

Configuration de la fonction

• Le test de performance de votre fonction Lambda est une partie cruciale pour garantir que vous choisissez la configuration de taille mémoire optimale. Toute augmentation de la taille mémoire déclenche une augmentation équivalente de l’UC disponible pour votre fonction. L'utilisation de la mémoire pour votre fonction est déterminée par appel et peut être consultée sur Amazon CloudWatch. À chaque invocation, une entrée REPORT: est créée, comme indiqué ci-dessous :

  REPORT RequestId: 3604209a-e9a3-11e6-939a-754dd98c7be3	Duration: 12.34 ms	Billed Duration: 100 ms Memory Size: 128 MB	Max Memory Used: 18 MB

  En analysant le champ Max Memory Used:, vous pouvez déterminer si votre fonction a besoin de plus de mémoire ou si vous avez surdimensionné la taille mémoire de votre fonction.

  Pour trouver la configuration de mémoire adaptée à vos fonctions, nous vous recommandons d'utiliser le projet open source AWS Lambda Power Tuning. Pour plus d'informations, voir Réglage AWS Lambda de l'alimentation activé GitHub.

  Pour optimiser les performances des fonctions, nous recommandons également de déployer des bibliothèques capables de tirer parti des extensions vectorielles avancées 2 (AVX2). Cela vous permet de traiter des charges de travail exigeantes, comme l’inférence du machine learning, le traitement multimédia, le calcul haute performance (HPC), les simulations scientifiques et la modélisation financière. Pour plus d'informations, consultez la section Création de AWS Lambda fonctions plus rapides avec AVX2.

• Effectuez un test de charge de votre fonction Lambda pour déterminer une valeur de délai d’expiration optimale. Il importe d’analyser comment votre fonction s’exécute afin que vous puissiez mieux déterminer les problèmes de service de dépendance qui peuvent accroître la simultanéité de la fonction au-delà de ce que vous attendez. Cet aspect est particulièrement important quand votre fonction Lambda effectue des appels réseau aux ressources qui peuvent ne pas gérer la mise à l’échelle de Lambda. Pour plus d’informations sur le test de charge de votre application, consultez Test de charge distribué sur AWS.

• Utilisez les autorisations les plus restrictives lors de la définition des stratégies IAM. Maîtrisez les ressources et les opérations dont votre fonction Lambda a besoin et limitez le rôle d’exécution à ces autorisations. Pour plus d'informations, consultez Gestion des autorisations dans AWS Lambda.

• Familiarisez-vous avec Quotas Lambda. La taille de la charge utile, les descripteurs de fichiers et l'espace /tmp sont souvent ignorés lors de la détermination des limites des ressources.

• Supprimez les fonctions Lambda que vous n'utilisez plus. En procédant ainsi, les fonctions inutilisées n’interviendront plus inutilement dans la limite de taille de votre package de déploiement.

• Si vous utilisez Amazon Simple Queue Service en tant que source d’événement, assurez-vous que la valeur de la durée de l’invocation prévue de la fonction ne dépasse pas la valeur Délai de visibilité de la file d’attente. Cela s'applique à CreateFunction et UpdateFunctionConfiguration.

  • Dans le cas de CreateFunction, le processus de création de la fonction AWS Lambda échouera.

  • Dans le cas de UpdateFunctionConfiguration, cela pourrait entraîner des appels dupliqués de la fonction.

Capacité de mise à l’échelle de la fonction

• Familiarisez-vous avec vos contraintes de débit en amont et en aval. Bien que les fonctions Lambda se mettent à l’échelle parfaitement, les dépendances en amont et en aval peuvent avoir des mêmes capacités de débit différentes. Si vous devez limiter le niveau de mise à l’échelle de votre fonction, configurez la simultanéité réservée sur votre fonction.

• Créez une tolérance à la limitation. Si votre fonction synchrone est ralentie en raison d’un trafic dépassant le taux de mise à l’échelle de Lambda, vous pouvez utiliser les stratégies suivantes pour améliorer la tolérance à la limitation :

  • Utilisez les délais d’expiration, les nouvelles tentatives et le backoff avec instabilité. La mise en œuvre de ces stratégies facilite les nouvelles tentatives d’invocation et permet de garantir que Lambda peut se mettre à l’échelle en quelques secondes afin de minimiser la limitation des utilisateurs finaux.

  • Utilisez la simultanéité allouée. La simultanéité allouée est le nombre d’environnements d’exécution préinitialisés que Lambda alloue à votre fonction. Lambda gère les requêtes entrantes en utilisant la simultanéité allouée lorsqu’elle est disponible. Lambda peut également mettre à l’échelle votre fonction au-delà de votre paramètre de simultanéité allouée si nécessaire. La configuration de la simultanéité provisionnée entraîne des frais supplémentaires pour votre compte. AWS

Métriques et alarmes

• Utilisez Utilisation de CloudWatch métriques avec Lambda les CloudWatch alarmes et au lieu de créer ou de mettre à jour une métrique à partir de votre code de fonction Lambda. C’est une manière beaucoup plus efficace de suivre l’état de vos fonctions Lambda, qui vous permet de détecter de façon précoce d’éventuels problèmes dans le processus de développement. Par exemple, vous pouvez configurer une alarme basée sur la durée attendue de l’invocation de votre fonction Lambda afin de pouvoir prendre en compte les goulots d’étranglement ou les latences du code de votre fonction.

• Mettez à profit votre bibliothèque de journalisation et les dimensions et métriques AWS Lambda pour intercepter les erreurs d’application (par exemple, ERR, ERROR, WARNING, etc.)

• Utiliser Détection des anomalies de coûts AWS pour détecter les activités inhabituelles sur votre compte. La détection des anomalies de coûts utilise le machine learning pour effectuer une surveillance permanent de votre coût et votre utilisation, tout en minimisant les alertes de faux positifs. La détection des anomalies de coût utilise les données provenant de AWS Cost Explorer, avec un délai pouvant aller jusqu'à 24 heures. Par conséquent, après utilisation, jusqu’à 24 heures peuvent être nécessaires pour détecter une anomalie. Afin de vous familiariser à la détection des anomalies de coûts, vous devez d’abord vous inscrire à Cost Explorer. Ensuite, accéder à la détection des anomalies des coûts.

Utilisation des flux

• Testez différentes tailles de lot et d’enregistrement de telle sorte que la fréquence d’interrogation de chaque source d’événement soit réglée sur la vitesse à laquelle votre fonction peut exécuter sa tâche. Le CreateEventSourceMapping BatchSize paramètre contrôle le nombre maximum d'enregistrements qui peuvent être envoyés à votre fonction à chaque appel. Une taille de lot plus grande peut souvent absorber plus efficacement l’invocation sur un plus large ensemble d’enregistrements, ce qui accroît votre débit.

  Par défaut, Lambda invoque votre fonction dès que des enregistrements sont disponibles. Si le lot que Lambda lit à partir de la source d’événements ne comprend qu’un seul enregistrement, Lambda envoie un seul registre à la fonction. Pour éviter d’invoquer la fonction avec un petit nombre de registres, vous pouvez indiquer à la source d’événement de les mettre en mémoire tampon pendant 5 minutes en configurant une fenêtre de traitement par lots. Avant d’invoquer la fonction, Lambda continue de lire les registres de la source d’événements jusqu’à ce qu’il ait rassemblé un lot complet, que la fenêtre de traitement par lot expire ou que le lot atteigne la limite de charge utile de 6 Mo. Pour de plus amples informations, veuillez consulter Comportement de traitement par lots.

  Avertissement

  Les mappages des sources d’événements Lambda traitent chaque événement au moins une fois, et le traitement des enregistrements peut être dupliqué. Pour éviter les problèmes potentiels liés à des événements dupliqués, nous vous recommandons vivement de rendre votre code de fonction idempotent. Pour en savoir plus, consultez Comment rendre ma fonction Lambda idempotente dans le Knowledge Center. AWS

• Augmentez le débit de traitement du flux Kinesis en ajoutant des partitions. Un flux Kinesis est composé d’une ou plusieurs partitions. La vitesse à laquelle Lambda peut lire les données de Kinesis s’échelonne linéairement en fonction du nombre de partitions. L’augmentation du nombre de partitions entraîne directement celle du nombre maximum d’invocations simultanés de fonctions Lambda, et peut accroître le débit de traitement de votre flux Kinesis. Pour de plus amples informations sur la relation entre les partitions et les invocations de fonctions, consultez Flux d’interrogation et de mise en lots. Si vous augmentez le nombre de partitions dans un flux Kinesis, assurez-vous d’avoir choisi une clé de partition appropriée (consultez Clés de partition) pour vos données, de façon à ce que les enregistrements associés se retrouvent sur les mêmes partitions et que vos données soient correctement distribuées.

• Utilisez Amazon CloudWatch on IteratorAge pour déterminer si votre flux Kinesis est en cours de traitement. Par exemple, configurez une CloudWatch alarme avec un réglage maximal de 30 000 (30 secondes).

Bonnes pratiques de sécurité

• Surveillez votre utilisation AWS Lambda en ce qui concerne les meilleures pratiques de sécurité en utilisant AWS Security Hub. Security Hub utilise des contrôles de sécurité pour évaluer les configurations des ressources et les normes de sécurité afin de vous aider à respecter divers cadres de conformité. Pour plus d'informations sur l'utilisation de Security Hub pour évaluer les ressources Lambda, consultez la section AWS Lambda Contrôles du Guide de l' AWS Security Hub utilisateur.

• Surveillez les journaux d'activité du réseau Lambda à l'aide d'Amazon Lambda Protection GuardDuty . GuardDuty La protection Lambda vous aide à identifier les menaces de sécurité potentielles lorsque des fonctions Lambda sont invoquées dans votre. Compte AWS Par exemple, si l'une de vos fonctions interroge une adresse IP associée à une activité liée aux cryptomonnaies. GuardDuty surveille les journaux d'activité réseau générés lorsqu'une fonction Lambda est invoquée. Pour en savoir plus, consultez la section Protection Lambda dans le guide de GuardDuty l'utilisateur Amazon.