Part 2: Cloud cost estimates in pull requests

  • August 19, 2020
  • 2 min read

Development teams use pull requests as a key part of their workflow. Pull requests are used for all sorts of things such as linting and running tests before merging to avoid breaking changes. GitHub Actions offer an easy way to make pull requests do more, and the GitHub Marketplace has thousands of actions that can be plugged into a workflow quickly and easily. The great thing about tools that integrate into pull requests is that, usually, it only takes one person from a team to add it and everyone benefits from it as part of their workflow automatically.

Pull requests are often used by teams to review and discuss changes too. The increasing popularity of infrastructure-as-code tools such as Terraform and Pulumi mean that deployments can also be driven from pull requests. This enables developers, DevOps/SREs, architects and managers to discuss specific issues that the code-change under review might have with respect to security, performance and cost.

We’ve seen many organizations use showback and chargeback reports from cloud providers and third party vendors to help teams be responsible for their cloud costs and optimize them. The reason that these cloud cost management tools are needed in the first place is that cloud pricing is complicated; for example, AWS has hundreds of services, and hundreds of thousands of prices across these services. Whilst existing cloud cost management tools serve a purpose, most of them offer an “after the fact” view of of the changes, thus they do not help with decisions that need to be made during development. For example, as a developer, I want to quickly know how much it would cost if I change an EBS volume’s IOPs from 100 to 200. I know I can calculate this using information from AWS’ website, but if I’m changing multiple things as part of my pull request, that can take longer than I’d like. Furthermore, it would be great if I could discuss the cost change with the rest of the team and my manager to see what they think; just like I can do with other changes in pull requests.

This is why we created the infracost GitHub Action that:

  1. checks if any Terraform files (.tf) have changed as part of the pull request, if so it runs infracost on the master branch and the pull request.
  2. compares the monthly cost estimate of the master branch and the pull request.
  3. posts a comment on the pull request if there is a change. Optionally a percentage_threshold can be set; for example, only post a comment if the cost estimate changed by +/-5%.
  4. show a git diff of the infracost output. This shows a detailed breakdown of the changes that contributed to the monthly cost estimate change.

infracost GitHub Action Screenshot

We hope development teams find this useful as it’s easy to setup and provides better visibility of the cost estimates from infrastructure-as-code changes. Try it and let us know how it goes on Twitter or GitHub issues.