Merapar DevOps —Communicating AWS Account spending via Slack

In a series of blog posts we will focus on some of the best practices we use within Merapar to evolve our DevOps practices we have built around the AWS platform. Why? Because we think it’s fun to share knowledge and to learn from others in the industry!

Situation

In this blog post we focus on how we increase our (developers) cost awareness of the ongoing spend we have in our development AWS accounts.

It might be a stigma, but we developers are lazy by nature and not very interested in accounts and budgets. Actually this is something which Merapar promotes, don’t do repetitive tasks yourself but automate them wherever possible. We don’t look that often at the AWS spend we have in the multiple AWS accounts, and sometimes we overspend because we forget to delete a (set of) resource(s) which will cost the company unnecessary money.

To have this information pushed, we have created an automated service which sends a weekly spending report to a shared slack channel. Developers and budget owners are members of this channel to ensure complete visibility across the organisation and creating a culture where necessary action can be taken on a regular basis.

This is not a replacement for setting budget alarms in the AWS Budgets service, but rather provides additional insight in the spending in a frictionless way, even when the forecast budget is not reached.

Solution

Naturally we choose to run this service as a weekly task using AWS Lambda. In our AWS organisation where we use consolidated billing we don’t want to run this AWS Lambda in the root account. To comply with the best practices we have an AWS account for “internal services”. We run the AWS Lambda in this account and provide access to the billing information via cross account access.

The high level solution is depicted on the following diagram:

Deployment overview

In the AWS Lambda, which is triggered by a CloudWatch event, we execute the following functionality:

• Configure the AWS javascript SDK to assume a role to the root account when requesting information.
• Setup a client to retrieve the AWS accounts in the AWS organisation.
• Get a list of all accounts (we need this later to map account IDs to account names).
• Setup a client to the AWS cost explorer.
• Ask the AWS cost explorer for all costs (while we exclude refunds, so we have the actual costs).
• Sort the accounts depending on the costs made, and log the result to slack. With the list of accounts we can map account IDs to account names to make the result easy to understand.

The following gist shows the code, this code accepts the following environment variables to configure :

• BILLING_ACCOUNT_ROLE : The role to assume to get right to AWS Organisation and AWS Costs Explorer in the root account
• SLACK_TOKEN : Token used to authenticate on slack
• SLACK_CHANNEL : The channel to post the messages to

Note that you only need a single service per AWS organisation, if you managed multiple AWS organisations you must deploy the service for each.