HN Explorer

Show HN: Infracost (YC W21): Cloud Costs for Terraform in VSCode

76 points by hugorut ↗ HN
Hey, Hugo from Infracost (https://www.infracost.io) here. Infracost shows engineers the cost of each Terraform change in CI/CD before launching resources. When something changes, it posts a comment with the cloud cost impact. e.g. you’ve added two instances and volumes and have changed an instance type from medium to large; this will increase your bill by 25% next month from $1000 to $1250 per month.

Over the last few months, I've been working on a native evaluation for Terraform. Previously we relied on the Terraform CLI to fetch cloud resource information, which was a little slow and cumbersome.

Native parsing is not only lightning-fast, but it means we have contextual file information, which allows us to try a load of cool new things. For example, we could provide real-time suggestions to optimise your cloud costs as you write your infrastructure code! This VSCode extension is the result of a few weeks of hacking away whilst I should have been relaxing in the sun in Italy... time better spent, I think!

We're excited about the possibilities of directly integrating with editors. There is so much we can do to make DevOps lives easier when optimising cloud spend. Right now, we're looking for your feedback on this initial version of the extension. It currently ships with:

1. Show a snapshot of the total cost of resources right above their Terraform definitions. Updated on file save.

2. Resource and module blocks support showing cost estimates, including 3rd party module blocks.

3. A cost overview web-view shows a detailed breakdown of what components affect the price.

Please note this is an early release of the VSCode extension, so there will likely be bugs. If you get stuck, please raise an issue (https://github.com/infracost/vscode-infracost/issues), and we'll help you out asap.

We’d love to get your feedback on this extension, mainly what you think it’s missing and would help your workflow. Head over to the GitHub repo (https://github.com/infracost/vscode-infracost) for more information and installation instructions.

35 comments

[ 7.9 ms ] story [ 98.5 ms ] thread
amarraja
I skim most Show HN posts and think "that's cool", but never look at it again.

Seeing this, I thought that's cool and it's something I really want to start using! Thanks!

hugorut
Oooh, that's really nice to hear! Thank you!
leetrout
Fun fact... HashiCorp actually got a patent around (part of) this https://patents.google.com/patent/US11347559B2/
mustava
Seriously? Does that mean any other provisioning method isn't able to estimate a cost without licensing this? E.g cloudformation?
gwen-shapira
Any plans to also support Pulumi?
[deleted]
(comment deleted)
hugorut
Great question, and it's something we get asked a lot. We have an open PR on our main CLI repo to add Pulumi support (https://github.com/infracost/infracost/pull/1752). This still has some way to go and is currently just using a Pulumi preview file. To get to full editor support, we'd need to be able to read raw Pulumi configuration in all the different languages and flavours it comes in. It's definitely on our radar, but it's not "simple" addition. I'd recommend following our Pulumi issue (https://github.com/infracost/infracost/issues/187) for updates on feature support.
cube2222
Congrats on the release!

One question, do you support, or maybe are planning to support usage-based pricing? Stuff like Lambda invocations.

It's a common use-case and I think it's a tough nut to crack with your architecture, so wondering if you came up with something for that.

gneray
Congrats on this. Love to see what you're doing here!
whoomp12342
does this include azure, GCP and aws pricing?

what happens when the cloud vendor update their pricing strats?

gregwebs
Do you have plans to support Cloudformation (and cdk)?
hugorut
We actually have limited Cloudformation support in the Infracost CLI at this very moment in time. That being said we haven't been actively expanding support for it. We're a small team, and our core focus is on Terraform users and making their experience top-notch. However, we have a very lively community and always welcome contributions. Community members are building the Pulumi integration at the moment.
[deleted]
(comment deleted)
rco8786
Cool tech, though I am personally sad that this is even a problem that needs solving. The fact that there's no price transparency, seemingly by design, in cloud products is :(
akh
When I started looking at cloud pricing in 2009 there were ~10K price points, today there are more than 3M. The cloud vendors focus on moving fast and continually release new services but there is more they could be doing to make it easy for engineers to understand the costs. Infra-as-code added another layer of complexity as now engineers have no idea what we're about to buy on AWS when we run "terraform apply" or similar checkout commands in other tools. All software has a cost, it's just not visible until it's too late - that's what we want to change.
mikkergp
Are you concerned that there's no price transparency or that pricing isn't predictable? If so, I guess I'm curious how you define price transparency, since pricing in the cloud isn't opaque in the same way it is in medicine.
rco8786
A little of both I guess.
lazzurs
Been using this for what seems like a year now as part of our review process using Atlantis (https://www.runatlantis.io) and it has been a welcome addition to have a cost report for every change.

We don’t have strict rules around this but it would be easy to add some policy checking to block any change that is surprisingly expensive.

akh
Awesome! it's always fun hearing how users use Infracost in their workflow
Arbortheus
This is cool, but if you extensively use cloud-native components where the bare metal is abstracted from you (eg: noSQL databases, pubsub, storage buckets, cloud functions, etc) it's very rare you're paying a fixed sum, compared to if you're doing stuff the old school way with a virtual machine assigned 2GB of RAM and 2 CPUs where it's more obvious that you're paying a fixed sum.

I ran the tool on one of my projects' terraform files and it came out with a huuuuge list of infrastructure along with summaries like "Monthly cost depends on usage: $0.026 per GiB". But the grand estinated total cost of this entire project was: $0 per month...

That's the tricky bit, you can't really estimate the cost of this stuff without doing napkin maths on usage. I don't really see how you'd be able to improve this situation, either.

I'm glad someone is trying to bring better transparency to cloud costs. I think this would be a cool thing to add in a terraform CI pipeline. For example: you could allow your devs to be more agile when prototyping by allowing them to change terraform in dev without approval, assuming the MR doesn't add more than $XYZ in costs per month.

rattray
> I don't really see how you'd be able to improve this situation, either

I have to assume they could model some projections based on your current usage, and give you that? Predicting the future is hard, of course, but if their algorithm is simple & basic enough to understand, it'd surely be quite helpful, no?

Arbortheus
Sure, but that only works if you’re modifying an existing piece of infrastructure. If I’m creating a new cloud function they have no idea if it’s getting invoked once per week or once per second.
rattray
Ah, good point! That definitely does sound tricky. Might be cool to see some syntax where you encode your estimates, and it sends an async warning of some kind when the estimates are wildly off?

    resource "aws_lambda" "foo" {
      estimated_invocations = {p5: "1 per hour", p95: "100 per minute"}
      # or
      estimated_invocations = {avg: "5 per minute"}
    }
Then you might get a range estimate of some kind, and maybe even an automated pull request with the real numbers if you're way off?
akh
We need to iterate on the output for usage-based resources, repeating the same "Monthly cost depends on usage" hundreds of times is not great! Maybe summarizing it as "you have 20 Lambda functions, all running on US-east-1, with this pricing" is better?

But you're right that it needs usage data, or models of usage data... For now, the CLI can fetch usage data from the cloud APIs for S3/Lambda/Dynamo and show engineers that functionX was invoked 2M times in the last 30 days: https://www.infracost.io/docs/features/usage_based_resources...

trash_goblin
I've used infracost and kubecost heavily in my last two positions and love it. Great way to let other developers and clients who aren't as familiar with the cloud's nonsense see which items are big spending points and where cost-optimizing makes more sense.