Stop 10 · Infrastructure as Code & AutomationTopics · 5/9

Terraform Modules

In short

Your dev, staging and prod networks are 90% the same code, copied three times. Fix a bug in one, forget the others. Modules let you write it once and reuse it.

Reusable, parameterized bundles of Terraform configuration — avoiding copy-pasted infrastructure code across environments (dev/staging/prod) the same way functions avoid copy-pasted application code.

The mascot assembles identical modular cabinets in three sizes from the same flat-pack kit.

Think of it like this

The modular kitchen kit

Modular kitchen makers don't design every cabinet from scratch. They have one tested unit that comes in small, medium and large, with the same hinges and fittings. A Terraform module is that unit: one tested design, with inputs for size and colour.

Watch it happen

A root module calling two child modules

envs/prod

module vpc

module web

aws_vpc

aws_subnet x3

aws_instance

aws_lb

1/4The root module is the folder you run Terraform in, here envs/prod. It mostly just calls modules.

The big ideas

What you need to know

A module is a folder

Any folder of .tf files is a module. It has inputs (variables), resources inside and outputs.

Inputs, not copies

Environments differ only in the values they pass: instance size, CIDR range, replica count.

Pin versions

When calling a module from Git or the Terraform Registry, pin a version so an upstream change doesn't surprise you.

Keep them focused

A module should do one job well, like 'a network' or 'a web service', not 'all of production'.

See it in code

Walk through the code

hcl

1module "web" {2  source        = "./modules/web-server"3  env           = "prod"4  instance_type = "t3.small"5  min_size      = 26}7 8output "web_url" {9  value = module.web.url10}

1/3Call a module from a local folder. It could also be a Git URL or a Registry address with a version.

The modules/web-server folder must declare variables named env, instance_type and min_size, and an output named url.

Save yourself the pain

Common mistakes

Oops

Building one giant module with fifty variables for every possible case.

Do this instead

Make small modules with a few clear inputs. If a module needs many if-else flags, it's probably two modules.

Oops

Using a public module from the Registry without reading its code.

Do this instead

Read what it creates and pin the version. You're responsible for every resource it adds to your account.

Your mission

Write your first module

~35 min

Quick check

Dev and prod need the same network setup with different CIDR ranges. What's the cleanest approach?

Go deeper

1Refactor a Terraform configuration into a reusable module with input variables.
2Use your module to provision the same infrastructure pattern twice with different parameters.
3Explore a public Terraform module registry for well-tested, community-maintained modules.