Search for a command to run...
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.
No comments yet. Be the first to comment.
This series contains my journey where I learn Terraform from scratch and share my progress every single day. My goal is to stay consistent, learn at a steady and honest pace, and hopefully complete all 30 days.
#30daysofawsterraform By Day 7, Terraform usage starts to resemble real production workflows. You now have structured code, reusable modules, variables, and clean repositories. The next problem becomes obvious: how do you manage multiple environments...
Docker Isn’t the Problem. The Assumption Is.
#30daysofawsterraform By the time I reached Day 10, Terraform had already stopped feeling like a tool for “just creating resources.” Days 8 and 9 changed that mindset completely. Meta-arguments taught
Deployed a Stateless Django Docker App on AWS with Terraform for Fault Tolerance and Autoscaling
Debugging Isn’t the Problem. The Assumption Is.
I Didn’t Understand Cloud Costs Until Resources Kept Running A few months ago, I signed up for an AWS account. The promise of the cloud felt almost magical — servers I could spin up in minutes, no har
Aditya Raj Singh
17 posts
#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.
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
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.
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.
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.
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.
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 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.
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.