Lambda@Edge et modèles pilotés par les événements

Lambda@Edge vous permet d’exécuter des fonctions Lambda dans les emplacements périphériques CloudFront du monde entier, plus près des utilisateurs finaux, plutôt que dans une Région centralisée. Vous pouvez ainsi personnaliser les requêtes et les réponses HTTP avec une latence supplémentaire inférieure à la milliseconde au niveau du CDN. Les fonctions Lambda@Edge sont déployées mondialement et invoquées à chaque événement d’accès ou de non-accès au cache CloudFront, ce qui les rend idéales pour les tâches légères de manipulation des requêtes.

Lambda@Edge peut intercepter le trafic à quatre points du cycle de vie d’une requête CloudFront :

• requête du visualiseur : se déclenche lorsque CloudFront reçoit une requête du visualiseur (utilisateur), avant de vérifier le cache
• requête d’origine : se déclenche lorsque CloudFront transmet une absence du cache à l’origine
• réponse d’origine : se déclenche lorsque l’origine renvoie une réponse, avant sa mise en cache
• réponse du visualiseur : se déclenche avant que CloudFront renvoie la réponse au visualiseur

Lambda@Edge est soumis à des limites plus strictes que Lambda classique : 128 MB de mémoire au maximum (événements du visualiseur), 1 GB (événements de l’origine), 5 secondes de délai d’expiration maximal (visualiseur) et 30 secondes (origine). Les fonctions doivent être créées dans us-east-1 et déployées vers les emplacements périphériques via CloudFront. VPC, variables d’environnement et couches Lambda ne sont pas pris en charge. Ces contraintes signifient que Lambda@Edge est conçu pour des transformations légères, et non pour des traitements lourds.

Lambda@Edge est particulièrement adapté aux situations suivantes : tests A/B (réécrire les URL vers différents chemins d’origine selon les témoins), authentification (valider les JWT à la périphérie avant de les transmettre à l’origine), manipulation des en-têtes HTTP (ajouter des en-têtes de sécurité tels que HSTS, CSP et X-Frame-Options), normalisation des URL (rediriger www vers la version sans www ou imposer les barres obliques finales) et personnalisation (diffuser un contenu différent selon le pays du visualiseur à partir de l’en-tête CloudFront-Viewer-Country).

Les fonctions CloudFront sont des fonctions JavaScript extrêmement légères qui s’exécutent uniquement aux étapes de requête et de réponse du visualiseur, avec une limite de durée d’exécution de 2 ms et un coût bien inférieur. Pour les cas d’utilisation simples (réécriture d’URL, manipulation des en-têtes, normalisation de la clé de cache), les fonctions CloudFront sont préférables à Lambda@Edge, car elles sont plus rapides et moins coûteuses. Utilisez Lambda@Edge lorsque vous avez besoin d’accéder à des appels réseau, de traiter des charges utiles plus volumineuses ou d’utiliser les points de déclenchement des requêtes et réponses d’origine.

Une architecture pilotée par les événements connecte les services au moyen d’événements : des messages qui représentent quelque chose qui s’est produit. Dans AWS, Lambda est le principal consommateur d’événements : il reçoit des événements de SQS, SNS, DynamoDB Streams, Kinesis, S3, EventBridge et d’autres services. Chaque événement déclenche une exécution Lambda, ce qui permet aux systèmes de réagir de manière asynchrone et indépendante, sans couplage étroit. Ce modèle permet un couplage lâche, une mise à l’échelle indépendante et une isolation des pannes.

Lambda peut être configuré comme mappage de source d’événements pour SQS. Lambda interroge la file d’attente, récupère jusqu’à une taille de lot de messages (jusqu’à 10 000 pour les files standard et 10 pour FIFO), puis invoque la fonction une fois par lot. Si la fonction échoue, l’ensemble du lot est renvoyé dans la file d’attente. Configurez une fenêtre de lot pour attendre d’autres messages avant l’invocation afin d’améliorer le débit. Utilisez une DLQ sur la file d’attente SQS source pour les messages qui échouent à plusieurs reprises.

DynamoDB Streams capture chaque modification au niveau d’un élément (INSERT, MODIFY, REMOVE) sous la forme d’une séquence ordonnée d’événements. Lambda lit le flux à l’aide d’un mappage de source d’événements avec TRIM_HORIZON (commencer par le plus ancien) ou LATEST (commencer par le plus récent). Lambda traite les enregistrements dans l’ordre au sein d’une partition. Les lots ayant échoué bloquent la poursuite du traitement de la même partition jusqu’à résolution du problème ; utilisez la division en cas d’erreur pour fractionner les lots défaillants et isoler les enregistrements problématiques.

Lambda traite les enregistrements Kinesis de manière similaire à ceux de DynamoDB Streams : une exécution simultanée par fragment. Les principales options de configuration comprennent le facteur de parallélisation (jusqu’à 10 invocations Lambda simultanées par fragment, avec traitement parallèle de sous-lots) et la distribution améliorée (débit dédié de 2 MB/s par fragment pour le consommateur Lambda). Ces options augmentent considérablement le débit des flux à gros volume sans augmenter le nombre de fragments.

Amazon EventBridge est le bus d’événements recommandé pour connecter les services AWS et les applications personnalisées. Les événements arrivent sur un bus, puis les règles les filtrent selon un modèle et les acheminent vers des cibles telles que Lambda, SQS, Step Functions et d’autres services. EventBridge découple complètement les producteurs et les consommateurs d’événements : aucun des deux ne connaît l’autre. Le bus d’événements par défaut reçoit les événements des services AWS ; créez un bus d’événements personnalisé pour les événements de votre application.

Un modèle courant piloté par les événements est la diffusion : un événement déclenche plusieurs flux de traitement en parallèle. Publiez sur un rubrique SNS afin que plusieurs abonnements à des fonctions Lambda réagissent chacun indépendamment. Par exemple, un événement indiquant qu’une commande a été passée est diffusé vers : une fonction Lambda qui envoie un courriel de confirmation, une fonction Lambda qui met à jour l’inventaire et une fonction Lambda qui informe l’entrepôt. Chaque consommateur est indépendant et évolue séparément ; aucun consommateur unique ne peut bloquer les autres.

Vérifiez votre compréhension des concepts AWS Solutions Architect (SAA-C03) abordés dans cette leçon.

Dans cette leçon, vous avez appris que Lambda@Edge exécute des fonctions dans les emplacements périphériques CloudFront, avec quatre points de déclenchement (requête/réponse du visualiseur et requête/réponse de l’origine), pour des tâches telles que l’authentification, la réécriture d’URL et la manipulation des en-têtes ; que les fonctions CloudFront constituent une solution moins coûteuse et plus rapide pour les transformations simples au niveau du visualiseur ; et que les modèles pilotés par les événements utilisant SQS, DynamoDB Streams, Kinesis, EventBridge et la diffusion SNS permettent des architectures faiblement couplées dans lesquelles Lambda réagit aux événements en temps réel. Nous allons maintenant étudier les files d’attente SQS Standard et FIFO.