Understanding Parent and Child Modules

Terraform modules use a parent–child relationship to organize reusable infrastructure. The root module (also called the parent or calling module) invokes one or more child modules. Child modules encapsulate the resources and configuration that actually create infrastructure — for example, a TLS certificate module, a load balancer module, a Kubernetes cluster module, or a database module. The parent module’s role is to call those child modules and provide the inputs they need.

A purple slide titled "Module Block: Parent Module vs. Child Module" explaining that a parent (calling) module references and configures other modules while a child module is the reusable infrastructure component being called. A diagram on the right shows a Parent Module pointing to two Child Modules.

Modules can be sourced from the Terraform Registry, local directories, Git repositories, or other supported locations. This flexibility enables teams to share well-designed infrastructure components and keep root configurations clean and maintainable.

When you reference a remote module (for example, from the Terraform Registry), running terraform init in your working directory downloads the module into the local .terraform directory so Terraform can use it.

Where modules come from

Source type	Use case	Example
Terraform Registry	Reusable community or organization modules	`terraform-aws-modules/vpc/aws`
Local directory	In-repo modules for tight coupling or development	`./modules/vpc`
Git repository	Versioned modules stored externally	`git::https://github.com/org/repo.git//modules/vpc`
Other supported sources	Private registries, S3, etc.	See Terraform docs for details

Parent (root/calling) module: module block

A module block in the root module tells Terraform to invoke a child module. The block has:

A local name (for example, module "vpc").
A source that points to the child module location.
Additional arguments corresponding to the child module’s input variables.

Example parent module calling a VPC module from the Registry:

module "vpc" {
  source = "terraform-aws-modules/vpc/aws"

  name = "my-vpc"
  cidr = "10.0.0.0/16"

  # Example of using a data source for availability zones
  azs                   = data.aws_availability_zones.available.names
  private_subnets       = var.private_subnets
  public_subnets        = var.public_subnets

  enable_nat_gateway    = true
  enable_vpn_gateway    = true

  tags = {
    CreatedBy   = "terraform"
    Environment = "prod"
  }
}

Notes:

The module block name (vpc) is a local identifier; choose a name that fits your codebase (for example prod_vpc, dev_vpc).
Keys inside the block (such as name, cidr, azs) must match the variable names expected by the child module.
Values can be literals, parent variables (var.*), outputs from data resources, or expressions.

Child module: variables, resources, and outputs

A child module is a regular Terraform configuration composed of:

variable blocks to declare inputs,
resource blocks to create infrastructure,
output blocks to export values.

Design child modules to be configurable via variables so they can be reused across environments. Example of a simple child module that accepts name and cidr and creates an AWS VPC resource:

variable "cidr" {
  type    = string
  default = "10.0.0.0/16"
}

variable "name" {
  type    = string
  default = ""
}

resource "aws_vpc" "vpc" {
  cidr_block = var.cidr
  tags = {
    Name = var.name
  }
}

output "vpc_id" {
  value = aws_vpc.vpc.id
}

Key points:

Resource blocks live in the child module; the parent normally does not contain resource blocks that the child creates.
Variables are the module’s configuration surface and make the module reusable.
Outputs expose values (for example, the VPC ID) so the parent or other modules can reference them.

Passing values and retrieving outputs

When the root (parent) module calls a child module, it passes input variables. The child uses those inputs to create resources, then exposes outputs that the parent can reference. Example flow showing a parent declaring a variable, calling a child module, and exporting the child’s output: Root module (calling the child module):

variable "cidr_block" {
  type    = string
  default = "192.168.0.0/16"
}

module "prod_vpc" {
  source = "terraform-aws-modules/vpc/aws"

  name = "my-vpc"
  cidr = var.cidr_block
}

output "vpc_id" {
  value = module.prod_vpc.vpc_id
}

Child module (local modules/vpc or remote source) — simplified:

variable "cidr" {
  type    = string
  default = "10.0.0.0/16"
}

variable "name" {
  type    = string
  default = ""
}

resource "aws_vpc" "vpc" {
  cidr_block = var.cidr
  tags = {
    Name = var.name
  }
}

output "vpc_id" {
  value = aws_vpc.vpc.id
}

How this works:

The root module sets cidr_block and calls module "prod_vpc", passing cidr = var.cidr_block and name = "my-vpc".
Terraform initializes and, if the module source is remote, downloads the module during terraform init.
The child module receives inputs, creates resources (for example, an AWS VPC), and exposes outputs such as vpc_id.
The parent references child outputs using module.<MODULE_NAME>.<OUTPUT_NAME>, e.g. module.prod_vpc.vpc_id.

You can chain modules: for example, a subnet module can accept vpc_id as input where that value originates from module.prod_vpc.vpc_id. Chaining enables clear separation of responsibilities and reusability.

Ensure the input attribute names you provide in the parent module match the variable names declared in the child module. For example, if the child declares variable "cidr", then the parent must pass cidr = ..., not vpc_cidr = ..., unless the child expects vpc_cidr.

Quick comparison: Parent vs Child

Aspect	Parent (root/calling)	Child (module)
Purpose	Orchestrates and composes modules	Encapsulates resources and logic
Contains	`module` blocks, top-level variables, outputs	`variable`, `resource`, `output` blocks
Resources	Typically none for child-managed resources	Houses the actual `resource` blocks
Example reference	`module.prod_vpc.vpc_id`	`output "vpc_id" { value = aws_vpc.vpc.id }`

Best practices

Keep child modules focused on a single responsibility (for example: VPC, database, or IAM).
Make modules configurable via variables; avoid hard-coded values.
Export only necessary outputs to minimize coupling between modules.
Version remote modules and pin versions to avoid unexpected changes.
Document input variables and outputs inside module README files.

Links and references

Modules let you express reusable infrastructure patterns while keeping root configurations concise — use them to standardize and scale your infrastructure-as-code.

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

Understanding Parent and Child Modules

Where modules come from

Parent (root/calling) module: module block

Child module: variables, resources, and outputs

Passing values and retrieving outputs

Quick comparison: Parent vs Child

Best practices

Links and references

Watch Video

​Where modules come from

​Parent (root/calling) module: module block

​Child module: variables, resources, and outputs

​Passing values and retrieving outputs

​Quick comparison: Parent vs Child

​Best practices

​Links and references

Watch Video

Where modules come from

Parent (root/calling) module: module block

Child module: variables, resources, and outputs

Passing values and retrieving outputs

Quick comparison: Parent vs Child

Best practices

Links and references