Lambda@Edge e pattern event-driven

Lambda@Edge consente di eseguire funzioni Lambda nelle CloudFront edge locations di tutto il mondo, più vicine agli utenti finali, invece che in una Regione centrale. In questo modo può personalizzare le richieste e le risposte HTTP con una latenza aggiuntiva inferiore al millisecondo a livello CDN. Le funzioni Lambda@Edge vengono distribuite globalmente e invocate a ogni evento di cache hit o cache miss di CloudFront, risultando ideali per attività leggere di manipolazione delle richieste.

Lambda@Edge può intercettare il traffico in quattro punti del ciclo di vita delle richieste CloudFront:

• Viewer Request: si attiva quando CloudFront riceve una richiesta dal viewer (utente), prima di verificare la cache
• Origin Request: si attiva quando CloudFront inoltra all'origine una richiesta in seguito a un cache miss
• Origin Response: si attiva quando l'origine restituisce una risposta, prima della memorizzazione nella cache
• Viewer Response: si attiva prima che CloudFront restituisca la risposta al viewer

Lambda@Edge presenta limiti più rigidi rispetto a Lambda standard: massimo 128 MB di memoria (eventi viewer), 1 GB (eventi origin), timeout massimo di 5 secondi (viewer) e 30 secondi (origin). Le funzioni devono essere create in us-east-1 e distribuite all'edge tramite CloudFront. Non sono supportati VPC, variabili d'ambiente o Lambda Layers. Questi vincoli fanno sì che Lambda@Edge sia progettato per trasformazioni leggere, non per elaborazioni intensive.

Lambda@Edge è particolarmente adatto a: A/B testing (riscrivere gli URL verso percorsi di origine diversi in base ai cookie), autenticazione (convalidare i JWT all'edge prima dell'inoltro all'origine), manipolazione degli header HTTP (aggiungere header di sicurezza come HSTS, CSP e X-Frame-Options), normalizzazione degli URL (reindirizzare da www a non-www o imporre gli slash finali) e personalizzazione (servire contenuti diversi in base al Paese del viewer indicato nell'header CloudFront-Viewer-Country).

Le CloudFront Functions sono funzioni JavaScript estremamente leggere che vengono eseguite solo nelle fasi di richiesta/risposta del viewer, con un limite di esecuzione di 2 ms e un costo molto più contenuto. Per casi d'uso semplici (riscrittura degli URL, manipolazione degli header, normalizzazione della chiave della cache), è preferibile CloudFront Functions a Lambda@Edge perché è più veloce ed economico. Utilizzi Lambda@Edge quando ha bisogno di accedere a chiamate di rete, payload più grandi o ai punti di attivazione delle richieste/risposte all'origine.

Un'event-driven architecture collega i servizi tramite eventi, cioè messaggi che rappresentano qualcosa che è accaduto. In AWS, Lambda è il principale consumer di eventi: riceve eventi da SQS, SNS, DynamoDB Streams, Kinesis, S3, EventBridge e altri servizi. Ogni evento attiva un'esecuzione Lambda, consentendo ai sistemi di reagire in modo asincrono e indipendente senza un accoppiamento stretto. Questo pattern abilita loose coupling, scalabilità indipendente e isolamento dagli errori.

Lambda può essere configurato come event source mapping per SQS. Lambda esegue il polling della coda, recupera fino a una batch size di messaggi (fino a 10.000 per le code standard e 10 per le code FIFO) e invoca la funzione una volta per batch. Se la funzione ha esito negativo, l'intero batch viene restituito alla coda. Configuri una batch window per attendere altri messaggi prima dell'invocazione, migliorando il throughput. Utilizzi una DLQ sulla coda SQS di origine per i messaggi che continuano a non essere elaborati.

DynamoDB Streams acquisisce ogni modifica a livello di elemento (INSERT, MODIFY, REMOVE) come una sequenza ordinata di eventi. Lambda legge dallo stream utilizzando un event source mapping con TRIM_HORIZON (inizio dal più vecchio) o LATEST (inizio dal più recente). Lambda elabora i record in ordine all'interno di una partizione. I batch non riusciti bloccano l'ulteriore elaborazione della stessa partizione finché il problema non viene risolto: utilizzi bisect on error per suddividere i batch che causano errori e isolare i record problematici.

Lambda elabora i record Kinesis in modo simile a DynamoDB Streams: una singola esecuzione simultanea per shard. Le principali opzioni di configurazione includono il parallelisation factor (fino a 10 invocazioni Lambda simultanee per shard, con elaborazione parallela di sottobatch) e l'enhanced fan-out (throughput dedicato di 2 MB/s per shard per il consumer Lambda). Queste opzioni aumentano notevolmente il throughput degli stream ad alto volume senza incrementare il numero di shard.

Amazon EventBridge è l'event bus consigliato per collegare servizi AWS e applicazioni personalizzate. Gli eventi confluiscono in un bus e le rules li filtrano in base a un pattern e li instradano verso destinazioni tra cui Lambda, SQS, Step Functions e altri servizi. EventBridge disaccoppia completamente i produttori dagli eventi e i consumer: nessuno dei due conosce l'altro. L'event bus predefinito riceve gli eventi dai servizi AWS; crei un custom event bus per gli eventi dell'applicazione.

Un pattern comune basato sugli eventi è il fan-out: un singolo evento attiva più pipeline di elaborazione parallele. Pubblicando su un SNS topic, più sottoscrizioni a funzioni Lambda reagiscono indipendentemente. Ad esempio, un evento di ordine effettuato può diramarsi verso: una Lambda che invia un'e-mail di conferma, una Lambda che aggiorna l'inventario e una Lambda che avvisa il magazzino. Ogni consumer è indipendente e scala separatamente: nessun consumer può bloccare gli altri.

Verifichi la Sua comprensione dei concetti AWS Solutions Architect (SAA-C03) trattati in questa lezione.

In questa lezione ha imparato che Lambda@Edge esegue funzioni nelle edge location di CloudFront con quattro punti di attivazione (viewer request/response e origin request/response) per attività come autenticazione, riscrittura degli URL e manipolazione degli header; le CloudFront Functions sono l'alternativa più economica e con latenza inferiore per semplici trasformazioni nella fase viewer; infine, i pattern basati sugli eventi che utilizzano SQS, DynamoDB Streams, Kinesis, EventBridge e il fan-out di SNS consentono architetture scarsamente accoppiate in cui Lambda reagisce agli eventi in tempo reale. Ora esploreremo le code SQS Standard e FIFO a confronto.