When five engineers at CRED each write their own version of a VPC, you get five slightly different VPCs, five sets of bugs, and five things to maintain. A Terraform module solves this by writing the VPC once correctly, testing it once, and letting every team use it without knowing how it works inside. As your infrastructure grows from 200 lines to 20,000 lines across multiple environments, how you organise that code determines whether your team moves fast or spends all day untangling configuration.
What This Pillar Covers
- Writing your first Terraform module — the right directory structure, input variables, and outputs
- Calling modules from a root configuration with local paths, Git references, and registry addresses
- Using the Terraform Registry to find battle-tested community modules for AWS, GCP, and Azure
- Publishing and versioning your own modules with semantic version tags
- Organising code for multiple environments — directory-per-environment vs Terraform workspaces
- Using Terragrunt to eliminate repeated backend configuration and manage module dependencies
Who This Is For
Platform engineers and senior DevOps engineers who are scaling Terraform beyond a single team or environment and need patterns that prevent the codebase from becoming unmaintainable.
Why This Matters in Production
Hotstar's platform team manages infrastructure across 12 microservices and three environments. Without modules, every environment change means editing the same blocks in 36 different places — and getting it wrong in at least one. With a shared VPC module pinned to a version tag, a security fix goes out to all environments with a single version bump and a pull request that anyone can review.
Prerequisites
- Terraform Fundamentals — HCL syntax, resources, variables, and outputs
- Terraform State — understanding how state works before splitting it across modules
- Basic Git knowledge — tags, branches, and repository structure