We launched the first version of Infracost just under a year ago (https://news.ycombinator.com/item?id=26064588). As we said in our first release ‘the people who are purchasing cloud resources are not shown costs upfront, so they don’t know how much the resources will cost before launching them’. Our assumption was that because we are open source and engineers are flying blind, they (the engineers) would pull us into their workflow. Actually, something different is happening:

The engineers are not pulling us in - it turns out to be the senior DevOps, SREs and platform teams. One of their challenges is figuring out how their small team of 7 people can fulfill the infrastructure requirements of hundreds of engineers. To solve this, they have created and put in place processes for engineers to provision infrastructure when they need. Now they want to implement cost policies and guardrails so that these hundreds of engineers don’t blow past all budgets. For example, if a change will result in a higher than 15% increase, leave a warning. If a change results in a >25% increase in costs, block the change till a team lead has reviewed it.

This has two implications for us. First, we need to create an output that isn’t only used by humans but is also digested into other systems to make further decisions. The second is the people we have been speaking to are not our end users. We need to figure out how we can get introduced to our end users, and create a different set of questions for each persona.

We’d really love your feedback around the cost policies use-case. We've created examples with standard policy tools like Open Policy Agent (OPA), HashiCorp Sentinel and Conftest. Check out the repo for GitHub Actions at https://github.com/infracost/infracost. Our other CI/CD integrations are listed here: https://www.infracost.io/docs/#4-add-to-cicd.

We'd love to hear how you think about policies and guardrails for containing cloud costs!