The Day I Stopped Clicking Around the AWS Console
I used to think AWS infrastructure was something you built by clicking through the Console. Terraform changed that mindset—here’s how Infrastructure as Code made my AWS projects more reproducible, reviewable, and slightly less terrifying.
There is something dangerously satisfying about the AWS Console.
You click a few buttons.
Select a region.
Choose an instance type.
Create a VPC.
Add a subnet.
Click Create.
And suddenly you have infrastructure.
It feels productive.
Until you need to create the exact same thing again.
Then you realize you have absolutely no idea what you clicked 20 minutes ago.
That was basically my introduction to Infrastructure as Code.
The problem with “I'll just create it manually”
When you're learning AWS, manually creating resources is actually useful.
You get to see what a VPC looks like.
You understand where subnets live.
You discover security groups.
You learn what an EC2 instance actually needs.
But eventually you start building larger environments.
VPC.
Subnets.
Route tables.
Internet gateways.
NAT gateways.
IAM roles.
Load balancers.
EKS.
RDS.
At that point, clicking through the console starts feeling less like cloud engineering and more like filling out an extremely long government form.
And there's another problem:
How do you recreate the environment?
Enter Terraform
Terraform changed the way I thought about infrastructure.
Instead of telling AWS:
“Click this, then this, then this…”
you describe what you want.
For example:
1
2
3
resource "aws_s3_bucket" "app" {
bucket = "my-example-app"
}
That's the basic idea.
Your infrastructure becomes code.
And once infrastructure becomes code, you suddenly get things you've been taking for granted in software development:
Git.
Version history.
Code review.
Collaboration.
Automation.
You can look at a Terraform file and actually see what infrastructure a project is supposed to have.
The really cool part: plan
One of my favorite Terraform commands is:
1
terraform plan
Terraform basically looks at:
What I have
versus
What I said I want
and shows you the difference.
It doesn't immediately start deleting half your AWS account because you accidentally changed one line.
It gives you a preview.
That makes infrastructure feel much less mysterious.
You can review the changes before applying them.
And yes, you should absolutely review them.
Especially when Terraform says:
Plan: 109 to add, 0 to change, 0 to destroy.
At that point you start questioning every decision that led you here.
State was another rabbit hole
Then I discovered Terraform state.
And learned that Terraform needs to keep track of the infrastructure it manages.
Which sounds simple.
Until you have a team.
Now you don't want everyone's laptop holding a different copy of the state.
So you start thinking about remote backends.
Then locking.
Then permissions.
Then encryption.
And suddenly your simple infrastructure project has its own infrastructure.
Classic DevOps.
Terraform also taught me something important about cloud
Before Infrastructure as Code, I mostly thought about individual AWS services.
EC2.
S3.
RDS.
VPC.
EKS.
Terraform made me think about how everything connects.
An application isn't just:
“I need an EC2 instance.”
It might actually be:
1
2
3
4
5
6
7
8
9
10
11
12
VPC
├── Public Subnets
│ └── Load Balancer
│
├── Private Subnets
│ ├── Application
│ └── Database
│
├── Route Tables
├── NAT Gateway
├── Security Groups
└── IAM
Now you're thinking about architecture rather than individual services.
And that's where Infrastructure as Code becomes really powerful.
But Terraform doesn't mean “never use the console”
This is something I had to learn too.
The AWS Console is still incredibly useful.
It's great for exploring.
It's great for troubleshooting.
It's great when you're learning a service for the first time.
The problem isn't using the console.
The problem is having important production infrastructure that only exists because someone remembers which 14 buttons they clicked six months ago.
That's not reproducible infrastructure.
That's archaeology.
The bigger picture
Eventually the workflow starts looking something like:
1
2
3
4
5
6
7
8
9
10
11
GitHub
↓
Terraform
↓
AWS Infrastructure
↓
Docker / EKS
↓
Application
↓
Monitoring
And now infrastructure changes can go through the same workflow as application changes.
Create a pull request.
Review the Terraform.
Run a plan.
Approve it.
Apply it through CI/CD.
Infrastructure becomes something your team can actually collaborate on.
My biggest takeaway
Terraform isn't really about avoiding the AWS Console.
It's about making infrastructure:
repeatable, reviewable, version-controlled, and predictable.
And honestly, that's a much better feeling than wondering:
“Wait… which subnet did I create manually last Tuesday?”
The Console is still open in another tab, though.
I'm not a monster.
Enjoyed reading this content? Let the author know!
Your likes, comments, shares, and saves help creators reach more builders.
Loading recommendations
Loading article