Hey, thanks for the outputs. I wonder if it might be the same as https://github.com/infracost/infracost/issues/2003? The output makes it look like it might be. We’ve prioritized that issue and looking to get a fix out in our next version.

Alrighty 🙂 I’ll see if I can whip something up, a quick look at some of the resources in my breakdown (for example:

module.aws.module.aws_test.module.infrastructure.module.euc_bastion.module.extra_interfaces[4].aws_eip.service_instance_eip[2]

) they use

count = length(whatever)

quite a lot, so looks like it could be kind of the same?

Ah interesting, yeah it could be to do with how our HCL parsing is evaluating

whatever

If I rewrite the repro in the issue to use

count

instead of

for_each

I cannot repro though

right, it might not be related then. I’m guessing it’s something with how we’re evaluating

whatever

in

count = length(whatever)

. Is the

whatever

an expression, local or data resource?

It’s the result of a resource

Hmm, here’s a related issue: https://github.com/infracost/infracost/issues/1856 Since the HCL parsing method doesn’t use any creds to query the cloud, unlike

terraform plan

, then it’s not possible to get the result of something which can’t be determined from reading the HCL. So if this is the case for this, I wonder if you have any thoughts on what we should show in this situation.

I think that might be it yeah. It’s a good question what to do instead. My general experience with the HCL parsing feature haven’t been the best, it’s extremely slow to run on our codebase as well. Running infracost with the TF plan output only shows we have about 8k spend where we in reality have ~15k, and HCL parsing puts us at 31k 😂 I haven’t had much success setting up the usage file using the aws api’s either, but I guess that might be related to the HCL parsing?

not to hijack, but re: #1856 - i'd love the option to configure creds to query the values of vars in TF Cloud. especially since using TF Cloud's remote execution mode prevents the remote generation of a plan

@numerous-plastic-31859

My general experience with the HCL parsing feature haven’t been the best, it’s extremely slow to run on our codebase as well.

How long does it take? Do you use a lot of external modules? I wonder if it’s also that this bug is causing it to be slow.

Running infracost with the TF plan output only shows we have about 8k spend where we in reality have ~15k, and HCL parsing puts us at 31k 😂

Do you use a lot of usage-based services like Lambda/S3/Dynamo? We’re looking more at how we can better handle these. I’ll cc @white-airport-8778 here if he has any follow-up questions

I haven’t had much success setting up the usage file using the aws api’s either, but I guess that might be related to the HCL parsing?

What issues are you hitting?

yes...i've used that. let me refresh my memory on what the discrepancy was between HCL parsing and using a plan. perhaps it was things like # of AZs in a region

Ah okay, yeah let us know if you work it out. And if you have any ideas please add them here https://github.com/infracost/infracost/issues/1856. it would be great to get more feedback on this so we can solve it in a nicer way.

How long does it take? Do you use a lot of external modules? I wonder if it’s also that this bug is causing it to be slow.

It takes about 5 minutes to run

infracost breakdown

, same with

infracost diff

- this was using the example github actions workflow from the readme 🙂 Just ran it on my own laptop as well, 4:50min We use a lot of our own wrapper modules that are already inside the repo to cut down on boilerplate, I wouldn’t call them external though

Do you use a lot of usage-based services like Lambda/S3/Dynamo? We’re looking more at how we can better handle these.

We use dynamodb a fair bit, and tbh i don’t have an overview of our dynamo cost atm, so that could be it, I was hoping infracost could pull those metrics automatically from aws’ usage api when generating the usage file

What issues are you hitting?

https://www.infracost.io/docs/features/usage_based_resources/#fetch-from-cloudwatch I ran the command here, and

/tmp/ignore.yml

didn’t have any usage specified, it was just 8000 lines of mostly commented out yaml 🙂

@numerous-plastic-31859 if you already have a plan JSON file, I’d recommend you keep using that with

infracost --path

as that works better for your use-case and is supported in v0.10+ too. Re actual usage data, I’m talking to a few of our top users to explore how we can connect to their bills pull-in actual cost and usage data. DM me if you’re interested in having a call about this as it’s not an easy problem to solve and there are 3 options we’re exploring with users. @lively-journalist-48952 the same offer applies to you! Having the plan JSON method helps with this as the plan JSON has resource IDs whereas HCL does not.

Ah I see, I don’t know why I didn’t realise that I could pull down usage data with

plan.json

as

--path

- I’m getting useful values now, will look into it a bit more tomorrow. Thanks!