Safely Spawning Multiple Instances with Terraform's count Meta-Argument

count is the meta-argument for spawning multiple identical resources or modules from a single block. It expresses anything from 0 to N instances with minimal syntax.

Frequent exam topics include count.index, the splat operator ([*]), conditional creation (? 1 : 0), and how count differs from for_each.

count Fundamentals and Where It Applies

count is a meta-argument that produces N identical instances from a single resource block. Just feeding it a number lets you toggle between 0 (no instance) and N. Every reference becomes indexed, so even with a single instance you must write [0].

count works on modules as well as resources. It cannot be combined with for_each on the same block, so you have to pick one. References take the form resource.type.name[index].attribute for resources, and module.name[index].output for modules.

• count must be a numeric expression. Expressions that cannot be resolved at plan time may raise an error.
• When count = 0, no instances are created (the reference is treated as an empty list).
• count.index is zero-based and can be used inside attribute references.
• Best suited for creating identical instances from a single block when named identifiers are not required.

Real-World Patterns: Conditional Creation and N-Instance Fan-Out

The two patterns you'll use most often in practice are: toggling creation with a flag (count = var.enabled ? 1 : 0) and fanning out N identical resources (count = var.size). For the latter, weaving count.index into names and tags makes debugging much easier.

When a resource may have count=0, guard the reference (try or length check) to avoid evaluation errors during planning.

• For conditional creation, reference safely with try(resource[0].attr, null).
• For N-instance fan-out, embed the index in the naming convention and keep the configuration identical with no external dependencies.

Basic examples for conditional creation and N-instance fan-out

# Example: create a single NAT Gateway only when the flag is on
variable "enable_nat" {
  type    = bool
  default = false
}

resource "aws_nat_gateway" "nat" {
  count = var.enable_nat ? 1 : 0
  allocation_id = var.enable_nat ? aws_eip.nat[0].id : null
  subnet_id     = var.enable_nat ? aws_subnet.public[0].id : null
  tags = {
    Name = var.enable_nat ? "nat-0" : null
  }
}

# Safe guard on the reference side
output "nat_gateway_id" {
  value = try(aws_nat_gateway.nat[0].id, null)
}

# Example: spin up N identical web servers
variable "web_count" {
  type    = number
  default = 3
}

resource "aws_instance" "web" {
  count         = var.web_count
  ami           = var.ami_id
  instance_type = var.instance_type
  tags = {
    Name = format("web-%02d", count.index)
  }
}

# Collect every ID at once via splat
output "web_ids" {
  value = aws_instance.web[*].id
}

References: count.index and the Splat Operator

count.index is the zero-based index unique to each instance. Use it for naming, pulling values out of arrays, and tagging. Don't forget: if you used count, references need [0] even when there's only one instance.

To pull a specific attribute from every instance in one go, the splat operator ([*]) is your friend. resource.type.name[*].attribute returns a list that's easy to pass to other modules or data sources.

• Single reference: resource.name[0].id
• Bulk reference: resource.name[*].id
• Bulk reference to module outputs: module.mod[*].output_name

Behavior on Changes and Plan Stability

count tends to produce large diffs when the count itself changes or when index-dependent attributes shift. In particular, if you assign names or CIDRs based on the index, reordering the source array forces many resources to be replaced.

The count value must be evaluable at plan time. If it depends on values that aren't known until apply (such as unknown attributes of other resources), planning fails with an error.

To keep destructive diffs in check: lock the input order (sort it), reach for for_each when you need identification that doesn't depend on the index, and design lifecycle blocks deliberately.

• Reordering the array drags every index-based assignment along with it and can trigger sweeping replacements.
• When count goes 3 → 2, index=2 is destroyed. When count goes 1 → 2, index=1 is newly created.
• Avoid making count depend on values that aren't yet known at plan time.

Choosing Between count and for_each (with Comparison Table)

Both produce multiple instances, but they differ in how they handle identifiers and how resilient they are to changes. Use for_each when you want named, individualized instances; reach for count when you just need a fixed number of identical ones. This trade-off shows up often on the Associate exam.

• If the keys are stable, for_each keeps diffs smaller.
• If a count-based scaling model is enough, count is the most concise and readable option.

Using count with Modules and Handling Their Outputs

count works on modules too. Reference an individual instance with an index, like module.vpc[0], or grab them all at once via splat, like module.vpc[*].vpc_id. Module outputs become lists, which makes it safe to pipe them from a parent module into other modules or resources.

Just like resources, references take the module.vpc[0].output form even when count=1. When count=0 is possible, guard the access with try(module.vpc[0].output, null).

• Aggregate module outputs into a list with module.mod[*].out.
• Use module.mod[index].out for an individual reference.
• When count=0 is allowed, wrap the reference in try for safety.

Conceptual diagram of count applied to a module

Check Your Understanding

Frequently Asked Questions