Launch HN: Infracost (YC W21) – open-source cloud cost estimator
Existing cloud cost management products focus on post-bill analysis and target finance and management teams via charting dashboards. We built one of these back in 2013. They are all missing an important piece - the people who are responsible for purchasing cloud resources are not shown costs upfront, so they don’t know how much the resources will cost before launching them. We want to make cloud costs simpler to understand for developers and DevOps so they can make better decisions, which we believe will lead to more cost-efficient systems.
In 2011 Ali and Hassan started a cloud cost forecasting company based on Ali’s PhD research. They applied to YC and got through to the interview round. RightScale acquired them in 2012. I read about their YC interview experience on HN, reached out and ended up joining them. We went on to form the team that built RightScale’s cloud cost management product (now called Flexera Optima).
In our most recent startup (which failed) we were launching cloud stacks for users on-demand and we wanted a way to work out the cost of each. We hacked together something by building a GraphQL-based cloud pricing API and a CLI that parsed our Terraform code and output a cost breakdown.
We released the code on GitHub as Infracost and discovered that others had similar problems. We got requests to support more cloud services and integrate it into pull requests. At the moment, Infracost supports Terraform for AWS and Google Cloud (we’re adding new resources every week). It can be integrated into GitHub, GitLab, CircleCI, Bitbucket and Atlantis, or can be used anywhere through the CLI. In the future we plan to add support for more cloud vendors and infrastructure-as-code tools (Azure, CloudFormation, Pulumi, etc).
We now spend a lot of our days trawling through the cloud pricing pages working out how pricing works for different cloud services. We’re grateful for the contributors who have helped us with this. AWS currently has over 2 million price points and this is constantly increasing. Users are requesting better support for usage-based services like data transfer, S3 and Lambda. Currently we allow for usage estimates to be passed into the tool, and are looking at other methods, i.e. based on last month’s actual usage. We’ve also learned, the hard way, the importance of UX in CLI and workflow tools.
So far we are seeing a few use-cases for Infracost. Some enterprise users have integrated it into their “self-service” cloud catalog to set cost expectations before provisioning. Other users have integrated it into their CI pipeline as a safety net to catch unexpected costs. And some users are running it at design time to compare options and model usage.
We’ve talked to Sid Sijbrandij (CEO of GitLab), and Ian Tien (CEO of Mattermost) about when and how to monetize. Currently we are thinking about a buyer-based open core approach, in which the individual contributor edition will always be free, and enterprise paid features will include multi-team support, management reports and private cloud support.
We’d really appreciate it if you try it out and give us feedback. You can check out the repo at https://github.com/infracost/infracost. We’d love your thoughts on our approach, and anything that has worked, or hasn’t worked for you when it comes to managing cloud costs.
55 comments
[ 0.33 ms ] story [ 101 ms ] threadhttps://github.com/antonbabenko/terraform-cost-estimation
State files should be considered secret....
[0] https://github.com/antonbabenko/terraform-cost-estimation/bl...
We talked about if we should approach it with user-based pricing, or usage-based pricing. Do you think usage based pricing would be preferred here? Or should we keep it in a way that users can run it as many times as they like?
Our current thinking is buyer-based open core with per user pricing, maybe like SYNK.
you should do a "build minutes" kind of pricing. or the number of times i triggered a re-run.
From your perspective, it can only be better than per-user, since the number of commits will be minimally proportional to the number of users.
Do you have a guide for how this information should be used most effectively? I’m thinking of co-workers who would request a change that reduces the monthly cost by $10 but the time it takes to go through the code review and make the change and test it... by that point any $ cost saving has been spent on the time it spent in code review.
My instinct is that perhaps rather than reporting the $ or % change, instead projects could have alarms / limits on cost increases, but I’m not so sure if that is really tackling the problem.
Another idea we have is to allow developers to set alerts based on their actual project/IaC concepts instead of configuring alerts based on tags and services. Do you think this would help?
https://www.terraform.io/docs/cloud/cost-estimation/index.ht...
We also fit in with existing toolsets - we think it’s important that users don’t need to change their workflow, so we integrate with different ways of running Terraform (Terragrunt, Terraform Cloud) different source control systems (GitHub, GitLab, etc) and CI/CD systems (Atlantis, CircleCI).
We also have additional features, like the ability to specify resource usage (for data transfer and Lambda, etc) and generate HTML and JSON reports so it can be integrated into your own systems.
edit : just adding that this is the suckiest part of my job and I fully expect to be grilled by management for every little cell in the spreadsheet
No. we are using VMC cloud , which I believe is its own offering.
Also, we have a huge infrastructure group that adds a markup and conditions to the published pricing. For example, my line of business pays a different rate for using a Azure VM than the price published by Azure for the VM. Being able to plugin "lob" price as opposed the prices posted by the vendor is very useful to us.
(not tee dee literally .. )
I will delete this post later.
The only thing more complicated than cloud billing at this point is medical billing.
the crowd can plug in their costs (EOBs) they receive along with their insurance information, and an open source engine would crunch the numbers to provide these estimates?
The landing page is gorgeous. Re the service: IDK, on the one side it's amazing, on the other hand, key to significant cost savings is to use Google and AWS only for must-have services, otherwise avoid them as much as possible and deploy the rest on self-managed k8s-clusters on vps farms. Latter might not work for huge deployments like Fortnite's server park but creates a very competitive performance-to-cost-ratio for small to medium deployments.[1] Not sure how this would fit in your design but just my two cents.
Also, once you fully locked-in yourself into a cloud provider real cost-savings get harder and harder. If your tool is just about forecasting for finance and controlling then it's sufficient.
[1] If your business model is so good (like Fortnite's) you shouldn't obsess about cloud costs, going all-in with AWS and Google might be the better choice.
This can happen but already for medium deployments the costs are so much lower that you can hire a bunch of devops managing a proper centralized RBAC-based k8s cluster which isn't over-provisioned nor under-utilized. And even if, it should be still significantly cheaper than anything from Google and AWS. But again, if a company runs a strong-margin business model cloud cost optimizations are the wrong thing to think about. Whatever, your solution is definitely a big step in the right direction.