Was ist Amazon EventBridge – Ein Kurzüberblick

Einführung

Amazon EventBridge bietet Entwicklern die Möglichkeit, Anwendungen mithilfe eines serverlosen Event Bus zu entkoppeln und Nachrichten basierend auf verschiedenen Anforderungen an unterschiedliche Empfänger weiterzuleiten.

Den Kern von EventBridge stellen hierbei sowohl der sog. Event Bus als auch verschiedene Verarbeitungsregeln (Rules) dar, über die gesteuert wird, welchem Empfänger (Target) eine Nachricht zugewiesen wird. Ein einzelner Event Bus kann dabei bis zu 300 Rules enthalten. Eine Rule wiederum kann bis zu 5 Targets besitzen, an die die Nachricht gesendet wird. Die unterschiedlichsten AWS Services oder SaaS-Anwendungen können Nachrichten auf einem zugehörigen Event Bus zur Weiterverarbeitung hinterlegen.

Der Default Event Bus wird in der AWS-Managementkonsole wie folgt dargestellt:

Nutzt man nun EventBridge mit einem Custom Event Bus bzw. dem Default Event Bus könnte ein theoretischer Aufbau folgendermaßen aussehen:

In obigem Beispiel wurden dem Default Event Bus zwei Rules zugeordnet:

• Rule 1 sendet passende Nachrichten an eine Lambda-Funktion
• Rule 2 sendet einkommende Messages an CloudWatch Logs

Rules werden dabei durch JSON-Objects repräsentiert, welche einkommende Events auf die benötigten Attribute hin überprüfen. Beispielsweise könnte eine einfache Rule den folgenden Inhalt besitzen:

{
  "source": ["myapp"],
  "detail-type": ["logs"]
}

Alle einkommenden Events, die als Quelle (source) den Inhalt myapp besitzen und im detail-type den Wert logs hinterlegt haben, werden an die mit der Rule verknüpften Empfänger gesendet. Diese Regeln können hierbei beliebig komplex werden und u.a. numerische Vergleiche, Verknüpfungen (and/or) oder das matching von prefixen enthalten.
Ein Überblick über alle Filtermöglichkeiten findet sich in der EventBridge Dokumentation:

• Content filtering in Amazon EventBridge event patterns

Sollte eine Nachricht nicht zugewiesen werden können, versucht EventBridge diese (standardmäßig) 24 Stunden lang dem entsprechenden Empfänger zu übergeben. Diese sog. Retry-Policy kann aber auch basierend auf den Nutzeranforderungen angepasst werden, sodass eine garantierte Zustellung sichergestellt wird.

• Hinweis: Sollten Nachrichten trotz aller Bemühungen nicht erfolgreich zugestellt werden, können diese Events in einer Dead-Letter-Queue (DLQ) für weitere Analysen hinterlegt werden.

Darüber hinaus bietet EventBridge Entwicklern die Möglichkeit, einkommende Nachrichten vorzuverarbeiten, bevor diese an ihren entsprechenden Empfänger geleitet werden. Dies kann über den sog. Input Transformer erreicht werden, bei dem der Inhalt der Nachricht definiert wird, der an das zugehörige Target gesendet wird, sollte die zugehörige Rule zutreffen. So können bspw. überflüssige oder nicht relevante Informationen aus der Nachricht vor der eigentlichen Verarbeitung gelöscht werden.

Beispielarchitektur

In folgender Anwendung wird Amazon EventBridge als intermediärer Dienst zwischen API und den zugehörigen Backend-Diensten genutzt. Eingehende Anfragen kommen auf dem Event Bus in EventBridge an und werden entsprechend der vorliegenden Rules an die zugehörigen Targets weitergeleitet. Wie im eingehenden Beispiel sind auf dem Event Bus zwei Rules hinterlegt, welche passende Nachrichten jeweils an eine Lambda-Funktion zur Verarbeitung bzw. an CloudWatch Logs zur Ausgabe/Analyse weiterleiten. Events, auf die keine Rule zutrifft, werden automatisch verworfen.

Parktische Implementation

Für die Umsetzung und Nutzung von Amazon Eventbridge existieren zahlreiche Tutorials im Internet. Alternativ dazu kann aber auch auf IaC-Lösungen wie CloudFormation oder auf das CDK von AWS zurückgegriffen werden. Allgemein betrachtet, werden die folgenden Ressourcen benötigt:

1. Lambda-Funktion
   Sollte eine Lambda-Funktion als Target genutzt werden, muss diese zunächst erstellt werden, um beim Anlegen der entsprechenden Rule referenzierbar zu sein.
2. EventBridge Bus/Default Event Bus
   Je nach Bedarf kann entweder auf den Default Event Bus von EventBridge zurückgegriffen oder ein eigener Event Bus erstellt werden.
3. EventBridge Rules & Targets
   Anlegen der entsprechenden Rule mit den zugehörigen Targets auf dem passenden Event Bus. Hierbei muss das EventPattern (JSON) definiert werden (Beispiel-Rule siehe oben), auf dessen Basis einkommende Nachrichten überprüft und bei Übereinstimmung an den zugehörigen Empfänger geleitet werden. Im Zuge dessen kann beim Erstellen der Rule, ein Input Transformer definiert werden, damit die zu weiterleitenden Nachrichten den Entwicklerwünschen entsprechend auf den nötigen Inhalt reduziert werden können.
4. IAM Policy & Role
   Es wird eine Rolle mit zugehöriger Policy benötigt, die die Ablage von Events auf dem Default Event Bus bzw. dem selbst erstellten Event Bus erlaubt.
5. HTTP-API
   Die Integration von EventBridge ist sowohl mit einer HTTP- als auch REST-API möglich (Im vorliegenden Beispiel wurde eine HTTP-API genutzt).
   Beim Erstellen der entsprechenden Route wird eine POST-Methode benötigt, über welche anschließend per Service-Integration EventBridge ausgewählt werden kann. Hierbei muss die zuvor erstellte Rolle referenziert werden, um der API die nötigen Berechtigungen zur Ablage der Nachrichten zu übergeben.

Testen der Integration

EventBridge Rules

{
  "source": ["http-api"],
  "detail-type": ["invoke-lambda"]
}

Die erste Rule leitet Nachrichten an die zugehörige Lambda-Funktion zur Verarbeitung weiter.

{
  "source": ["http-api"],
  "detail-type": ["log-message"]
}

Die zweite Rule sendet Nachrichten an eine CloudWatch Log Group zur Ausgabe.

API-Request

Im Folgenden werden via Postman zwei Anfragen an den mit EventBridge verknüpften Endpunkt gesendet.

Anfrage 1:

{
    "Source": "http-api",
    "DetailType": "invoke-lambda",
    "Detail": {
        "message": "Hello, world!"
    }
}

Anfrage 2:

{
    "Source": "http-api",
    "DetailType": "log-message",
    "Detail": {
        "message": "Hello, world!"
    }
}

Ergebnisse

Die erste Anfrage wird entsprechend der zugehörigen Rule nur an die verknüpfte Lambda-Funktion gesendet. Hierbei wurde außerdem ein einfacher Input Transformer definiert, welcher die Nachricht auf eine Teilmenge reduziert. Folgende Ausgabe kann dabei beobachtet werden:

{
    source: 'http-api',
    'detail-type': 'invoke-lambda',
    detail: { message: 'Hello, world!' }
}

Bei der zweiten Anfrage wurde eine CloudWatch Log Group als Target definiert, um eine einfache Ausgabe der über die API gesendeten Anfrage zu ermöglichen:

{   
    "version": "0", 
    "id": "de4642d4-2ff5-8e38-db82-261ed10c8512", 
    "detail-type": "log-message", 
    "source": "http-api", 
    "account": "XXX", 
    "time": "2022-07-07T10:16:31Z", 
    "region": "eu-central-1", 
    "resources": [], 
    "detail": { "message": "Hello, world!" } 
}

Vergleicht man beide Ausgaben, fällt auf, dass sich der Inhalt beider unterscheidet. Dies liegt an dem zuvor erwähnten Input Transformer, welcher für die Rule der Lambda-Funktion definiert worden ist.

Fazit

EventBridge ermöglicht die detaillierte Steuerung der Zustellung von Nachrichten an verschiedene Empfänger einer Applikation.
Hierbei werden Events basierend auf zuvor erstellten Rules überprüft und an die entsprechenden Ziele gesandt. Nachrichten können dabei beliebig granular gefiltert und vor der Zustellung über Input Transformer eine entsprechende Anpassung erhalten, sodass nur notwendige Informationen das zugehörige Target erreichen.
Sollte eine Nachrichtenübergabe nicht erfolgreich sein, kann über die Retry Policy die Anzahl der wiederholten Zustellungen definiert werden. Somit kann der Informationsfluss innerhalb einer Anwendung garantiert, kontrolliert und sichergestellt werden, sodass jede Komponente nur die für sie notwendigen Nachrichten erhält.

Sollten Sie weitere Fragen zu Amazon EventBridge oder zum Entwickeln verteilter Anwendungen haben, stehe ich für Anfragen jederzeit gerne zur Verfügung. Ebenfalls ist Feedback aller Art zu diesem Blog-Post gerne gesehen.