Stop 09 · Infrastructure as CodeTopics · 4/9

Terraform Modules

Part of the DevOps Roadmap

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

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

More topics at this stop

Stuck on this topic? Ask an Insider

Get 1:1 guidance from people who've walked this exact path — on the InsideEdge app.

Download
InsideEdge