Amazon EventBridge introduce gli enhanced custom event bus, un nuovo modello pensato per condividere un unico bus tra più account AWS senza costruire una catena di bus e regole di inoltro. La novità, annunciata il 24 settembre 2026, interessa soprattutto organizzazioni con una struttura multi-account, molti team applicativi e la necessità di governare gli eventi in modo coerente.
Il vantaggio potenziale è reale, ma “centralizzare” non significa automaticamente semplificare. Cambiano il modello dei permessi, la responsabilità sui contratti evento e anche la lettura dei costi. Prima di adottare il nuovo bus conviene quindi capire quali problemi risolve, quali rischi concentra e come provarlo senza trasformarlo in una dipendenza critica.
Che cosa cambia con il bus EventBridge condiviso
Nel modello classico, un’architettura EventBridge distribuita tra account richiede policy cross-account e, spesso, l’inoltro da un bus all’altro. Con il nuovo modello il bus può essere condiviso tramite AWS Resource Access Manager (RAM) con un’intera organizzazione, una Organizational Unit, singoli account o specifici principal IAM.
I produttori pubblicano sul bus condiviso e i consumatori si registrano come Subscriber. AWS indica una quota predefinita di 10.000 Subscriber per bus, aumentabile su richiesta. Ogni Subscriber riunisce filtro, destinazione, politica di retry e dead-letter queue: un confine operativo più chiaro rispetto a un insieme disperso di regole.
| Aspetto | Bus classico multi-account | Enhanced custom event bus |
|---|---|---|
| Condivisione | Policy e inoltro tra bus | Condivisione diretta tramite AWS RAM |
| Consumatore | Regole e target separati | Risorsa Subscriber con filtro, target, retry e DLQ |
| Ordinamento | Da progettare con servizi complementari | Ordinamento per EventGroupId |
| Duplicati | Idempotenza gestita dall’applicazione | Deduplicazione basata sul contenuto entro una finestra di cinque minuti |
| Trasformazione | Input transformer e logica esterna | JSONata e deserializzazione Avro/Protobuf verso JSON |
| Prezzo | Ingestione e consegna secondo il modello classico | Ingresso a carico del publisher, uscita a carico del Subscriber |
I bus classici non vengono sostituiti: continuano a funzionare come prima. Il nuovo modello è una risorsa distinta da valutare per i casi in cui la condivisione tra account e la gestione di molti consumatori sono realmente centrali.
Le funzioni da valutare, senza fermarsi all’annuncio
Ordinamento per gruppo di eventi
Il campo EventGroupId permette di mantenere l’ordine all’interno di uno stesso gruppo. Può essere utile, per esempio, per le variazioni di stato di un ordine o di un dispositivo. Sullo stesso bus possono convivere Subscriber ordinati e non ordinati, evitando di imporre la stessa caratteristica a ogni consumatore.
L’ordinamento non elimina però la necessità di progettare errori, timeout e concorrenza. Se il target è una funzione, restano importanti capacità, durata e comportamento in caso di retry. In questo senso è utile affiancare la valutazione con l’analisi EP sulle nuove opzioni di durata di AWS Lambda.
Deduplicazione e semantica “exactly once”
EventBridge può calcolare un hash sulle parti significative dell’evento e collassare i duplicati rilevati entro cinque minuti. AWS presenta questa funzione come un modo per ottenere una consegna esattamente una volta nei retry coperti dalla finestra. Non va interpretata come una garanzia universale su tutta la catena.
Un consumer dovrebbe restare idempotente: un evento può essere riprodotto intenzionalmente, arrivare da un processo esterno o essere duplicato fuori dalla finestra. Se esiste già un token di idempotenza affidabile, AWS raccomanda di continuare a utilizzarlo.
Trasformazione e schemi
Il supporto a JSONata consente di trasformare gli eventi prima della consegna. Inoltre il bus può deserializzare eventi Avro o Protobuf in JSON per applicare filtri e routing. Questa comodità riduce parte del codice intermedio, ma rende ancora più importante stabilire chi possiede lo schema, come si versiona e quali modifiche sono compatibili con i consumatori esistenti.
Replay e onboarding di nuovi consumatori
Un Subscriber può iniziare da un momento configurabile. Ciò facilita il recupero degli eventi e l’avvio di un nuovo consumer senza chiedere al produttore una pubblicazione speciale. Il replay va però trattato come un’operazione controllata: può aumentare improvvisamente traffico, invocazioni e costi, oltre a riattivare effetti non idempotenti.
Quando il nuovo modello può convenire
L’enhanced custom event bus ha senso soprattutto quando l’organizzazione possiede già una strategia multi-account e vuole offrire un’infrastruttura eventi comune. Alcuni segnali utili sono:
- più account producono eventi dello stesso dominio aziendale;
- nuovi consumer vengono aggiunti frequentemente;
- le regole di inoltro tra bus sono diventate difficili da censire;
- serve attribuire chiaramente il costo di consegna ai team consumer;
- ordinamento, deduplicazione o replay sono requisiti ricorrenti;
- un platform team può assumere la responsabilità del servizio condiviso.
Per una piccola applicazione in un solo account, con pochi flussi stabili, il bus classico può restare più semplice. Anche un’architettura con requisiti forti di buffering e controllo della pressione potrebbe continuare ad avere bisogno di SQS o di altri componenti: l’invocazione sincrona del target non sostituisce automaticamente una coda.
Costi: il fan-out diventa una variabile da misurare
Nel nuovo modello il publisher sostiene il costo di ingresso, mentre ogni Subscriber sostiene quello di uscita. È un’impostazione più leggibile in un’organizzazione multi-team, ma può sorprendere se si guarda soltanto al volume pubblicato.
Un milione di eventi inviati a un solo Subscriber produce un profilo diverso dallo stesso milione distribuito a dieci Subscriber. Vanno poi considerati dimensione dei payload, trasformazioni, replay, invocazioni dei target, dead-letter queue e trasferimenti tra regioni. La pagina prezzi AWS resta il riferimento da usare nel momento in cui si costruisce il business case.
Un modello FinOps minimo dovrebbe quindi calcolare: eventi in ingresso, percentuale filtrata per Subscriber, consegne effettive, dimensione media, retry, replay e costo dei servizi a valle. Lo stesso approccio per scenari, anziché una stima unica, è utile anche in altri servizi cloud; l’analisi EP sui costi di Amazon CloudFront mostra perché traffico e opzioni architetturali devono essere letti insieme.
I rischi di governance da non spostare sotto il tappeto
Un servizio condiviso è anche una dipendenza condivisa
Un unico bus riduce i collegamenti tra account, ma concentra l’impatto di policy errate, quote esaurite o schemi incompatibili. Servono un owner, un percorso di escalation, obiettivi di servizio e una procedura per le modifiche ad alto rischio.
Permessi e identità
La condivisione tramite RAM non deve trasformarsi in un permesso generico a pubblicare o sottoscrivere. È opportuno separare account, ruoli e domini, applicare il privilegio minimo e registrare chi crea Subscriber o modifica filtri e target. Le credenziali temporanee meritano test specifici, come approfondito nell’articolo EP sui token di sessione AWS STS.
Contratti evento e dati sensibili
Centralizzare gli eventi aumenta il numero potenziale di destinatari. Ogni contratto deve indicare classificazione dei dati, campi vietati, durata di conservazione, compatibilità e modalità di deprecazione. I filtri non sono un sostituto della minimizzazione: un dato non necessario non dovrebbe essere pubblicato.
Un progetto pilota in sei passaggi
- Scegliere un dominio non critico: un flusso con due o tre account e impatto reversibile.
- Misurare la situazione attuale: numero di bus, regole, consegne, errori, tempi operativi e costi.
- Definire il contratto: schema, proprietario, versione, dati ammessi,
EventGroupIde chiave di idempotenza. - Creare publisher e Subscriber separati: con policy minime, retry e dead-letter queue.
- Provare gli errori: duplicati, eventi fuori ordine, target lento, replay e superamento delle quote.
- Confrontare gli esiti: complessità operativa, costo per consumer, affidabilità e tempo di onboarding.
EP Consulting può affiancare PMI e aziende in questa fase con una valutazione indipendente dell’architettura, dei costi e dei rischi: non per spingere automaticamente verso una migrazione, ma per capire se il bus condiviso riduce davvero la complessità, quali controlli mancano e quali indicatori usare per decidere. È un tipo di consulenza particolarmente utile quando cloud, sicurezza e responsabilità tra fornitori o team interni si sovrappongono.
Checklist prima di adottare il bus condiviso
- Account, OU e principal autorizzati sono inventariati.
- Ogni dominio evento ha un owner e uno schema versionato.
- I dati sensibili sono esclusi o minimizzati.
- Subscriber, retry e dead-letter queue hanno responsabili chiari.
- Idempotenza e comportamento del replay sono stati verificati.
- Quote, picchi e backpressure sono stati testati.
- Log, metriche e allarmi coprono pubblicazione e consegna.
- Il modello economico include fan-out, replay e servizi a valle.
- È previsto un percorso di rollback verso il flusso precedente.
- La regione AWS scelta supporta la nuova risorsa.
Domande frequenti
Il nuovo EventBridge sostituisce i bus classici?
No. AWS mantiene i bus classici senza cambiamenti. L’enhanced custom event bus è una nuova opzione, utile soprattutto per scenari condivisi e multi-account.
È già disponibile nella regione AWS di Milano?
Nell’annuncio del 24 settembre 2026 AWS elenca in Europa Irlanda, Francoforte, Stoccolma e Spagna, ma non Milano. Prima di progettare il servizio è necessario verificare la disponibilità regionale aggiornata.
La deduplicazione elimina l’idempotenza applicativa?
No. La deduplicazione copre eventi equivalenti rilevati entro una finestra di cinque minuti. Il consumer deve comunque gestire replay, duplicati esterni e retry fuori finestra.
Si può eliminare SQS davanti a Lambda?
Non automaticamente. L’invocazione sincrona può semplificare alcuni flussi, ma una coda resta utile quando servono buffering, controllo della pressione, disaccoppiamento o gestione indipendente dei picchi.
Qual è il primo indicatore da osservare?
Il costo e il tasso di consegna per Subscriber, insieme agli errori e al tempo necessario per aggiungere un consumer. Misurare solo gli eventi pubblicati nasconde l’effetto del fan-out.
Conclusioni
Il bus EventBridge condiviso può ridurre molte configurazioni cross-account e offrire strumenti migliori per ordinamento, deduplicazione, trasformazione e replay. Il valore emerge però solo con contratti evento chiari, privilegi minimi, osservabilità e una corretta attribuzione dei costi.
Per valutare un’architettura event-driven AWS o confrontare il nuovo modello con quello esistente, è possibile richiedere a EP Consulting un confronto mirato su complessità, sicurezza, costi e sostenibilità operativa, mantenendo la decisione tecnologica ancorata ai processi reali dell’azienda.