akh

Thanks - indeed, it's also difficult to estimate how much the agents will cost in advance, and how much changes could reduce or increase costs.

yep, the ROI for cloud and AI spend tools is fairly easy to measure: it has to save multiples of what it costs.

We prevent way more than that from being added to the cloud bill by showing engineers cost estimates that enables them to make better decisions pre-deploy - e.g. when an engineer knows the IOPS option on their EC2 instance is costing them a lot, they're more likely to reduce that or not use that in dev envs vs just copy/paste what's on production. There's an ROI report on infracost.io that shows how we measure the cost prevention between the first and last commit on merged PRs.

CI/CD pipelines needs 1 CLI run per commit (like any other code scanning tool), we regularly see enterprises with 100K+ runs/month.

OpenRouter is great for keeping your LLM API bill down, Infracost is about the AWS/Azure/GCP bill your IaC creates. When an agent writes IaC that creates a NAT gateway or an RDS instance, that's $50-5000/mo in cloud spend, so the agent knowing that estimate and the best practices as it's generating the code can optimize it pre-deploy.

co-founder of Infracost here, we launched Infracost on HN five years ago, when the CLI just generated cost estimates for Terraform. Earlier this year we were scoping a 1.0 release: the CLI would stop being just a cost-estimation tool and start surfacing the issues behind the costs: previous-generation instances, policy violations, the kinds of issues a thorough PR review would catch.

Then agent traffic started showing up, and it became clear the 1.0 scope was the right idea aimed at the wrong caller. A human reviewer reads a PR comment; an agent runs `infracost inspect --filter` ... and gets the same insight as a tabular row it can pipe into the next step. So we decided to skip our planned 1.0 release and go for 2.0, where we treated agents as a first-class citizen user of the CLI.

Along the way we picked up some interesting lessons on optimizing user token usage when designing a CLI, and we want to share them with the HN community since other CLI builders might benefit.

and the vast majority of times you don't need those 2 recommendations in non-prod envs... Infracost only makes recommendations if they reduce your costs, not increase them.

We started out with the Infracost CLI showing engineers cost estimates in the terminal before they deployed their code. The learning was that it also makes sense to check for other things like tagging policy issues and best practices not being followed as these things are more actionable than showing engineers a cost estimate. The cost estimate is actually more useful to trigger notifications on, e.g. if an engineer is adding $10K worth of databases, let the engineering management or FinOps teams know so they're not surprised by the spike in the bill and can adjust budgets if needed.

Thanks! Yep, we're partners with HashiCorp and worked on that integration early on :)

I suppose the difference between flaky tests and typos in tags/missing tags is that the latter is less about flaky-ness, and more about the engineer deciding not to fix the tagging issue and merging anyway. In Terraform, tags are fairly easy to fix and don't require the resource to be recreated so it feels like it should be a quicker fix then fixing/refactoring tests.

I think the easier we make it for engineers to fix tagging issues, the more likely it'll be for engineers to take action. Send me an email asking me to read the company's wiki page on tagging policy and I'll delete the email; tell me I have a typo on line 8 as soon as I open my pull request, I'll fix it and move on.

Interesting idea! The pull request authors are shown out of the box but we hadn't thought of using git to find the user for each resource on the main branch. Most organizations end-up tagging the resources with some sort of owner or team so they can group the costs using that and track it per team/service/product over time. That's often how FinOps teams start to create a sense of ownership for cloud costs amongst teams.

Great point - indeed FinOps teams consistently rank "empowering engineers to take action" as their number 1 challenge (https://data.finops.org) - and by that they mean the human and organization dynamics of the culture change they want to create across the org.

The testing analogy is a good one as this feature also shows the engineers the current "failing policies" on the main branch too, so whilst they could merge the pull request without fixing the tagging issue, it'll just get added to the list. And maybe like tests, they group them into one task and go through to fix them all every so often to get the main branch back to green!

I'm co-founder of Infracost, happy to chat more about how we can make it great :) feel free to join the community chat if you want to DM me: https://www.infracost.io/community-chat

Great examples - thanks!

Very cool idea! Some created a prototype with Terragrunt (https://github.com/infracost/infracost/issues/463#issuecomme...). With Infracost parsing HCL directly, we might be able to introduce annotations for estimates -> alerts

Not yet but users are asking for it, feel free to add a list of the resources you think would be useful to here: https://github.com/infracost/infracost/discussions/985#discu...

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...

Awesome! it's always fun hearing how users use Infracost in their workflow

In case you're wondering: https://www.infracost.io/docs/faq/#whats-the-difference-betw...

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.

Great question! See 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#discu...

I wrote a blog about how stars helped us at the very early stages of our open source product: https://www.infracost.io/blog/github-stars-matter-here-is-wh...

Thanks!

We couldn't wait either so we talked with other TFE users who were using Infracost and we learned from them to make an example of how to run it with GitHub Actions: https://github.com/infracost/actions/tree/master/examples/te...

We have similar examples for GitLab (https://gitlab.com/infracost/infracost-gitlab-ci/-/tree/mast...) and Azure DevOps (https://github.com/infracost/infracost-azure-devops/tree/mas...).

Happy to help with any issues via infracost.io/community-chat

Thanks!

1. I suspect there might be the need for migration calculators but for smaller bills, the cost of the actual migration might be more than the cloud bill savings. For larger bills, it'll depend on the discounts and custom prices the vendors are offering them.

2. If I remember correctly, AWS Cost Explorer has a filter to remove the free tier usage, or maybe that's the credits? That might help to see what the costs will be.

Thanks! Cloud pricing is messy for sure. This blog describes the Cloud Pricing API: https://www.infracost.io/blog/cloud-pricing-api/ it's the 3rd one our team has built in the last 10 years. The Infracost CLI uses the GraphQL API from this service to retrieve prices.

Thanks!

The complexity is crazy for sure. Around 10 years ago I started looking at cloud costs as part of my PhD - back then there were around 10,000 price points that I was scraping manually, today there are more than 3 million prices between AWS, Azure and Google that we're fetching in https://github.com/infracost/cloud-pricing-api

Hi HN, this is the 3rd Cloud Pricing API I've worked on. It's an open source GraphQL-based API that includes all public prices from AWS, Azure and Google; it contains over 3 million prices that are automatically updated via a weekly job.

My previous iterations were in 2010 (scrapers to fetch cloud prices as vendors didn't offer APIs then - there were over 10,000 prices back then) and in 2015 (a RESTful API - there were over 100,000 prices then).

Whilst this latest Cloud Pricing API was built with the open source Infracost CLI in mind, I'm curious if people find it useful as a standalone thing? I'm happy to help people who want to build stuff on top of it.

Capacity planning challenges can't be ignored and it's interesting that Pinterest share their forecasts with AWS significantly in advance. Makes me wonder if AWS will offer more incentives to older/larger enterprises that are used to datacenter-era capacity planning, I suppose RIs and Savings Plans are a manifestation of that already.