Set up a ChatOps notifications service within your AWS environment in 5 minutes using EventBridge, Lambda, and Python

AWS EventBridge is Amazon’s serverless event bus that simplifies the process for creating event driven applications at scale. It allows developers to build event driven applications that can scale across AWS, on-premise systems, and SaaS products. This architecture can capitalize on events to trigger communication between decoupled applications and services. An event can represent a range of things within your application e.g. updates, deletes, and changes in state.

After reading this article, you will have the ability to set up a rule within EventBridge that invokes a Lambda you’ve created based on a specific event within your AWS environment.

So what is ChatOps?

You’ve probably heard/seen the term ChatOps at a conference, on StackOverflow or on Reddit. But, what does it actually mean?

This concept was brought to light by GitHub in 2013 when they released/produced Hubot — their open-source chatbot.

ChatOps is a collaborative model that connects people, tools, and processes into a transparent workflow. This flow connects the work needed, the work happening and work done in one central location. This level of transparency tightens the feedback loop, improves information sharing between teams, and ultimately enhances team collaboration. Instead of teams having to access different parts of their applications or infrastructure to view certain details, we can make use of ChatOps to push this information to one centralized location to save time and effort. For example, if a developer creates a pull request in AWS CodeCommit — instead of that developer having to manually message his colleagues to review it. It would be nice to have a mechanism that detects this event (the pull request) and acts on it by sending a message to the relevant people on the pull request.

Ultimately, ChatOps promotes conversation-driven development, from configuring automated scripts and plugins to sharing information regarding security event responses as notifications. This is great because it promotes visibility across the board. ChatOps creates a seamless environment that puts information, functions and businesses processes into one centralized location such as Slack, Discord, Microsoft Teams (🤢), and Telegram.

Typical ChatOps Architecture

Ok, how do I get started?

The overall architecture for this solution is quite simple. It is composed of 3 parts —Lambda, Slack, and EventBridge.

We will create a Lambda function — you can use any of the supported languages for your function e.g. Go, Java, Python, Node and C#. We will then link this function to an event within our AWS environment by creating a rule in EventBridge. This rule will invoke our function whenever the rule is satisfied. For this guide, we will use Slack as the preferred destination for our notifications. Therefore, we will need to configure a few things in Slack.

Slack Configuration

For the purposes of this guide/demo we will be sending data to Slack. Slack provides us with the ability to make use of incoming Webhooks, these Webhooks enable us to post messages from our applications into Slack.

Creating an Incoming Webhook gives you a unique URL to which you send a JSON payload with the message text and some options. You can use all the usual formatting and layout blocks with Incoming Webhooks to make the messages stand out. Set up your Webhook by following this guide on Slack’s official website: Set up your Incoming Webhook.

Once you have set that up, you’ll be sent back to your app settings, and you should now see a new entry under the Webhook URLs for Your Workspace section, with a Webhook URL that’ll look something like this:

https://hooks.slack.com/services/T00000000/B00000000/XXXXXXXXXXXXXXXXXXXXXXXX

This will be the endpoint that we make our POST request to.

Lambda

In this step, we will create a Lambda function. In this article, I won’t cover a specific Lambda for a specific event but I will provide you with a generic Lambda that you can play around with to match your specific requirements.

Create your Lambda Function

If you’re new to AWS you can access the Lambda service by searching “Lambda” in the search bar within the AWS management console. Once you’ve done this, you should create your Lambda function as shown in the image above.

Python Lambda Function

For the purposes of this guide, we will create our Lambda function in Python. Although you can choose to create the Lambda in any of the supported languages e.g. Go, Java, Python, Node, and C#.

The code above simply serializes the JSON from the event into a String. We can anticipate the format of the JSON in the event that’s being passed into the function by reading the AWS documentation. For example, if we’re looking to invoke a Lambda function based on an S3 event, then we can read the S3 docs and view how the JSON payload will look. We can then use this information to store the stuff we need into variables.

If you plan to use this in production or a real work environment, I would highly suggest taking a look at Slack’s Block Kit Builder — it’ll make your messages look more presentable.

The final step simply involves using a post request to send the data to our endpoint.

EventBridge

Great, so now you’ve got your Lambda function sorted. We need to generate a rule within EventBridge. This rule will simply watch for certain events and route this to an AWS target we choose.

In order to achieve this, you need to click the rules button on the left navigation pane within AWS whilst you’re in the EventBridge service.

Create a new rule that invokes a Lambda function when your event is satisfied

After pressing “create rule”, you’ll be presented with a form that allows you to configure your rule. In order to configure the rule, you will need to do the following:

• Provide a name and description
• Define a pattern.
• Select an event bus — you can use the default
• Select a target — the target will be the Lambda function you created

AWS patterns can match events within a range of services within AWS (as shown above)

Conclusion

This short guide highlights how quickly we can set up a serverless application within AWS that can provide value to teams immediately.

Some people might ask why they should use this approach instead of AWS Chatbot. Whilst AWS Chatbot can do the above, it is restricted to Slack and Chime. Whereas the process above can post to any endpoint, whether it be teams, discord, slack, etc. Additionally, we can capture a vast range of events from nearly every service within the AWS Environment via EventBridge.

In the next AWS article, we will look at how we can further improve our solution by utilizing the AWS Serverless Application Model which is an open-source framework for building serverless applications.