Day 6 of #30DaysOfTerraform: Thinking in Modules, Not Files
Diving into Cloud and DevOps like a kid who learned cycling yesterday and signed up for a race today. I break things, read error logs like bedtime stories, and slowly figure out how not to repeat the same mistakes. If you enjoy honest tech journeys with a bit of humor, you’ll fit right in.
#30daysofawsterraform
By Day 6, Terraform starts to demand a different mindset.
Up until now, writing everything in a single directory worked fine. Variables improved flexibility, remote state improved reliability, but the structure was still flat. That approach breaks down quickly as infrastructure grows.
Day 6 was about Terraform modules — not as a feature, but as a design philosophy. This is the day where Terraform stops feeling like configuration files and starts behaving like a real infrastructure framework.
Why Modules Exist at All
Without modules, Terraform encourages repetition. You define the same VPC logic, security groups, or tagging patterns again and again across environments. That repetition creates drift, inconsistency, and eventually fear of change.
Modules solve this by introducing encapsulation. They allow you to define infrastructure once and reuse it everywhere with different inputs. Instead of copying code, you compose infrastructure.
This mirrors good software design:
Functions instead of duplicated logic
Interfaces instead of hardcoded values
Inputs and outputs instead of hidden assumptions
What a Terraform Module Really Is
At its core, a module is just a directory with Terraform files. There’s no special syntax, no magic wrapper. Terraform treats any directory with .tf files as a module.
A typical module structure looks like this:
Day-6/
├── main.tf
├── variables.tf
├── locals.tf
├── outputs.tf
├── providers.tf
└── modules/
└── vpc/
├── main.tf
├── variables.tf
├── outputs.tf
Inside the module, resources are defined normally. What changes is how values enter and leave the module.
Defining Inputs and Outputs
Modules communicate through variables and outputs. This explicit interface is what makes them safe and reusable.
Inside a VPC module, you might see:
variable "cidr_block" {
type = string
}
resource "aws_vpc" "this" {
cidr_block = var.cidr_block
}
And an output:
output "vpc_id" {
value = aws_vpc.this.id
}
The module itself doesn’t care where it’s used. It only knows what inputs it receives and what outputs it exposes. That separation is intentional and powerful.
Using a Module from the Root Configuration
At the root level, modules are called explicitly:
module "vpc" {
source = "./modules/vpc"
cidr_block = "10.0.0.0/16"
}
This is where composition happens. The root module orchestrates infrastructure by wiring together smaller, focused modules. Each module solves one problem well.
If you need multiple VPCs or environments, you don’t rewrite the module. You reuse it with different inputs.
Why This Changes Everything
Modules force discipline. They push you to:
Separate concerns
Define clear boundaries
Avoid hidden dependencies
Treat infrastructure like reusable building blocks
They also make Terraform safer. When logic lives in one place, fixes and improvements propagate automatically. When something breaks, you know where to look.
From a team perspective, modules enable collaboration. One person can maintain networking modules while another consumes them without needing to understand every internal detail.
Local vs Remote Modules
Day 6 typically starts with local modules, sourced from directories in the same repo. That’s intentional. It builds understanding before introducing complexity.
Later, these same modules can live in:
Git repositories
Versioned module registries
Shared internal platforms
The interface stays the same. Only the source changes.
That consistency is one of Terraform’s strongest design decisions.
The Mental Shift of Day 6
The biggest takeaway from Day 6 wasn’t syntax. It was architectural thinking.
Instead of asking:
“How do I create this resource?”
You start asking:
“How do I design this so it can be reused safely?”
That’s the difference between infrastructure that works today and infrastructure that scales tomorrow.
Takeaway
Day 6 introduced the idea that Terraform is not about writing files — it’s about composing systems.
Modules encapsulate infrastructure logic
Variables and outputs define clean interfaces
Reuse replaces duplication
Structure replaces chaos
Once you start thinking in modules, every Terraform project becomes easier to reason about, safer to change, and far more professional.
This is where Infrastructure as Code begins to feel like engineering, not configuration.
