8 ms·

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

76 points by hugorut 4y ago

Hey, Hugo from Infracost (https://www.infracost.io 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 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 https://github.com/infracost/vscode-infracost) for more information and installation instructions.

gregwebs 4y ago
Do you have plans to support Cloudformation (and cdk)?
- hugorut 4y ago
  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 4y ago
  [deleted]
leetrout 4y ago
Fun fact... HashiCorp actually got a patent around (part of) this https://patents.google.com/patent/US11347559B2/ https://patents.google.com/patent/US11347559B2/
- debarshri 4y ago
  Terraform cloud does have a cost estimation feature [1]. You might have to upgrade your plan to access it. [1] https://www.terraform.io/cloud-docs/cost-estimation https://www.terraform.io/cloud-docs/cost-estimation
  - akh 4y ago
    In case you're wondering: https://www.infracost.io/docs/faq/#whats-the-difference-between-infracost-and-terraform-clouds-cost-estimation https://www.infracost.io/docs/faq/#whats-the-difference-betw...
- mustava 4y ago
  Seriously? Does that mean any other provisioning method isn't able to estimate a cost without licensing this? E.g cloudformation?
  - myroon5 4y ago
    Although there's not much coverage, CloudFormation had prior art for a decade before this patent: https://github.com/aws-cloudformation/cloudformation-coverage-roadmap/issues/217 https://github.com/aws-cloudformation/cloudformation-coverag... Can't find a blog detailing exactly when it launched, but here's a file from an AWS SDK in 2011 with it: https://github.com/aws/aws-sdk-java/blob/2b08c776c16fc1c8f5891e93b715ee90a81c287a/src/main/java/com/amazonaws/services/cloudformation/model/EstimateTemplateCostRequest.java https://github.com/aws/aws-sdk-java/blob/2b08c776c16fc1c8f58...
amarraja 4y ago
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 4y ago
  Oooh, that's really nice to hear! Thank you!
timcavel 4y ago
gwen-shapira 4y ago
Any plans to also support Pulumi?
- deleted 4y ago
  [deleted]
- hugorut 4y ago
  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 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 https://github.com/infracost/infracost/issues/187) for updates on feature support.
cube2222 4y ago
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.
- akh 4y ago
  Great question! See https://www.infracost.io/docs/features/usage_based_resources/ https://www.infracost.io/docs/features/usage_based_resources... as the CLI can pull usage data for Lambda/S3/Dynamo from the AWS APIs (e.g. CloudWatch). The other data source we can tap into is the actual billing data, e.g. AWS Cloud and Usage Reports - if you have any thoughts/preferences, checkout https://github.com/infracost/infracost/discussions/985#discussioncomment-2602739 https://github.com/infracost/infracost/discussions/985#discu...
gneray 4y ago
Congrats on this. Love to see what you're doing here!
- hugorut 4y ago
  Thanks!
whoomp12342 4y ago
does this include azure, GCP and aws pricing? what happens when the cloud vendor update their pricing strats?
- hugorut 4y ago
  Hey, yes we support azure, GCP and AWS. We continually keep up to date with vendors' pricing. You can check out our aggregate cloud pricing graphql API for more info (https://github.com/infracost/cloud-pricing-api/ https://github.com/infracost/cloud-pricing-api/)
rco8786 4y ago
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 4y ago
  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 4y ago
  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 4y ago
    A little of both I guess.
lazzurs 4y ago
Been using this for what seems like a year now as part of our review process using Atlantis (https://www.runatlantis.io 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 4y ago
  Awesome! it's always fun hearing how users use Infracost in their workflow
Arbortheus 4y ago
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 4y ago
  > 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 4y ago
    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 4y ago
      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?
trash_goblin 4y ago
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.

76 points by hugorut 4y ago

gregwebs 4y ago

Do you have plans to support Cloudformation (and cdk)?

hugorut 4y ago
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 4y ago
[deleted]

leetrout 4y ago

Fun fact... HashiCorp actually got a patent around (part of) this https://patents.google.com/patent/US11347559B2/ https://patents.google.com/patent/US11347559B2/

debarshri 4y ago
Terraform cloud does have a cost estimation feature [1]. You might have to upgrade your plan to access it. [1] https://www.terraform.io/cloud-docs/cost-estimation https://www.terraform.io/cloud-docs/cost-estimation
- akh 4y ago
  In case you're wondering: https://www.infracost.io/docs/faq/#whats-the-difference-between-infracost-and-terraform-clouds-cost-estimation https://www.infracost.io/docs/faq/#whats-the-difference-betw...
mustava 4y ago
Seriously? Does that mean any other provisioning method isn't able to estimate a cost without licensing this? E.g cloudformation?
- myroon5 4y ago
  Although there's not much coverage, CloudFormation had prior art for a decade before this patent: https://github.com/aws-cloudformation/cloudformation-coverage-roadmap/issues/217 https://github.com/aws-cloudformation/cloudformation-coverag... Can't find a blog detailing exactly when it launched, but here's a file from an AWS SDK in 2011 with it: https://github.com/aws/aws-sdk-java/blob/2b08c776c16fc1c8f5891e93b715ee90a81c287a/src/main/java/com/amazonaws/services/cloudformation/model/EstimateTemplateCostRequest.java https://github.com/aws/aws-sdk-java/blob/2b08c776c16fc1c8f58...

amarraja 4y ago

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 4y ago
Oooh, that's really nice to hear! Thank you!

timcavel 4y ago

gwen-shapira 4y ago

Any plans to also support Pulumi?

deleted 4y ago
[deleted]
hugorut 4y ago
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 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 https://github.com/infracost/infracost/issues/187) for updates on feature support.

cube2222 4y ago

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.

akh 4y ago
Great question! See https://www.infracost.io/docs/features/usage_based_resources/ https://www.infracost.io/docs/features/usage_based_resources... as the CLI can pull usage data for Lambda/S3/Dynamo from the AWS APIs (e.g. CloudWatch). The other data source we can tap into is the actual billing data, e.g. AWS Cloud and Usage Reports - if you have any thoughts/preferences, checkout https://github.com/infracost/infracost/discussions/985#discussioncomment-2602739 https://github.com/infracost/infracost/discussions/985#discu...

gneray 4y ago

Congrats on this. Love to see what you're doing here!

hugorut 4y ago
Thanks!

whoomp12342 4y ago

does this include azure, GCP and aws pricing? what happens when the cloud vendor update their pricing strats?

hugorut 4y ago
Hey, yes we support azure, GCP and AWS. We continually keep up to date with vendors' pricing. You can check out our aggregate cloud pricing graphql API for more info (https://github.com/infracost/cloud-pricing-api/ https://github.com/infracost/cloud-pricing-api/)

rco8786 4y ago

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 4y ago
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 4y ago
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 4y ago
  A little of both I guess.

lazzurs 4y ago

Been using this for what seems like a year now as part of our review process using Atlantis (https://www.runatlantis.io 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 4y ago
Awesome! it's always fun hearing how users use Infracost in their workflow

Arbortheus 4y ago

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 4y ago
> 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 4y ago
  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 4y ago
    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?

trash_goblin 4y ago

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.