Quando un cliente ci dice "voglio che succedano cose quando arriva un file su S3", la risposta facile è "metti un trigger Lambda". Funziona. Ma se i file arrivano da 4 fonti diverse e devono essere instradati in 6 modi, ti ritrovi con 24 trigger e zero osservabilità. EventBridge è la strada migliore.
Il pattern
- S3 emette eventi
ObjectCreatedin EventBridge (basta abilitarlo nel bucket). - EventBridge filtra per pattern (es.
$.detail.object.key suffix .csv) e instrada al target giusto. - I target possono essere Lambda, Step Functions, SQS, EventBridge Pipes (per arricchimento), o servizi terzi via API Destinations.
Cosa ci dà rispetto a S3 → Lambda diretto
- Filtraggio dichiarativo: pattern matching senza scrivere codice.
- Multi-target: lo stesso evento può triggerare 5 cose contemporaneamente.
- Replay: gli eventi possono essere replay-ati durante il debug.
- DLQ a livello di rule: una sola dead letter queue per tutta la pipeline.
Quando S3 → Lambda diretto è ancora la scelta
- Un solo handler, semplice.
- Latenza minima (S3 → Lambda è ~100-300ms; EventBridge aggiunge ~150ms).
- Costi marginali per piccoli volumi (EventBridge fattura per evento, non gratis come S3 → Lambda).
Lezione operativa
Costruire le rule come codice (Terraform, CDK, Pulumi) è obbligatorio. Le rule create dal pannello tendono a essere dimenticate, e nessuno sa più chi triggera cosa. Su un cliente con 38 rule, abbiamo passato due giorni a fare reverse engineering.