Using Locals to Avoid Code Duplication

One of the biggest challenges as your Terraform codebase grows is keeping it clean and maintainable. Repeating the same values — naming conventions, environment tags, or computed expressions — leads to duplicated effort and increases the risk of mistakes. Locals let you define values once and reuse them anywhere in your configuration. That simplifies updates to shared values, reduces repetition, and makes your configuration easier to read and reason about.

The problem: repeated values across resources

Imagine managing several resources and copying the same environment name or prefix into each resource. That works at first, but when you move from dev to prod you must update the same value in multiple places — a repetitive and error-prone task. Here’s an example showing duplicated tag values across two resources:

resource "some_resource" "server_abc" {
  argument       = var.argument
  argument_type  = var.argument_type

  tags = {
    Name        = "${var.app_name}-${var.server}"
    ManagedBy   = "Terraform"
    Team        = var.team
    Environment = var.environment
    ID          = "server-${local.environment}-${data.aws_region.name}-${var.server}"
  }
}

resource "some_resource" "server_xyz" {
  argument       = var.argument
  argument_type  = var.argument_type

  tags = {
    Name        = "${var.app_name}-${var.server}-xyz"
    ManagedBy   = "Terraform"
    Team        = var.team
    Environment = var.environment
    ID          = "server-${local.environment}-${data.aws_region.name}-${var.server[1]}"
  }
}

This avoids hard-coded values, but it still repeats the same tag map structure and computed expressions in multiple places. Locals let you centralize these values and expressions in one place.

What are locals?

Local values (commonly called “locals”) are named values defined in a locals block. They act as short-term memory for your configuration and are ideal for naming conventions, shared tags, environment names, or temporary computed values. Example:

locals {
  app_name    = "my-app"
  environment = "dev"
}

Reference these with local.app_name and local.environment. Update the locals block once and every reference updates automatically.

Use locals to move repeated logic or long expressions out of resource blocks. This makes your resources concise and centralizes shared logic for easier updates.

Simple use: centralized prefix and environment

Define shared values once and reference them when naming resources:

# Define shared values in locals
locals {
  environment = "dev"
  prefix      = "myorg"
}

resource "github_repository" "dev_repo" {
  name        = "${local.prefix}-${local.environment}-repo"
  visibility  = "private"
  description = "Terraform-managed repo for dev environment"
}

resource "github_team" "awesome_people" {
  name        = "${local.prefix}-${local.environment}-team"
  description = "My Awesome Team"
  privacy     = "closed"
}

By storing prefix and environment in locals, both resource names are generated consistently. Change the values in one place and all resources reflect that change. You can create multiple locals blocks to group related values. Locals can reference other locals (but be careful about creating cycles). Example: group common tags into a single map and reuse it across resources.

locals {
  app_team = "customer-experience"
}

locals {
  # Common tags to be assigned to all resources
  common_tags = {
    Name      = "${var.server_name}-${var.app}"
    Owner     = var.team
    App       = var.application
    Service   = "${var.team}-${var.application}-${var.env}"
    AppTeam   = local.app_team
    CreatedBy = data.aws_caller_identity.current.user_id
    Image     = data.aws_ami.ubuntu.name
  }
}

Then reuse the entire map in a resource:

resource "aws_instance" "example" {
  ami           = data.aws_ami.ubuntu.id
  instance_type = var.instance_type

  tags = local.common_tags
}

Any change to local.common_tags updates every resource that references it. This centralization is the primary advantage of locals: a single source of truth for commonly repeated values.

You can reference one local from another (for example, app_team = local.app_team_base), but you must avoid circular references. Ensure locals only reference values defined earlier or computed without cycles.

When to use locals — guidance and examples

Use locals in these common scenarios:

Computed or derived values: Combine variables, data sources, or inputs to produce standardized formats (naming conventions, IDs, tags).
Reusable constants: Store prefixes, environment names, or shared tag sets so you only update them in one place.
Complex expressions: Move long or messy Terraform expressions into locals to keep resource blocks concise and readable.

Quick reference table:

Use case	Why use locals	Example
Computed naming	Calculate a standardized name once	`local.full_name = "${var.prefix}-${var.env}-${var.name}"`
Shared tags	Keep all tags in one place	`local.common_tags = { Owner = var.team, Env = var.env }`
Complex expressions	Improve readability in resources	`local.subnet_cidrs = cidrsubnets(var.vpc_cidr, 8, 4)`

Some Terraform functions and expressions become long when embedded in resources. Calculate them in a local first, then reference the local in your resource for clearer configuration.

A purple presentation slide titled "When Should I Use Local Values?" with bullet points explaining when to use locals in code. On the right is a framed photo of a laptop on a purple background and HashiCorp Terraform branding along the bottom.

Summary

Locals reduce repetition, centralize logic, and manage complex expressions in one place. They make Terraform configurations cleaner, more maintainable, and less error-prone. Refactor repetitive code into locals, create computed values once, and make configurations more dynamic and easier to update.

Course Introduction

Preparing Your Environment

Terraform Foundations

The Core Terraform Workflow

Terraform CLI

Terraform File Structure and Organization

Terraform Configuration - Fundamentals

Understading and Managing Terraform State

Marking Code Reusable

Refactoring Terraform State

Terraform Modules

Managing Resource Behavior and Dependencies

Securing Terraform Configurations

Terraform Troubleshooting

HCP Terraform

Using Locals to Avoid Code Duplication

The problem: repeated values across resources

What are locals?

Simple use: centralized prefix and environment

When to use locals — guidance and examples

Summary

Links and references

Watch Video

Practice Lab

​The problem: repeated values across resources

​What are locals?

​Simple use: centralized prefix and environment

​Grouping related values and reusing maps

​When to use locals — guidance and examples

​Summary

​Links and references

Watch Video

Practice Lab

The problem: repeated values across resources

What are locals?

Simple use: centralized prefix and environment

Grouping related values and reusing maps

When to use locals — guidance and examples

Summary

Links and references