Il tuo frontend carica, l'API risponde, ma alla fine del mese il conto AWS ti fa alzare gli occhi al cielo. Oppure hai una funzione Lambda che teoricamente dovrebbe eseguire un'elaborazione ogni volta che un file finisce su S3, ma metà delle volte non parte. Se lavori con serverless da un po', sai che la magia svanisce quando devi gestire trigger imprecisi e costi che esplodono senza preavviso. No, di Meteora Web, abbiamo visto situazioni del genere in progetti reali — a volte un solo errore di configurazione moltiplica la spesa per dieci. Per questo abbiamo messo a punto un approccio concreto: partiamo dai trigger, poi mettiamo i costi sotto una lente d'ingrandimento.
Questa guida è per chi ha già un progetto serverless su AWS e vuole capire come far funzionare le Lambda senza sorprese. Non è un'introduzione: parliamo di trigger reali (S3, SQS, API Gateway, DynamoDB Streams) e di come domare i costi con tecniche collaudate.
Come funzionano i trigger delle Lambda AWS in un progetto reale?
Una Lambda da sola non fa nulla. Ha bisogno di un evento che la risvegli. Il trigger è quel legame tra una fonte di eventi e la funzione. AWS offre una decina di servizi che possono invocare una Lambda in modo sincrono o asincrono. La scelta del trigger cambia tutto: latenza, affidabilità, e soprattutto costo.
Trigger sincroni: API Gateway e Application Load Balancer
Quando un utente chiama la tua API, la Lambda deve rispondere subito. Qui il trigger è sincrono: AWS attende la risposta della funzione e la reinoltra al client. È il caso classico delle REST API. Il problema? Se la Lambda impiega 3 secondi per una richiesta semplice, hai un cold start che si somma alla latenza di rete. Noi risolviamo impostando Provisioned Concurrency sulle funzioni critiche — così la Lambda è già calda, anche se il costo orario aumenta. Per un API di produzione, il compromesso è necessario.
Sponsored Protocol
# Esempio di handler per API Gateway
import json
def lambda_handler(event, context):
# event contiene il corpo della richiesta, parametri query, header
nome = event.get('queryStringParameters', {}).get('nome', 'Mondo')
return {
'statusCode': 200,
'body': json.dumps({'messaggio': f'Ciao {nome}!'}),
'headers': {'Content-Type': 'application/json'}
}Trigger asincroni: S3, SQS, DynamoDB Streams
I trigger asincroni sono più interessanti per chi gestisce batch, upload, code di messaggi. La Lambda riceve l'evento e viene eseguita senza che il chiamante aspetti. Ma attenzione: se la funzione fallisce, di default AWS riprova fino a 3 volte. Se sbagli la gestione degli errori, paghi per esecuzioni inutili. Un cliente che seguiamo aveva una Lambda collegata a un bucket S3 per ridimensionare le immagini all'upload. Il trigger funzionava, ma a volte l'immagine era già in formato webp: la funzione non faceva nulla, ma pagava comunque l'esecuzione. Abbiamo risolto filtrando gli eventi S3 con .png e .jpg già a livello di trigger, usando i filtri di evento S3. Meno invocazioni, meno costi.
# Configurazione del trigger S3 con filtro (Console AWS o Terraform)
{
"LambdaFunctionArn": "arn:aws:lambda:...",
"Events": ["s3:ObjectCreated:*"],
"Filter": {
"Key": {
"FilterRules": [
{"Name": "suffix", "Value": ".jpg"},
{"Name": "suffix", "Value": ".png"}
]
}
}
}Trigger da code e stream: SQS e DynamoDB
SQS è il modo più pulito per decuplicare il carico di lavoro. Una coda accumula messaggi e la Lambda li consuma a lotti. Il costo? Zero per i primi milione di richieste SQS al mese, poi si paga solo il traffico. Ma bisogna configurare correttamente batchSize e maximumBatchingWindowInSeconds. Con DynamoDB Streams, invece, ogni modifica a una tabella scatena la Lambda. Qui il costo è legato ai record letti dallo stream. Un errore comune: attivare lo stream su tutte le modifiche quando basterebbe solo INSERT e MODIFY. Usiamo i filtri nativi degli stream (da fine 2024) per ridurre le invocazioni del 50%.
Sponsored Protocol
Quali sono i costi reali di Lambda e serverless AWS?
Il pricing AWS Lambda è semplice solo sulla carta: paghi per il numero di richieste e per la durata dell'esecuzione (arrotondata allo 0.1 secondi più vicino). Ma la realtà è piena di insidie. Noi, di Meteora Web, analizziamo regolarmente i costi serverless dei nostri clienti. Ecco i tre fattori che fanno la differenza.
Il costo delle richieste: gratuito fino a 1 milione al mese
Il tier gratuito include 1 milione di richieste al mese e 400.000 GB‑secondi di calcolo. Per un progetto piccolo è sufficiente. Ma appena superi la soglia, ogni milione di richieste costa $0.20. Sembra poco, ma se la tua API serve 10 milioni di richieste al mese, sono $2 solo di richieste, più la durata. La durata si calcola in GB‑secondi: 1 GB di memoria per 1 secondo = 1 GB‑secondo. Una funzione con 512 MB di memoria che impiega 200 ms costa 0.0000002 GB‑secondi? No: la memoria allocata conta, non quella usata. Se assegni 1024 MB per una funzione che usa 128 MB, paghi di più. Quindi: dimensiona la memoria al minimo indispensabile usando AWS Lambda Power Tuning (tool open source).
Sponsored Protocol
Costi nascosti: trasferimento dati, CloudWatch, VPC
La Lambda in sé è solo una parte. Ogni invocazione produce log su CloudWatch Logs. Un log di 1 KB per esecuzione, con 5 milioni di invocazioni, sono circa 5 GB di log al mese. A $0.50 per GB (primi 5 GB gratis), il costo sale. Soluzione: imposta un periodo di retention breve (7 giorni per ambienti non prod) e usa log di debug con condizionali. Inoltre, se la Lambda è in una VPC, paghi per i NAT Gateway o VPC Endpoints. Evita di mettere tutte le Lambda in VPC se non necessario: usa AWS Lambda managed policy per accedere a servizi come S3 e DynamoDB senza VPC.
L'impatto della memoria e della durata sul costo
Più memoria significa più costo per GB‑secondo, ma spesso anche meno tempo di esecuzione. Una funzione che fa compressione immagini può impiegare 5 secondi con 256 MB, ma 1 secondo con 1024 MB. Il costo totale potrebbe essere inferiore con più memoria perché si paga meno durata. Noi usiamo AWS Lambda Power Tuning per testare automaticamente diverse configurazioni di memoria e trovare il punto di costo minimo. In un caso reale abbiamo ridotto la spesa del 30% passando da 512 MB a 1024 MB su una funzione di transcodifica.
Come ottimizzare i costi delle funzioni serverless AWS?
Ora che conosci i meccanismi, passiamo alle azioni concrete che puoi attuare oggi stesso.
Sponsored Protocol
1. Imposta un budget e un allarme su Cost Explorer
AWS ti permette di creare budget mensili e ricevere notifiche quando la spesa supera una soglia. Imposta un budget di $10 al mese per le Lambda e un allarme a $8. Se superi, sai che qualcosa è cambiato. Noi consigliamo di abilitare i tag di costo sulle funzioni (es. Environment: production) per filtrare nel report.
2. Usa ARM64 (Graviton) invece di x86_64
Le istanze ARM64 sono il 20% più economiche per la stessa potenza. AWS offre le Lambda su architettura Graviton2. Basta cambiare il valore di architectures nel template CloudFormation o nella console. Assicurati che le dipendenze (binari nativi) siano compilate per ARM. Per Python e Node.js non ci sono problemi. Noi su molti progetti abbiamo ridotto del 20% il costo senza toccare una riga di codice.
3. Riduci le invocazioni con filtri e batch
Ogni invocazione ha un costo. Quindi filtra a monte. Per S3, usa i filtri di evento. Per SQS, aumenta il batchSize a 10 (massimo predefinito) e imposta un maximumBatchingWindowInSeconds di 30 secondi. Invece di invocare la Lambda per ogni messaggio, raccogli fino a 10 messaggi per esecuzione. Le richieste totali calano drasticamente.
# Esempio di configurazione SQS event source mapping (Terraform)
resource "aws_lambda_event_source_mapping" "sqs_trigger" {
event_source_arn = aws_sqs_queue.my_queue.arn
function_name = aws_lambda_function.my_lambda.arn
batch_size = 10
maximum_batching_window_in_seconds = 30
}4. Attiva Provisioned Concurrency solo per funzioni critiche
Provisioned Concurrency mantiene un numero fisso di ambienti caldi. Costa come se la funzione fosse sempre in esecuzione (circa $0.000004 per GB‑secondo più la durata reale). Usala solo per API ad alta latenza o in produzione. Per il resto, il cold start è accettabile se inferiore a 1 secondo. Noi lo attiviamo soltanto per le funzioni dietro API Gateway con SLA di risposta < 200 ms.
Sponsored Protocol
5. Monitora con CloudWatch e crea dashboard
Metti in piedi una dashboard CloudWatch con i metriche: Invocations, Duration, Throttles, ConcurrentExecutions. Aggiungi anche EstimatedCost (se usi il tag). Se vedi un picco di invocazioni, controlla subito il trigger. Noi usiamo anche AWS Lambda Insights per debug più profondi.
Cosa fare adesso
Ecco tre azioni che puoi mettere in pratica oggi:
- Rivedi i trigger di ogni Lambda: filtra gli eventi S3, ottimizza il batch su SQS, riduci gli stream DynamoDB ai soli eventi necessari.
- Esegui AWS Lambda Power Tuning sulle funzioni con più invocazioni. Trova il rapporto memoria‑durata ottimale.
- Imposta un budget su AWS Cost Explorer e un allarme per le Lambda. Inserisci i tag per tracciare ambiente e progetto.
Il serverless promette di pagare solo per ciò che usi, ma senza controllo i costi possono esplodere. Noi, di Meteora Web, abbiamo imparato a bilanciare efficienza e spesa in anni di lavoro su progetti reali. Se hai un'infrastruttura AWS da mettere a punto, parti dal nostro pillar AWS e poi approfondisci con questa guida. Ogni centesimo risparmiato è un centesimo che resta nel tuo business.
Per approfondire l'ecosistema serverless, consulta la documentazione ufficiale AWS Lambda.
