🔁 Terraform Variables, Outputs & State — Make Your Code Reusable (Part 4)

yazar

In the previous post, you deployed your first EC2 instance using Terraform.

That was a huge step.

But if you look at your code now, you’ll notice something:

👉 Everything is hardcoded
👉 It’s not reusable
👉 It’s not scalable

Let’s fix that.

🎯 What You’ll Learn

In this guide, you’ll understand:

  • How to use variables
  • How to output useful data
  • How Terraform tracks infrastructure (state)

These are core concepts used in real-world DevOps projects.

🔁 Why Variables Matter

Right now, your code probably looks like this: 

instance_type = "t2.micro"

This is fine for learning — but not for real projects.

👉 What if you want:

  • different instance types for dev vs production?
  • reusable code?

🔹 Step 1 — Create Variables

Create a new file: 

touch variables.tf

Add: 

variable "instance_type" {
  default = "t2.micro"
}

🔹 Step 2 — Use Variables in Your Code

Update your main.tf: 

resource "aws_instance" "web_server" {
  ami           = "ami-xxxxxxxxxxxx"
  instance_type = var.instance_type

  tags = {
    Name = "terraform-server"
  }
}

👉 Now your code is flexible.

🔹 Step 3 — Override with terraform.tfvars

Create: 

touch terraform.tfvars

Add: 

instance_type = "t3.micro"

👉 Now you can change behavior without editing code

📤 Outputs — See What Terraform Created

Sometimes you want to know:

👉 What is the public IP of my EC2?

Create: 

touch outputs.tf

Add: 

output "instance_public_ip" {
  value = aws_instance.web_server.public_ip
}

After running: 

terraform apply

You’ll see: 

instance_public_ip = 18.xxx.xxx.xxx

🧠 Terraform State — The Brain of Terraform

Terraform stores everything in: 

terraform.tfstate

This file tracks:

  • what resources exist
  • their IDs
  • their current state

🔍 Inspect Your State

Run: 

terraform state list

Example output: 

aws_instance.web_server

🔎 Deep Dive

terraform state show aws_instance.web_server

👉 You’ll see full details of your EC2.

⚠️ Important Insight

Terraform doesn’t query AWS every time.

👉 It relies on state file

That’s why state is critical in real systems.

💡 DevOps Insight

Right now, your setup is: 

Local state → terraform.tfstate

This works for learning.

But in real teams:

❌ Not safe
❌ Not shareable

👉 In the next post, we’ll fix this using:

  • S3 backend
  • DynamoDB locking

🎯 What You Just Learned

  • How to use variables
  • How to make Terraform reusable
  • How outputs work
  • How Terraform state works

💡 Final Thought

You are no longer just writing Terraform.

You are now:

👉 designing reusable infrastructure

That’s the difference between beginner and real DevOps.

👨‍💻 About the Author

Hi, I’m Ahkar — sharing DevOps, AWS, and Infrastructure knowledge to help others grow 🚀

I publish bilingual content (Myanmar 🇲🇲 + English 🇺🇸) focused on real-world cloud learning.

🌐 Blog: https://mindgnite.com

If you found this helpful, consider following for more Terraform & DevOps content 🔥

📚 Terraform Learning Series

  • Part 1: Why Terraform
  • Part 2: Setup Guide
  • Part 3: First EC2 Deployment
  • Part 4: Variables, Outputs & State (this post)
  • Part 5: Modules & Remote Backend (coming next)

👉 Follow to continue the journey 🚀