Häufig gestellte Fragen zu Amazon EventBridge

EventBridge verfügt über Standardkontingente für die Geschwindigkeit, mit der Sie Ereignisse veröffentlichen können, die Anzahl der Regeln, die auf einem Event Bus erstellt werden können, und die Rate, mit der Ziele aufgerufen werden können. Auf der Seite mit den Service Quotas finden Sie eine vollständige Liste der Kontingente und wie sie erhöht werden können.

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

Ja, Sie können Regeln und Event Busse markieren.

Die standardmäßigen EventBridge-Kontingente können erhöht werden, um Hunderttausende von Ereignissen pro Sekunde zu verarbeiten. Die Durchsatz-Limits des Event Busses finden Sie auf der Seite von AWS Service Quotas. 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 „Fall erstellen“ und anschließend „Service-Limit-Erhöhung“ auswählen.

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.

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 hilft Ihnen, Code basierend auf diesen Daten zu schreiben.

Ein Schema-Register speichert eine durchsuchbare Sammlung von Schemas, so dass jeder Entwickler in Ihrem Unternehmen leichter auf die von der Anwendung generierten Schemas zugreifen kann. Im Gegensatz dazu müssen Sie für diese Informationen nicht in der Dokumentation nachsehen oder den Autor des Schemas suchen. Sie können ein Schema manuell zur Registry hinzufügen oder diesen Prozess automatisieren, indem Sie das Feature zur EventBridge-Schema-Erkennung aktivieren.

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 zum Register hinzugefügt wurde, können Sie eine Codebindung für das Schema entweder in der EventBridge-Konsole oder direkt in Ihrer integrierten Entwicklungsumgebung (IDE) erstellen. Dies hilft Ihnen, das Ereignis als stark typisiertes Objekt in Ihrem Code darzustellen. Sie können dann die Vorteile von IDE-Features wie Validierung und Autovervollständigung nutzen.

Ja, in der Schemaerkennung können Sie Ereignisse für mehrere Konten ermitteln, sodass Sie einen vollständigen Überblick über das in Ihren Event Bussen veröffentlichte Schema der Ereignisse haben.

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 den Preisen zu EventBridge.

Die Schema Registry reduziert die Menge an Code, indem sie Ihnen Folgendes ermöglicht:

• Schemas automatisch für alle an Ihren EventBridge-Event-Bus gesendeten Ereignisse identifizieren und in der Registry speichern, sodass Sie Ihr Ereignisschema nicht manuell verwalten müssen.
• Anwendungen schreiben, die Ereignisse auf Ihrem Bus verarbeiten und Codebindungen für das Schema generieren und herunterladen, um stark typisierte Objekte direkt in Ihrem Code zu verwenden.

Codebindungen reduzieren den Aufwand für die Deseralisierung, Validierung und das Rätselraten für Ihren Ereignis-Handler.

Sie sollten Schema Registry verwenden, um ereignisgesteuerte Anwendungen schneller zu erstellen. Die Schema Registry macht den Zeitaufwand für die Koordination zwischen den Entwicklungsteams überflüssig, da die verfügbaren Ereignisse automatisch aus allen unterstützten Ereignisquellen, einschließlich AWS-Services, Drittanbieteranwendungen und benutzerdefinierten Anwendungen, ermittelt und deren Schema erkannt werden. Es wurde entwickelt, um es Entwicklern zu ermöglichen, sich ausschließlich auf ihren Anwendungscode zu konzentrieren, anstatt wertvolle Zeit damit zu verschwenden, nach verfügbaren Ereignissen und deren Struktur zu suchen und Code zur Interpretation und Übersetzung von Ereignissen zu schreiben.

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

Ja, die neueste Version der AWS-SAM-CLI enthält einen interaktiven Modus, mit dem Sie neue Serverless-Anwendungen auf EventBridge für jedes Schema als Ereignistyp erstellen können.

Wählen Sie die Vorlage EventBridge Starter App und das Schema Ihres Ereignisses aus, und 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 Features wie Validierung und Auto-Vervollständigung in Ihrer IDE verwenden können.

Das AWS Toolkit für JetBrains (IntelliJ IDEA, PyCharm, Webstorm, Rider) und das AWS Toolkit für Visual Studio Code bieten auch Funktionen, um aus dieser Vorlage Serverless-Anwendungen mit einem Schema als Auslöser direkt aus diesen IDEs zu generieren.

EventBridge bietet Codegenerierung in Java (8+), Python (3.6+) und TypeScript (3.0+) sowie Go (1+).

Die EventBridge-Schema-Registry ist in den folgenden Regionen verfügbar:

• USA Ost (Ohio und Nord-Virginia)
• USA West (Nordkalifornien und Oregon)
• Asien-Pazifik (Hongkong, Mumbai, Seoul, Singapur, Sydney und Tokio)
• Kanada (Zentral)
• Europa (Frankfurt, Irland, London, Paris und Stockholm)
• Südamerika (São Paulo)

EventBridge Pipes bietet eine einfachere, konsistente und kosteneffiziente Möglichkeit, Punkt-zu-Punkt-Integrationen zwischen Event-Produzenten und -Konsumenten zu erstellen. Die Erstellung einer Pipe ist so einfach wie die Auswahl einer Quelle und eines Ziels. Sie haben die Möglichkeit, die Stapelverarbeitung, die Startposition, die Gleichzeitigkeit und vieles mehr anzupassen. Ein optionaler Filterschritt ermöglicht, dass nur bestimmte Quellereignisse in die Pipe fließen, und ein optionaler Anreicherungsschritt mit AWS Lambda, AWS Step Functions, API Destinations oder Amazon API Gateway kann verwendet werden, um Ereignisse anzureichern oder umzuwandeln, bevor sie das Ziel erreichen. EventBridge Pipes macht es überflüssig, undifferenzierten Integrationscode zu schreiben, zu verwalten und zu skalieren, so dass Sie Ihre Zeit damit verbringen können, Anwendungen aufzubauen, anstatt sie zu verbinden.

Sie können damit beginnen, indem Sie die EventBridge-Konsole aufrufen, die Registerkarte Pipes auswählen und Pipe erstellen wählen. Von dort aus können Sie aus einer Liste verfügbarer Quellen wählen und ein optionales Filtermuster angeben, das verwendet wird, um nur die von Ihnen gewünschten Ereignisse zu übertragen. Für den optionalen Transformations- und Anreicherungsschritt einer Pipe können Sie einen API-Endpunkt bereitstellen, z. B. eine SaaS-Anwendungs-API oder einen Container-Cluster, eine Lambda-Funktion oder eine AWS Step Function. Die Pipe wird dann die API-Anfrage stellen und die Antwort erfassen, sobald die Verarbeitung abgeschlossen ist. Legen Sie schließlich einen Ziel-Service fest, an den die Ereignisse geliefert werden, und geben Sie an, ob die Archivierungs- oder DLQ-Funktionen in der Pipe aktiviert sein sollen. Sie können eine Pipe auch mit der AWS CLI, CloudFormation oder dem AWS Cloud Development Kit (CDK) erstellen.

EventBridge Pipes führt Amazon SQS, Amazon Kinesis, Amazon DynamoDB, Amazon Managed Streaming Kafka, selbstverwaltetes Kafka und Amazon MQ als Quellen in die EventBridge Produktsuite ein. EventBridge Pipes unterstützt die gleichen Zielservices wie Event-Busse, wie Amazon SQS, AWS Step Functions, Amazon Kinesis Data Streams, Amazon Kinesis Data Firehose, Amazon SNS, Amazon ECS und Event-Busse selbst.

EventBridge Pipes unterstützen grundlegende Transformationen mit der Velocity Template Language (VTL). Für leistungsfähigere Transformationen hilft Ihnen EventBridge Pipes, eine Lambda-Funktion oder einen Step Functions-Workflow anzugeben, um Ihr Ereignis zu transformieren. Wenn Sie lieber einen Containerservice wie Amazon Elastic Container Service (ECS) oder Amazon Elastic Kubernetes Service (EKS) verwenden möchten, können Sie den API-Endpunkt und das Authentifizierungsschema für Ihren Container-Cluster angeben. EventBridge kümmert sich dann um die Bereitstellung des Ereignisses für die Transformation.

Nein, EventBridge Pipes können unabhängig von den bestehenden EventBridge-Features verwendet werden und helfen Ihnen, Ereignisse von anderen Ereignisproduzenten wie Kinesis, SQS oder Amazon MSK zu empfangen, ohne dass Sie einen EventBridge-Event-Bus verwenden müssen. Er wird auch für Punkt-zu-Punkt-Integrationen verwendet, während ein Event Bus für Many-to-Many-Integrationen eingesetzt wird. Wenn Sie bereits einen EventBridge-Event-Bus verwenden, um Ereignisse weiterzuleiten, können Sie EventBridge Pipes verwenden, um eine Verbindung zu einer unterstützten Quelle herzustellen und Ihren Event Bus als Quelle einer Pipe festzulegen.

EventBridge-Event-Buses eignen sich gut für das Many-to-Many-Routing von Ereignissen zwischen ereignisgesteuerten Services. EventBridge Pipes ist für Punkt-zu-Punkt-Integrationen zwischen Event-Publishern und -Verbrauchern gedacht, mit Unterstützung für erweiterte Transformationen und Anreicherungen. EventBridge Pipes können einen EventBridge-Event-Bus als Ziel verwenden. Die Migration von einer EventBridge-Event-Bus-Regel zu einer Pipe ist einfacher, da die Filterung und die Ziele zwischen den beiden Ressourcen gleich bleiben.

Das Event Source Mapping (ESM) von AWS Lambda und Amazon EventBridge Pipes verwenden die gleiche Polling-Infrastruktur, um Ereignisse auszuwählen und zu senden. ESM ist ideal für Kunden, die Lambda als Ziel verwenden möchten, um die empfangenen Ereignisse zu verarbeiten. Pipes ist ideal für Kunden, die sich nicht um die Erstellung, Wartung und Skalierung von Lambda-Code kümmern möchten und stattdessen eine einfache, verwaltete Ressource bevorzugen, um ihre Quelle mit einem von über 14 Zielen zu verbinden.

Ja, EventBridge Pipes behält die Reihenfolge der von einer Ereignisquelle empfangenen Ereignisse bei, wenn diese Ereignisse an einen Ziel-Service gesendet werden.

Ja, für Services, die Batching-Ereignisse unterstützen, können Sie bei der Erstellung einer Pipe die gewünschte Batch-Größe konfigurieren. Bei Quellen und Zielen, die keine Batching unterstützen, können Sie dennoch Ereignisse für Ihren Anreicherungs- und Transformationsschritt stapeln. Auf diese Weise sparen Sie Rechenkosten und können dennoch Ereignisse individuell an das von Ihnen gewählte Ziel liefern.

Zum Abrufen eines Verlaufs aller EventBridge-Pipes-API-Aufrufe, die für Ihr Konto erfolgt sind, müssen Sie CloudTrail in der AWS-Managementkonsole aktivieren.

Die vollständigen Preisdetails für Amazon EventBridge Pipes finden Sie auf der Seite mit den Preisen.

Amazon EventBridge Scheduler ist ein Serverless-Aufgabenplaner, der das Erstellen und die Ausführung und Verwaltung von Millionen von Zeitplänen über AWS-Services hinweg vereinfacht, ohne dabei die zugrunde liegende Infrastruktur bereitstellen oder verwalten zu müssen.

Melden Sie sich bei Ihrem AWS-Konto an, navigieren Sie zur EventBridge-Konsole und wählen Sie dann die Schaltfläche Zeitplan erstellen aus. Befolgen Sie den schrittweisen Anleitungen und füllen Sie die erforderlichen Felder aus. Wählen Sie ein Zeitplan-Format mit einem Zeitfenster für die Implementierung der Aufgabe, eine bestimmte Häufigkeit, ein Cron oder eine bestimmte Datums- und Uhrzeitangabe. Wählen Sie das Ziel aus einer Liste von AWS-Services und konfigurieren Sie Wiederholungs-Richtlinien für die maximale Kontrolle über die Implementierung Ihres Zeitplans. Überprüfen Sie Ihren Zeitplan und wählen Sie Erstellen aus.

EventBridge Scheduler baut auf den Planungsfunktionen von Geplante Regeln auf. EventBridge Scheduler bietet Unterstützung für Zeitzonen, erhöhte Skalierbarkeit, angepasste Zielnutzlasten, zusätzliche Zeitausdrücke und ein Dashboard zur Überwachung von Zeitplänen. Zeitpläne können unabhängig von einander erstellt werden, ohne einen Event Bus mit einer geplanten Regel erstellen zu müssen.

Geplante Regeln werden weiterhin verfügbar sein, jedoch bietet EventBridge Scheduler einen umfassenderen Satz an Features und mehr Flexibilität bei der Erstellung, Ausführung und Verwaltung Ihrer Zeitpläne. Die ersten Schritte kostenlos. Weitere Informationen finden Sie auf der Seite mit den Preisen.

EventBridge Scheduler verfügt über tiefgreifende Integrationen mit AWS-Services und kann Zeitpläne für jeden Service mit einer AWS-API-Aktion erstellen. Konfigurationen für Zeitmuster und Wiederholungen sind in AWS einheitlich, um ein konsistentes Erlebnis bei der Planung zu gewährleisten. Die Überwachung von Zeitplänen ist einfacher über die EventBridge Scheduler-Konsole, die eine Übersicht über Ihre Zeitpläne in einem Dashboard oder mit einer „ListSchedule“-API-Anfrage liefert. Sie können wichtige Informationen zu Ihren Zeitplänen einsehen, z. B. die Startzeit, den letzten Lauf und das zugewiesene AWS-Ziel. Für genauere Details können Sie die in CloudWatch Logs verfügbaren Ausführungsprotokolle einsehen oder sie an S3 oder Kinesis Firehose senden.

Sie können Ihre Zeitpläne in der EventBridge-Scheduler-Konsole aktualisieren, indem Sie den Zeitplan auswählen, den Sie anpassen möchten. Ein neues Feld zeigt Ihre Optionen an.

Ja, mit EventBridge Scheduler können Sie auswählen, in welcher Zeitzone ein Zeitplan ausgeführt wird. Diese Zeitpläne passen sich automatisch an die Sommerzeit und zurück an die Standardzeit an.

EventBridge Scheduler bietet „at-least-once“-Ereignislieferung an Ziele, was bedeutet, dass mindestens eine Lieferung erfolgreich mit einer Rückmeldung des Ziels abschließt. Optionen zur Einstellung von Wiederholungen, Zeitfenster und Timeouts sind verfügbar, um Ihren geschäftlichen Anforderungen gerecht zu werden.

Löschen nach Abschluss ist für alle derzeit unterstützten Planungsmuster verfügbar: Cron-, Raten- und Einmalpläne.

Ja, Sie können Ihren Zeitplan jederzeit aktualisieren, um das Löschen nach Abschluss zu konfigurieren, bevor der Zeitplan aufgerufen wird. Nach dem letzten Zeitplanaufruf können Sie keine Änderungen mehr vornehmen.

Wenn Sie einen Zeitplan mit „Nach Abschluss löschen“ vor dem letzten Aufruf des Zeitplans deaktivieren, verbleibt der Zeitplan in Ihrem Konto in einem deaktivierten Zustand.

Der Zeitplan ruft weiterhin sein Ziel auf und wird erst automatisch gelöscht, wenn ein Enddatum konfiguriert wurde.

EventBridge Scheduler bietet keine direkte Unterstützung für nicht-AWS-Ziele. Sie können jedoch nicht-AWS-Ziele mit Lambda, ECS und Fargate aufrufen, oder mit dem Feature EventBridge über die API-Ziele.

Die vollständigen Preisdetails für Amazon EventBridge Scheduler finden Sie auf der Seite mit den Preisen.

Globale Endpunkte vereinfachen die Erstellung hochverfügbarer ereignisgesteuerter Anwendungen mit AWS. Sie können Ihre Ereignisse zwischen primären und sekundären Regionen replizieren, um ein Failover mit minimalem Datenverlust zu realisieren. Sie können auch die Fähigkeit implementieren, im Falle von Serviceunterbrechungen automatisch auf eine Backup-Region umzuschalten. Dies vereinfacht die Einführung von Architekturen mit mehreren Regionen und hilft Ihnen, Resilienz in Ihre ereignisgesteuerten Anwendungen zu integrieren.

Globale Endpunkte helfen 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 Amazon-CloudWatch-Alarmen (durch Amazon-Route-53-Zustandsprüfungen) zu konfigurieren, um zu bestimmen, wann ein Failover erfolgen soll und wann Ereignisse an die primäre Region zurückgeleitet werden sollen.

Nachdem Sie Ereignisse im 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 (durch Route53-Zustandsprüfungen), die Sie angeben, leichter erkannt werden. Wenn das Problem behoben ist, leiten wir neue Ereignisse an die primäre Region zurück und setzen die Verarbeitung der Ereignisse fort.

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 tolerieren, dass Ereignisse bis zu 420 Sekunden lang nicht repliziert werden. Sie würden also in der primären Region festsitzen, bis der Service oder die Region wiederhergestellt ist (das so genannte Recovery Point Objective).

Wir haben eine neue Metrik hinzugefügt, die die gesamte Latenz von EventBridge meldet, mit der Sie einfacher feststellen können, ob es Fehler bei EventBridge gibt, die ein Failover Ihrer Ereigniserfassung in die sekundäre Region erfordert.

Die Konsole erleichtert Ihnen den Einstieg, indem sie einen vorgefertigten CloudFormation-Stack (den Sie nach Belieben anpassen können) für die Erstellung eines CloudWatch-Alarms und von Route 53-Zustandsprüfungen bereitstellt. Weitere Einzelheiten zum Einrichten der Alarme und Zustandsprüfungen finden Sie in unserem Launch-Blog und unserer Dokumentation.

Wir raten davon ab, die Metriken der Abonnenten in Ihren Zustandsprüfung aufzunehmen. Dies könnte dazu führen, 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 zu überprüfen, ob Ihr Abonnent in der sekundären Region Ereignisse erfolgreich verarbeiten kann.

Das Recovery Time Objective (RTO) ist die Zeit, in der 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 Initiieren 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.

Ja. Aktivieren Sie die Replikation, 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 zu überprüfen, ob 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 zu überprüfen, nachdem das Problem behoben wurde.

Sie sollten überprüfen, ob in Ihren primären und sekundären Regionen dieselben Kontingente eingerichtet wurden. Sie sollten die Replikation aktivieren und Ihre Ereignisse in der sekundären Region verarbeiten, da dies nicht nur überprüft, ob Sie über die richtigen Kontingente verfügen, sondern auch, ob Ihre Anwendung in der sekundären Region richtig konfiguriert ist.

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

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

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

Nein, wir unterstützen kein latenzbasiertes Routing in der ersten Iteration des Launches.

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

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

Globale Endpunkte sind in den folgenden Regionen verfügbar:

• USA Ost (Ohio und Nord-Virginia)
• USA West (Nordkalifornien und Oregon)
• Asien-Pazifik (Mumbai, Osaka, Seoul, Singapur, Sydney und Tokio)
• Kanada (Zentral)
• Europa (Frankfurt, Irland, London, Paris und Stockholm)
• Südamerika (São Paulo)

Amazon EventBridge bietet mit seiner nutzungsbasiertem Zahlungsmodell flexible Preise. Sie zahlen nur für Ereignisse, die von Ihrem Event Bus veröffentlicht wurden, sowie für Ereignisse, die für Schema Discovery, Event Replay und API Destinations erfasst wurden. Beispiele und weitere Preisdetails für EventBridge finden Sie auf unserer Seite mit den Preisen.

Nein.

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. Dies kann verwendet werden, um Ereignisse von mehreren Konten in einem einzigen Event Bus zu zentralisieren, um Ihre Ereignisse einfacher zu überwachen und zu prüfen und die Daten zwischen den Konten zu synchronisieren.

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 EventBridge finden Sie in unserer Dokumentation.

Sowohl EventBridge als auch SNS können für die Entwicklung von ereignisgesteuerten Anwendungen genutzt werden. Ihre Wahl wird von Ihren spezifischen Anforderungen bestimmt.

Amazon EventBridge empfiehlt sich, wenn Sie eine Anwendung erstellen möchten, die auf Ereignisse von Ihren eigenen Anwendungen, SaaS-Anwendungen und AWS-Services reagiert. EventBridge ist der einzige ereignisbasierte Service, der eine direkte Integration mit Drittanbieter-SaaS-Partnern ermöglicht. EventBridge nimmt zudem automatisch Ereignisse aus mehr als 200 AWS-Services auf, ohne dass Entwickler Ressourcen in ihrem Konto erstellen müssen.

EventBridge verwendet eine definierte JSON-basierte Struktur für Ereignisse und hilft Ihnen bei der Erstellung von Regeln, die über das gesamte Ereignis hinweg angewendet werden, sodass Ereignisse ausgewählt und an ein Ziel weitergeleitet werden können. EventBridge unterstützt derzeit über 20 AWS-Services als Ziele, darunter Lambda, SQS, SNS und Amazon Kinesis Data Streams sowie Data Firehose.

Amazon SNS wird für Anwendungen empfohlen, die einen hohen Fanout benötigen (Tausende oder Millionen von Endpunkten). Ein häufiges Muster, das wir beobachten, ist, dass Kunden SNS als Ziel für ihre Regel verwenden, um die Ereignisse zu filtern, die sie benötigen, und sich auf mehrere Endpunkte auszubreiten.

Nachrichten sind unstrukturiert und können jedes beliebige Format aufweisen. SNS unterstützt die Weiterleitung von Nachrichten an sechs verschiedene Zieltypen, darunter Lambda, SQS, HTTP/S-Endpunkte, SMS, Mobile Push und E-Mail. Die typische Latenz von 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, einschließlich Amazon EC2, Amazon S3 und Amazon RDS).

AWS AppFabric, ein Service ohne Code, der die vorhandenen Investitionen von Unternehmen in Software as a Service (SaaS)-Anwendungen durch verbesserte Sicherheit, Verwaltung und Produktivität erweitert. Verwenden Sie AppFabric, um SaaS-Protokolldaten von Anwendungen wie Asana, Slack und Zoom sowie von Produktivitätssuites wie Microsoft 365 und Google Workspace zu aggregieren und zu normalisieren. Dadurch erhöhen Sie die Beobachtbarkeit von Anwendungen und senken die Betriebskosten, die mit der Entwicklung und Wartung von Punkt-zu-Punkt-Integrationen verbunden sind. EventBridge ist ein Serverless-Integrationsservice, der Ereignisse verwendet, um Anwendungskomponenten miteinander zu verbinden. Auf diese Weise können Entwickler problemlos skalierbare, ereignisgesteuerte Anwendungen erstellen. Verwenden Sie EventBridge, um Ereignisse aus Quellen wie benutzerdefinierten Anwendungen, AWS-Services und SaaS-Anwendungen von Drittanbietern an Verbraucheranwendungen im gesamten Unternehmen weiterzuleiten. EventBridge bietet eine einfache und konsistente Möglichkeit, Ereignisse zu erfassen, zu filtern, zu transformieren und bereitzustellen.

Amazon EventBridge erleichtert SaaS-Anbietern die Integration Ihres Service in die ereignisgesteuerten, in AWS entwickelten Architekturen ihrer Kunden.

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 Ereignis-Infrastruktur verwalten muss.

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

SaaS-Anbieter, die bereits einen Webhook oder andere Push-basierte Integrationsmodi unterstützen, benötigen möglicherweise weniger als fünf Tage für die Integration mit EventBridge.

Wir unterstützen über 45 SaaS-Integrationen. Eine vollständige Liste der unterstützten SaaS-Integrationen für Amazon EventBridge finden Sie hier.