This message was deleted.

Hello! Could you please elaborate a bit more on this? Is there an issue you encountered with the existing tiers? And if yes, what was the resource?

Hi Vadim, Sean and I are from IBM and we’ve been looking at using infracost to add support for IBM terraform resources (a 4th provider). We’ve been looking at how the existing resources are defined in the CLI

Great idea! I was thinking about this the other day too. I haven’t looked at it closely but I was thinking if we get a Cloud Pricing API response with multiple prices with different

StartUsageAmount

we could automatically split the quantity. This would simplify adding resources since price tiers would be handled automatically and consistently.

Agree. This would be possible for tiers based on the usage amount. Some resources have tiers based on region. So I believe we could simplify things a lot with that, but not for every case

to do this, would it make sense to have all of the pricing tiers information stored per sku? or is this already the case with the other providers?

Currently each SKU record can hold all price ranges in one json column

prices

. Each object has

"startUsageAmount": "0", "endUsageAmount": "Inf"

attributes

Yeah for example, S3 general storage in us-east-1 looks something like:

select prices ->> '4ba817554541b6117c5552e95da3b08f-ee3dd7e4624338037ca6fea0933a662f' p from products where service = 'AmazonS3' AND "productFamily" = 'Storage' and region = 'us-east-1' and attributes ->> 'storageClass' = 'General Purpose';

{"USD": "0.0230000000", "unit": "GB-Mo", "description": "$0.023 per GB - first 50 TB / month of storage used", "endUsageAmount": "51200", "purchaseOption": "on_demand", "startUsageAmount": "0", "effectiveDateStart": "2022-03-01T00:00:00Z"},
{"USD": "0.0220000000", "un
it": "GB-Mo", "description": "$0.022 per GB - next 450 TB / month of storage used", "endUsageAmount": "512000", "purchaseOption": "on_demand", "startUsageAmount": "51200", "effectiveDateStart": "2022-03-01T00:00:00Z"},
...

So it is currently possible to make an API request and receive all tiers. However, CLI expects to get only one record with a single price hence the price filters. If we modify this behavior, it would make it possible to reduce amount of the requests.

If you look at the implementation for the cli for this resource you will probably see an array [ 0, 51200] hardcoded. You could make this call get all the values and construct this array dynamically. So if the tiers change in the future the cli will not break. But I think you are saying you would prefer to solve this at a higher level in the code as a generic solution?

You are right, we have to list these numbers as we're using them as price filters and making several API requests due to the behavior I mentioned above.

Is this something that you think will be implemented?

It looks like a good way to greatly reduce the API requests amount, but I don't think it's a problem right now. It would also remove a certain duplication and data will drive the logic. However, it won't work for 100% of the existing cases, unfortunately. And I'm not sure what will be the impact of such change. We may look into this in future, but I don't think it's on our radar right now as we don't have immediate issues with that. However, it would require your resources to have additional logic :/

Yeah I don’t think I see it being prioritized until we make another big push to add resources, so it would probably have to come from the community.