This message was deleted.

Hi @helpful-hydrogen-90026. It's possible to override the instance count of an autoscaling group by passing in a usage file (See https://www.infracost.io/docs/usage_based_resources#infracost-usage-file). Here's an example of what to include in the usage file: https://github.com/infracost/infracost/blob/master/infracost-usage-example.yml#L47-L48

Thanks, looking good. If I want to have a minimum and a maximum, the current recommendation would then be to create two usage files I guess.

Yeah that would be the way to do it just now. We've played around with having ranges in the output in the past, but it's something we need to investigate more. The other thing we've been looking at is pulling actual usage data from CloudWatch/other sources to allow the number to be populated automatically. Is this something that would be useful for your case?

Not really. Our use case is that we have a deployment template. We are going to deploy several instances of that deployment module. A change in the deployment template can have a big impact on our costs, so we want to have some governance around this. The usage patterns per instance can be wildly different, and thus the usage data as well. It might be interesting if we could calculate the usage data from all the instances of the deployment template. However, that does mean that the complexity of your implementation increases significantly. On the other hand, ranges are also not that straightforward to use. If you only hit your maximum in a very limited time span, you can't use it to budget since it will be way too high. It might give a theoretical value. It seems a combination of min, max and average usage is what would be most useful.

@broad-addition-19827 added support for Azure CosmosDB recently that had a similar setup. I think for that we used the Max from Terraform and let the user define a

max_request_units_utilization_percentage

. Would that help?

That might indeed be useful. Whether it's a percentage or an absolute value pbb doesn't matter that much. I guess if we base it on actual usage, we'll translate the absolute value to a percentage in the case of AWS ASG or Azure VMSS. However, having min, max and estimated utilization in one report would definitely be great.

Good point. There are three types of cost components for resources: 1. Fixed: e.g. NAT Gateway’s monthly fee. 2. Elastic non-bounded: e.g. S3 storage. For these we can show: monthly_cost_estimate (based on usage file). 3. Elastic with an upper bound (like autoscaling_group instance count): for these we can show monthly_cost_estimate_min, monthly_cost_estimate_max, monthly_cost_estimate (based on usage file, either when

instances

is provided or using a

max_percentage_utilization

). Maybe as a new Range column? If your use-case using the json output?

I'm still experimenting with it. But since we want to add some governance around it, we'll surely use json as it's a structured format.