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.
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 ;)
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.
- 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.