Migration von Custom Event Bus — Classic zum Custom Event Bus

Custom Event Bus — Classic ist weiterhin verfügbar, und Sie können beide Produkte nebeneinander ausführen. Da der Custom Event Bus den events: IAM-Namespace und den events.amazonaws.com Service Principal beibehält, werden Ihre Identitätsrichtlinien und Bereitstellungsrollen übernommen. Was sich ändert, ist das Routing-Modell.

Benutzerdefinierter Event-Bus — Klassisch	Benutzerdefinierter Event-Bus
Eine Regel und eines ihrer Ziele	Ein Abonnent
Eine Regel mit fünf Zielen	Fünf Teilnehmer im selben Bus
Ereignismuster für eine Regel	Ein Filter mit einem Gültigkeitsbereich vonDATA. Wenn Produzenten mit veröffentlichenPutEvents, bleibt das Muster unverändert.
Eingangstransformator	Ein Transformator mit einer Art JSONATA
Dead-letter Warteschlange auf einem Ziel	OnFailureConfigurationauf dem Abonnenten
Versuchen Sie es erneut mit der Richtlinie für ein Ziel	RetryPolicyauf dem Abonnenten
Archivieren und Wiederholen	Verbleib im Bus und Startposition des Teilnehmers
Regeln, die vom Busbesitzer für jeden Verbraucher festgelegt wurden	Abonnenten, die von den Verbrauchern selbst erstellt wurden
events:PutEvents	events:PutEvents, plus events:PutRawEvents für Nicht-JSON-Payloads

Für vier Funktionen gibt es keinen Custom Event Bus — ein klassisches Äquivalent, sodass ein migriertes Design sie ohne eine Problemumgehung nutzen kann: Beibehaltung auf dem Bus selbst, Startposition eines Abonnenten, Pause und Wiederaufnahme mit einem Backlog und eine zweite Veröffentlichungs-API für Nicht-JSON-Payloads. Sie müssen nicht alles verschieben: Die beiden Busse fahren nebeneinander, eine Custom Event Bus — Classic-Regel kann auf einen Custom Event Bus — Classic abzielen, und ein Abonnent kann auf einen Custom Event Bus — Classic abzielen, sodass Sie jeweils einen Verbraucher oder einen Produzenten verschieben können. Siehe Ziel des Event-Busses: Bus zu Bus.

Was ändert sich nicht

Die folgenden Punkte bleiben unverändert, sodass die entsprechenden Teile Ihrer Bereitstellung unverändert übernommen werden.

Unverändert	Was bedeutet das für den Umzug
IAM-Aktionsnamespace events: und der events.amazonaws.com Dienstprinzipal	Identitätsrichtlinien, Busressourcenrichtlinien und Vertrauensrichtlinien für Bereitstellungsrollen werden wiederverwendet
Zieldienste: Amazon SQS, Lambda, Amazon SNS, Kinesis, Firehose, Step Functions, API-Gateway, API-Ziele, Event-Busse	Für Bereitstellungsrollen gelten dieselben Zielaktionen; jedes Ziel hat einen Parameterblock mit denselben Feldern wie das entsprechende Classic-Gegenstück. Siehe Ziele für einen Custom Event Bus-Abonnenten
Syntax des Ereignismusters, außer Platzhaltern	Regelmuster werden zu DATA Filtern, die für den PutEvents Datenverkehr unverändert bleiben. Siehe Ereignisse für einen Abonnenten filtern
AWS Serviceereignisse und SaaS-Partnerereignisse	Dieselben Ereignisse erreichen einen Custom Event Bus über eine Ereignisquelle. Siehe Ereignisquellen für einen benutzerdefinierten Event-Bus
Die PutEvents API und der Umschlag	Die Produzenten ändern den Endpunkt und den Client, nicht die Anfrage
Eingabetransformation mit JSonata	Ausdrücke werden Transformer mit dem Ereignis unter $events

Standardwerte, die sich unterscheiden

Wichtig

Ein Abonnent wiederholt eine fehlgeschlagene Zustellung 300 Sekunden lang und standardmäßig 5 Versuche. Ein benutzerdefiniertes Event Bus — Classic-Ziel versucht es 24 Stunden lang und 185 Versuche erneut. Wenn Ihre Kunden während eines Ausfalls auf einen Tag mit Wiederholungsversuchen angewiesen sind, stellen Sie RetryPolicy.MaxEventAgeInSeconds den Wert auf 86.400 und 185 pro Abonnent ein und MaxRetryAttempts fügen Sie eine Warteschlange hinzu, in der keine Meldung mehr erfolgt. Andernfalls werden Ereignisse, die länger als 5 Minuten fehlschlagen, nicht verspätet zugestellt. Siehe Richtlinien und Warteschlangen mit unzustellbaren Briefen wiederholen.

Zwei weitere Standardwerte unterscheiden sich. Ein Abonnent übermittelt einen Batch als JSON-Array an eine Funktion oder eine Zustandsmaschine, wobei eine Regel ein Ereignis pro Aufruf auslöst; BatchConfiguration.MaxBatchSize auf 1 gesetzt, um ein Ereignis pro Aufruf beizubehalten. Und ein Bus speichert Ereignisse, sodass ein Abonnent, der nach einem Vorfall erstellt wurde, lesen kann, was er verpasst hat, während bei einer spät erstellten Regel nichts erkannt wurde.

Klassische Ziele ohne ein maßgeschneidertes Äquivalent

Jeder Zieltyp Custom Event Bus — Classic, der kein maßgeschneidertes Ziel im Custom Event Bus hat, wird durch ein universelles Ziel erreicht, das die API-Aktion des Dienstes aufruft. Stellen Sie TargetArn die Anfrage auf ein arn:aws:events:::aws-sdk:service:apiAction und erstellen Sie sie einInput; sieheUniverselle Ziele für einen Custom Event Bus.

Benutzerdefinierter Event-Bus — Klassisches Ziel	Universelles Ziel, Aktion
Amazon-ECS-Aufgabe	arn:aws:events:::aws-sdk:ecs:runTask
AWS Batch-Job	arn:aws:events:::aws-sdk:batch:submitJob
CodeBuild Projekt	arn:aws:events:::aws-sdk:codebuild:startBuild
CodePipeline Pipeline	arn:aws:events:::aws-sdk:codepipeline:startPipelineExecution
Aufrufen von Systems Manager Run Command	arn:aws:events:::aws-sdk:ssm:sendCommand
Systems Manager Automation	arn:aws:events:::aws-sdk:ssm:startAutomationExecution
AWS Arbeitsablauf beim Kleben	arn:aws:events:::aws-sdk:glue:startWorkflowRun
SageMaker Pipeline	arn:aws:events:::aws-sdk:sagemaker:startPipelineExecution
Redshift Data API-Anweisung	arn:aws:events:::aws-sdk:redshiftdata:executeStatement
CloudWatch Logs, Protokollgruppe	arn:aws:events:::aws-sdk:cloudwatchlogs:putLogEvents
Amazon EC2-Aktionen (Stoppen, Neustarten, Beenden, Snapshot erstellen)	arn:aws:events:::aws-sdk:ec2:stopInstances, rebootInstances, terminateInstances, createSnapshot
Bewertung durch den Inspektor	arn:aws:events:::aws-sdk:inspector:startAssessmentRun

Die Dienst- und Aktionsnamen folgen den allgemeinen Target-Benennungsregeln; CreateSubscriber lehnt einen Namen ab, der nicht erkannt wird. Bestätigen Sie daher jeden Namen, wenn Sie den Abonnenten erstellen.

Reihenfolge der Migration

Verschieben Sie einen Bus nach dem anderen in fünf Schritten, wobei die Regeln für Custom Event Bus — Classic bis zum letzten Schritt gelten. Jeder Schritt kann rückgängig gemacht werden, bis Sie die Regeln löschen.

Wichtig

Ein aus einer Regel kopiertes Muster entspricht Ereignissen, die mit veröffentlicht wurdenPutEvents, da diese API den gleichen Envelope wie Custom Event Bus - Classic erzeugt. Das gleiche Muster stimmt nicht mit Ereignissen überein, die mit veröffentlicht wurdenPutRawEvents, da die Nutzlast nicht untergeordnet ist. detail Siehe Eventstruktur: Daten, Metadaten und Systemmetadaten.

1. Erstellen Sie den Custom Event Bus mit der gewünschten Aufbewahrungsdauer und warten Sie, bis sein Status erreicht ist. ACTIVE

2. Erstellen Sie für jede Regel einen Abonnenten für jedes ihrer Ziele. Verwenden Sie das Ereignismuster der Regel als DATA Filter, ihren JSONATA Eingangstransformator als Transformator und ihre Zielrolle alsRoleArn. Fügen Sie eine Warteschlange hinzu, in der keine Nachrichten mehr angezeigt werden, und aktivieren Sie die Protokolle, bevor Sie Traffic senden.

3. Veröffentlichen Sie von Ihren Produzenten für beide Busse und bestätigen Sie bei jedem Ziel, dass beide Pfade dieselben Ereignisse liefern.

4. Verschiebe nur Produzenten auf den Custom Event Bus.

5. Deaktivieren Sie die Regeln auf dem Custom Event Bus — Classic. Löschen Sie sie, nachdem das Wiederholungsfenster und Ihr eigener Bestätigungszeitraum abgelaufen sind.