Migrating EventBridge archives

If your infrastructure utilizes EventBridge and its archive feature, you may easily encounter situations where modifications to your event bus are necessary. This could involve creating a new archive or event bus and subsequently transferring events from the old archive to the new one as there is no way to attach an existing archive to a new event bus, so creating a new event bus requires creating a new archive for it.

However, performing this migration is not straightforward. Even AWS currently lacks documentation on the process. Replaying events to a different event bus and archiving them through that bus is currently not possible. Initially, our instinct was to create a second event bus with an archive and then forward events from the old archive using a rule and the replay feature of the archives.

So after replaying the events, much to our surprise, we discovered that the events did not end up in the new archive as expected. This unexpected outcome prompted us to delve deeper into the situation, checking to uncover any potential issues or anomalies that might be causing this discrepancy.

Our first instinct was to check for any potential permission issues, but after confirming that it was not the case, we decided to try forwarding the events into a SQS queue and then comparing the number of events to the original archive, after the replay finished.

To our surprise the number of events in the queue matched the events in the archive so we were able to pin down the issue to the new event bus and the new archive.

After further digging, we found that when an archive is attached to an event bus, a managed rule is added to it, which checks whether a field called "replay-name" exists in the payload of the event and thanks to this we were able to find a snippet in the documentation explaining this functionality.

"The event pattern excludes events containing a replay-name attribute, which prevents replayed events from being archived multiple times." [1]

Thanks to this, now we knew that this managed rule, which also existed in the new archive was preventing the events from being put into the new archive and we had to look for an alternate solution.

The solution to the problem was solved with 25 lines of code packed into a Lambda and then modifying our infrastructure, to first forward the events from the old archive replay to our Lambda function, which then essentially stripped the "replay-name" field from the event payload and then used the PutEvents API call to forward it to the new event bus, where thanks to the lack of the "replay-name" field, it was able to successfully save it in our brand new archive. An alternative solution to this issue could have been using EventBridge Pipes and doing the event payload transformation there and finally piping the events to the new event bus.

Finally, the Lambda Python code itself:

Thank you for joining me in this exciting journey of archive migrations, I hope that this blog post was able to help you better understand the deep intricacies of AWS EventBridge and its archives. Happy migrating!