How to use EventBridge to centralize AWS Organizations events
What is EventBridge? See how you can use it to implement cross-account notifications in AWS Organizations and forward centralized event streams to a SaaS tool.
Jun 08, 2023 • 6 Minute Read
Amazon EventBridge is a serverless event routing service that allows us to react to incoming events in real time. In this post, we'll take on a scenario showing how to implement cross-account notifications within AWS Organizations and then leverage EventBridge to forward centralized event streams to a third-party SaaS tool.
Accelerate your career in cloud
What is Amazon EventBridge?
Amazon EventBridge is an evolution of the original CloudWatch Events service offered by AWS. It allows us to utilize a serverless event bus to perform operational tasks based on incoming events within our accounts in real-time.
One of the beautiful things about the service is that we can fully customize the implementation. Previously, when we had to use CloudWatch Events, we could only leverage the default event bus and had very limited options for integrations.
Using Amazon EventBridge, however, allows us to fully customize options and settings from start to finish.
- Your team wants several custom event buses for different use cases? Amazon EventBridge offers that.
- You want to configure multiple rules that allow for parallel processing of events on a single event bus? Amazon EventBridge offers that, too.
- Oh, you also want to be able to send events between AWS accounts and regions?! Amazon EventBridge. 😉
Third-party SaaS vendors
Amazon EventBridge offers us numerous default integrations, which, at the time of this publishing totals 34 verified partners. Pretty impressive!
These supported integrations allow us to easily connect our event buses with our chosen SaaS vendor — places like DataDog, PagerDuty, and MongoDB, just to name a few.
We perform our own custom actions based on the data sent to and from Amazon EventBridge when working with these supported platforms.
A perfect example would be PagerDuty. We can easily monitor for specific event patterns within our accounts, and when one matches, leverage a rule that uses a connection to PagerDuty so that our operational teams can receive alerts and take the appropriate remediation actions or steps.
AWS Default Services
How many AWS services can we natively use with EventBridge, you ask? Well, to put it simply, a lot!
Here is a detailed list of currently supported AWS services that can generate default service events that are easily used with EventBridge: Events from AWS Services
As you can see, there are numerous services for us to use!
Let’s take this example architecture for a scenario:
We have a simple internal application hosted on EC2 compute, which runs on custom software that is stored and updated within a private S3 bucket.
Earlier, before implementing EventBridge, whenever we wanted to update the software, it would take hours of the operations team’s time.
Now, using EventBridge, it allows us to speed up the process from several hours down to mere minutes. By leveraging S3
PutObject API calls from the specific private buckets that host our custom software, we can create EventBridge rules on our event bus with pattern matching in place. Once the
PutObject event is generated, we utilize the EventBridge rule that watches for that specific event (PutObject) on that specific resource (S3 bucket).
Using the rule we created, we can then set a target of a custom Systems Manager Automation Document that uses the
RunCommand capability to execute software updates on targeted EC2 instances EventBrige allows us to fully automate tedious tasks that overwise would take lots of time to complete.
EventBridge allows us to implement a completely serverless solution for automating our custom software updates! 🚀
One of the amazing features that EventBridge offers, which we touched on earlier, is the ability to leverage the service using a cross-account and cross-region design. Because of this powerful feature, we can utilize EventBridge to help us take actions based on events that occur within any account within our AWS Organization.
Take for example, the following diagram:
By putting a resource policy in place on the SecOps Event Bus in the security account, the SecOps team can easily allow all accounts within the organization (or specific Organizational Units) to send events to the centralized event bus. They can then put a pattern match in place via a rule on the event bus that looks for specific events generated from within the organizational accounts that need to be reviewed and potentially addressed.
For this example above, we have a junior engineer who maliciously or accidentally deletes an Amazon Elastic Container Registry image from their development account. SecOps doesn’t want any junior engineers to be able to purge images; instead, they only want senior engineers to do so.
To identify issues like this, they share their Event Bus to the organization, create a resource policy allowing the organization to send events cross-account and cross-region, and then implement a rule on every child AWS account’s default event bus.
This default rule would be a pattern match for the DELETE action-type field in the incoming ECR events. Once it matches, it would send this event to the SecOps account event bus, which they can then handle however they see fit.
In this example, they simply use SNS to send an alert to their SecOps engineer team. However, we could integrate with a SaaS like PagerDuty to handle alerts and notifications as well.
Learn more about Amazon EventBridge
If you are ready to learn more about the Amazon EventBridge service an all the amazing features it offers, be sure to check out the Introduction to Amazon EventBridge course.
In this course, we'll walk through the fundamentals of the service itself and get a solid understanding of how it works. Building off the fundamentals, we'll then dive into some more intermediate topics at a deeper level. We'll talk about things like event sources, event rules, and targets or API destinations. There will even be a portion that shows where and how we can implement the cross-account resource-based policy that allows us to leverage cross-account and cross-region EventBridge architecture.