DRY Configuration Patterns

Don't-Repeat-Yourself is a goal in infrastructure code too, but it competes with isolation and explicitness, and over-applying it produces clever abstractions that are harder to operate than the duplication they replaced. The patterns worth knowing remove genuine repetition — shared modules, common-tag locals, generated config — and the judgment worth developing is knowing when a little duplication is the right call.

DRY is a tool, not a virtue in itself. The question is never "is this repeated?" but "does removing this repetition make the code easier or harder to change safely?" — and for infrastructure, where a wrong change can take down production, the answer leans toward explicitness more often than it does in application code.

Where Repetition Comes From

Three things repeat most. Provider and backend boilerplate gets copy-pasted into every root module. Tag maps — owner, cost-center, environment — get re-typed on every resource. And near-identical environment configs get duplicated across directories. The first is structural and the hardest to remove with native tools; the second and third are exactly what locals, modules, and tfvars are for.

The Native DRY Tools

Plain Terraform already removes most real repetition. A shared module collapses a repeated resource pattern into one definition. A common_tags local defines the tag map once and merges it into every resource. for_each turns a repeated resource into one block driven by a map. And per-environment tfvars let one module serve dev and prod by varying inputs rather than copying code. Reach for these before reaching for any extra tool.

locals {
  common_tags = {
    Environment = "prod"
    Owner       = "platform"
    ManagedBy   = "terraform"
  }
}

resource "aws_instance" "web" {
  ami           = var.ami_id
  instance_type = "t3.small"
  tags          = merge(local.common_tags, { Name = "web" })
}

The Limits of DRY

There is a point where removing duplication makes the result harder to understand. A module so deeply parameterized that every resource is configurable becomes harder to call correctly than writing the resources outright — its interface is the new complexity. Worse, eliminating duplication can destroy a boundary that was protecting you: sharing one config across prod and dev to be DRY couples their fates, so a change meant for dev rolls into prod. Some repetition is load-bearing.

Templated Config and Deliberate Duplication

The repetition the native tools cannot remove cleanly is the structural backend and provider boilerplate across many roots — and that is where teams start generating Terraform or reaching for a wrapper like Terragrunt (the next topic). That is a real signal, not a failure. But before adopting a wrapper, weigh the alternative: a little deliberate copy-paste. Isolating prod often justifies duplicating a config rather than sharing it, because the duplication is what keeps a dev mistake out of prod. Abstract on the second or third real occurrence, not the first — a thing used in exactly one place does not need an abstraction.