Dynamic Blocks in Terraform

Dynamic blocks in Terraform offer a powerful way to construct repeatable nested configuration blocks within your resources. They are particularly useful when the number and content of these nested blocks depend on input variables or other computed data, keeping your code DRY (Don't Repeat Yourself).

What are Dynamic Blocks?

Imagine configuring an AWS security group where the ingress rules are not fixed but come from a list of port configurations. Instead of writing multiple static ingress blocks or complex conditional logic, you can use a dynamic block.

A dynamic block iterates over a complex data structure (like a list of objects) and generates a nested block for each element.

variable "ingress_rules" {
  description = "A list of ingress rules for the security group"
  type = list(object({
    port        = number
    protocol    = string
    cidr_blocks = list(string)
    description = optional(string)
  }))
  default = [
    {
      port        = 80
      protocol    = "tcp"
      cidr_blocks = ["0.0.0.0/0"]
      description = "HTTP access"
    },
    {
      port        = 443
      protocol    = "tcp"
      cidr_blocks = ["0.0.0.0/0"]
      description = "HTTPS access"
    }
  ]
}

resource "aws_security_group" "web_sg" {
  name        = "web-server-sg"
  description = "Security group for web servers"

  dynamic "ingress" {
    for_each = var.ingress_rules // Iterates over the list of objects
    content {
      from_port   = ingress.value.port
      to_port     = ingress.value.port
      protocol    = ingress.value.protocol
      cidr_blocks = ingress.value.cidr_blocks
      description = ingress.value.description
    }
  }

  // Egress rule can be static or also dynamic
  egress {
    from_port   = 0
    to_port     = 0
    protocol    = "-1"
    cidr_blocks = ["0.0.0.0/0"]
  }
}

Key Components of a Dynamic Block:

• dynamic "<NESTED_BLOCK_NAME>": Defines the type of nested block to create (e.g., ingress, setting, listener).
• for_each = <COLLECTION>: The expression that provides the collection to iterate over.
• iterator = <NAME> (Optional): Sets a custom name for the iterator variable (defaults to the NESTED_BLOCK_NAME).
• labels = [<STRINGS>] (Optional): A list of strings to use as unique identifiers for each block instance in the Terraform plan and state, if the for_each expression itself isn't descriptive enough.
• content {}: The block that defines the arguments for each generated nested block. Inside content, you use iterator_name.value (or each.value if for_each is a map/set, or dynamic_block_label.value if no iterator is set) to access elements from the collection.

Common Sticking Points

• Syntax Complexity: The structure, especially the content block and accessing iterated values (e.g., ingress.value.port), can be confusing initially.
• When to Use: Deciding if a dynamic block is the best approach versus using for_each on the resource itself with inline nested blocks or separate resources. Dynamic blocks are for repeatable nested blocks within a single resource.
• Data Structures: Preparing the input data in the correct format (often a list of objects or a map of objects) for the for_each expression can be tricky.
• Debugging: If a dynamic block isn't generating the expected configuration, debugging can be less straightforward than with static blocks.

The Scalr Perspective

Dynamic blocks add a layer of abstraction that, while powerful, can reduce immediate readability if not carefully constructed. When these configurations are managed through a platform like Scalr:

• Enhanced Previews: Scalr's detailed run previews become even more critical. They allow you to see exactly how Terraform has interpreted your dynamic blocks and what nested configurations will be created or modified before applying. This visual confirmation helps catch errors in complex dynamic logic.
• Policy Enforcement: OPA policies within Scalr can be used to set guardrails on the complexity or usage patterns of dynamic blocks, ensuring they don't become unmanageable or lead to overly complex resource configurations that violate organizational standards.
• Standardized Inputs: For dynamic blocks driven by variables, Scalr's environment-level variable management ensures that the inputs are consistent and auditable, reducing the chance of misconfiguration when iterating.
• Collaborative Review: When a configuration change involves complex dynamic blocks, Scalr's collaborative workflow (with PR-like review and approval steps) ensures that team members can scrutinize the planned changes before they are applied.

While Scalr doesn't change how dynamic blocks work fundamentally, it provides a safer and more transparent environment to deploy and manage configurations that use them.

Summary Table

Conclusion

Dynamic blocks are a valuable tool for writing concise Terraform code when dealing with repetitive nested structures. Mastering their syntax and appropriate use cases is essential. Leveraging a platform like Scalr for execution and review can provide crucial visibility and control, ensuring these dynamic configurations are deployed confidently.