PERCORSO FORMATIVO AVANZATO

AWS Lambda e Serverless

Computing
Percorso formativo avanzato per Cloud Architect, Serverless Developer e DevOps
Engineer

50 slide · 8 moduli · Architettura, sicurezza, operations e FinOps

MODULO 1 · FONDAMENTI DEL SERVERLESS

Agenda del percorso

Modulo 1 · Slide 1-7 Modulo 5 · Slide 32-38

Introduzione e fondamenti del Serverless Computing Sviluppo, packaging e deployment moderni

Modulo 2 · Slide 8-16 Modulo 6 · Slide 39-44

Anatomia, runtime e ciclo di vita della funzione Orchestrazione e pattern architetturali

Modulo 3 · Slide 17-25 Modulo 7 · Slide 45-48

Event source e modelli di invocazione Monitoraggio, troubleshooting e osservabilità

Modulo 4 · Slide 26-31 Modulo 8 · Slide 49-50

Sicurezza, IAM e access management FinOps, pricing e best practices

AWS Lambda · Serverless Computing 2

MODULO 1 · FONDAMENTI DEL SERVERLESS

L'evoluzione del Cloud

1 2 3 4

On-Premise IaaS Container Serverless

Hardware Istanze virtuali on- Immagini portabili e Unità di deploy =
proprietario, demand: sparisce il orchestrazione: funzione. Nessun
capacity planning a datacenter, resta la densità elevata, ma server da gestire,
3-5 anni, utilizzo gestione del sistema cluster e nodi scalabilità e billing
medio sotto il 20%. operativo. restano da per uso reale.
governare.

Ogni passaggio sposta responsabilità operativa verso il provider e riduce il tempo tra codice e valore.

AWS Lambda · Serverless Computing 3

MODULO 1 · FONDAMENTI DEL SERVERLESS

Cos'è AWS Lambda

Definizione Filosofia FaaS

• Servizio di compute event-driven che • L'unità di deploy è la funzione, non il server

esegue codice in risposta a eventi. o il container.
• Nessuna istanza da fornire, patchare o • Modello event → handler → risultato,
scalare. intrinsecamente stateless.
• Costo proporzionale all'esecuzione effettiva,
• Esecuzione in ambienti isolati effimeri gestiti
non al tempo di accensione.
da AWS.

Obiettivo: massimizzare il tempo speso sulla logica di business, minimizzare quello speso sull'infrastruttura.

AWS Lambda · Serverless Computing 4

MODULO 1 · FONDAMENTI DEL SERVERLESS

Vantaggi chiave

Zero server management Scalabilità automatica Pagamento al millisecondo

• Provisioning, patching e • Da zero a migliaia di • Fatturazione su richieste

failover gestiti da AWS. esecuzioni concorrenti in e durata in GB-secondi,
secondi. arrotondata al
• Alta disponibilità multi-
AZ nativa. millisecondo.
• Un ambiente per ogni
richiesta concorrente. • Idle cost pari a zero.

Il vantaggio economico è massimo su carichi variabili, discontinui o imprevedibili.

AWS Lambda · Serverless Computing 5

MODULO 1 · FONDAMENTI DEL SERVERLESS

Responsabilità condivisa nel Serverless

AWS gestisce Il cliente gestisce

• Infrastruttura fisica, hypervisor e • Codice applicativo e dipendenze di

Firecracker microVM. terze parti (CVE incluse).
• Sistema operativo, patching e • Policy IAM, configurazione di rete e
aggiornamenti del runtime gestito. crittografia dei dati.
• Isolamento, scaling e disponibilità del • Gestione dei segreti, validazione degli
servizio. input e logica di retry.

Il perimetro si restringe ma non sparisce: la sicurezza applicativa e l'identità restano interamente del cliente.

AWS Lambda · Serverless Computing 6

MODULO 1 · FONDAMENTI DEL SERVERLESS

Quando usare Serverless

Casi d'uso ideali Anti-pattern

• Backend API event-driven con traffico • Elaborazioni oltre i 15 minuti o batch

variabile o a picchi. pesanti di lunga durata.
• Elaborazione asincrona di file, stream e • Carichi costanti 24/7 ad altissimo volume:
code. EC2 o Fargate costano meno.
• Automazioni, glue code e task di • Latenza ultra-bassa e deterministica
integrazione tra servizi AWS. sensibile ai cold start.
• Job schedulati e ETL a esecuzione breve. • Applicazioni stateful o con forte
dipendenza dal filesystem locale.

AWS Lambda · Serverless Computing 7

MODULO 2 · ANATOMIA, RUNTIME E CICLO DI VITA

Anatomia di una funzione Lambda

Handler Codice sorgente Dipendenze

• Punto di ingresso • Logica di business, • Librerie incluse nel

invocato dal runtime, es. preferibilmente pacchetto, nei Layer o
`[Link]`. disaccoppiata dall'handler. nell'immagine container.
• Minimizzarle riduce
• Riceve event e context e • Handler sottile →
restituisce la risposta. dimensione e tempo di
testabilità e portabilità
cold start.
migliori.

L'oggetto context espone requestId, tempo residuo e log stream: fondamentale per tracing e timeout guard.

AWS Lambda · Serverless Computing 8

MODULO 2 · ANATOMIA, RUNTIME E CICLO DI VITA

Runtime nativi e Custom Runtime

Runtime gestiti Custom Runtime

• [Link], Python, Java, Go, .NET, Ruby • Interfaccia Runtime API per qualsiasi
con versioni aggiornate da AWS. linguaggio (Rust, PHP, COBOL).
• Patching del runtime a carico del servizio. • Distribuito come Layer o immagine
container.
• Ogni runtime ha una data di fine supporto
da monitorare. • Il ciclo di vita del runtime diventa
responsabilità del team.

[Link] e Python offrono i cold start più rapidi; Java e .NET privilegiano throughput e ecosistema enterprise.

AWS Lambda · Serverless Computing 9

MODULO 2 · ANATOMIA, RUNTIME E CICLO DI VITA

Ciclo di vita di un'esecuzione

1 2 3

Init Phase Invoke Phase Shutdown Phase

Download del codice, Esecuzione dell'handler Al termine dell'inattività
avvio del runtime ed sull'evento ricevuto; l'ambiente viene
esecuzione del codice l'ambiente viene riusato terminato, con notifica alle
statico fuori dall'handler. per invocazioni successive. extension registrate.

Inizializzare client SDK e connessioni nella Init Phase permette di riusarli su tutte le invocazioni successive.

AWS Lambda · Serverless Computing 10

MODULO 2 · ANATOMIA, RUNTIME E CICLO DI VITA

Cold Start vs Warm Start

Cause del cold start Mitigazioni

• Prima invocazione, scale-out o nuova • Ridurre bundle e usare tree-shaking o

versione pubblicata. lazy loading.
• Pacchetti di deploy grandi e dipendenze • Riuso di connessioni e client fuori
pesanti. dall'handler.
• Attach di ENI in VPC e runtime a lunga • Provisioned Concurrency o SnapStart
inizializzazione. per i percorsi critici.

Su un'applicazione a regime i cold start restano tipicamente sotto l'1% delle invocazioni: ottimizzare dove la latenza è visibile all'utente.

AWS Lambda · Serverless Computing 11

MODULO 2 · ANATOMIA, RUNTIME E CICLO DI VITA

Provisioned Concurrency

Cosa fa mantiene un numero definito di ambienti già inizializzati e pronti a rispondere.

Effetto elimina la latenza di init per le invocazioni servite dalla capacità riservata.

Configurazione si applica a un alias o a una versione pubblicata, mai a $LATEST.

Scaling integrabile con Application Auto Scaling e schedule su finestre di traffico note.

Costo si paga la capacità mantenuta calda: usarla solo su funzioni latency-critical.

AWS Lambda · Serverless Computing 12

MODULO 2 · ANATOMIA, RUNTIME E CICLO DI VITA

SnapStart per Java

Come funziona Attenzioni

• Snapshot cifrato della memoria dopo • Attivo su versioni pubblicate, non su $LATEST.
l'inizializzazione (Firecracker).
• Unicità: rigenerare seed casuali e connessioni
• Le invocazioni successive ripristinano lo
dopo il restore.
snapshot invece di reinizializzare.
• Hook di runtime per gestire lo stato non
• Riduzione dei tempi di avvio fino a un ordine di riproducibile.
grandezza.

Ideale per Spring Boot e framework con inizializzazione pesante, a costo zero aggiuntivo sul servizio.

AWS Lambda · Serverless Computing 13

MODULO 2 · ANATOMIA, RUNTIME E CICLO DI VITA

Memoria e CPU

Range di memoria da 128 MB a 10.240 MB, configurabile in incrementi di 1 MB.

CPU proporzionale la potenza di calcolo cresce con la memoria; oltre ~1.769 MB si dispone di una vCPU piena.

Multi-core le funzioni multi-thread traggono beneficio solo con memoria elevata.

Tuning più memoria può ridurre il costo totale se la durata cala più di quanto cresce il prezzo unitario.

Metodo misurare con Lambda Power Tuning invece di procedere per tentativi.

AWS Lambda · Serverless Computing 14

MODULO 2 · ANATOMIA, RUNTIME E CICLO DI VITA

Timeout e storage temporaneo

Timeout Storage effimero

• Massimo 15 minuti, default 3 secondi. • Directory /tmp da 512 MB fino a 10.240 MB.
• Allinearlo al timeout del client a monte (es. • Persiste tra invocazioni nello stesso
API Gateway, 29 s). ambiente: utile come cache locale.
• Timeout troppo alti mascherano deadlock e • Per dati condivisi o persistenti usare S3, EFS
retry costosi. o DynamoDB.

Non assumere mai che /tmp sia vuoto: pulire i file temporanei e non fidarsi del contenuto residuo.

AWS Lambda · Serverless Computing 15

MODULO 2 · ANATOMIA, RUNTIME E CICLO DI VITA

Variabili d'ambiente e configurazione

Uso corretto endpoint, nomi di tabelle, feature flag e livelli di log per ambiente.

Crittografia cifratura a riposo con KMS; per valori sensibili abilitare l'helper di encryption in transit.

Limite 4 KB complessivi per tutte le variabili della funzione.

Segreti credenziali e token vanno in Secrets Manager o Parameter Store, mai nelle variabili in chiaro.

Governance separare configurazione e codice permette promozioni tra ambienti senza rebuild.

AWS Lambda · Serverless Computing 16

MODULO 3 · EVENT SOURCE E INVOCAZIONE

Modelli di invocazione

Sincrona Asincrona Event Source Mapping

• Il chiamante attende la • Evento accodato • Lambda esegue il polling

risposta. internamente da della sorgente.
Lambda.
• API Gateway, ALB, SDK, • SQS, Kinesis, DynamoDB
Function URL. • S3, SNS, EventBridge. Streams, MSK.
• Retry a carico del client. • Retry automatici e DLQ. • Elaborazione a batch.

Il modello di invocazione determina retry, ordinamento, gestione degli errori e strategia di idempotenza.

AWS Lambda · Serverless Computing 17

MODULO 3 · EVENT SOURCE E INVOCAZIONE

Invocazione sincrona

Flusso richiesta → esecuzione → risposta restituita al chiamante nello stesso ciclo.

Sorgenti tipiche API Gateway, Application Load Balancer, Function URL, invocazione diretta via SDK.

Vincoli payload fino a 6 MB e limite di timeout imposto dal servizio a monte.

Errori l'eccezione risale al client: gestione e retry restano a carico del chiamante.

Latenza è il percorso dove i cold start incidono di più sull'esperienza utente.

AWS Lambda · Serverless Computing 18

MODULO 3 · EVENT SOURCE E INVOCAZIONE

Invocazione asincrona

Coda interna Lambda accetta l'evento, risponde 202 e lo elabora in modo indipendente.

Retry automatici due tentativi aggiuntivi con backoff esponenziale in caso di errore.

Event age gli eventi possono restare in coda fino a 6 ore prima di essere scartati.

DLQ gli eventi definitivamente falliti vengono inoltrati a una coda SQS o a un topic SNS.

Idempotenza obbligatoria: la stessa richiesta può essere elaborata più di una volta.

AWS Lambda · Serverless Computing 19

MODULO 3 · EVENT SOURCE E INVOCAZIONE

Lambda Destinations

Cosa offrono Vantaggi sulla DLQ

• Instradamento dichiarativo dell'esito di • Il record include evento, risposta ed errore,

un'invocazione asincrona. non solo il payload originale.
• Destinazioni separate per successo e • Cattura anche gli esiti positivi, abilitando
fallimento. pipeline di post-elaborazione.
• Target: SQS, SNS, EventBridge o un'altra • Meno codice di plumbing all'interno della
funzione Lambda. funzione.

Le Destinations sono l'approccio raccomandato; la DLQ resta valida per scenari legacy o di sola cattura errori.

AWS Lambda · Serverless Computing 20

MODULO 3 · EVENT SOURCE E INVOCAZIONE

Event Source Mapping

Amazon SQS Kinesis DynamoDB Streams

• Polling gestito con scaling • Elaborazione ordinata per • Reazione alle modifiche delle
automatico dei poller. shard. tabelle.
• Parallelization factor per
• Batch size e batching window • Ordine garantito per chiave di
aumentare il throughput.
configurabili. partizione.
• Bisect on error per isolare i
• Coda DLQ e partial batch • Base per CQRS ed Event
record velenosi.
response. Sourcing.

Nel poll-based è Lambda a leggere la sorgente: il tuning di batch, concorrenza e retry determina throughput e costi.

AWS Lambda · Serverless Computing 21

MODULO 3 · EVENT SOURCE E INVOCAZIONE

Integrazione con Amazon S3

Trigger notifiche su creazione, rimozione, ripristino o replica degli oggetti.

Filtri selezione per prefisso e suffisso per evitare invocazioni inutili.

Casi d'uso generazione di thumbnail, validazione e antivirus, ingestion e indicizzazione.

Ricorsione mai scrivere l'output nello stesso prefisso di input: si generano loop infiniti.

Consegna invocazione asincrona at-least-once: progettare handler idempotenti.

AWS Lambda · Serverless Computing 22

MODULO 3 · EVENT SOURCE E INVOCAZIONE

EventBridge e Lambda

Event bus e regole Architetture event-driven

• Bus default, custom e partner per • Publisher e consumer completamente

separare i domini. disaccoppiati.
• Regole basate su pattern JSON sul • Schema Registry per contratti di evento
contenuto dell'evento. versionati.
• Schedule expression per job periodici e • Archive e replay degli eventi per audit e
cron. recovery.

EventBridge sostituisce le integrazioni punto-punto con un router centrale governabile e osservabile.

AWS Lambda · Serverless Computing 23

MODULO 3 · EVENT SOURCE E INVOCAZIONE

Function URLs

Cosa sono endpoint HTTPS dedicato e permanente esposto direttamente dalla funzione.

Auth modalità AWS_IAM con SigV4 oppure NONE per endpoint pubblici.

CORS configurazione nativa di origini, header e metodi consentiti.

Streaming supporto al response streaming per payload progressivi e time-to-first-byte ridotto.

Limiti niente API key, usage plan, WAF nativo o routing multi-risorsa: per questi serve API Gateway.

AWS Lambda · Serverless Computing 24

MODULO 3 · EVENT SOURCE E INVOCAZIONE

WebSocket con API Gateway

Route e connessioni Comunicazione bidirezionale

• Route riservate $connect, $disconnect e • Push verso il client tramite l'API

$default. @connections.
• Ogni route può invocare una funzione • Casi d'uso: chat, notifiche live, dashboard
Lambda dedicata. real-time, collaborazione.
• Connection ID persistito su DynamoDB per • Gestire la pulizia delle connessioni scadute
il routing. o interrotte.

Il modello resta stateless: lo stato della sessione vive in un datastore esterno, non nella funzione.

AWS Lambda · Serverless Computing 25

MODULO 4 · SICUREZZA, IAM E ACCESS MANAGEMENT

Execution Role e minimo privilegio

Execution Role ruolo IAM assunto dalla funzione per accedere ai servizi AWS.

Credenziali temporanee, ruotate automaticamente ed esposte al runtime: nessuna chiave statica.

Minimo privilegio una policy per funzione, con azioni e ARN di risorsa espliciti.

Anti-pattern policy gestite ampie o wildcard su azioni e risorse.

Verifica IAM Access Analyzer e Access Advisor per rimuovere i permessi inutilizzati.

AWS Lambda · Serverless Computing 26

MODULO 4 · SICUREZZA, IAM E ACCESS MANAGEMENT

Resource-based policies

A cosa servono Buone pratiche

• Policy applicata alla funzione, non • Vincolare SourceArn e SourceAccount

all'identità chiamante. per evitare il confused deputy.
• Autorizza servizi AWS (S3, SNS, • Un permission statement per ogni
EventBridge) a invocarla. sorgente, con ID parlante.
• Abilita l'invocazione cross-account senza • Applicare la policy ad alias o versione per
ruoli condivisi. isolare gli ambienti.

Identity-based e resource-based policy si combinano: l'accesso è concesso solo se entrambe lo permettono.

AWS Lambda · Serverless Computing 27

MODULO 4 · SICUREZZA, IAM E ACCESS MANAGEMENT

Secrets Manager e Parameter Store

AWS Secrets Manager SSM Parameter Store

• Rotazione automatica di credenziali di • Parametri standard e SecureString cifrati

database e API key. con KMS.
• Integrazione nativa con RDS e Aurora. • Gerarchia per ambiente e applicazione.

• Costo per segreto e per chiamata API. • Tier standard gratuito: ideale per
configurazione non critica.

Usare l'extension Lambda per il caching locale dei segreti: meno latenza, meno chiamate API, meno costi.

AWS Lambda · Serverless Computing 28

MODULO 4 · SICUREZZA, IAM E ACCESS MANAGEMENT

Crittografia con AWS KMS

Ambito variabili d'ambiente, codice a riposo, log e snapshot SnapStart cifrati di default.

AWS managed key chiave gestita da AWS, senza costi di gestione e senza controllo sulla policy.

Customer managed key policy, rotazione e audit trail sotto il controllo del cliente.

Envelope encryption data key locale protetta dalla chiave master: crittografia efficiente su payload grandi.

Governance separare le chiavi per ambiente e tracciare l'uso via CloudTrail.

AWS Lambda · Serverless Computing 29

MODULO 4 · SICUREZZA, IAM E ACCESS MANAGEMENT

VPC Integration

Quando serve Come configurarla

• Accesso a RDS, ElastiCache o servizi • Subnet private su almeno due AZ e security

interni in subnet private. group dedicato.
• Requisiti di conformità sul traffico privato. • Uscita verso Internet solo tramite NAT
Gateway.
• Integrazione con reti on-premise via Direct
Connect o VPN. • VPC Endpoint per raggiungere S3,
DynamoDB e KMS senza uscire dalla rete.

Una funzione in VPC senza NAT o endpoint non raggiunge i servizi AWS pubblici: causa frequente di timeout silenziosi.

AWS Lambda · Serverless Computing 30

MODULO 4 · SICUREZZA, IAM E ACCESS MANAGEMENT

Hyperplane ENI

Cosa sono ENI condivise e gestite da AWS Hyperplane per l'accesso di Lambda alla VPC.

Beneficio le ENI vengono create una sola volta per combinazione di subnet e security group.

Impatto la penalità di cold start dovuta al networking scende da decine di secondi a pochi millisecondi.

Condivisione molte esecuzioni concorrenti riusano lo stesso set di interfacce di rete.

Progettazione limitare le combinazioni subnet/security group e dimensionare gli IP disponibili nelle subnet.

AWS Lambda · Serverless Computing 31

MODULO 5 · SVILUPPO, PACKAGING E DEPLOYMENT

Packaging: ZIP vs Container

ZIP archive Container image

• Fino a 50 MB compressi e 250 MB • Immagine OCI fino a 10 GB su Amazon

decompressi. ECR.
• Deploy rapido, supporto ai Layer e • Toolchain e processo di build identici al
all'editor in console. resto della piattaforma.
• Percorso più semplice e con cold start • Ideale per dipendenze pesanti come ML
generalmente inferiori. e librerie native.

Il container non è più lento per definizione: caching a livelli e ottimizzazione dell'immagine riducono l'avvio.

AWS Lambda · Serverless Computing 32

MODULO 5 · SVILUPPO, PACKAGING E DEPLOYMENT

Lambda Layers

Cosa sono archivi ZIP versionati con librerie, runtime custom o file di configurazione condivisi.

Limite fino a 5 layer per funzione, entro i 250 MB decompressi complessivi.

Vantaggi riuso tra funzioni, pacchetti di deploy più snelli e aggiornamenti centralizzati.

Condivisione distribuibili cross-account o pubblicamente tramite resource policy.

Attenzione i layer sono immutabili e versionati: gestirne il ciclo di vita come artefatti di build.

AWS Lambda · Serverless Computing 33

MODULO 5 · SVILUPPO, PACKAGING E DEPLOYMENT

AWS SAM

Infrastructure as Code Sviluppo locale

• Estensione di CloudFormation con sintassi • `sam local invoke` e `start-api` per

sintetica per il serverless. l'esecuzione in container.
• Risorse `AWS::Serverless::Function`, `Api`, • `sam sync` per iterazioni rapide
`StateMachine`. sull'ambiente di sviluppo.
• Deploy guidato, versionamento e rollback • Generazione di eventi di test per le
nativi. sorgenti più comuni.

Alternativa idiomatica per team che preferiscono un linguaggio di programmazione: AWS CDK.

AWS Lambda · Serverless Computing 34

MODULO 5 · SVILUPPO, PACKAGING E DEPLOYMENT

Serverless Framework e Terraform

Serverless Framework Terraform

• Configurazione YAML orientata alle • Multi-cloud e coerente con il resto

funzioni e agli eventi. dell'infrastruttura aziendale.
• Ecosistema ricco di plugin per packaging • State file, moduli riusabili e piano di
e ottimizzazione. modifica esplicito.

• Astrae comunque CloudFormation sotto • Più verboso sul serverless, ma

il cofano. governance uniforme.

Il criterio di scelta è organizzativo: chi possiede l'infrastruttura e con quale toolchain la gestisce già.

AWS Lambda · Serverless Computing 35

MODULO 5 · SVILUPPO, PACKAGING E DEPLOYMENT

CI/CD per Lambda

1 2 3 4

Build Test Deploy Release

Compilazione, Unit test, analisi Pubblicazione di Traffic shifting
installazione delle statica, scansione una nuova versione canary o lineare
dipendenze e delle dipendenze e e aggiornamento con CodeDeploy e
creazione policy check IaC. dell'alias di rollback su allarme.
dell'artefatto ambiente.
versionato.

Versioni immutabili e alias sono la base per deploy progressivi sicuri e reversibili in secondi.

AWS Lambda · Serverless Computing 36

MODULO 5 · SVILUPPO, PACKAGING E DEPLOYMENT

Lambda Extensions

Come funzionano Casi d'uso

• Processi che affiancano il runtime nello • Agent di observability, APM e tracing di

stesso ambiente di esecuzione. terze parti.
• Internal: nello stesso processo del • Caching di parametri e segreti a bassa
runtime. latenza.
• External: processo separato, con accesso • Controlli di sicurezza runtime e telemetria
alle fasi di init e shutdown.
custom.

Le extension consumano memoria e possono incidere sulla durata: misurarne sempre l'impatto sui costi.

AWS Lambda · Serverless Computing 37

MODULO 5 · SVILUPPO, PACKAGING E DEPLOYMENT

Testing locale e unit testing

Separazione logica di business fuori dall'handler: test veloci e senza dipendenze AWS.

Mocking eventi payload realistici generati da SAM o da librerie di event fixture.

Test di integrazione eseguire contro risorse cloud reali in un ambiente effimero dedicato.

Emulazione container di emulazione locale utile ma non fedele su IAM, limiti e latenze.

Regola pratica testare la logica in locale, testare le integrazioni nel cloud.

AWS Lambda · Serverless Computing 38

MODULO 6 · ORCHESTRAZIONE E PATTERN

Architetture serverless scalabili

Disaccoppiamento Idempotenza Osservabilità

• Code e bus tra i • Consegna at-least-once • Correlation ID

componenti per come assunzione di propagato lungo tutto
assorbire i picchi. base. il flusso.
• Guasti isolati anziché • Chiavi di deduplica e • Tracing distribuito fin
propagati. store di idempotenza. dal primo giorno.

Nel serverless l'architettura si sposta dal codice alla configurazione delle integrazioni tra servizi gestiti.

AWS Lambda · Serverless Computing 39

MODULO 6 · ORCHESTRAZIONE E PATTERN

AWS Step Functions

Orchestrazione Standard vs Express

• Macchine a stati con Task, Choice, • Standard: esecuzioni lunghe, exactly-

Parallel, Map e Wait. once, storico completo.
• Retry, catch e timeout dichiarativi, fuori • Express: alto volume, breve durata, costo
dal codice. inferiore.
• Workflow fino a un anno di durata. • Integrazione diretta con oltre 200 servizi
AWS.

Preferire l'orchestrazione dichiarativa alle catene di funzioni che si invocano a vicenda.

AWS Lambda · Serverless Computing 40

MODULO 6 · ORCHESTRAZIONE E PATTERN

Fan-out e Fan-in

1 2 3 4

Publish Fan-out Process Fan-in

Un evento viene Più code SQS Le funzioni I risultati
pubblicato su un sottoscritte Lambda confluiscono in
topic SNS o su un ricevono una elaborano i batch uno store comune
bus EventBridge. copia dell'evento in modo o in uno stato
in parallelo. indipendente e aggregato.
concorrente.

Il pattern SNS + SQS + Lambda aggiunge buffering, retry indipendenti e DLQ per ogni consumer.

AWS Lambda · Serverless Computing 41

MODULO 6 · ORCHESTRAZIONE E PATTERN

CQRS ed Event Sourcing

CQRS Event Sourcing

• Separazione tra modello di scrittura e • Lo stato è la proiezione di una sequenza

modelli di lettura. immutabile di eventi.
• Read model materializzati e ottimizzati • DynamoDB Streams o Kinesis come log
per query specifiche. degli eventi.
• Scalabilità indipendente dei due percorsi.
• Audit trail completo e replay dello stato
storico.

Prezzo da pagare: consistenza eventuale, versionamento degli eventi e maggiore complessità operativa.

AWS Lambda · Serverless Computing 42

MODULO 6 · ORCHESTRAZIONE E PATTERN

Stateless e persistenza esterna

DynamoDB Aurora Serverless v2 S3 ed ElastiCache

• Latenza costante e • Scaling granulare della • S3 per oggetti e data

scaling on-demand. capacità. lake.
• Modello di consumo • RDS Proxy per il • Cache condivisa per
affine al serverless. pooling delle stato a bassa latenza.
connessioni.

Le connessioni a database relazionali sono la risorsa scarsa: senza pooling la concorrenza satura il database.

AWS Lambda · Serverless Computing 43

MODULO 6 · ORCHESTRAZIONE E PATTERN

Architetture reali

Web backend Elaborazione immagini Data ingestion

• CloudFront e S3 per il • Upload su S3 come • Kinesis Data Streams

frontend statico. trigger dell'evento. come punto di ingresso.
• API Gateway, Lambda e • Lambda per resize, • Lambda per
DynamoDB per le API. watermark e metadati. trasformazione e
arricchimento.
• Cognito per • Step Functions per
l'autenticazione. pipeline multi-step. • Firehose verso S3, poi
Athena.

AWS Lambda · Serverless Computing 44

MODULO 7 · MONITORAGGIO E OSSERVABILITÀ

CloudWatch Logs e metriche

Metriche native Logging

• Invocations, Errors, Duration, Throttles. • Un log group per funzione, con retention
• ConcurrentExecutions, IteratorAge e esplicita.
DestinationDeliveryFailures.
• Log strutturati in JSON interrogabili con
• Allarmi su tasso di errore e percentili di Logs Insights.
durata (p95, p99). • Livelli di log controllati da variabile
d'ambiente.

La retention di default è infinita: impostarla è una delle ottimizzazioni di costo più immediate.

AWS Lambda · Serverless Computing 45

MODULO 7 · MONITORAGGIO E OSSERVABILITÀ

AWS Lambda Powertools

Logger Metrics Tracer

• Log JSON strutturati • Metriche custom in • Annotazioni e

con contesto della formato EMF, senza subsegmenti X-Ray con
funzione. chiamate API sincrone. poche righe.
• Correlation ID • Dimensioni di business • Idempotency e batch
propagato già pronte. processing inclusi nel
automaticamente. toolkit.

Disponibile per Python, TypeScript, Java e .NET: standardizza l'osservabilità tra team e linguaggi.

AWS Lambda · Serverless Computing 46

MODULO 7 · MONITORAGGIO E OSSERVABILITÀ

Distributed Tracing

AWS X-Ray OpenTelemetry

• Service map end-to-end di API, funzioni • Standard vendor-neutral tramite ADOT

e datastore. Lambda Layer.
• Segmenti e subsegmenti per isolare i colli • Export verso X-Ray o backend di terze
di bottiglia. parti.

• Attivabile con il tracing attivo e i • Traccia unica su architetture ibride e

permessi IAM dedicati. multi-cloud.

Tracciare l'intero percorso della richiesta: nelle architetture event-driven la latenza si nasconde nelle integrazioni.

AWS Lambda · Serverless Computing 47

MODULO 7 · MONITORAGGIO E OSSERVABILITÀ

Concorrenza e throttling

Limiti di concorrenza Gestione del throttling

• Account concurrency: 1.000 di default, • Errore 429 TooManyRequestsException

incrementabile su richiesta. al superamento del limite.
• Reserved concurrency: quota garantita • Sincrono: errore al client. Asincrono: retry
e tetto massimo per funzione. automatici.
• Burst iniziale, poi crescita progressiva • Allarmi sulla metrica Throttles e buffering
della capacità. tramite SQS.

Riservare concorrenza a una funzione la sottrae al pool comune: governare la ripartizione a livello di account.

AWS Lambda · Serverless Computing 48

MODULO 8 · FINOPS, PRICING E BEST PRACTICE

Modello di pricing

Componenti di costo Free Tier e ottimizzazione

• Richieste: costo per milione di invocazioni. • 1 milione di richieste e 400.000 GB-secondi al

• Durata: GB-secondi, calcolati su memoria e mese, sempre gratuiti.
tempo al millisecondo.
• Right-sizing della memoria per ridurre il costo
• Voci aggiuntive: Provisioned Concurrency,
totale.
storage effimero e traffico dati.
• Attenzione ai costi indiretti: log, NAT Gateway
e chiamate API a valle.

Il costo di Lambda è spesso minore di quello dei servizi che la circondano: modellare l'intera architettura.

AWS Lambda · Serverless Computing 49

MODULO 8 · FINOPS, PRICING E BEST PRACTICE

Checklist finale delle best practice

Performance Sicurezza Costi e operations

• Handler sottile e • Un ruolo per funzione, • Retention dei log e right-

dipendenze minime. minimo privilegio. sizing.
• Riuso di client e • Segreti in Secrets Manager, • Idempotenza, DLQ e
connessioni. mai nel codice. allarmi attivi.
• Memoria calibrata con • VPC ed endpoint solo dove • Deploy canary con rollback
misure reali. servono. automatico.

Il serverless premia la disciplina architetturale: automazione, osservabilità e revisione continua dei costi.

AWS Lambda · Serverless Computing 50