ClearPoint’s SRE Practice Lead – AWS, Terence White, explains how to set up and manage your AWS environment in Slack.
Integrating Slack and Amazon Web Services (AWS)
As a company that has over 200 staff spread across a variety of clients and locations in New Zealand and Australia, ClearPoint, like many others, relies on Slack to maintain a sense of community and keep the conversations flowing amongst our employees. As a messaging app for businesses, Slack can be transformative in the way that organisations communicate.
ClearPoint is an Amazon Web Services (AWS) APN partner with highly skilled engineers who play an important part in New Zealand’s AWS community. We consistently build and run secure scalable solutions on AWS for our clients.
In our experience working with a variety of clients utilising both Slack and AWS, we encourage organisations to employ a way to bring these two together.
AWS Chatbot is an interactive agent that makes it easy to set up a bi-directional connection between an AWS environment and your Slack workspace. Users can receive notifications about operational events, security findings, or budget alerts in a Slack channel where entire operations teams can see and discuss them.
Users can issue AWS Command Line Interface (CLI) commands from Slack to retrieve diagnostic information, invoke AWS Lambda functions, configure Amazon Simple Storage Service (S3) buckets, change Kinesis shards, restart Amazon Elastic Compute Cloud (EC2) instances, and resolve AWS System Manager incidents.
AWS Chatbot enables entire teams to stay updated on, respond to and resolve operational events, security findings, and budget alerts for applications running in the AWS environment without leaving Slack.
Over a series of ‘how to’ blogs, we present a step by step guide and best practices to implement and utilise AWS Chatbot for organisations looking to take advantage of bi-directional connection. In this first part of the series, we will showcase how to set up and connect Slack and AWS Chatbot to show a one-way display of notifications.
How to begin the set-up
Step 1: Initial Link
While most of the set-up utilises Infrastructure as Code (IaC), there is a one-off initial linking of the two services that needs to be done by a Slack workspace owner in the AWS console before switching across to using IaC.
In your Slack workspace go to apps and find the AWS Chatbot app. Approve this app for your organisation.
Step 2: Invite AWS Chatbot to the relevant Slack Channel
Depending on the use case and requirements of your organisation for AWS Chatbot, you should identify the relevant channel and membership for the chatbot activity.
In this example, we are creating a new private Slack channel for our operations team. We have set this channel as private as it may have confidential information about our AWS bills coming through. We want to restrict membership of the channel to the operations team as members of the channel will be enabled to take actions in our AWS account at a later date.
Once the private channel is established, we invite the AWS Chatbot bot to the channel with /invite @AWS. You can also invite other members of your operations team.
Step 3: Enable member permissions and access
The next stage is to log in to the AWS console of your operations team’s AWS account with a user that has sufficient permissions to manage the chatbot. On the chatbot console page select configure a chat client, then choose Slack and then configure client.
You’ll be redirected to Slack’s authorization page to request permission for AWS Chatbot to access your Slack workspace. This will only work if you are a Slack workspace administrator.
Click Allow and the initial manual setup is done.
Creating Simple Notification Service (SNS) topics with IaC
Once the manual setup is in place, we are able to apply a simplified IaC change to connect AWS Chatbot to the new Slack channel. The chatbot can forward notifications received through Simple Notification Service (SNS) topics. We can then create a new SNS topic and link it to our chatbot.
The process outlined is done with chatbot permissions set to “read-only”. In a later blog post, we will explain how operations teams can take actions in AWS from the Slack channel but here, the Chatbot is restricted to a one-way display of notifications only.
The first step to creating an SNS topic is to launch a CloudFormation stack in the operation team’s AWS account using the template 01-aws-chatbot-channel. This CloudFormation template takes a configuration name parameter – put something descriptive about this implementation here to remind you what it is later.
It also takes:
- Slack workspace ID: This can be hard to find in Slack but look at the URL when administering your workspace apps in Slack – it is the string of letters and numbers after the /apps-manage/ part of the URL, alternatively you can look in the AWS Chatbot console after the initial connection.
- Slack channel ID: Right click on the channel in the Slack client, select view channel details and the Channel ID will be at the bottom of the about page.
- Logging level parameter: This defaults to NONE – it can help with troubleshooting a connection issue if messages aren’t coming through on the channel.
If we look at the outputs of the stack, we see the Amazon Resource Name (ARN) of the SNS topic that was created and linked to the chatbot and Slack channel. This will be used later.
When looking at the SNS topic in the AWS Console, we see that the AWS ChatBot has subscribed to it. This was enabled by us setting up the CloudFormation stack above which directed the chatbot to listen to the newly created topic.
This will now enable us to connect the AWS services we want to get notifications from to this topic. AWS Chatbot can show notifications from CloudWatch alarms and the AWS developer services (the Code* tools) natively, but can handle many more AWS services through an AWS EventBridge integration.
Establishing and testing notifications
Let’s set up some test notifications using the supplied CloudFormation template 02-notifications.
- Firstly we’ll put an EventBridge rule in place to notify us every time an EC2 server is started, stopped or terminated.
- Secondly, we’ll create a Virtual Private Cloud (VPC) with some basic networking and an EC2 Linux server.
- Finally, we’ll set up a CloudWatch alarm to trigger an alert when the CPU usage on this server goes over 90% and then we’ll put a load on it.
The template takes two parameters, the ARN of the SNS topic created by the previous CloudFormation stack and the Amazon Machine Image ID of the EC2 server to be created. You are able to accept the default value for the Amazon Machine Image ID.
After a couple of minutes of CloudFormation working away, we will have some messages on our Slack channel from the AWS Chatbot.
The server is up and running!
You may also get an initial notification from CloudWatch showing that the server is not using more than 90% CPU which is not really a surprise as it’s just been created.
The final step to test notifications is to connect to the new server through AWS Systems Manager (SSM) Session Manager and put a load onto it using a Prime95 CPU test available from https://www.mersenne.org/download. This will peg the CPU usage at 100% until we stop it.
After two minutes of high CPU load, the CloudWatch alarm will go into an alert status and a notification will come through on the Slack channel with a helpful CPU graph – the operations team can now see there is an incident with this server and action it.
At this stage, the operations team will need to connect to the AWS Console or use the CLI to investigate further to action. In our next blog in this series, we will showcase how to set up the AWS Chatbot within Slack so the operations can investigate and remediate incidents directly from Slack.
AWS provides a comprehensive portfolio of services that enable you to develop, deploy and scale your software in an innovative compute cloud. ClearPoint can guide your adoption of AWS so you can provide your customers or employees with products that feature greater flexibility, scalability and reliability.
