How to Fix Terraform Error: 'count' value depends on resource attributes

The Error ScenarioYou’re building out infrastructure where one resource depends on the output of another. For example, you might be creating a set of subnets and then trying to spin up an EC2 instance for every subnet created. Everything looks logically sound in your code, but when you run terraform plan, you hit this wall:

Error: Invalid count argument

on main.tf line 24, in resource "aws_instance" "web":
24:   count = length(aws_subnet.public_subnets[*].id)

The "count" value depends on resource attributes that cannot be determined until apply, so Terraform cannot predict how many instances will be created.

Why This HappensTerraform operates in distinct phases. During the Plan phase, Terraform builds a dependency graph and calculates exactly how many resources it needs to create, update, or destroy. To do this, any value passed to count or for_each must be known before any infrastructure is actually touched.

The error occurs when you point count to an attribute that only exists after a resource is created (like a generated ID, a computed ARN, or a list of IDs from a resource that doesn't exist yet). Since Terraform can't predict how many IDs will be returned until the apply finishes, it refuses to proceed.

How to Fix ItThere are several ways to handle this, depending on how your module is structured. Here are the most effective strategies.

1. Drive Logic from Variables or Locals (Recommended)Instead of making the count depend on the output of a resource, make it depend on the input that defines that resource. If you are creating subnets based on a list of CIDR blocks, use that same list to determine your instance count.

The Wrong Way:

resource "aws_subnet" "example" {
  count      = 3
  vpc_id     = aws_vpc.main.id
  cidr_block = "10.0.${count.index}.0/24"
}

resource "aws_instance" "server" {
  # ERROR: IDs aren't known until subnets are created
  count         = length(aws_subnet.example[*].id)
  ami           = "ami-123456"
  instance_type = "t3.micro"
}

The Correct Way:

locals {
  subnet_cidrs = ["10.0.1.0/24", "10.0.2.0/24", "10.0.3.0/24"]
}

resource "aws_subnet" "example" {
  for_each   = toset(local.subnet_cidrs)
  vpc_id     = aws_vpc.main.id
  cidr_block = each.value
}

resource "aws_instance" "server" {
  # SUCCESS: local.subnet_cidrs is known at plan time
  for_each      = toset(local.subnet_cidrs)
  ami           = "ami-123456"
  instance_type = "t3.micro"
  subnet_id     = aws_subnet.example[each.value].id
}

2. Use Data Sources with FiltersIf you are trying to count resources that already exist or are being managed in a different state file, use a data source with a filter. Terraform can often resolve data sources during the plan phase if the filters are static strings.

data "aws_subnets" "existing" {
  filter {
    name   = "vpc-id"
    values = [var.vpc_id]
  }
}

resource "aws_instance" "worker" {
  count         = length(data.aws_subnets.existing.ids)
  ami           = "ami-xxxxxx"
  instance_type = "t2.micro"
}

3. The "Two-Step" Apply (The Quick Fix)If you're in a pinch and can't refactor the code immediately, you can force Terraform to learn the attributes by targeting the dependency first. This is a manual workaround and not a long-term solution for CI/CD pipelines.

• Run terraform apply -target=aws_subnet.example
• Once the subnets exist and their IDs are stored in the state file, run a standard terraform apply. Now that the IDs are in the state, Terraform can resolve the length() during the plan phase of the second run.

VerificationTo confirm the fix worked, run a plan and look for the resource count in the output:

terraform plan

If the fix is successful, you will see a clear list of planned resources (e.g., Plan: 5 to add, 0 to change, 0 to destroy) instead of the "depends on resource attributes" error. If you are using for_each, ensure the keys in the plan output match your expected static identifiers (like CIDR blocks or names) rather than (known after apply).

Prevention

• Static Keys: Always use static strings (names, CIDRs, tags) as keys for for_each rather than database IDs or generated UIDs.
• Avoid count = length(data.something.ids): If that data source depends on a resource created in the same workspace, it will likely fail.
• Input-Driven Design: Structure your modules so that the "source of truth" for the number of resources is always a variable or a local constant.