Terraform Cloud agent networking usage

[sylr]

Hi,

I’ve been trying to optimise my terraform runs by enabling terraform providers cache on my tfc-agent running in kubernetes (hashicorp/tfc-agent:1.21.2) to avoid downloading the bulky terraform-aws-provider (currently 140MB zip) at each run.

It seems to be working according to the logs I see:

2025-04-15T08:28:33.738Z [TRACE] getproviders.SearchLocalDirectory: found registry.terraform.io/hashicorp/aws v5.94.1 for linux_amd64 at .terraform/providers/registry.terraform.io/hashicorp/aws/5.94.1/linux_amd64
2025-04-15T08:28:33.738Z [TRACE] providercache.fillMetaCache: including .terraform/providers/registry.terraform.io/hashicorp/aws/5.94.1/linux_amd64 as a candidate package for registry.terraform.io/hashicorp/aws 5.94.1

However, I still can’t make up the networking figures my monitoring gives me:

This graph shows a ~30MB decrease of received bytes between the 1st run (actually an “plan”) and the 2n and 3rd runs.

It seems to me this gain would match the caching of the terraform binary itself (around 27MB), not the terraform-aws-provider, and that would explain why a plan on a workspace that contains only 1 resource and 2 data (1 aws_cloudfront_distribution, 1 data.aws_caller_identity, 1 data.aws_s3_bucket) still downloads 150MB worth of data.

What do you think ?

Regards.

[sylr]

Marin from Hashicorp support team found the solution.

For provider caching to work the .terraform.lock.hcl files must be committed inside the VCS and must contains the good hash.

Our .terraform.lock.hcl only contained the hashes for the darwin_arm64 platform whereas our tfc-agent runners are linux_amd64. Addind the hashes for linux_amd64 with the following command fixed our caching problem:

for dir in $(find . -type f -name main.tf); do 
  (cd $(dirname $dir); terraform providers lock -platform=darwin_arm64 -platform=linux_amd64);
done

Hope it helps.