EventBridge startet neue Busse mit Reihenfolge, Aufbewahrung und CloudEvents
Victoria Shinder1 Min. LesezeitAmazon Web Services hat am 24. September eine neue Version des eigenen Ereignisbusses von EventBridge angekündigt, des serverlosen Brokers, der Ereignisse zwischen Anwendungen, SaaS-Integrationen und AWS-Diensten verteilt. Der erweiterte Bus bringt mehrere Fähigkeiten, die ereignisgesteuerte Systeme bisher aus anderen Diensten zusammensetzen mussten.
Ein eigener Bus lässt sich nun über AWS Resource Access Manager mit anderen Konten teilen, sodass Absender Ereignisse direkt an einen zentralen Bus schicken. Eine neue Veröffentlichungs-API nimmt Ereignisse in gängigen JSON-Formaten wie CloudEvents an und bewahrt ihr Schema unverändert. Ereignisse werden standardmäßig 24 Stunden aufbewahrt, verlängerbar auf ein Jahr, sodass Verbraucher sich von Fehlern erholen oder neue Komponenten aus der Historie befüllt werden können. Eine neue Subscriber-Ressource filtert Ereignisse und liefert sie an mehr als 250 AWS-Dienste. Der Bus unterstützt jetzt strikt geordnete Verarbeitung in exakter Eingangsreihenfolge und inhaltsbasierte Deduplizierung.
Der bisherige Bus heißt nun "Custom event bus - classic", und laut AWS bleiben alle bestehenden APIs unverändert. Der erweiterte Bus startet in vierzehn Regionen in den USA, Europa und Asien-Pazifik, mit einem neuen Preismodell, das nach übertragenen Daten statt pro Ereignis abrechnet und mit wachsender Last günstiger wird.
Was das bedeutet
Aufbewahrung, Wiedergabe und Reihenfolge sind Funktionen, für die Teams meist zu Kafka oder Kinesis greifen. Dass EventBridge sie bekommt, verkleinert den Abstand zwischen einem Verteildienst und einem Streaming-Log; für Organisationen, die EventBridge schon als Bindeglied zwischen Teams nutzen, entfällt womöglich ein zweites System nur für Historie oder Reihenfolge.
Die Preisänderung verdient vor einer Migration Aufmerksamkeit. Abrechnung nach Daten statt nach Ereignissen begünstigt viele kleine Ereignisse und bestraft große Nutzlasten; die Rechnung einer bestehenden Last kann sich also in beide Richtungen bewegen. Weil der klassische Bus unverändert bleibt, gibt es keine erzwungene Migration; der neue Bus ist eine Entscheidung je Anwendungsfall.