So I finally started my 30-day Terraform journey. Day 1 wasn't about writing code — it was about understanding why this thing exists in the first place.
Let me share what clicked for me.
The problem with doing things manually
Imagine you need to spin up a new environment for your app. You go to the AWS console, create a VPC, add subnets, launch an EC2 instance, set up security groups, configure IAM... By the time you're done it's 2 hours later and you've clicked through 40 screens.
Now imagine doing that again for staging. And again for prod.
That's the world before IaC. And the worst part? No two environments ever end up exactly the same. Someone forgets a firewall rule here, picks the wrong instance type there. Then you spend hours debugging "why does it work in dev but not in prod?" — and the answer is always some tiny config difference that nobody documented.
What Infrastructure as Code actually means
IaC is simple in concept: instead of clicking through a UI, you write a file that describes what you want. Terraform reads that file and talks to the cloud API to make it happen.
Your infrastructure becomes:
Version controlled — you can see every change in git
Reproducible — run the same code, get the same environment every time
Reviewable — infrastructure changes go through PRs like code does
Automated — plug it into a CI/CD pipeline and it runs itself
The mental shift is: treat your servers and networks like you treat your application code.
Where Terraform fits
There are a bunch of IaC tools out there. They mostly fall into two camps:
Cloud-specific tools — AWS CloudFormation, Azure ARM Templates, GCP Deployment Manager. They're deep integrations with their platforms but lock you in.
Multi-cloud tools — Terraform, Pulumi. Write once, deploy anywhere (AWS, GCP, Azure, even GitHub and Datadog).
Terraform wins in most teams because it's open-source, cloud-agnostic, and has been around long enough that almost every problem you'll hit has already been solved by the community.
How Terraform works (the 30-second version)
You write .tf files using HCL (HashiCorp Configuration Language). Those files describe the resources you want. Then you run a few CLI commands:
bashterraform init # download the providers you need
terraform plan # preview what's going to change
terraform apply # make it happen
terraform destroy # tear it all down
That's it. Terraform figures out the order to create things, handles dependencies, and tracks what it built in a state file.
The key idea: Terraform doesn't "control" your servers after creating them. It just calls the same AWS APIs you'd call manually — but from code.
Setting up
Day 1 setup was quick:
bash# Install via brew (macOS)
brew tap hashicorp/tap
brew install hashicorp/tap/terraform
Verify
terraform version
Terraform v1.7.x
Optional but nice — enable autocomplete
terraform -install-autocomplete
I also installed the HashiCorp Terraform extension for VS Code. It gives you syntax highlighting, formatting on save, and inline docs. Worth it.
One small but real example
To make it concrete — here's the simplest possible Terraform config. It just tells Terraform "I'm using AWS, in us-east-1":
hcl# provider.tf
terraform {
required_providers {
aws = {
source = "hashicorp/aws"
version = "~> 5.0"
}
}
}
provider "aws" {
region = "us-east-1"
}
Running terraform init after this downloads the AWS provider plugin. Nothing gets created yet — but you've told Terraform where to work.
What I'm building toward
Over the next 29 days I'll go from this setup all the way to deploying real, production-grade AWS infrastructure — VPCs, EKS clusters, CI/CD pipelines, the works.
If you're starting from zero with Terraform, follow along. I'll share the mistakes I make, not just the parts that worked.
See you on Day 2. 👋
Top comments (0)