Forem: Ahkar Swe

🚀 Automating Terraform with CI/CD (GitHub Actions) — Part 10

Ahkar Swe — Thu, 16 Apr 2026 00:30:00 +0000

So far in this series, we’ve:

Learned Terraform fundamentals
Built reusable modules
Managed remote state
Designed production-ready structure
Compared workspaces vs environments
Deployed VPC and real AWS architecture
Built a 3-tier system

Now we complete the journey 🔥

👉 Automating Terraform using CI/CD

🎯 What You’ll Learn

In this guide:

Why CI/CD is important for Terraform
How to automate Terraform with GitHub Actions
Safe deployment practices
Production workflow

🔁 Why CI/CD for Terraform?

Without CI/CD:

❌ Manual deployment
❌ Human errors
❌ No consistency

With CI/CD:

✅ Automated workflows
✅ Consistent deployments
✅ Safer infrastructure changes

🏗️ CI/CD Workflow Overview

Developer → Git Push
        ↓
GitHub Actions
        ↓
Terraform Plan
        ↓
Approval (optional)
        ↓
Terraform Apply

📁 Project Structure

.github/
  workflows/
    terraform.yml

🔹 GitHub Actions Example

name: Terraform CI/CD

on:
  push:
    branches:
      - main

jobs:
  terraform:
    runs-on: ubuntu-latest

    steps:
      - name: Checkout
        uses: actions/checkout@v3

      - name: Setup Terraform
        uses: hashicorp/setup-terraform@v2

      - name: Terraform Init
        run: terraform init

      - name: Terraform Plan
        run: terraform plan

      - name: Terraform Apply
        run: terraform apply -auto-approve

🔐 Security Best Practices

👉 Never hardcode AWS credentials

Use:

GitHub Secrets
IAM roles
Least privilege access

🧠 DevOps Insight

CI/CD enables:

Team collaboration
Safe infrastructure changes
Faster deployments

👉 This is how modern DevOps teams operate.

⚠️ Important Note

Avoid:

❌ Direct auto-apply in production
❌ No approval process

👉 Always use review before apply

🎯 What You Just Learned

Terraform automation
CI/CD pipeline design
Production workflow

💡 Final Thought

You started with:

👉 “What is Terraform?”

Now you can:

👉 Design and automate real infrastructure systems

🎉 Terraform Journey Complete

You have completed:

✔ Infrastructure as Code fundamentals
✔ AWS resource provisioning
✔ Modular Terraform design
✔ Remote state management
✔ Production repository structure
✔ Real architecture (VPC + 3-tier)
✔ CI/CD automation

👉 You are now production-ready with Terraform

🚀 What’s Next?

Continue your journey:

Terraform + Kubernetes (EKS)
Terraform + Docker
Advanced DevOps pipelines

👨‍💻 About the Author

Hi, I’m Ahkar — sharing DevOps, AWS, and Infrastructure knowledge 🚀

🌐 https://mindgnite.com

Follow for more DevOps content 🔥

📚 Terraform Learning Series (Complete)

Part 1: Introduction
Part 2: Setup
Part 3: EC2
Part 4: Variables
Part 5: Modules & Backend
Part 6: Production Structure
Part 7: Workspaces vs Environments
Part 8: VPC Lab
Part 9: 3-Tier Architecture
Part 10: CI/CD Automation (this post)

👉 You’ve completed the full journey 🚀

🏗️ Building a 3-Tier Architecture with Terraform (ALB + EC2 + DB) — Part 9

Ahkar Swe — Wed, 15 Apr 2026 00:30:00 +0000

So far in this series, we’ve:

Built Terraform fundamentals
Created reusable modules
Designed production-ready structure
Compared workspaces vs environments
Deployed a VPC with Terraform

Now it’s time to build something closer to real production 🔥

👉 A 3-tier architecture on AWS

🎯 What You’ll Learn

In this guide:

What 3-tier architecture is
How AWS components work together
How to design scalable infrastructure
Terraform-based architecture thinking

🏗️ What is 3-Tier Architecture?

A 3-tier architecture separates your system into:

1. Presentation Layer (ALB)
2. Application Layer (EC2)
3. Data Layer (Database)

🌐 Architecture Overview

Internet
   ↓
ALB (Load Balancer)
   ↓
EC2 Instances (App)
   ↓
RDS (Database)

🔹 Layer 1: Load Balancer (ALB)

Handles incoming traffic
Distributes requests
Improves availability

👉 Entry point of your system

🔹 Layer 2: Application (EC2)

Runs your app (Node.js, PHP, etc.)
Can scale horizontally
Connected to ALB

🔹 Layer 3: Database (RDS)

Stores data
Private (not exposed to internet)
Secured via subnet + security group

🧠 DevOps Insight

👉 This architecture is used in:

Web applications
SaaS platforms
Enterprise systems

🔧 Terraform Design Approach

Instead of writing everything in one file:

👉 Break into components:

modules/
  vpc/
  alb/
  ec2/
  rds/

🔹 Example: ALB Resource

resource "aws_lb" "app_lb" {
  name               = "app-lb"
  load_balancer_type = "application"
  subnets            = var.public_subnets
}

🔹 Example: EC2 Layer

resource "aws_instance" "app" {
  ami           = var.ami
  instance_type = "t2.micro"
}

🔹 Example: RDS

resource "aws_db_instance" "db" {
  allocated_storage = 20
  engine            = "mysql"
  instance_class    = "db.t3.micro"
}

🔐 Security Design (Important)

ALB → Public
EC2 → Private
RDS → Private

👉 Use Security Groups to control access

🚀 Deployment Flow

```bash id="3tier7"
terraform init
terraform plan
terraform apply




---

## 🧠 What You Just Built

You now understand:

* Real-world AWS architecture
* Multi-layer infrastructure
* Terraform design patterns

👉 This is production-level thinking.

---

## ⚠️ Important Note

3-tier architecture introduces:

* More cost
* More complexity

👉 Always destroy resources when not needed

---

## 🎯 What You Just Learned

* 3-tier system design
* AWS service integration
* Terraform architecture mindset

---

## 💡 Final Thought

This is where Terraform becomes powerful.

👉 You are no longer deploying resources.

👉 You are designing systems.

---

## 🚀 What’s Next?

Next, we go automation:

👉 Terraform + CI/CD (GitHub Actions)

---

## 👨‍💻 About the Author

Hi, I’m Ahkar — sharing DevOps, AWS, and Infrastructure knowledge 🚀

🌐 https://mindgnite.com

Follow for more Terraform content 🔥

---

## 📚 Terraform Learning Series

* Part 8: VPC Lab
* Part 9: 3-Tier Architecture (this post)
* Part 10: CI/CD with Terraform

👉 Follow to continue 🚀

🌐 Deploying an AWS VPC with Terraform (Hands-On Lab) — Part 8

Ahkar Swe — Tue, 14 Apr 2026 00:30:00 +0000

So far in this series, we’ve:

Built Terraform fundamentals
Created reusable modules
Managed remote state
Designed production-ready structure
Compared workspaces vs environments

Now it’s time to build something real 🔥

👉 A complete AWS VPC using Terraform

🎯 What You’ll Learn

In this guide:

What a VPC is
How to design basic network architecture
Create VPC using Terraform
Add subnet and internet gateway

🌐 What is a VPC?

A VPC (Virtual Private Cloud) is:

👉 Your own isolated network in AWS

It allows you to control:

IP range
Subnets
Routing
Internet access

🏗️ Architecture We’ll Build

VPC (10.0.0.0/16)
│
├── Public Subnet (10.0.1.0/24)
│   └── Internet Gateway

📁 Project Structure

vpc-lab/
  main.tf
  variables.tf

🔹 Step 1: Provider Configuration

provider "aws" {
  region = "ap-southeast-1"
}

🔹 Step 2: Create VPC

resource "aws_vpc" "main" {
  cidr_block = "10.0.0.0/16"

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

🔹 Step 3: Create Subnet

resource "aws_subnet" "public" {
  vpc_id     = aws_vpc.main.id
  cidr_block = "10.0.1.0/24"

  tags = {
    Name = "public-subnet"
  }
}

🔹 Step 4: Internet Gateway

resource "aws_internet_gateway" "igw" {
  vpc_id = aws_vpc.main.id

  tags = {
    Name = "main-igw"
  }
}

🔹 Step 5: Route Table

resource "aws_route_table" "public" {
  vpc_id = aws_vpc.main.id
}

🔹 Step 6: Add Internet Route

resource "aws_route" "internet_access" {
  route_table_id         = aws_route_table.public.id
  destination_cidr_block = "0.0.0.0/0"
  gateway_id             = aws_internet_gateway.igw.id
}

🔹 Step 7: Associate Subnet

resource "aws_route_table_association" "a" {
  subnet_id      = aws_subnet.public.id
  route_table_id = aws_route_table.public.id
}

🚀 Deploy Infrastructure

terraform init
terraform plan
terraform apply

🧠 What You Just Built

You now have:

A VPC
A public subnet
Internet access via IGW
Routing configuration

👉 This is the foundation of AWS networking.

💡 DevOps Insight

Almost every AWS architecture starts with:

👉 VPC → Subnets → Routing

⚠️ Important Note

Always clean up resources:

terraform destroy

👉 Avoid unnecessary AWS cost.

🎯 What You Just Learned

Basic AWS networking
Terraform resource relationships
Real infrastructure deployment

💡 Final Thought

This is no longer theory.

👉 You are now building real cloud infrastructure.

🚀 What’s Next?

Next, we go deeper:

👉 Build a 3-tier architecture (ALB + EC2 + DB)

👨‍💻 About the Author

Hi, I’m Ahkar — sharing DevOps, AWS, and Infrastructure knowledge 🚀

🌐 https://mindgnite.com

Follow for more Terraform content 🔥

📚 Terraform Learning Series

Part 7: Workspaces vs Environments
Part 8: VPC Lab (this post)
Part 9: 3-Tier Architecture 🔥

👉 Follow to continue 🚀

⚔️ Terraform Workspaces vs Environments — Part 7

Ahkar Swe — Mon, 13 Apr 2026 00:30:00 +0000

So far in this series, we’ve:

Deployed infrastructure with Terraform
Used variables and outputs
Built reusable modules
Implemented remote backend (S3 + DynamoDB)
Structured projects using dev / staging / prod

Now, there’s an important question 👇

👉 Should you use Terraform Workspaces instead of environments?

Let’s break it down.

🎯 What You’ll Learn

In this guide:

What Terraform workspaces are
How they work
Differences between workspaces and environments
When to use each approach

🔹 What is a Workspace?

A workspace is:

👉 A way to manage multiple state files using the same Terraform configuration

By default, Terraform uses:

terraform workspace list

Output:

default

🔹 Creating Workspaces

terraform workspace new dev
terraform workspace new prod

Switch between them:

terraform workspace select dev

👉 Each workspace represents a separate state.

🔹 How Workspaces Work

Terraform stores state per workspace:

terraform.tfstate.d/
  dev/
  prod/

👉 Same code
👉 Different state files

🔁 Example

resource "aws_instance" "example" {
  instance_type = terraform.workspace == "prod" ? "t3.medium" : "t2.micro"
}

👉 Behavior changes based on workspace.

💡 DevOps Insight

Workspaces allow you to:

Avoid duplicating code
Manage multiple environments quickly

⚠️ The Problem

Workspaces seem simple… but in real-world projects 👇

❌ Not very clear for teams
❌ Easy to select wrong workspace
❌ Hard to manage at scale

🏗️ Environment-Based Approach (Recap)

From Part 6:

environments/
  dev/
  staging/
  prod/

👉 Each environment has:

Separate folder
Separate backend
Clear structure

⚔️ Workspaces vs Environments

Let’s compare 👇

Workspaces → simple but limited
Environments → structured and scalable

🧠 DevOps Insight

👉 Workspaces are useful for:

Quick testing
Personal projects

👉 Environments are better for:

Production systems
Team collaboration
Long-term infrastructure

🎯 Recommendation

👉 Use environment-based structure for real-world projects

👉 Use workspaces only for simple use cases

⚠️ Important Note

Do not rely only on workspaces for:

Production infrastructure
Team-based deployments

👉 It increases risk.

🎯 What You Just Learned

How Terraform workspaces work
Their advantages and limitations
Why environments are preferred in production

💡 Final Thought

Terraform gives you multiple ways to solve a problem.

👉 But not all approaches scale.

Choosing the right structure is what separates:

👉 beginners from real DevOps engineers

🚀 What’s Next?

Next, we go hands-on 🔥

👉 Build a real AWS VPC using Terraform
👉 Apply everything you’ve learned so far

👨‍💻 About the Author

Hi, I’m Ahkar — sharing DevOps, AWS, and Infrastructure knowledge 🚀

🌐 https://mindgnite.com

Follow for more Terraform content 🔥

📚 Terraform Learning Series

Part 1: Why Terraform
Part 2: Setup Guide
Part 3: First EC2
Part 4: Variables & Outputs
Part 5: Modules & Backend
Part 6: Production Structure
Part 7: Workspaces vs Environments (this post)
Part 8: VPC Lab (coming next)

👉 Follow to continue 🚀

🏗️ Terraform Production Structure (Dev / Staging / Prod) — Part 6

Ahkar Swe — Sun, 12 Apr 2026 03:34:37 +0000

Terraform Production Structure (Dev / Staging / Prod) — Part 6

So far, you've learned:

EC2 deployment
Variables and outputs
Modules
Remote backend (S3 + DynamoDB)

Now it’s time to answer a critical question 👇

👉 How do real companies organize Terraform projects?

🎯 What You’ll Learn

Multi-environment setup (dev / staging / prod)
Professional Terraform folder structure
How teams manage infrastructure at scale

❗ The Problem

Your current setup might look like this:

main.tf
variables.tf
outputs.tf

👉 Works for learning
👉 Breaks in production ❌

Why?

No environment separation
Hard to manage changes
Risk of deploying to wrong environment

🏗️ Production Structure

Here’s how professionals structure Terraform:

terraform-project/
│
├── modules/
│   └── ec2/
│       ├── main.tf
│       ├── variables.tf
│       └── outputs.tf
│
├── environments/
│   ├── dev/
│   │   ├── main.tf
│   │   └── backend.tf
│   │
│   ├── staging/
│   │   ├── main.tf
│   │   └── backend.tf
│   │
│   └── prod/
│       ├── main.tf
│       └── backend.tf

🔹 Why This Structure?

1️⃣ Separation of Environments

Each environment is isolated:

dev → testing
staging → pre-production
prod → live system

👉 Prevents mistakes like deploying test code to production.

2️⃣ Reuse with Modules

All environments use the same module:

module "ec2" {
  source = "../../modules/ec2"

  instance_type = "t2.micro"
}

👉 Consistent infrastructure across environments.

3️⃣ Independent State Files

Each environment has its own backend:

terraform {
  backend "s3" {
    bucket = "tf-state-bucket"
    key    = "dev/terraform.tfstate"
    region = "ap-southeast-1"
  }
}

👉 Dev and prod never conflict.

🔄 Workflow Example

Deploy to Dev

cd environments/dev
terraform init
terraform apply

Deploy to Production

cd environments/prod
terraform init
terraform apply

👉 Same code, different environment.

🧠 DevOps Insight

This structure enables:

Safe deployments
Team collaboration
Scalable infrastructure

👉 This is how companies manage cloud at scale.

⚠️ Common Mistakes

❌ Single folder for all environments
❌ Sharing same state file
❌ Hardcoding values

🎯 What You Just Learned

Multi-environment Terraform design
Production folder structure
Environment isolation best practices

💡 Final Thought

Infrastructure is not just code.

👉 It’s a system that must be safe, scalable, and predictable.

🚀 What’s Next?

Next, we’ll go deeper:

👉 Terraform workspaces vs environments
👉 When to use each approach

📚 Terraform Learning Series

Part 1: Introduction
Part 2: Setup
Part 3: EC2
Part 4: Variables
Part 5: Modules + Backend
Part 6: Production Structure (this post)
Part 7: Workspaces vs Environments

Follow for more DevOps content 🔥

⚙️ Terraform Modules & Remote Backend (S3 + DynamoDB) — Part 5

Ahkar Swe — Fri, 03 Apr 2026 04:58:00 +0000

So far in this series, we’ve:

Deployed an EC2 instance
Used variables and outputs
Understood Terraform state

But there’s a problem 👇

👉 Your code is still not production-ready

Let’s fix that.

🎯 What You’ll Learn

In this guide:

What Terraform modules are
How to structure reusable code
Why remote state is critical
How to use S3 + DynamoDB backend

🔁 Why Modules Matter

Right now, your code is probably:

👉 All in one file
👉 Hard to reuse
👉 Difficult to manage

🔹 What is a Module?

A module is:

👉 A reusable Terraform component

Example:

modules/
  ec2/
    main.tf
    variables.tf
    outputs.tf

🔹 Using a Module

In your root main.tf:

module "ec2" {
  source = "../../modules/ec2"

  instance_type = "t2.micro"
}

👉 Instead of writing everything again, you reuse code.

💡 DevOps Insight

Modules help you:

Standardize infrastructure
Reduce duplication
Scale across environments

🧠 Terraform State Problem

So far, your state is:

terraform.tfstate

👉 Stored locally ❌

Problems:

Not safe
Not shareable
Not suitable for teams

🔹 Solution — Remote Backend

We move state to:

👉 S3 bucket
👉 DynamoDB (for locking)

🔹 Backend Configuration

Create backend.tf:

terraform {
  backend "s3" {
    bucket         = "my-terraform-state-bucket"
    key            = "dev/terraform.tfstate"
    region         = "ap-southeast-1"
    dynamodb_table = "terraform-lock"
  }
}

🔹 Initialize Backend

terraform init

👉 Terraform will migrate state to S3.

🔒 Why DynamoDB?

DynamoDB provides:

👉 State locking

This prevents:

Multiple users applying at same time
State corruption

🧠 What You Just Built

You now have:

Modular Terraform code
Remote state storage (S3)
State locking (DynamoDB)

👉 This is how real DevOps teams work.

⚠️ Important Note

Never commit:

terraform.tfstate

👉 Add to .gitignore

🎯 What You Just Learned

Modules for reusable infrastructure
Remote backend best practices
Production-ready Terraform setup

💡 Final Thought

You are no longer writing scripts.

You are designing:

👉 scalable infrastructure systems

🚀 What’s Next?

Next, we’ll go deeper into:

👉 Multi-environment structure (dev / prod)
👉 Professional Terraform repo design

👨‍💻 About the Author

Hi, I’m Ahkar — sharing DevOps, AWS, and Infrastructure knowledge 🚀

🌐 https://mindgnite.com

Follow for more Terraform content 🔥

📚 Terraform Learning Series

Part 1: Why Terraform
Part 2: Setup Guide
Part 3: First EC2
Part 4: Variables & State
Part 5: Modules & Backend (this post)
Part 6: Production Structure (coming next)

👉 Follow to continue 🚀

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

Ahkar Swe — Fri, 27 Mar 2026 06:15:27 +0000

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 🚀

🖥️Deploy Your First EC2 with Terraform (Step-by-Step Guide) — Part 3

Ahkar Swe — Mon, 23 Mar 2026 06:26:59 +0000

In the previous post, you set up Terraform and AWS CLI.

Now it’s time to do what really matters:

👉 Build real infrastructure using code

By the end of this guide, you’ll launch an EC2 instance using Terraform — no AWS Console clicks required.

🎯 What You’ll Build

We’ll create:

An EC2 instance
Using Terraform
In just a few lines of code

📁 Step 1 — Create Project Structure

Create a new folder:

mkdir terraform-ec2
cd terraform-ec2

Create files:

touch provider.tf main.tf

🔹 Step 2 — Configure AWS Provider

Open provider.tf:

provider "aws" {
  region = "ap-southeast-1"
}

🔹 Step 3 — Create EC2 Instance

Open main.tf:

resource "aws_instance" "web_server" {
  ami           = "ami-xxxxxxxxxxxx"
  instance_type = "t2.micro"

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

⚠️ Replace the AMI with a valid one from your AWS region.

🔹 Step 4 — Initialize Terraform

terraform init

This downloads the AWS provider and prepares your project.

🔹 Step 5 — Preview Changes

terraform plan

Terraform will show something like:

Plan: 1 to add, 0 to change, 0 to destroy.

👉 This means Terraform is about to create 1 resource (your EC2).

🔹 Step 6 — Apply (Create Infrastructure)

terraform apply

Type:

yes

🔍 Verify in AWS Console

Go to:

👉 AWS Console → EC2 → Instances

You should see:

👉 Your instance running 🎉

🧠 What Just Happened?

Terraform just:

Read your .tf files
Compared desired state vs current state
Called AWS API
Created your EC2 instance

👉 This is Infrastructure as Code in action.

⚠️ Common Issue — AMI Not Found

You might see this error:

InvalidAMIID.NotFound

Why?

AMI IDs are region-specific.

✅ Fix

Go to AWS Console → EC2 → AMIs
Copy a valid AMI ID for your region
Replace it in your code

💡 DevOps Insight

Right now, we are using a hardcoded AMI.

This works for learning, but in production:

❌ Not reusable
❌ Not flexible

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

Variables
Data sources (dynamic AMI selection)

🧹 Clean Up (Important)

To delete your infrastructure:

terraform destroy

Always clean up to avoid unnecessary AWS charges.

🎯 What You Just Learned

How to create an EC2 with Terraform
How init, plan, and apply work
How Terraform interacts with AWS

💡 Final Thought

You just replaced:

clicking in AWS Console

with:

writing infrastructure as code

That’s a major step toward becoming a DevOps engineer 🚀

👨‍💻 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 (this post)
Part 4: Variables, Outputs & State (coming next)

👉 Follow to continue the journey 🚀

🛠️ Terraform Setup Guide: Install Terraform, AWS CLI & Prepare Your DevOps Environment (Part 2)

Ahkar Swe — Sat, 21 Mar 2026 01:35:02 +0000

In the previous post, we talked about why Terraform matters and how it replaces manual AWS work.

Now it’s time to set up your environment and get ready to build real infrastructure.

🎯 What You’ll Do in This Guide

By the end of this post, you will:

Install Terraform
Configure AWS CLI
Verify your environment
Run your first Terraform command

🧰 Environment Used

This guide uses:

WSL Ubuntu / Linux

(You can adapt these steps for macOS or Windows as well.)

🔹 Step 1 — Install Terraform

Run the following commands:

sudo apt update
sudo apt install -y gnupg software-properties-common

wget -O- https://apt.releases.hashicorp.com/gpg | \
gpg --dearmor | \
sudo tee /usr/share/keyrings/hashicorp-archive-keyring.gpg

echo "deb [signed-by=/usr/share/keyrings/hashicorp-archive-keyring.gpg] \
https://apt.releases.hashicorp.com $(lsb_release -cs) main" | \
sudo tee /etc/apt/sources.list.d/hashicorp.list

sudo apt update
sudo apt install terraform

✅ Verify Installation

terraform version

Expected output:

Terraform v1.x.x

🔹 Step 2 — Install AWS CLI

sudo apt install awscli -y

Verify:

aws --version

🔹 Step 3 — Configure AWS Credentials

Run:

aws configure

Enter:

AWS Access Key ID
AWS Secret Access Key
Region (e.g. ap-southeast-1)
Output format (json)

🔍 Test AWS Connection

aws sts get-caller-identity

If successful, you’ll see your AWS account details.

🔹 Step 4 — Create Your First Terraform Project

Create a new folder:

mkdir terraform-test
cd terraform-test

Create a file:

touch main.tf

Add the following:

provider "aws" {
  region = "ap-southeast-1"
}

🔹 Step 5 — Initialize Terraform

Run:

terraform init

Expected output:

Terraform has been successfully initialized!

⚠️ Common Errors (From Real Experience)

❌ AWS credentials not working

Fix:

aws configure

❌ Network / STS error

Check:

aws sts get-caller-identity

❌ Terraform not found

Check:

terraform version

🎯 What You Just Completed

You now have:

Terraform installed
AWS CLI configured
Working environment
Verified setup

👉 You are ready to build real infrastructure.

💡 DevOps Insight

A correct setup saves hours of debugging later.

Before writing Terraform code, always verify:

terraform version
aws sts get-caller-identity

🚀 What’s Next?

Now that your environment is ready, let’s build something real.

In the next post, we’ll:

👉 Deploy your first EC2 instance using Terraform
👉 Understand plan and apply in action
👉 See real infrastructure created from code

This is where you move from setup → real DevOps work 🔥

👨‍💻 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 (this post)
Part 3: First EC2 Deployment (coming next)

👉 Follow to continue the journey 🚀

🚀 Terraform for Beginners: Stop Clicking AWS Console — Start Building Infrastructure Like a DevOps Engineer

Ahkar Swe — Thu, 19 Mar 2026 06:18:05 +0000

When I first started using AWS, I did everything manually:

Click EC2
Launch instance
Configure security group
Repeat again… and again

It worked — until it didn’t.

I couldn’t reproduce environments.
I made mistakes.
And scaling? Impossible.

That’s when I discovered Terraform.

🔰 What is Terraform?

Terraform is an Infrastructure as Code (IaC) tool that lets you define cloud infrastructure using code.

Instead of clicking in AWS Console, you write:

resource "aws_instance" "web" {
  instance_type = "t2.micro"
}

And Terraform builds it for you.

❌ The Problem with Manual AWS Setup

If you're still using the console:

You can’t version control infrastructure
You can’t easily replicate environments
You will eventually make mistakes

This becomes a serious problem in real projects.

✅ Why DevOps Engineers Use Terraform

Terraform solves all of that:

✔ Reproducible infrastructure
✔ Version-controlled (Git)
✔ Automated deployments
✔ Multi-environment support

⚙️ Terraform Workflow (Core Concept)

Every Terraform project follows this flow:

terraform init
terraform plan
terraform apply
terraform destroy

What each command does:

init → prepares your project
plan → shows what will happen
apply → creates infrastructure
destroy → removes everything

📁 Your First Terraform Project Structure

terraform-aws-lab/
├── provider.tf
├── main.tf
├── variables.tf
└── outputs.tf

🎯 What You Just Learned

What Terraform is
Why Infrastructure as Code matters
How Terraform replaces manual AWS work

💡 Final Thought

If you're serious about DevOps, stop thinking:

“How do I click this in AWS?”

Start thinking:

“How do I define this in code?”

🚀 What’s Next?

In the next post, we’ll go hands-on:

👉 Install Terraform + AWS CLI
👉 Configure your environment
👉 Deploy your first EC2 using Terraform

Follow along — this is where things get real 🔥

👨‍💻 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 (this post)
Part 2: Setup Guide (coming next)

👉 Follow to continue the journey 🚀