Fix: Invalid count argument

This error means Terraform tried to resolve a count and could not, because the number it was given depends on something that will not exist until apply time. A common trigger is setting count = length(some_resource.thing) where the list is produced by a resource that has not been created yet. Terraform needs the count during planning to know how many instances to manage and how to address them, so a count that is unknown at plan time is a hard stop.

Error: Invalid count argument

  on main.tf line 14, in resource "aws_route53_record" "app":
  14:   count = length(aws_instance.web[*].id)

The "count" value depends on resource attributes that cannot be determined
until apply, so Terraform cannot predict how many instances will be created.
To work around this, use the -target argument to first apply only the
resources that the count depends on.

What this error means

Terraform decides the set of instances for a resource from its count, and builds an address for each one such as aws_route53_record.app[0]. That number has to be known when Terraform draws the plan, so it can show you and later track each instance. When count is derived from a computed attribute, like the IDs of instances that have not been created, Terraform cannot know the number until apply, so it cannot produce a stable plan and refuses. The fix is to make the count depend only on values that are known before anything runs.

Common causes

• Setting count = length(...) on a list built from a resource attribute like .id or .arn that is computed.
• Sizing count from the result of a data source that itself depends on resources created in the same run.
• Passing a computed count through a module output and using it downstream.
• A conditional count = var.enabled ? something_computed : 0 where the computed branch is unknown.
• Deriving count from a value returned by another provider call that resolves only at apply.

How to fix it

Stabilize

1. Read the error and find the exact count line it names. Look at where the number comes from. If the expression references a resource attribute, directly or through length(), that is the problem.

terraform plan

Diagnose

1. Confirm which value is unknown. In the example, length(aws_instance.web[*].id) is unknown because the instance IDs do not exist until apply. The count depends on a computed list.

2. Find a known source for the same number. If you control how many instances exist, that number is usually already in a variable or a static list.

Fix

Base the count on a value known at plan time. If the same variable or list drives the upstream resource, use it directly instead of counting a computed output:

variable "instance_names" {
  type    = list(string)
  default = ["api", "worker", "cron"]
}

resource "aws_instance" "web" {
  count         = length(var.instance_names)
  ami           = var.ami_id
  instance_type = "t3.micro"
  tags = { Name = var.instance_names[count.index] }
}

resource "aws_route53_record" "app" {
  count   = length(var.instance_names)
  zone_id = var.zone_id
  name    = "${var.instance_names[count.index]}.example.com"
  type    = "A"
  ttl     = 300
  records = [aws_instance.web[count.index].private_ip]
}

Here length(var.instance_names) is known at plan time, and the computed private_ip only appears in the value position where unknowns are allowed.

If you cannot restructure right now and just need to unblock a deploy, apply the upstream resource first so its attributes become known, then run a normal plan:

terraform apply -target=aws_instance.web
terraform plan

Treat -target as a one time escape hatch, not a fix. If the count still reads from a computed value, the next clean run will fail the same way.

How to prevent it

• Size count from variables, locals, or length() of a static list, never from computed resource attributes.
• Keep computed values in the body of a resource, not in the count or for_each that shapes it.
• Prefer for_each with stable keys over count when instances map to named things, so adds and removes do not shift indexes.
• Avoid conditional counts whose active branch is a computed value.
• Review new count expressions in code review for any reference to .id, .arn, or length() of a computed list.

When to call a senior engineer

If fixing the count means changing how many instances exist or shifting their indexes, Terraform will plan to destroy and recreate resources, which is dangerous on anything stateful. count based resources renumber when the list changes, so a careless edit can replace live infrastructure. Erzon engineers can restructure the counting, plan the necessary terraform state mv moves so nothing is needlessly destroyed, and keep your apply clean through the change.