Amazon EventBridge

Now, these are the key features. First of all, this is built on top of CloudWatch events, as it was formerly called the Amazon CloudWatch events. It uses the same API endpoints and underlying architecture as that of the CloudWatch events. It uses the same API so that’s why it is the extension form of CloudWatch events that makes it easy to consume external events, also. It is directly integrated with over 100 event sources and even 15 targets that are already built-in including Amazon Lambda, Amazon SQS, SNS, and many more. It provides architectures that are secure because it is integrated with IAM (identity and access management). You can control which users and resources have permission to access the data. The most important feature of the service is that it can build services or architectures that are loosely coupled and the event-driven application. This is one of the most important in the service. The event target doesn’t need to be aware of the event sources. This decoupling allows teams to work independently, which leads to event development that is faster, and it improves the agility of the team. The next feature is message filtering. You can filter events with these rules. A rule matches incoming events for a given event bus and routes them to the target for processing. You don’t have to pay anything upfront here. You will pay for what you use.

Let’s proceed to the core components that make up this EventBridge service. First, is the event. The event is anything. It is like a change that happens in service. For example, in S3, if our object is uploaded in an S3 bucket, or if in EC2, an instance gets terminated then it is a change in that service. Then that will be called an event. Even worse, it is kind of a pipeline that receives the events. For rules, a rule is nothing but a kind of instruction and it matches incoming events and sends the targets to those events. Sources are like the services that send the event over the Event Bus. It could be an AWS service or your own application or could be a sales application. Targets are resources or endpoints that send an event to. It could be like DataDog or any AWS service that receives these events. About schema registry, the schema is the structure of events and schema registry are the containers that contain these schemas.

Let’s understand how this service actually works. You have a bunch of event sources, which could be any AWS service, your custom application, or any sales application. In sales applications, you can have third-party integrations like Shopify or DataDog or you can use Zendesk, also. When an event is created here, like an AWS service if an EC2 instance gets terminated in a custom application, the event could be like you receive an order or a new user is registered in your application. That will be the event. In the sales application, that event could be like in Zendesk if a new ticket is created, or you can see a status change for our ticket that will be also the event. Now, when these events are created, they will reach the event bus through the event sources. And when this event is received, what actually will even reach here is it actually does a schema discovery, because basically, it goes to a schema registry here. At the schema registry, it will say “Hi I have received this event” whatever happens in that service like an object has been uploaded to the S3 bucket or an event is created in EC2 like object instances created or it can be terminated. It will say yes, it wants to receive this event and will be registered in the particular schema. After that, it will look for the rule. In the rule, it will check if it matches it, like the pattern we defined in the rule. If the event matches this rule, it will accept this event and will be registered in the schema registry. Now for all AWS services, the schema will be registered in the schema registry by default. You can also have code binding here, where you can download the code bindings for any schema in the registry. One more thing, if you’re using the search application, you will need to create your own schemas. For the custom applications, you need to create your custom schemas and need to add them to the schema registry.

Now let’s proceed with the demo. In the demo, we will use the service to filter the events. We will match the event for a particular event with the pattern that we defined in the rule that we created while using event tracing. We also involve the Lambda function, when a specific event will create. In S3, we will use object uploading in the S3 bucket.

This is the default event. Every AWS account has a default path that is called the default event bus. We just will use this. In the rule, we will create a rule for ourselves. Let it be Demo111 or you can say any name here. There are two options to create the rule. If you want to just schedule a run, like if you want to run a Lambda function every 30 minutes, you can use this. For cron functionality, you can select this option and just add up deals here. If you want to execute that Lambda function every 30 minutes or 10 minutes, anything you can take and you will proceed to the next. Lambda will be involved every 30 minutes and it will match and this rule will be inserted.

For this demo, we will be using the first option as we need to match the pattern for the S3 object creation event. We will go to the next option as S3 is the AWS service so we will select the first service and here we will select S3. If you want to use this rule for any event created, then we can use all events but we want to execute it only if the object is uploaded in the S3 buckets. We will select this option, Amazon S3 event notification, and here we will specify that event. An object created we have selected and we can select a specific bucket here. We already have a bucket. We have defined a specific bucket here. In target, you can take a CloudWatch log group here and if you select this log group and name here anything the log group will be created with this name only and a role has been created. Now this will be in a running state once we upload an object in this S3 bucket. The object has been uploaded now, we can check the log group here. A log group has been created and we can see the event that the object has been uploaded in that specific bucket. We are seeing this event here only because it matches the event pattern. We have created this rule with this pattern, it is matching with this pattern that’s why we are able to win this event. If we deleted this bucket or this object then there will be no object here.

Now, we want to involve the Lambda function in the implementation of this event. When the S3 bucket will have the new object then the Lambda function should be involved. For that, what we will do is we will change our target. As we have selected the CloudWatch log group here, we will have a Lambda function here. For this, we need to first create the Lambda function actually. Let’s name it. We can keep it as Node.js. We will do a bit of modification so we can have the event here. The Lambda function has been selected as a target. This Lambda should be triggered when we upload an object in the S3 bucket that was defined in the pattern. Here let’s upload another object. The upload is successful. To verify, we can go to Lambda and check its logs. Here is the log stream that is created after uploading the object. Again, it is for the object creation and for the same bucket that was defined in the pattern. We have confirmed that the Lambda function has been involved only after this event occurred.

One more thing that I want to show is here. We can also send notifications to SNS topics. For that, we don’t need to change this target, we will keep the Lambda function. What we need to do is first create an SNS topic. It will be a standard one and give it a similar name again. We can add a subscription. We will subscribe from our email. Now what we will do is we will add this as a destination in our Lambda. Here we need to add the destination but before that, we need to add permissions for the SNS in the rule that was already added as a default. This is the rule that was by default added to the Lambda function. We will go to a similar role rather than create the new one and we will attach the policy for SNS access. Here are the permissions. What we will do is attach a policy for SNS. Now it should be able to access the SNS topic. So let’s get back to the destinations. As we want to send the notification when the Lambda function is successful, we have to select this option. Here we have selected SNS topics. Now, what we need to do again is just go to the S3, and upload an object here. We have received the notification that this event has occurred. Using EventBridge, we can filter events of our choice, and this is its benefit over the SNS. There, we cannot define the content of the event that we certainly want, but here we can define the EventBridge in the rule, so whatever type of events we want to have, we can define them.