Bonnes pratiques pour les fonctions Web Lambda

Chaque point de terminaison est accessible depuis Internet, quel que soit son type d'authentification. AvecApplicationManaged, Lambda n'authentifie pas les demandes, de sorte que tout client connaissant le domaine peut appeler votre application. Mettez en œuvre l'authentification, l'autorisation, la validation des entrées, le contrôle de la taille des demandes et la protection contre les abus dans l'application ou dans une porte d'entrée.

IamAuthÀ utiliser lorsque les appelants peuvent signer des demandes et que les politiques IAM fournissent le modèle d'autorisation requis. Élargissez les politiques de ressources aux ARN et aux principaux spécifiques des terminaux.

Placez Amazon CloudFront ou Amazon API Gateway devant un point de terminaison lorsque vous avez besoin d'un domaine personnalisé, d'une AWS WAF inspection, d'une mise en cache ou de contrôles périphériques centralisés. Limitez l'origine afin que les clients ne puissent pas contourner la porte d'entrée. Avec CloudFront, utilisez un contrôle d'accès aux points de IamAuth terminaison et aux origines (OAC), comme décrit dansCloudFront intégration. Avec les autres portes d'entrée, le point de terminaison reste directement accessible. Vérifiez donc un secret ou un jeton partagé dans l'application.

Utilisez un rôle d'exécution dédié avec des autorisations de moindre privilège. Séparez l'identité de déploiement, le téléchargeur de code, le principal du service Lambda, le rôle d'exécution et les autorisations de l'appelant du point de terminaison.

Ne mettez pas de secrets dans les packages ou les journaux de déploiement. Chargez les secrets au moment de l'exécution à partir d'un magasin de secrets approprié, mettez-les en cache uniquement le temps nécessaire et supprimez les champs de requête sensibles.

Activez le versionnement dans le compartiment de code et enregistrez l'ID de version de l'objet pour chaque déploiement.

Ne remplacez ni ne supprimez les versions d'objets utilisées par les révisions actives ou annulées. Conservez l'accès principal au service Lambda tant qu'une révision fait référence à l'objet.

Créez des packages de déploiement dans un pipeline reproductible. Installez les dépendances de production à partir d'un fichier de verrouillage, excluez les fichiers de développement et testez l'archive exacte avant le téléchargement.

Créez des dépendances natives pour Arm64. Un module natif créé pour x86_64 ne s'exécute pas dans l'environnement d'exécution des fonctions Web.

Utilisez des compartiments, des préfixes, des rôles ou des comptes distincts lorsque les environnements ont des exigences de confiance ou de rétention différentes.

Conservez les données spécifiques à la demande dans le champ d'application de la demande. Ne stockez pas les informations d'identification, les données client, les objets de réponse ou l'état modifiable par demande dans des variables globales.

Utilisez le mode asynchrone I/O. Le fonctionnement synchrone du processeur ou du système de fichiers bloque la boucle d'Node.jsévénements et retarde chaque demande en cours dans l'environnement.

worker_threadsÀ utiliser pour les CPU-intensive travaux qui doivent utiliser plusieurs vCPU ou moins maxConcurrencyPerEnvironment afin de réduire les conflits.

Tenez compte du Node.js tas séparément de la mémoire de l'environnement. L'environnement dispose de 2 Go, tandis que le segment de mémoire V8 par défaut est de 1 024 Mo. Si vous augmentez le tas avec --max-old-space-size inNODE_OPTIONS, laissez de la mémoire pour les tampons, les modules natifs, le runtime et les requêtes simultanées.

Réutilisez les clients initialisés et les pools de connexions entre les demandes, mais validez les connexions périmées et la croissance du cache liée. Conserve l'état requis en dehors de l'environnement d'exécution.

Maintenez les connexions sortantes actives afin que les demandes adressées aux bases de données et autres dépendances les réutilisent au lieu d'ouvrir une nouvelle connexion à chaque fois. Node.jsactive keep-alive par défaut dans son agent HTTP global. Si vous créez votre propre agent ou configurez un client SDK, maintenez Keep-Alive activé. Gérez également les connexions que la télécommande ferme lorsqu'elles sont inactives.

Utilisez des noms uniques pour les fichiers temporaires et supprimez-les lorsqu'ils ne sont plus nécessaires. Plusieurs demandes partagent le système de fichiers de 512 Mo /tmp de l'environnement, et les fichiers peuvent être conservés d'une demande à l'autre jusqu'à ce que l'environnement soit supprimé.

Démarrez rapidement le serveur HTTP et écoutez la valeur exacte deAWS_LAMBDA_HTTP_ENDPOINT.

Conservez la taille du package et supprimez les dépendances de production inutilisées.

Initialisez uniquement les ressources nécessaires pour que le serveur puisse accepter le trafic. Effectuez des tâches facultatives avec paresse, mais évitez que les demandes simultanées ne dupliquent une initialisation coûteuse.

Gérez SIGTERM le nettoyage qui se termine en 1 seconde, mais ne vous fiez pas aux rappels d'arrêt pour conserver les données requises.

Test de charge avec les mêmes dépendances applicatives et les mêmes services en aval que ceux utilisés en production. Augmentez la simultanéité jusqu'à ce que la latence, la consommation du processeur, la mémoire ou la capacité en aval deviennent la contrainte contraignante.

maxConcurrencyPerEnvironmentÀ utiliser pour limiter le contentieux par processus, maxEnvironments pour limiter l'échelle horizontale et rateLimit pour protéger les dépendances en aval contre les rafales de demandes.

Vérifiez les limites de compte et régionales appliquées avant les tests de performances et les lancements. La configuration du point de terminaison ne peut pas créer de capacité au-delà d'une limite de compte.

Réessayez les réponses HTTP 429 et les réponses HTTP 503 sans lambda-web-error-type en-tête. Utilisez le backoff et le jitter, et réessayez uniquement lorsque l'opération est idempotente. Utilisez des clés d'idempuissance ou une déduplication au niveau de l'application pour les écritures.

Utilisez des pondérations de révision manuelles pour les points finaux de production. Maintenez le déploiement automatique des dernières révisions pour les environnements de développement dans lesquels un déploiement immédiat est acceptable.

Attendez que la nouvelle révision soit disponible Active et que la mise à jour du terminal soit terminée avant de l'évaluer. Pour les PerRegion terminaux MultiRegion et les terminaux, vérifiez l'état de mise à jour dans chaque région.

Utilisez des journaux d'applications ou des métriques personnalisées qui incluent l'identifiant de révision lors des déploiements Canary. Service-vended les métriques n'incluent pas de dimension de révision.

Avant de transférer le trafic, définissez les indicateurs auxquels une nouvelle révision doit répondre et la durée pendant laquelle vous les observez (critères de stabilisation), ainsi que les seuils déclenchant une annulation. Conservez la version de l'objet de code, l'accès par clé et la configuration de la révision précédente jusqu'à la fin de la fenêtre de restauration. Lambda supprime automatiquement les révisions les plus anciennes vers lesquelles aucun point de terminaison n'est acheminé lorsqu'une fonction Web dépasse sa limite de révision. Conservez donc la révision d'annulation sur un point de terminaison (par exemple, un point de terminaison de test) ou soyez prêt à la recréer à partir de la même version d'objet. Pour plus de détails, consultez Limites de révision et nettoyage automatique.

Émettez des journaux d'applications structurés avec l'ID de demande, l'ID de révision, l'itinéraire, le code d'état, la durée et les identifiants nécessaires pour diagnostiquer les défaillances en aval. N'enregistrez pas les informations d'identification, les jetons ou les corps de demande sensibles.

Alarmez en cas de réponse et de limitation 5xx, et surveillez les demandes exécutées, les environnements actifs et la capacité du compte. Configurez des mesures d'erreur éparses pour traiter les données manquantes de manière appropriée.

Utilisez l'ID de demande de réponse et les en-têtes du flux de journal pour corréler les défaillances des clients avec les journaux. Activez les journaux système DEBUG uniquement lorsque vous avez besoin des événements supplémentaires.

Enregistrez les opérations de gestion et les événements liés aux données d'invocation des terminaux AWS CloudTrail lorsque vos exigences d'audit en ont besoin.

Rendez les données d'application, les secrets, les clés et les dépendances en aval disponibles dans toutes les régions susceptibles de recevoir du trafic.

Testez les échecs de déploiement partiels et les échecs de dépendance régionale. Ne partez pas du principe que toutes les régions exécutent la même révision tant que chaque mise à jour régionale n'indique un succès.

Après chaque mise à jour du terminal, vérifiez updateStatus chaque entréeregionalEndpoints. La réplication peut échouer dans certaines régions alors qu'elle réussit dans d'autres. Par conséquent, une mise à jour peut être partiellement appliquée. Réessayez ou revenez en arrière avant de considérer le déploiement comme terminé.

Pour les PerRegion terminaux, testez votre DNS externe ou votre basculement frontal indépendamment du déploiement de la fonction Web.

Centralisez les vues opérationnelles dans la région d'origine, mais maintenez une trajectoire de reprise en cas de retard ou d'interruption de la télémétrie.