Merapar DevOps —Communicating AWS Account spending via Slack

Tom de Brouwer
Jun 26, 2020 · 3 min read

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!


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.


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.

Medium is an open platform where 170 million readers come to find insightful and dynamic thinking. Here, expert and undiscovered voices alike dive into the heart of any topic and bring new ideas to the surface. Learn more

Follow the writers, publications, and topics that matter to you, and you’ll see them on your homepage and in your inbox. Explore

If you have a story to tell, knowledge to share, or a perspective to offer — welcome home. It’s easy and free to post your thinking on any topic. Write on Medium

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store