Dynamic blocks in ingress rules in Terraform - Deep Dive

Overview - Dynamic blocks in ingress rules

What is it?

Dynamic blocks in ingress rules allow you to create flexible and reusable firewall rules in Terraform. Instead of writing each rule manually, you can use dynamic blocks to generate multiple ingress rules based on input data. This helps manage complex security settings efficiently and reduces repetitive code.

Why it matters

Without dynamic blocks, managing many ingress rules becomes tedious and error-prone, especially when rules change often or depend on variable inputs. Dynamic blocks solve this by automating rule creation, making infrastructure safer and easier to update. This saves time and reduces mistakes that could expose systems to risks.

Where it fits

Before learning dynamic blocks, you should understand basic Terraform syntax and how to write static ingress rules in security groups. After mastering dynamic blocks, you can explore advanced Terraform features like modules and conditional expressions to build scalable infrastructure.

Mental Model

Core Idea

Dynamic blocks let Terraform write repeated parts of configuration automatically based on data, turning manual rule lists into flexible templates.

Think of it like...

Imagine you are organizing invitations for a party. Instead of writing each invitation by hand, you create a template and fill in guest names from a list. Dynamic blocks do the same for ingress rules, generating each rule from a list of inputs.

Security Group
┌─────────────────────────────┐
│ ingress {                   │
│   dynamic "rule" {         │
│     for_each = var.rules    │
│     content {               │
│       from_port = rule.value.from_port
│       to_port   = rule.value.to_port
│       protocol  = rule.value.protocol
│       cidr_blocks = rule.value.cidr_blocks
│     }                       │
│   }                         │
}                             │
└─────────────────────────────┘

Build-Up - 7 Steps

1

Foundation

Understanding static ingress rules

Concept: Learn how to write fixed ingress rules in Terraform security groups.

A static ingress rule looks like this: resource "aws_security_group" "example" { name = "example-sg" ingress { from_port = 80 to_port = 80 protocol = "tcp" cidr_blocks = ["0.0.0.0/0"] } } This rule allows HTTP traffic from anywhere.

Result

Terraform creates a security group with one fixed rule allowing TCP traffic on port 80 from all IPs.

Understanding static rules is essential because dynamic blocks build on this structure to automate multiple similar rules.

2

Foundation

Introducing Terraform dynamic blocks

Concept: Dynamic blocks let you generate repeated nested blocks based on input data.

A dynamic block looks like this: dynamic "ingress" { for_each = var.rules content { from_port = ingress.value.from_port to_port = ingress.value.to_port protocol = ingress.value.protocol cidr_blocks = ingress.value.cidr_blocks } } Here, Terraform creates one ingress block for each item in var.rules.

Result

Terraform generates multiple ingress blocks automatically from the list var.rules.

Knowing dynamic blocks lets you avoid writing repetitive code and handle variable numbers of rules easily.

3

Intermediate

Structuring input data for dynamic rules

🤔Before reading on: do you think input data for dynamic blocks must be a list or can it be a map? Commit to your answer.

Concept: Input data for dynamic blocks can be lists or maps of objects describing each rule.

Example input variable: variable "rules" { type = list(object({ from_port = number to_port = number protocol = string cidr_blocks = list(string) })) } Example value: [ { from_port = 80, to_port = 80, protocol = "tcp", cidr_blocks = ["0.0.0.0/0"] }, { from_port = 443, to_port = 443, protocol = "tcp", cidr_blocks = ["10.0.0.0/16"] } ] This lets Terraform create two ingress rules.

Result

Terraform reads the list and creates one ingress block per item with the specified ports and CIDRs.

Understanding how to structure input data is key to using dynamic blocks effectively and flexibly.

4

Intermediate

Combining dynamic blocks with conditionals

🤔Before reading on: can dynamic blocks include conditional logic inside content blocks? Commit to yes or no.

Concept: You can use conditionals inside dynamic blocks to include or exclude parts of rules based on variables.

Example: content { from_port = rule.value.from_port to_port = rule.value.to_port protocol = rule.value.protocol cidr_blocks = rule.value.cidr_blocks description = rule.value.description != "" ? rule.value.description : null } This sets description only if provided.

Result

Terraform creates ingress rules with optional descriptions, skipping empty ones.

Knowing how to combine conditionals with dynamic blocks allows more precise and adaptable rule definitions.

5

Intermediate

Using dynamic blocks for egress rules too

Concept: Dynamic blocks are not limited to ingress; they can generate egress rules similarly.

Example: dynamic "egress" { for_each = var.egress_rules content { from_port = egress.value.from_port to_port = egress.value.to_port protocol = egress.value.protocol cidr_blocks = egress.value.cidr_blocks } } This creates multiple egress rules from input data.

Result

Terraform creates multiple egress rules automatically, improving consistency and reducing errors.

Recognizing that dynamic blocks apply to all nested blocks expands their usefulness beyond just ingress.

6

Advanced

Avoiding common pitfalls with dynamic blocks

🤔Before reading on: do you think dynamic blocks can replace all static blocks without issues? Commit to yes or no.

Concept: Dynamic blocks require careful input validation and cannot always replace static blocks without adjustments.

If input data is empty, dynamic blocks produce no nested blocks, which may cause security groups to have no rules. Also, mixing static and dynamic blocks for the same nested block type can cause conflicts. Example mistake: resource "aws_security_group" "bad" { ingress { from_port = 22 to_port = 22 protocol = "tcp" cidr_blocks = ["0.0.0.0/0"] } dynamic "ingress" { for_each = [] content { ... } } } This can confuse Terraform's plan.

Result

Terraform may produce unexpected plans or errors if dynamic blocks are misused.

Understanding dynamic blocks' limitations prevents configuration errors and ensures predictable infrastructure.

7

Expert

Dynamic blocks internals and evaluation order

🤔Before reading on: do you think dynamic blocks are evaluated before or after Terraform validates the resource? Commit to your answer.

Concept: Terraform evaluates dynamic blocks during the plan phase, generating nested blocks before resource validation and apply.

Terraform processes dynamic blocks by iterating over for_each collections and injecting generated blocks into the resource configuration. This happens before validation, so invalid input data can cause plan failures. Also, dynamic blocks are merged with static blocks, and order matters for overrides. Understanding this helps debug complex configurations and optimize performance.

Result

Terraform produces a complete resource plan with all generated blocks, ready for apply.

Knowing when and how dynamic blocks are evaluated helps troubleshoot and optimize Terraform configurations in production.

Under the Hood

Terraform parses the configuration files and encounters dynamic blocks with for_each expressions. It evaluates the for_each collection, then for each item, it generates a nested block inside the resource. These generated blocks become part of the resource's configuration before Terraform validates and plans the changes. Internally, dynamic blocks are a way to programmatically build repeated nested blocks, reducing manual repetition.

Why designed this way?

Dynamic blocks were introduced to solve the problem of repetitive nested blocks in Terraform configurations. Before dynamic blocks, users had to write many similar blocks manually or use complex workarounds. The design balances simplicity and power, allowing flexible generation of nested blocks while keeping Terraform's declarative model intact.

Terraform Configuration
┌─────────────────────────────┐
│ resource "aws_security_group" {
│   dynamic "ingress" {      │
│     for_each = var.rules    │
│     content {               │
│       ...                   │
│     }                       │
│   }                         │
│ }                           │
└─────────────┬───────────────┘
              │
              ▼
  Evaluate for_each collection
              │
              ▼
  Generate one ingress block per item
              │
              ▼
  Merge generated blocks into resource
              │
              ▼
  Validate and plan resource changes

Myth Busters - 4 Common Misconceptions

Quick: do you think dynamic blocks automatically validate input data types? Commit to yes or no.

Common Belief: Dynamic blocks automatically check that input data is correct and complete.

Reality: Terraform does not validate the contents of for_each collections beyond type constraints; invalid or missing fields cause plan errors or unexpected behavior.

Why it matters: Assuming automatic validation leads to runtime errors and broken infrastructure deployments.

Quick: do you think you can mix static and dynamic blocks of the same type without issues? Commit to yes or no.

Common Belief: Static and dynamic blocks for the same nested block type can be freely combined.

Reality: Mixing static and dynamic blocks for the same nested block type can cause conflicts or unexpected overrides in Terraform plans.

Why it matters: This can cause Terraform to produce incorrect security group rules or fail to apply changes.

Quick: do you think dynamic blocks can generate nested blocks outside their parent resource? Commit to yes or no.

Common Belief: Dynamic blocks can create nested blocks anywhere in Terraform configuration.

Reality: Dynamic blocks only work inside resource or module blocks that support nested blocks; they cannot generate top-level resources or unrelated blocks.

Why it matters: Misusing dynamic blocks leads to syntax errors and confusion about Terraform's capabilities.

Quick: do you think dynamic blocks always improve readability? Commit to yes or no.

Common Belief: Using dynamic blocks always makes Terraform code easier to read and maintain.

Reality: Overusing dynamic blocks or using them with complex expressions can make code harder to understand for new team members.

Why it matters: Poor readability increases maintenance costs and risk of misconfiguration.

Expert Zone

1

Dynamic blocks do not support all nested block types equally; some resource providers have limitations or quirks that require workarounds.

2

The order of generated blocks from dynamic blocks can affect resource behavior, especially when combined with static blocks or other dynamic blocks.

3

Terraform's plan output shows dynamic blocks expanded, but debugging complex dynamic expressions often requires careful use of terraform console and logging.

When NOT to use

Avoid dynamic blocks when the number of rules is fixed and small, as static blocks are simpler and clearer. For very complex logic, consider using Terraform modules or external scripts to generate configuration files instead.

Production Patterns

In production, teams use dynamic blocks to manage security groups with dozens of ingress and egress rules driven by environment variables or external data sources. They combine dynamic blocks with modules to create reusable security group templates that adapt to different application needs.

Connections

Template Engines

Dynamic blocks are similar to template engines that generate repeated content from data.

Understanding how templates generate repeated sections helps grasp how dynamic blocks automate repeated Terraform nested blocks.

Database Query Parameterization

Both dynamic blocks and query parameterization use data-driven generation to avoid repetition and errors.

Knowing how parameterized queries prevent SQL injection by separating data from code parallels how dynamic blocks separate rule data from configuration structure.

Factory Design Pattern (Software Engineering)

Dynamic blocks act like factories producing multiple similar objects (rules) from input data.

Recognizing dynamic blocks as a factory pattern clarifies their role in creating multiple similar configuration blocks efficiently.

Common Pitfalls

#1 Empty input list causes no ingress rules

Wrong approach:

variable "rules" { default = [] }
resource "aws_security_group" "example" {
dynamic "ingress" {
for_each = var.rules
content {
from_port = ingress.value.from_port
to_port = ingress.value.to_port
protocol = ingress.value.protocol
cidr_blocks = ingress.value.cidr_blocks
}
}
}
# No static ingress block

Correct approach:

variable "rules" { default = [] }
resource "aws_security_group" "example" {
ingress {
from_port = 22
to_port = 22
protocol = "tcp"
cidr_blocks = ["0.0.0.0/0"]
}
dynamic "ingress" {
for_each = var.rules
content {
from_port = ingress.value.from_port
to_port = ingress.value.to_port
protocol = ingress.value.protocol
cidr_blocks = ingress.value.cidr_blocks
}
}
}
# Static rule ensures at least one ingress

Root cause:

Assuming dynamic blocks always produce rules even when input is empty leads to security groups with no ingress rules.

#2 Mixing static and dynamic ingress blocks causes conflicts

Wrong approach:

resource "aws_security_group" "example" {
ingress {
from_port = 80
to_port = 80
protocol = "tcp"
cidr_blocks = ["0.0.0.0/0"]
}
dynamic "ingress" {
for_each = var.rules
content {
from_port = ingress.value.from_port
to_port = ingress.value.to_port
protocol = ingress.value.protocol
cidr_blocks = ingress.value.cidr_blocks
}
}
}
# var.rules includes port 80 again

Correct approach:

resource "aws_security_group" "example" {
dynamic "ingress" {
for_each = var.rules
content {
from_port = ingress.value.from_port
to_port = ingress.value.to_port
protocol = ingress.value.protocol
cidr_blocks = ingress.value.cidr_blocks
}
}
}
# Ensure var.rules does not duplicate static rules

Root cause:

Overlapping rules between static and dynamic blocks cause Terraform to produce conflicting or duplicate rules.

#3 Incorrect input data structure causes plan errors

Wrong approach:

variable "rules" {
default = [
{ port = 80, protocol = "tcp", cidr = "0.0.0.0/0" }
]
}
# Missing from_port, to_port, and wrong keys

Correct approach:

variable "rules" {
default = [
{ from_port = 80, to_port = 80, protocol = "tcp", cidr_blocks = ["0.0.0.0/0"] }
]
}
# Correct keys and types

Root cause:

Misunderstanding the required object structure for dynamic blocks leads to Terraform errors during plan.

Key Takeaways

Dynamic blocks in Terraform automate the creation of repeated nested blocks like ingress rules, reducing manual work and errors.

They rely on input data structures such as lists of objects to generate multiple rules flexibly and consistently.

Combining dynamic blocks with conditionals and static blocks requires careful design to avoid conflicts and ensure correct security configurations.

Understanding Terraform's evaluation order for dynamic blocks helps debug and optimize complex infrastructure code.

While powerful, dynamic blocks should be used thoughtfully to maintain code readability and avoid pitfalls like empty rule sets or overlapping rules.

Practice

1. What is the main purpose of using dynamic blocks in Terraform ingress rules?

easy

A. To define a single static ingress rule

B. To encrypt ingress rule data

C. To delete existing ingress rules automatically

D. To create multiple similar ingress rules without repeating code

Solution

1. Step 1: Understand what dynamic blocks do

   Dynamic blocks allow repeating a block multiple times based on a list or map, avoiding code repetition.

2. Step 2: Apply this to ingress rules

   Ingress rules often need multiple similar blocks; dynamic blocks generate these efficiently.

3. Final Answer:

   To create multiple similar ingress rules without repeating code -> Option D

4. Quick Check:

   Dynamic blocks = multiple similar blocks [OK]

Hint: Dynamic blocks repeat blocks from lists or maps [OK]

Common Mistakes:

• Thinking dynamic blocks delete rules
• Confusing dynamic with static blocks
• Assuming dynamic blocks encrypt data

2. Which of the following is the correct syntax to start a dynamic block named ingress in Terraform?

easy

A. dynamic "ingress" { for_each = var.rules { content { ... } } }

B. dynamic ingress { for_each = var.rules { content { ... } } }

C. dynamic "ingress" { for_each = var.rules content { ... } }

D. dynamic ingress { for_each = var.rules content { ... } }

Solution

1. Step 1: Recall dynamic block syntax

   Dynamic blocks require the block type as a quoted string, e.g., dynamic "ingress".

2. Step 2: Check for correct placement of for_each and content

   for_each is assigned outside braces, and content block is inside the dynamic block.

3. Final Answer:

   dynamic "ingress" { for_each = var.rules content { ... } } -> Option C

4. Quick Check:

   Dynamic block syntax uses quotes and for_each outside braces [OK]

Hint: Use quotes around block type and place for_each before content [OK]

Common Mistakes:

• Omitting quotes around block type
• Placing for_each inside braces incorrectly
• Using braces incorrectly around for_each

3. Given the Terraform snippet:

variable "rules" {
  default = [
    { from_port = 80, to_port = 80, protocol = "tcp" },
    { from_port = 443, to_port = 443, protocol = "tcp" }
  ]
}

resource "aws_security_group" "example" {
  name = "example"

  dynamic "ingress" {
    for_each = var.rules
    content {
      from_port   = each.value.from_port
      to_port     = each.value.to_port
      protocol    = each.value.protocol
      cidr_blocks = ["0.0.0.0/0"]
    }
  }
}

How many ingress rules will be created?

medium

A. 2

B. 0

C. 1

D. 3

Solution

1. Step 1: Count elements in var.rules

   var.rules contains 2 map elements, each with from_port, to_port, protocol.

2. Step 2: Understand dynamic block behavior

   Dynamic block creates one ingress block per element in var.rules, so 2 ingress blocks.

3. Final Answer:

   2 -> Option A

4. Quick Check:

   List length = 2 ingress rules created [OK]

Hint: Count list items in for_each to find block count [OK]

Common Mistakes:

• Counting only one rule
• Assuming dynamic block creates zero rules
• Miscounting list elements

4. Identify the error in this Terraform dynamic block snippet for ingress rules:

dynamic "ingress" {
  for_each = var.rules
  content = {
    from_port   = each.value.from_port
    to_port     = each.value.to_port
    protocol    = each.value.protocol
    cidr_blocks = ["0.0.0.0/0"]
  }
}

medium

A. Incorrect use of '=' after content instead of block

B. Missing quotes around "ingress"

C. for_each should be inside content block

D. cidr_blocks must be a string, not a list

Solution

1. Step 1: Check dynamic block syntax for content

   The content block should be a block, not assigned with '='. Using '=' causes syntax error.

2. Step 2: Verify other parts

   Quotes around "ingress" are present; for_each is correctly outside content; cidr_blocks accepts list.

3. Final Answer:

   Incorrect use of '=' after content instead of block -> Option A

4. Quick Check:

   content is a block, not an assignment [OK]

Hint: Use block syntax for content, not '=' assignment [OK]

Common Mistakes:

• Using '=' after content instead of block braces
• Placing for_each inside content
• Omitting quotes around block type

5. You want to create ingress rules dynamically but only for rules where from_port is greater than 1000. Which Terraform expression correctly filters var.rules for use in a dynamic block's for_each?

hard

A. for_each = [for r in var.rules : r if r.from_port > 1000]

B. for_each = { for idx, r in var.rules : idx => r if r.from_port > 1000 }

C. for_each = filter(var.rules, r => r.from_port > 1000)

D. for_each = { for r in var.rules : r.from_port => r if r.from_port > 1000 }

Solution

1. Step 1: Understand for_each type requirements

   for_each expects a map or set of strings; using a map with keys is preferred for dynamic blocks.

2. Step 2: Analyze each option

   A returns a list, which is invalid for for_each in dynamic blocks. B uses r.from_port as key, which may duplicate keys. C uses filter function which is invalid syntax in Terraform. D creates a map with index keys filtered by condition, valid and safe.

3. Final Answer:

   for_each = { for idx, r in var.rules : idx => r if r.from_port > 1000 } -> Option B

4. Quick Check:

   for_each needs map with unique keys filtered by condition [OK]

Hint: Use map comprehension with index keys and condition [OK]

Common Mistakes:

• Using list instead of map for for_each
• Using non-unique keys causing errors
• Trying unsupported filter() function