> However, to play devil's advocate, the number of Terraform resources is a (slightly weak) predictor for resource consumption. Every resource necessitates API calls that consume compute resources. So, if you're offering a "cloud" service that executes Terraform, it's probably a decent way to scale costs appropriately.

That would make sense if you paid per API call to any of the cloud providers.

What happens when you run `terraform apply`? Arguably, a lot of things, but at its core it:

- Computes a list of resources and their expected state (where computation is generally proportional to the number of resources).

- Synchronizes the remote state by looking up each of these resources (where network ingress/egress is proportional to the number of resources).

- Compares the expected state to the remote state (again, where computation is generally proportional to the number of resources).

- Executes API calls to make the remote state match the expected state (again, where network ingress/egress is proportional to the number of resources).

- Stores the new state (where space is most certainly proportional to the number of resources)

This is a bit simplified, but my point is that in each of the five operations, the number of resources can be used as a predictor for the consumed compute resources (network/cpu/memory/disk). A customer with 10k resources is necessarily going to consume more compute resources than one with 10 resources.

In absolute terms, I agree with you. But in practical terms I would wager it is negligible.

Yeah, I'm not putting it forward as a justifying argument (just playing devil's advocate). However, it's probably how they justify it to themselves :) What makes it extra absurd is the price they charge per resource. That's where it turns into robbery.

Sure but it’s calling those service apis directly. The “hard work” is not being done by the client making those calls. Presumably.

you can probably get a sense of it based on your own usage of terraform and the log output (or the time various resources take to get managed in the Terraform Cloud/Enterprise UI). I think in the majority of cases you'll see that the bulk of the compute time is actually network bound, not because of the number of resources, just because the server at the other end (AWS, Azure, GCP, etc.) is doing a lot of work. I know in some cases things like SQL Server Clusters on Azure can take literally hours to provision. Terraform will spend that "compute" time sitting there waiting, it's not actually doing much resource intensive though.

And then at the end as you said "stores the new state". Which is basically a big JSON file. 10 resources? 1M resources? I'll leave you to work out how much it probably costs to save a JSON file of that size somewhere like S3 ;)

> forces people to adopt anti-patterns to limit costs

The previous pricing model, per workspace, did the same. Pricing models are often based on "value received", and therefore often can be worked around with anti-patterns (e.g. you pay for Microsoft 365 per user, so you can have users share the same account to lower costs).

> Every resource necessitates API calls that consume compute resources

In that world, I think it'd make more sense to charge per run-time second of performing an operation. I understand the argument you are making but the issue is you get charged even if you never touch that resource again via an operation.

It might make sense if TFC did something, anything, with those resources between operations to like...manage them. But...