Naming conventions i Terraform

The readability, understandability, and maintainability of a code significantly depend on the proper application of naming conventions. This article discusses the various naming conventions for Terraform.

General conventions

Use of Underscore

One of the most common practices in naming elements in Terraform is the use of underscores (_) in place of dashes (-). Underscores should be used universally, covering resource names, data source names, variable names, outputs, etc. This approach promotes uniformity across the code and avoids potential confusion that may arise from the inconsistent use of underscore and dash characters.

Case and Character Considerations

In terms of case usage, lowercase letters are generally preferred. While Terraform supports UTF-8 characters, the use of lowercase letters and numbers offers a simpler and more readable format, thereby making the code more accessible to developers of varying skill levels.

Resource and data source arguments

Naming Resources

One critical rule to follow is to avoid repeating the resource type in the resource name. Neither partial nor complete repetition is recommended. For instance, for a resource type aws_route_table, the name should not repeat route_table.

# good
`resource "aws_route_table" "public" {}`

# bad
`resource "aws_route_table" "public_route_table" {}`

# bad
`resource "aws_route_table" "public_aws_route_table" {}`

The 'this' or 'main' Resource Name

If there isn't a more descriptive and general name available, or if the resource module only creates a single resource of a particular type, then the resource name should be this or main.

resource "aws_security_group" "this" {
  # ... other arguments omitted
}

Dash Usage

Dashes should be used inside arguments' values and in places where the value will be exposed to a human. For instance, inside the DNS name of an RDS instance.

resource "aws_db_instance" "this" {
  identifier = "my-rds-instance"
  # ... other arguments omitted
}

Placement of 'count' and 'for_each' arguments

The count or for_each argument should be included inside the resource or data source block as the first argument at the top and separated by a newline after it.

# good
resource "aws_route_table" "public" {
  count = 2

  vpc_id = "vpc-12345678"
  # ... remaining arguments omitted
}

# bad
resource "aws_route_table" "public" {
  vpc_id = "vpc-12345678"
  count  = 2

  # ... remaining arguments omitted
}

Placement of 'tags', 'depends_on', and 'lifecycle' arguments

The tags argument, if supported by the resource, should be included as the last real argument, followed by depends_on and lifecycle if necessary. Each of these should be separated by a single empty line.

# good
resource "aws_nat_gateway" "this" {
  count = 2

  allocation_id = "..."
  subnet_id     = "..."

  tags = {
    Name = "..."
  }

  depends_on = [aws_internet_gateway.this]

  lifecycle {
    create_before_destroy = true
  }
}

# bad
resource "aws_nat_gateway" "this" {
  count = 2

  tags = "..."

  depends_on = [aws_internet_gateway.this]

  lifecycle {
    create_before_destroy = true
  }

  allocation_id = "..."
  subnet_id     = "..."
}

References

https://www.terraform-best-practices.com/naming