count

count creates N copies of a resource from a single block. Set count = 3 on an aws_instance and Terraform makes three instances, addressed aws_instance.web[0], [1], and [2]. It is the simplest multiplicity primitive in HCL, and the same thing that makes it simple — identity by numeric position — is what makes it dangerous.

Because each instance is identified by its index, removing an item from the middle of the list renumbers everything after it. Terraform sees the resource that used to be [2] sitting at [1] now, decides they are different objects, and plans to destroy and recreate things you never touched. Knowing exactly when that happens is the whole point of this page.

Basic Usage

Set count to a whole number and reference count.index inside the block to differentiate each instance — picking an availability zone, building a name, slicing a CIDR. The index is zero-based, so three instances are numbered 0, 1, and 2.

resource "aws_instance" "web" {
  count         = 3
  ami           = "ami-0c55b159cbfafe1f0"
  instance_type = "t3.micro"

  tags = {
    Name = "web-${count.index}"  # web-0, web-1, web-2
  }
}

Conditional Creation

The idiom count = var.enabled ? 1 : 0 turns count into an on/off switch: a truthy variable makes exactly one instance, a falsy one makes zero and the resource does not exist at all. This is the standard way to make a resource optional in Terraform, since there is no if statement to wrap a block in.

resource "aws_cloudwatch_log_group" "audit" {
  count = var.enable_audit_logs ? 1 : 0
  name  = "/app/audit"
}

# Reference it as a list, even when there is only one:
# aws_cloudwatch_log_group.audit[0].arn

Index-Based Addressing

Every instance created by count lives at an indexed address — aws_instance.web[0], aws_instance.web[1] — and that address is exactly how the instance is keyed in state. The bare address aws_instance.web is now a list, so referencing aws_instance.web.id without an index is an error. Use aws_instance.web[0].id for one, or aws_instance.web[*].id to collect them all.

The Renumbering Trap

This is where count bites. Suppose count = length(var.names) over ["api", "worker", "cron"], giving you [0]=api, [1]=worker, [2]=cron. Remove "worker" from the middle and the list becomes ["api", "cron"]: now [1] is cron and [2] is gone. Terraform plans to update [1] from worker into cron and destroy [2] — it churns cron, a resource you only wanted to keep, because positions shifted underneath it.

# aws_instance.web[1] will be updated in-place  (was worker, now cron)
~ resource "aws_instance" "web" {
    ~ tags = { "Name" = "worker" -> "cron" }
  }

# aws_instance.web[2] will be destroyed
Plan: 0 to add, 1 to change, 1 to destroy.

Only appending to the end of the list is safe with count; any insert or delete anywhere else renumbers the tail. That single fact is the reason for_each exists and the reason the next two topics push you toward it for anything with identity.

Where count Fits

count is the right tool in two cases and almost no others: a fixed number of genuinely identical resources where position carries no meaning, and the ? 1 : 0 conditional-creation toggle for a single optional resource. Three identical NAT gateways, one per AZ, fit. A set of distinctly-named services or any collection a human will edit over time does not — reach for for_each there.