Übersicht

F: Was ist Amazon EventBridge?

Amazon EventBridge ist ein Service, der Echtzeitzugang zu Datenveränderungen in AWS-Services, Ihren eigenen Anwendungen und Software-as-a-Service (SaaS)-Anwendungen gewährt, ohne dass Sie selbst Code schreiben müssen. Zu Beginn können Sie in der Amazon EventBridge-Konsole eine Ereignisquelle und ein Ziel aus einer Anzahl von AWS-Services auswählen, darunter AWS Lambda, Amazon Simple Notification Service (SNS) und Amazon Kinesis Data Firehose. Amazon EventBridge stellt die Ereignisse dann automatisch und beinahe in Echtzeit bereit.

F: Welche ersten Schritte sind für die Benutzung von Amazon EventBridge notwendig?

Melden Sie sich bei Ihrem AWS-Konto an, navigieren Sie zur Amazon EventBridge-Konsole und wählen Sie aus einer Liste von Partner-SaaS-Anwendungen und AWS-Services eine Ereignisquelle aus. Wenn Sie eine Partneranwendung verwenden, stellen Sie sicher, dass Sie Ihr SaaS-Konto für die Übermittlung von Ereignissen konfiguriert haben und akzeptieren Sie die Anwendung in der Amazon EventBridge-Konsole im Abschnitt zu angebotenen Ereignisquellen. Amazon EventBridge erstellt automatisch einen Event Bus für Sie, an den Ereignisse weitergeleitet werden. Alternativ können Sie AWS SDK nutzen, um Ihre Anwendung für die Übermittlung von Ereignissen an Ihren Event Bus zu konfigurieren. Es besteht die Möglichkeit, eine Filterregel zu konfigurieren und ein Ziel für Ihre Ereignisse anzufügen, dies kann beispielsweise eine Lambda-Funktion sein. Amazon EventBridge nimmt die Ereignisse automatisch auf, filtert sie und sendet sie an das konfigurierte Ziel. Sicherheit und hohe Verfügbarkeit sind dabei gewährleistet.

F: Kann ich meine eigenen Ereignisse in Amazon EventBridge veröffentlichen?

Ja. Sie können benutzerdefinierte Ereignisse auf Anwendungsebene generieren und diese mithilfe der APIs des Services in Amazon EventBridge veröffentlichen. Sie können auch geplante Ereignisse einrichten, die in regelmäßigen Abständen generiert werden, und diese in allen von Amazon EventBridge unterstützten Zielen verarbeiten.

F: Welches Format weisen die Ereignisse auf?

Für Ereignisse wird eine spezifische JSON-Struktur verwendet. Jedes Ereignis verfügt auf oberster Ebene über dieselben Umschlagsfelder, wie Ereignisquelle, Zeitstempel und Region. Darauf folgt ein Detailfeld, welches das Hauptfeld des Ereignisses darstellt. Wird beispielsweise durch eine Amazon Elastic Compute Cloud (EC2)-Auto-Scaling-Gruppe eine neue Amazon-EC2-Instance erstellt, wird ein Ereignis mit der Quelle „aws.autoscaling“ und dem Detailfeld „EC2 instance created successfully“ (EC2-Instance erfolgreich erstellt) übermittelt.

Q: Wie kann ich filtern, welche Ereignisse einem Ziel bereitgestellt werden?

Sie können Ereignisse mithilfe von Regeln filtern. Eine Regel weist eingehende Ereignisse einem bestimmten Event Bus zu und leitet sie zur weiteren Verarbeitung an Ziele weiter. Eine einzige Regel kann an mehrere Ziele weiterleiten, die alle parallel verarbeitet werden. Regeln ermöglichen es verschiedenen Anwendungskomponenten, die Ereignisse zu suchen und zu verarbeiten, die für sie relevant sind. Mithilfe einer Regel kann ein Ereignis benutzerdefiniert angepasst werden, bevor es an das Ziel gesendet wird. Dabei werden nur bestimmte Teile weitergegeben oder es wird mit einer Konstante überschrieben. Für das Beispiel aus der vorherigen Frage kann etwa eine Ereignisregel erstellt werden, die für die Quelle „aws.autoscaling“ und das Detailfeld „EC2 instance created successfully“ (EC2-Instance erfolgreich erstellt) definiert ist. So werden Sie jedes Mal benachrichtigt, wenn eine Auto-Scaling-Gruppe erfolgreich eine Amazon-EC2-Instance erstellt.

F: Wie sichere ich den Zugriff auf Amazon EventBridge?

Amazon EventBridge ist integriert in AWS Identity and Access Management (IAM), sodass Sie angeben können, welche Aktionen ein Benutzer in Ihrem AWS-Konto ausführen kann. Sie können z. B. eine IAM-Richtlinie erstellen, die nur bestimmten Benutzern in Ihrer Organisation erlaubt, Ereignis-Busse zu erstellen oder Ereignisziele anzufügen.

F: In welchen Verhältnis steht Amazon EventBridge zu CloudWatch Events?

Amazon EventBridge basiert auf und erweitert CloudWatch Events. EventBridge nutzt dieselbe Service-API und denselben Endpunkt, sowie dieselbe zugrunde liegende Service-Infrastruktur. Für bestehende CloudWatch Events-Kunden verändert sich nichts: Sie können weiterhin dieselbe API, dieselben CloudFormation-Vorlagen und dieselbe Konsole nutzen. Unseren Kunden zufolge eignet sich CloudWatch Events ideal, um ereignisgesteuerte Architekturen zu erstellen. Daher haben wir neue Funktionen eingebaut, die es unseren Kunden ermöglichen, Daten aus ihren eigenen Apps und aus SaaS-Apps von Drittanbietern zu verbinden. Diese Funktionalität wurde nicht im Rahmen des CloudWatch-Services, sondern unter dem neuen Namen Amazon EventBridge veröffentlicht. So wird die Erweiterung auf Anwendungsfälle jenseits der Überwachung deutlich, für die CloudWatch Events entwickelt wurde.

F: Ich nutze zurzeit Amazon CloudWatch Events und ich möchte die Funktionen von Amazon EventBridge ausprobieren. Muss ich meine Regeln und Berechtigungen für Amazon CloudWatch Events zu Amazon EventBridge verschieben?

Nein. Benutzer von Amazon CloudWatch Events können sowohl über die Konsole und API von Amazon EventBridge als auch über die Konsole und API von Amazon CloudWatch Events auf vorhandene Standard-Busse, Regeln und Ereignisse zugreifen.

F: Ich nutze Amazon CloudWatch Events bereits und benötige die Funktionen von Amazon EventBridge nicht. Was ändert sich für mich?

Nichts. Amazon EventBridge nutzt dieselbe Amazon CloudWatch Events-API, daher bleibt Ihre Nutzung der CloudWatch Events-API in allen Fällen wie bisher.

F: Wird Amazon CloudWatch Events irgendwann eingestellt?

Nein, wir werden weder die API noch den Service selbst überholen. Amazon EventBridge nutzt dieselbe API und verfügt über zusätzliche Funktionen. Der Name Amazon CloudWatch Events wird im Lauf der Zeit durch Amazon EventBridge ersetzt werden.

F: Welche AWS-Services sind als Ereignisquellen für Amazon EventBridge integriert?

Es stehen über 90 AWS-Services als Ereignisquellen für EventBridge zur Verfügung, darunter AWS Lambda, Amazon Kinesis, AWS Fargate und Amazon Simple Storage Service (S3). Eine vollständige Liste der AWS-Service-Integrationen finden Sie in der EventBridge-Dokumentation.

F: Welche AWS-Services sind als Ereignisziele für Amazon EventBridge integriert?

Mehr als 15 AWS-Services sind als Ziele für EventBridge verfügbar, darunter AWS Lambda, Amazon Simple Queue Service (SQS), Amazon SNS, Amazon Kinesis Streams und Amazon Kinesis Data Firehose. Eine vollständige Liste der AWS-Service-Integrationen finden Sie in der EventBridge-Dokumentation.

Q: Was sind EventBridge-Archiv- und Replay-Ereignisse?

Event Replay ist eine neue Funktion für Amazon EventBridge, mit der Kunden vergangene Ereignisse wieder in einen Event Bus oder eine bestimmte EventBridge-Regel umwandeln können. Mit dieser Funktion können Entwickler ihre Anwendungen einfach debuggen und erweitern, indem sie Ziele mit historischen Ereignissen versorgen und Fehler beheben. Event Replay gibt Entwicklern die Gewissheit, dass sie immer Zugriff auf jedes in EventBridge veröffentlichte Ereignis haben.

Q: Was ist EventBridge API Destinations?

Mit API Destinations können Entwickler Ereignisse an viele On-Premises- oder SaaS-Anwendungen zurücksenden, um den Durchsatz und die Authentifizierung zu steuern. Kunden können Regeln mit Input-Transformationen konfigurieren, die das Format des Ereignisses auf das Format des empfangenden Services abbilden, und EventBridge kümmert sich um Sicherheit und Zustellung. Wenn eine Regel ausgelöst wird, transformiert Amazon EventBridge das Ereignis basierend auf den angegebenen Bedingungen und sendet es an den konfigurierten Webservice mit Authentifizierungsinformationen, die beim Einrichten der Regel angegeben wurden. Die Sicherheit ist integriert, so dass Entwickler keine Authentifizierungskomponenten mehr für den Service schreiben müssen, den sie verwenden möchten.

F: Was ist eine „Verbindung“ für API Destination? Wie richte ich API-Ziele ein?

Jedes API-Ziel verwendet eine Verbindung, die die Autorisierungsmethode und die Anmeldeinformationen definiert, die für die Verbindung zum HTTP-Endpunkt verwendet werden sollen. Wenn Sie die Autorisierungs-Einstellungen konfigurieren und eine Verbindung erstellen, wird in AWS Secrets Manager ein Secret erstellt, um die Autorisierungs-Informationen sicher zu speichern. Sie können auch zusätzliche Parameter hinzufügen, die je nach Anwendung in die Verbindung aufgenommen werden sollen.

Um ein API-Ziel einzurichten, müssen Sie einen API-Zielendpunkt angeben – ein HTTP-Aufruf-Endpunktziel für Ereignisse. Sie müssen eine Verbindung erstellen, um eine Autorisierung für diesen Endpunkt durchzuführen. Optional können Sie auch das Aufrufratenlimit definieren – die maximale Anzahl von Aufrufen pro Sekunde, die an den API-Zielendpunkt gesendet werden sollen. Erfahren Sie mehr über Verbindungen und API-Ziele.

Limits und Leistung

F: Was sind die Service Limits?

Die Seite „Service Limits“ finden Sie hier.

F: Welche Latenz kann ich zwischen dem Senden und Empfangen eines Ereignisses erwarten?

Die typische Latenz beträgt etwa eine halbe Sekunde. Dies kann variieren.

F: Unterstützt Amazon EventBridge das Tagging von Ressourcen?

Ja, Sie können Regeln mit Tags versehen. Ereignis-Busse oder Ereignisquellen können nicht mit Tags versehen werden.

F: Welchen Durchsatz kann ich von Amazon EventBridge erwarten?

Die Durchsatz-Limits des Ereignis-Busses finden Sie auf der Seite „Service Limits“ hier. Falls Sie einen höheren Durchsatz benötigen, können Sie im AWS Support Center eine Service-Limit-Erhöhung anfordern, indem Sie zunächst „Create Case“ (Fall erstellen) und anschließend „Service Limit Increase“ (Service-Limit-Erhöhung) auswählen.

F: Besteht für EventBridge ein Service Level Agreement?

Ja. Im Rahmen von AWS nehmen wir wirtschaftlich angemessene Anstrengungen auf uns, damit EventBridge mit einer monatlichen Betriebszeit in Prozent von mindestens 99,99 % in jeder AWS-Region während eines monatlichen Abrechnungszeitraums verfügbar ist. Weitere Informationen finden Sie im vollständigen EventBridge Service Level Agreement.

Schema-Register

F: Was ist ein Schema?

Ein Schema stellt die Struktur eines Ereignisses dar und enthält üblicherweise Informationen wie Titel und Format der einzelnen Daten, die in dem Ereignis enthalten sind. Ein Schema kann beispielsweise Felder wie Name und Telefonnummer sowie den Tatbestand enthalten, dass der Name eine Textfolge ist und die Telefonnummer eine ganze Zahl. Das Schema kann auch Informationen über Muster enthalten, wie z. B. die Anforderung, dass die Telefonnummer 10-stellig sein muss. Das Schema eines Ereignisses ist wichtig, da es zeigt, welche Informationen im Ereignis enthalten sind, und es Ihnen ermöglicht, Code basierend auf diesen Daten zu schreiben.

F: Was ist eine Schema Registry?

In der Schema-Registry wird eine durchsuchbare Sammlung von Schemas gespeichert, sodass jeder Entwickler in Ihrer Organisation leicht auf das von der Anwendung generierte Schema zugreifen kann, ohne die Dokumentation durchsehen oder den Autor des Schemas für diese Informationen finden zu müssen. Sie können ein Schema manuell zur Registry hinzufügen oder diesen Prozess automatisieren, indem Sie die EventBridge-Schema-Erkennung aktivieren.

F: Was ist eine Schema-Erkennung?

Die Schema-Erkennung automatisiert die Prozesse zum Auffinden von Schemas und deren Hinzufügen zu Ihrer Registry. Wenn die Schema-Erkennung für einen EventBridge Event Bus aktiviert ist, wird das Schema jedes an den Event Bus gesendeten Ereignisses automatisch der Registry hinzugefügt. Wenn sich das Schema eines Ereignisses ändert, erstellt die Schema-Erkennung automatisch eine neue Version des Schemas in der Registry. Sobald ein Schema zur Registry hinzugefügt wurde, können Sie eine Codebindung für das Schema generieren, entweder in der EventBridge-Konsole oder direkt in Ihrer IDE, wo Sie das Ereignis als stark typisiertes Objekt in Ihrem Code darstellen und die Vorteile von IDE-Funktionen wie Validierung und Auto-Vervollständigung nutzen können.

F: Kann ich Schemas von Ereignissen entdecken, die über andere Konten übertragen wurden?

Die Schema-Erkennung ist nur für Ereignisse aktiviert, die innerhalb desselben Kontos wie der Entdecker auf den Standard-, benutzerdefinierten und Partner-Ereignis-Busses entstehen.

F: Wie viel kostet die Schema-Registry?

Es entstehen keine Kosten für die Nutzung der Schema-Registry, jedoch fallen Kosten pro aufgenommenem Ereignis an, wenn Sie die Schema-Erkennung aktivieren. Die Schema-Erkennung hat ein kostenloses Kontingent von 5 Mio. aufgenommenen Ereignissen pro Monat, was für den größten Teil der Entwicklungsphase ausreichen sollte. Für die zusätzliche Nutzung außerhalb der kostenlosen Kontingents wird eine Gebühr von 0,10 USD pro einer Million aufgenommener Ereignisse verrechnet. Weitere Informationen zu Preisen finden Sie auf der Seite mit Preisen für EventBridge.

F: Wie hilft mir die Schema-Registry, die Menge an Code, die ich schreiben muss, zu reduzieren?

Erstens können Sie mit der Schema-Erkennung automatisch das Schema für alle an Ihren EventBridge-Ereignis-Bus gesendeten Ereignisse identifizieren und in der Registry speichern, sodass Sie Ihr Ereignisschema nicht manuell verwalten müssen. Zweitens, wenn Sie Anwendungen schreiben, die Ereignisse auf Ihrem Ereignis-Bus verarbeiten, können Sie Codebindungen für dieses Schema generieren und herunterladen, sodass Sie stark typisierte Objekte direkt in Ihrem Code verwenden können. Dies erspart Ihrem Ereignisbehandler Aufwand bei der Deserialisierung, Validierung und Beseitigung von Unsicherheiten.

F: Warum sollte ich eine Schema Registry verwenden?

Mit der Schema Registry bietet Ihnen EventBridge die Möglichkeit, ereignisgesteuerte Anwendungen schneller zu entwickeln, sodass Sie sich auf Ihren Anwendungscode konzentrieren können. Bisher mussten Sie verfügbare Ereignisse und deren Struktur finden und Code schreiben, um Ereignisse zu interpretieren und in ein für Ihren Code verständliches Format zu übersetzen. Mit der Schema Registry können Sie nun automatisch die Ereignisse finden, die in jeder unterstützten Ereignisquelle verfügbar sind, einschließlich AWS-Services, Drittanbieter und benutzerdefinierte Anwendungen, und ihr Schema erkennen.

F: Welche IDEs unterstützen die Schema Registry?

Die Schema Registry ist über das AWS Toolkit for JetBrains (IntelliJ, PyCharm, WebStorm, Rider) und VS Code sowie in der EventBridge-Konsole und den APIs verfügbar. Erfahren Sie mehr über die Verwendung der EventBridge-Schema-Registry innerhalb Ihrer IDE.

F: Kann ich Schema mit dem Serverless Application Model (AWS SAM) verwenden?

Ja, die neueste Version des AWS-SAM-CLI enthält einen interaktiven Modus, mit dem Sie neue serverlose Anwendungen auf EventBridge für jedes Schema als Ereignistyp erstellen können. Wählen Sie einfach die Vorlage „EventBridge Starter App“ und das Schema Ihres Ereignisses aus, und AWS SAM generiert automatisch eine Anwendung mit einer von EventBridge aufgerufenen Lambda-Funktion mit dem Verarbeitungscode des Ereignisses. Das bedeutet, dass Sie einen Ereignisauslöser wie ein normales Objekt in Ihrem Code behandeln und Funktionen wie Validierung und Auto-Vervollständigung in Ihrer IDE verwenden können.

Das AWS Toolkit for JetBrains (Intellij, PyCharm, Webstorm, Rider) und das AWS Toolkit for Visual Studio Code bieten auch Funktionen, um aus dieser Vorlage serverlose Anwendungen mit einem Schema als Auslöser direkt aus diesen IDEs zu generieren.

F: In welchen Sprachen kann ich Code aus meinen Schemas generieren?

Die Code-Generierung ist in Java (8+), Python (3.6+) und TypeScript (3.0+) verfügbar.

F: In welchen AWS-Regionen ist Schema Registry verfügbar?

Das EventBridge-Schema-Registry ist in den folgenden Regionen verfügbar: USA Ost (Ohio und Nord-Virginia), USA West (Oregon und Nordkalifornien), Kanada (Zentral), EU (Stockholm, Paris, Irland, Frankfurt und London), Asien-Pazifik (Mumbai, Tokio, Seoul, Singapur, Hongkong und Sydney) sowie Südamerika (São Paulo).

Globale Endpunkte

F: Was sind globale Endpunkte?

Globale Endpunkte sind eine neue Funktion von Amazon EventBridge, die es Ihnen erleichtert, hochverfügbare ereignisgesteuerte Anwendungen mit AWS zu erstellen. Sie können Ihre Ereignisse über primäre und sekundäre Regionen hinweg replizieren, um ein Failover mit minimalem Datenverlust zu ermöglichen, zusammen mit der Möglichkeit, im Falle von Serviceunterbrechungen automatisch ein Failover auf eine Backup-Region durchzuführen. Dies vereinfacht die Einführung von Architekturen mit mehreren Regionen und ermöglicht es Ihnen, Resilienz in Ihre ereignisgesteuerten Anwendungen zu integrieren.

F: Warum sollte ich globale Endpunkte verwenden?

Globale Endpunkte helfen Ihnen dabei, Ihren Endkunden ein besseres Erlebnis zu bieten, indem sie die Datenmenge minimieren, die bei Serviceunterbrechungen gefährdet ist. Sie können Ihre ereignisgesteuerten Anwendungen robuster und widerstandsfähiger machen, indem Sie die Möglichkeit haben, Ihre Ereignisaufnahme automatisch und ohne manuelle Eingriffe auf eine sekundäre Region umzuschalten. Sie haben die Flexibilität, Failover-Kriterien mithilfe von CloudWatch-Alarmen (über Route53-Zustandsprüfungen) zu konfigurieren, um zu bestimmen, wann ein Failover erfolgen soll und wann Ereignisse an die primäre Region zurückgeleitet werden sollen.

F: Wie verbessert ein globaler Endpunkt die Verfügbarkeit meiner Anwendungen?

Nachdem Sie Ereignisse auf dem globalen Endpunkt veröffentlicht haben, werden die Ereignisse an den Ereignis-Bus in Ihrer primären Region weitergeleitet. Wenn in der primären Region Fehler erkannt werden, wird Ihre Zustandsprüfung als fehlerhaft gekennzeichnet und eingehende Ereignisse werden an die sekundäre Region weitergeleitet. Fehler können mithilfe von CloudWatch-Alarmen (über Route53-Zustandsprüfungen), die Sie angeben, leicht erkannt werden. Sobald das Problem behoben ist, leiten wir neue Ereignisse an die primäre Region zurück und setzen die Verarbeitung der Ereignisse fort.

F: Welche Art von Anwendungen eignen sich gut für globale Endpunkte?

Globale Endpunkte eignen sich gut für Anwendungen, die keine Idempotenz erfordern oder die Idempotenz über Regionen hinweg handhaben können. Sie eignen sich auch gut für Anwendungen, die es tolerieren, dass Ereignisse bis zu 420 Sekunden lang nicht repliziert werden und daher in der primären Region hängen bleiben, bis der Service oder die Region wiederhergestellt ist (als Recovery Point Objective bezeichnet).

F: Welche Metriken sollte ich für das Failover meines globalen Endpunkts verwenden?

Wir haben eine neue Metrik hinzugefügt, die die End-to-End-Latenz von Amazon EventBridge meldet, mit der Sie einfach feststellen können, ob es Fehler bei EventBridge gibt, die ein Failover Ihrer Ereigniserfassung in die sekundäre Region erfordern würden. Wir haben Ihnen den Einstieg in die Konsole erleichtert, indem wir einen vorab ausgefüllten CloudFormation-Stack (den Sie bei Bedarf anpassen können) zum Erstellen eines CloudWatch-Alarms und von Route53-Zustandsprüfungen bereitstellen. Weitere Einzelheiten zum Einrichten der Alarme und Zustandsprüfungen finden Sie in unserem Launch-Blog und unserer Dokumentation.

F: Sollte ich Metriken von meinem Abonnenten verwenden, um einen Failover für meinen globalen Endpunkt durchzuführen?

Wir raten davon ab, Abonnentenmetriken in Ihre Zustandsprüfung aufzunehmen, da dies dazu führen könnte, dass Ihr Herausgeber auf die Backup-Region umschaltet, wenn bei einem einzelnen Abonnenten ein Problem auftritt, obwohl alle anderen Abonnenten in der primären Region fehlerfrei sind. Wenn einer Ihrer Abonnenten Ereignisse in der primären Region nicht verarbeiten kann, sollten Sie die Replikation aktivieren, um sicherzustellen, dass Ihr Abonnent in der sekundären Region Ereignisse erfolgreich verarbeiten kann.

F: Was ist das erwartete Recovery Time Objective (RTO) und Recovery Point Objective (RPO)?

Das Recovery Time Objective (RTO) ist die Zeit, für die die Backup-Region oder das Backup-Ziel nach einem Ausfall mit dem Empfang neuer Ereignisse beginnt. Das Recovery Point Objective (RPO) ist das Maß für die Daten, die während eines Ausfalls unverarbeitet bleiben. Bei globalen Endpunkten betragen RTO und RPO 360 Sekunden (maximal 420), wenn Sie unsere vorgeschriebene Anleitung zur Alarmkonfiguration befolgen. Für RTO umfasst die Zeit den Zeitraum zum Auslösen von CloudWatch-Alarmen und zum Aktualisieren des Status für Route53-Zustandsprüfungen. Für RPO umfasst die Zeit Ereignisse, die nicht in die sekundäre Region repliziert werden und in der primären Region hängen bleiben, bis der Service oder die Region wiederhergestellt ist.

F: Sollte ich die Replikation aktivieren?

Ja. Sie sollten die Replikation aktivieren, um das Risiko für die Daten während einer Serviceunterbrechung zu minimieren. Nachdem Sie Ihre benutzerdefinierten Busse in beiden Regionen eingerichtet und den globalen Endpunkt erstellt haben, können Sie Ihre Anwendungen aktualisieren, um Ihre Ereignisse auf dem globalen Endpunkt zu veröffentlichen. Auf diese Weise werden Ihre eingehenden Ereignisse zurück in die primäre Region repliziert, sobald das Problem behoben ist. Sie können Ihre Ereignisse in der sekundären Region archivieren, um sicherzustellen, dass keines Ihrer Ereignisse während einer Unterbrechung verloren geht. Um nach Unterbrechungen schnell eine Wiederherstellung durchzuführen, können Sie Ihre Architektur in der sekundären Region replizieren, um Ihre Ereignisse weiter zu verarbeiten. Sie müssen die Replikation aktivieren, um eine automatische Wiederherstellung sicherzustellen, nachdem das Problem behoben wurde.

F: Was ist die bewährte Methode für die Verwaltung von Kontingenten in meinen beiden Regionen?

Sie sollten sicherstellen, dass in Ihren primären und sekundären Regionen dieselben Kontingente eingerichtet wurden. Als bewährte Methode sollten Sie die Replikation aktivieren und Ihre Ereignisse in der sekundären Region verarbeiten, da dies nicht nur sicherstellt, dass Sie über die richtigen Kontingente verfügen, sondern auch, dass Ihre Anwendung in der sekundären Region richtig konfiguriert ist.

F: Gibt es eine einfache Möglichkeit, meine Architektur in meiner sekundären Region zu replizieren?

Sie können AWS CloudFormation StackSets verwenden, die es einfach machen, Ihre Architektur über AWS-Regionen hinweg zu replizieren. Ein Beispiel finden Sie in unserer Dokumentation.

F: Kann ich jedes Konto, jede Region und jeden Bus für meine sekundäre Architektur verwenden?

In der ersten Iteration des Launches werden Opt-in-, China- oder GovCloud-Regionen nicht unterstützt. Eine Liste der beim Launch unterstützten Regionen finden Sie unten in Frage 16. Wir unterstützen auch Failover und Wiederherstellung zwischen demselben Konto und Bussen mit demselben Namen in allen Regionen.

F: Funktionieren globale Endpunkte mit AWS-Ereignissen von CloudTrail, S3 und anderen AWS-Services?

Globale Endpunkte sind nur für benutzerdefinierte Ereignisse verfügbar. Wir werden in Zukunft Unterstützung für Ereignisse von AWS-Services, Opt-in-Ereignisse von S3 (Amazon S3-Ereignisbenachrichtigungen) und Ereignisse von Drittanbietern hinzufügen.

F: Unterstützen Sie latenzbasiertes Routing?

Nein, wir unterstützen kein latenzbasiertes Routing in der ersten Iteration des Launches.
Wie viel kosten globale Endpunkte?

Globale Endpunkte sind ohne Aufpreis erhältlich. Aktuell sind globale Endpunkte nur für benutzerdefinierte Ereignisse verfügbar, und benutzerdefinierte Ereignisse, die auf dem globalen Endpunkt veröffentlicht werden, werden gemäß den Preisen für benutzerdefinierte Ereignisse abgerechnet. Um mehr über die Preise zu erfahren, besuchen Sie bitte die EventBridge-Preisseite.

F: Fallen für die Replikation Kosten an?

Ja, Ihnen wird 1 USD pro Million Ereignisse für die Replikation in Rechnung gestellt, die EventBridge für regionsübergreifende Ereignisse berechnet.

F: In welchen Regionen sind globale Endpunkte verfügbar?

Globale Endpunkte sind in den folgenden Regionen verfügbar: USA Ost (Ohio und Nord-Virginia), USA West (Oregon und Nordkalifornien), Kanada (Zentral), EU (Stockholm, Paris, Irland, Frankfurt und London), Asien-Pazifik (Mumbai, Tokio, Seoul, Singapur, Osaka und Sydney) sowie Südamerika (São Paulo).

Kosten und Fakturierung

F: Was kostet EventBridge?

Preise finden Sie hier.

 

F: Werden mir Ereignisse berechnet, die von einem Partner an eine Ereignisquelle gesendet werden, die nicht mit einem Event Bus verbunden ist?

Nein.

Architektur und Design

F: Kann ein Ziel Ereignisse an ein anderes Konto senden?

Ja. Dabei handelt es sich um kontenübergreifende Ereignisse. Das Ziel kann entweder der standardmäßige Event Bus oder ein beliebiger Event Bus in einem anderen Konto sein.

F: Kann ich AWS CloudFormation mit Amazon EventBridge nutzen?

Ja. Support für CloudFormation ist in allen Regionen verfügbar, in denen Amazon EventBridge verfügbar ist. Weitere Informationen über die Verwendung von CloudFormation zur Bereitstellung und Verwaltung von Ressourcen für Amazon EventBridge finden Sie in unserer Dokumentation.

F: Wann sollte ich Amazon EventBridge und wann Amazon SNS nutzen?

Sowohl Amazon EventBridge als auch Amazon SNS können für die Entwicklung von ereignisgesteuerten Anwendungen genutzt werden, Ihre Wahl wird von Ihren spezifischen Anforderungen bestimmt. Die Nutzung von Amazon EventBridge empfiehlt sich, wenn Sie eine Anwendung erstellen möchten, die auf Ereignisse von SaaS-Anwendungen und/oder AWS-Services reagiert. Amazon EventBridge ist der einzige ereignisbasierte Service, der eine direkte Integration mit Drittanbieter-SaaS-Partnern ermöglicht. Amazon EventBridge nimmt zudem automatisch Ereignisse aus mehr als 90 AWS-Services auf, ohne dass Entwickler Ressourcen in ihrem Konto erstellen müssen. Darüber hinaus nutzt Amazon EventBridge eine feste JSON-basierte Struktur für Ereignisse und erlaubt Ihnen die Erstellung von Regeln, die über das gesamte Ereignis hinweg angewendet werden, sodass Ereignisse ausgewählt und an ein Ziel weitergeleitet werden können. Amazon EventBridge unterstützt zurzeit mehr als 15 AWS-Services als Ziele, darunter AWS Lambda, Amazon SQS, Amazon SNS und Amazon Kinesis Streams, Kinsis Data Firehose. Beim Launch hat Amazon EventBridge einen begrenzten Durchsatz (siehe Service Limits), der auf Anfrage erhöht werden kann, und eine typische Latenz von etwa einer halben Sekunde.

Die Nutzung von Amazon SNS empfiehlt sich, wenn Sie eine Anwendung erstellen möchten, die auf von anderen Anwendungen oder Microservices veröffentlichte Nachrichten mit hohem Durchsatz oder geringer Latenz reagieren (da Amazon SNS fast unbegrenzten Durchsatz ermöglicht). Amazon SNS empfiehlt sich auch für Anwendungen, die ein sehr hohes Rundsenden erfordern (Tausende oder Millionen von Endpunkten). Nachrichten sind unstrukturiert und können jedes beliebige Format aufweisen. Amazon SNS unterstützt die Weiterleitung von Nachrichten an sechs verschiedene Zieltypen, darunter AWS Lambda, Amazon SQS, HTTP/S-Endpunkte, SMS, Mobile Push und E-Mail. Die typische Latenz von Amazon SNS beträgt weniger als 30 Millisekunden. Bei einer Vielzahl von AWS-Services werden SNS-Nachrichten versendet, indem der Service dazu konfiguriert wird (mehr als 30, darunter Amazon EC2, Amazon S3 und Amazon RDS).

Integrationen

F: Warum sollte ich meine SaaS-Anwendung mit Amazon EventBridge integrieren?

Amazon EventBridge erleichtert SaaS-Anbietern die Integration Ihres Service in die ereignisgesteuerten, in AWS erstellten Architekturen ihrer Kunden. Amazon EventBridge macht Ihr Produkt Millionen von AWS-Entwicklern direkt zugänglich, wodurch sich neue Anwendungsfälle erschließen. EventBridge bietet eine vollständig überprüfbare, sichere und skalierbare Möglichkeit, Ereignisse zu senden, ohne dass der SaaS-Anbieter die Ereignisverarbeitungs-Infrastruktur verwalten muss.

F: Mein SaaS-Unternehmen würde eine sehr gute Ereignisquelle darstellen. Wie kann ich Partner werden?

SaaS-Anbieter, die Partner von Amazon EventBridge werden möchten, können den Self-Service-Anweisungen auf der Seite Amazon-EventBridge-Integrationen folgen, um mit der Veröffentlichung von Ereignissen in Amazon EventBridge zu beginnen.

F: Wie viel Aufwand stellt die Integration mit Amazon EventBridge für einen SaaS-Anbieter dar?

SaaS-Anbieter, die bereits einen Webhook oder eine andere push-basierte Integrationsart unterstützen, können mit weniger als fünf Tagen Entwicklungszeit für die Integration mit Amazon EventBridge rechnen.

F: Welche SaaS-Integrationen werden unterstützt?

Eine vollständige Liste unterstützter Integrationen finden Sie hier.

Amazon-EventBridge-Integrationen
Erfahren Sie mehr über die Amazon-EventBridge-Integrationen

Rufen Sie die Seite „Amazon EventBridge-Integrationen“ auf.

Weitere Informationen 
Beginnen Sie mit der Entwicklung in der Konsole
Beginnen Sie mit der Entwicklung in der Konsole

Beginnen Sie mit der Entwicklung mit Amazon EventBridge in der AWS-Managementkonsole.

Anmeldung 
Dokumentation lesen
Weitere Informationen finden Sie in der Dokumentation.

Im Entwicklerhandbuch erhalten Sie detailliertere Informationen zu EventBridge.

Weitere Informationen