Terraform Modules for reusable, scalable and production-ready infrastructure

Terraform Modules Architecture Diagram

Terraform modules are easier to understand visually. The root module acts as the main entry point. It passes input variables into child modules. Child modules create resources and return outputs such as VPC IDs, subnet IDs, database endpoints, cluster names, storage bucket names, or load balancer DNS names.

Terraform modules architecture reference

Root module, child modules, inputs, outputs, reusable infrastructure and team-friendly design.

Root Module Child Modules Variables Outputs Versioning Reusable IaC

What it shows How the root module calls child modules and passes variables into reusable infrastructure components.

Why it matters Modules make Terraform cleaner, easier to scale, easier to review, and easier to standardize across teams.

How to use it Start with the diagram, then study folder structure, variables, outputs, module calls, and versioning.

What are Terraform modules?

A Terraform module is a container for Terraform configuration files that are used together. Every Terraform project has at least one module: the root module. When that root module calls another reusable package of Terraform code, the called package is known as a child module.

In simple terms, Terraform resources are individual infrastructure objects, while Terraform modules are reusable groups of resources. A VPC module may include a VPC, subnets, route tables, internet gateway, NAT gateway, security groups, and outputs. An EKS module may include the cluster, node groups, IAM roles, security groups, and outputs.

module "network" {
  source = "./modules/vpc"

  environment = "dev"
  vpc_cidr    = "10.10.0.0/16"
}

Why Terraform modules matter in real DevOps teams

Without modules, Terraform code can become repetitive very quickly. The same subnet logic, IAM logic, tagging logic, security group rules, storage settings, and naming standards may be copied across multiple projects. That creates maintenance issues and inconsistent infrastructure.

Root module vs child module

Root and child modules are two of the most important Terraform module terms. Understanding this relationship makes module design much easier.

module "vpc" {
  source = "../../modules/vpc"

  name        = "cloudnetworking-dev"
  environment = "dev"
  vpc_cidr    = "10.10.0.0/16"
}

Recommended Terraform modules folder structure

A clean folder structure is one of the strongest parts of a good Terraform module strategy. The goal is to separate reusable modules from environment-specific configuration. Modules should define reusable building blocks. Environment folders should call those modules with different values.

terraform/
├── modules/
│   ├── vpc/
│   │   ├── main.tf
│   │   ├── variables.tf
│   │   ├── outputs.tf
│   │   ├── versions.tf
│   │   └── README.md
│   ├── eks/
│   │   ├── main.tf
│   │   ├── variables.tf
│   │   ├── outputs.tf
│   │   ├── versions.tf
│   │   └── README.md
│   ├── rds/
│   │   ├── main.tf
│   │   ├── variables.tf
│   │   ├── outputs.tf
│   │   ├── versions.tf
│   │   └── README.md
│   └── s3/
│       ├── main.tf
│       ├── variables.tf
│       ├── outputs.tf
│       ├── versions.tf
│       └── README.md
├── environments/
│   ├── dev/
│   │   ├── main.tf
│   │   ├── providers.tf
│   │   ├── backend.tf
│   │   ├── variables.tf
│   │   ├── terraform.tfvars
│   │   └── outputs.tf
│   ├── staging/
│   │   ├── main.tf
│   │   ├── providers.tf
│   │   ├── backend.tf
│   │   ├── variables.tf
│   │   ├── terraform.tfvars
│   │   └── outputs.tf
│   └── prod/
│       ├── main.tf
│       ├── providers.tf
│       ├── backend.tf
│       ├── variables.tf
│       ├── terraform.tfvars
│       └── outputs.tf
└── README.md

Terraform module inputs and outputs

Inputs and outputs are the contract between the root module and child modules. Inputs allow the caller to customize the module. Outputs allow the module to return important values after resources are created.

variable "name" {
  description = "Name prefix for resources created by this module"
  type        = string
}

variable "environment" {
  description = "Environment name such as dev, staging, or prod"
  type        = string
}

variable "vpc_cidr" {
  description = "CIDR block for the VPC"
  type        = string
}

variable "public_subnet_cidrs" {
  description = "List of public subnet CIDR blocks"
  type        = list(string)
}

variable "private_subnet_cidrs" {
  description = "List of private subnet CIDR blocks"
  type        = list(string)
}

variable "tags" {
  description = "Common resource tags"
  type        = map(string)
  default     = {}
}

output "vpc_id" {
  description = "ID of the created VPC"
  value       = aws_vpc.main.id
}

output "public_subnet_ids" {
  description = "IDs of public subnets"
  value       = aws_subnet.public[*].id
}

output "private_subnet_ids" {
  description = "IDs of private subnets"
  value       = aws_subnet.private[*].id
}

Practical Terraform AWS VPC module example

The best way to understand modules is to build a small reusable module. This example shows a simplified AWS VPC module pattern. In a production module, you may add NAT Gateways, route tables, security groups, VPC endpoints, flow logs, tagging rules, and additional controls.

resource "aws_vpc" "main" {
  cidr_block           = var.vpc_cidr
  enable_dns_hostnames = true
  enable_dns_support   = true

  tags = merge(var.tags, {
    Name        = "${var.name}-vpc"
    Environment = var.environment
    ManagedBy   = "terraform"
  })
}

resource "aws_subnet" "public" {
  count = length(var.public_subnet_cidrs)

  vpc_id                  = aws_vpc.main.id
  cidr_block              = var.public_subnet_cidrs[count.index]
  map_public_ip_on_launch = true

  tags = merge(var.tags, {
    Name        = "${var.name}-public-${count.index + 1}"
    Environment = var.environment
    Tier        = "public"
  })
}

resource "aws_subnet" "private" {
  count = length(var.private_subnet_cidrs)

  vpc_id     = aws_vpc.main.id
  cidr_block = var.private_subnet_cidrs[count.index]

  tags = merge(var.tags, {
    Name        = "${var.name}-private-${count.index + 1}"
    Environment = var.environment
    Tier        = "private"
  })
}

resource "aws_internet_gateway" "main" {
  vpc_id = aws_vpc.main.id

  tags = merge(var.tags, {
    Name        = "${var.name}-igw"
    Environment = var.environment
  })
}

module "vpc" {
  source = "../../modules/vpc"

  name        = "cloudnetworking-dev"
  environment = "dev"
  vpc_cidr    = "10.10.0.0/16"

  public_subnet_cidrs = [
    "10.10.1.0/24",
    "10.10.2.0/24"
  ]

  private_subnet_cidrs = [
    "10.10.11.0/24",
    "10.10.12.0/24"
  ]

  tags = {
    Project = "cloudnetworking"
    Owner   = "platform-team"
  }
}

output "vpc_id" {
  description = "VPC ID from the VPC module"
  value       = module.vpc.vpc_id
}

output "public_subnet_ids" {
  description = "Public subnet IDs from the VPC module"
  value       = module.vpc.public_subnet_ids
}

output "private_subnet_ids" {
  description = "Private subnet IDs from the VPC module"
  value       = module.vpc.private_subnet_ids
}

How companies use Terraform modules

In many organizations, Terraform modules are owned by cloud platform teams. The platform team creates approved modules for networking, identity, compute, Kubernetes, storage, security, observability, and databases. Application teams then consume those approved modules instead of building infrastructure from scratch.

Terraform Registry, private modules and versioning

Terraform modules can come from local folders, Git repositories, public registry modules, private registry modules, or internal source control repositories. For professional usage, versioning is very important because it prevents unexpected changes from breaking infrastructure.

module "vpc" {
  source  = "terraform-aws-modules/vpc/aws"
  version = "~> 5.0"

  name = "cloudnetworking-prod"
  cidr = "10.20.0.0/16"

  azs             = ["us-east-1a", "us-east-1b"]
  private_subnets = ["10.20.11.0/24", "10.20.12.0/24"]
  public_subnets  = ["10.20.1.0/24", "10.20.2.0/24"]
}

How modules improve Terraform automation

Terraform modules become more valuable when combined with Git and CI/CD. A pipeline can validate modules, run formatting checks, scan IaC security, generate plans, require approvals, and apply changes safely.

terraform fmt -check
terraform init
terraform validate
terraform plan

Common Terraform modules use cases

Terraform modules are useful whenever infrastructure patterns repeat. They are especially powerful in cloud foundations, platform engineering, DevOps automation, and multi-environment infrastructure delivery.

Terraform modules best practices

Modules can make Terraform clean and powerful, but poorly designed modules can also make infrastructure harder to understand. Good modules are focused, documented, versioned, and predictable.

variable "environment" {
  description = "Deployment environment"
  type        = string

  validation {
    condition     = contains(["dev", "staging", "prod"], var.environment)
    error_message = "Environment must be one of: dev, staging, prod."
  }
}

Common Terraform module mistakes to avoid

Terraform modules are useful only when they simplify infrastructure. If modules become too abstract, too large, or poorly documented, they can make Terraform harder instead of easier.

Recommended Terraform pages to build next

This modules page should connect strongly with the main Terraform hub and future practical Terraform pages. The best traffic usually comes from pages that solve specific implementation searches such as AWS VPC, commands, state, and interview questions.

Official Terraform modules references

Use these official references when you need deeper implementation details, module source syntax, registry usage, module publishing, and Terraform language behavior.