This message was deleted.

Hello! Are you able to share your TF code so we could reproduce it?

Will not be able to share the TF code. Posted the cost JSON files for the same resources across two runs with different cost estimates as private message

@lively-helicopter-12644 hey, I’m not sure if the is has been discussed by Vadim in you private chat, but could this be to do with un rebased changes in from your main to target branch? We’ve seen fluctuations like this before because of this. The other option is that internal bug with Infracost because of a case in your Terraform that we’re not handling correctly. In order to resolve issues like this it’s super helpful to have the underlying terraform code for the problematic resource (you can of course sanitize any sensitive values e.t.c). Otherwise it’s really very tricky for us to assist you.

From the provided files I found one price discrepancy for one resource, but the count of resources differs too. Looking into why

Thanks @mysterious-teacher-68276. re: Rebase: The fluctuation that I reported is not just on the working branch, but also on the fresh clone of master. re: TF code - I understand, however as you’d know there are quite a lot of controls over code. I will try my best, but highly unlikely.

If there is

count

logic and involved it’s probably likely that there’s a bug in the Terraform parsing our side, which again is incredibly tricky to resolve without the actual code. It could be as simple as doing the following for the problem resource:

variable "change_my_name" {}

resource "aws_instance" "replace_the_name" {
    count = var.change_my_name
    
    # remove any attributes that we're not interested in 
    ...
}

this should be pretty safe from a sec ops point of view

Okay, I was incorrect, the prices are fine. But the counts are off for many resources

Seems for sure there is a bug with NAT Gateway count. Tried in another repo as well. Same issue

are you fetching this count from a data block?

Yes -

data.aws_availability_zones.available.names

ok so this is an issue with how we mock the list that’s returned from that data block then. Infracost doesn’t use credentials to talk to AWS so it has no way to fetch the information from a data block. We thus mock the data, which in your case seems to be fluctuating with each run.

Ah makes sense. However for this specific case, isn’t it worth to keep a count of AZs per region instead of a blunt mock? Static values will return better than random values in this case.

for sure, but our mocking at this point in time is quite naive - so we don’t have many specific mock overrides defined for data blocks

Oh ok… FWIW, I looked through multiple large repos. The

data.aws_availability_zones

is the only one that required an accurate mock, as far as I see now. I am sure many use these for ensure all AZs in a given AWS region is covered.

yep understood - the other option you have is to parse the Terraform plan JSON directly

Just thinking about using the plan json. However, that would mean, it would show only what is in the plan, meaning only resources that will be created. Not the entire project. So ya, one will get an estimate of cost of resources to be created as part of MR. But will not be able to see the overall cost or master and how much this MR is increasing.

No I believe we will show you the entire project costs, just the diff on the resources changed as part of the plan

Cool, let me try