DEV Community: Amit Singh Deora

Day 4 AWS Terraform— Understanding Terraform State & Remote Backend (Made Simple)

Amit Singh Deora — Sat, 20 Dec 2025 18:05:57 +0000

Terraform is powerful, but understanding how it keeps track of your infrastructure is even more important. On Day 4, I learned the secret behind Terraform’s “memory” — the state file — and why moving it to a remote backend is a must for real-world DevOps work.

What Exactly Is the Terraform State File?

Whenever Terraform creates a resource, it needs to remember:

What was created
Its attributes
Its unique IDs
Current configuration details All of this is stored in a file called:

terraform.tfstate
This file is the source of truth for Terraform.
It helps Terraform compare two things:

🟢 Desired State
What I define in .tf files (like creating an S3 bucket, EC2 instance, VPC).

🔵 Actual State
What actually exists in AWS right now.

Terraform compares both and decides whether to:

Create
Update
Delete a resource. This is the heart of Infrastructure as Code.

Why Local State is Dangerous

By default, the state file is created locally, which is risky because:

❌ It contains sensitive data
❌ It can be deleted accidentally
❌ It cannot be shared with a team
❌ Multiple people modifying it can corrupt it

This is where remote state storage becomes essential.

Using a Remote Backend (AWS S3)

A remote backend stores the state file in a secure, centralized location.
For AWS users, the most common choice is S3.

Benefits of Remote Backend

Safe and encrypted storage
Easy collaboration within teams
Supports versioning
Can be accessed by CI/CD pipelines
Prevents conflicts using state locking
The state file now lives in S3, not on your laptop.

What Is State Locking?

Terraform operations must happen one at a time.
If two users run terraform apply simultaneously, the state file can get corrupted.

State locking ensures:

Only one process uses the state at a time
Others must wait until the lock is released Earlier, Terraform used DynamoDB for locking. Now S3 supports use_lockfile = true, making it much simpler.

Testing the Setup

With the backend configured, commands like:****

terraform init
terraform plan
terraform apply now interact with the remote state file inside S3. You can even run:

List resources:

terraform state list

Show resource details:

terraform state show <resource_name>

Remove resource from state (advanced):

terraform state rm <resource_name>
These commands help you understand and manage the state without touching the file manually.

Key Takeaways from Day 4

✔ Terraform state file is the memory of your infrastructure
✔ Always store state remotely — never locally
✔ Use S3 for remote backend + built-in locking
✔ Never edit the state file manually
✔ Keep separate state files for dev, test, prod
✔ Use versioning/backups for safety

Understanding Terraform state changed how I look at Infrastructure as Code.
It’s not just about writing .tf files — it’s about managing your infrastructure’s single source of truth.

Day 3 of 30 Days of AWS Terraform — Creating Your First S3 Bucket with Terraform

Amit Singh Deora — Sat, 20 Dec 2025 17:47:47 +0000

Welcome to Day 3 of my 30 Days of AWS Terraform Challenge!
Today marks an important milestone — I wrote my first Terraform configuration that actually creates a real AWS resource, an S3 bucket.

This might seem simple on the surface, but the concepts learned today build the foundation for every cloud automation task we’ll do going forward.

Let’s break down the entire process in a beginner-friendly way.

Why Start with S3?

Amazon S3 is one of the simplest services to automate.
It doesn’t need VPC, networking, or complex dependencies — making it perfect for understanding:

How Terraform resources are written
How provider blocks work
How to run Terraform commands
How a state file tracks your AWS infrastructure If you’re learning Infrastructure as Code, this is the ideal first step.

Folder Setup

Inside my project, I created a new folder:

day03/
And inside it:

main.tf
Terraform does not care about the filename; it only cares that the extension is .tf.

Writing the S3 Bucket Configuration

From the official Terraform documentation, the S3 resource block looks like this:

resource "aws_s3_bucket" "firstbucket" {
  bucket = "my-demo-bucket-123"
  tags = {
    Name        = "MyBucket"
    Environment = "Dev"
  }
}

What this means:

aws_s3_bucket → Terraform resource type
firstbucket → internal name used for referencing
bucket → must be globally unique
tags → key–value metadata Just like that, our infrastructure is defined as code.

Running the Terraform Workflow

Terraform has a very predictable 4-step workflow:

1. terraform init
This command downloads the AWS provider plugin and prepares your working directory.

terraform init
You run this whenever you create a new folder or add a new provider.

2. terraform plan
A dry-run that shows what changes Terraform will make.

terraform plan
For today’s code, it shows:

Plan: 1 to add, 0 to change, 0 to destroy.
Meaning Terraform will create 1 resource — our S3 bucket.

3. terraform apply
Time to actually create the bucket.

terraform apply
Terraform asks for confirmation:

Enter a value: yes
Or skip the prompt:

terraform apply -auto-approve
Within a few seconds, the new S3 bucket appears in the AWS console!

4. terraform destroy
To delete everything:

terraform destroy
Or:

terraform destroy -auto-approve
Terraform cleans up the bucket and returns your environment to original state.

This “build → modify → destroy” cycle is a huge part of real DevOps workflows.

How Terraform Detects Changes

One of the coolest things I learned today:

Terraform keeps track of all created resources using a local file called:

terraform.tfstate
If I update the tag in my code:

Name = "MyBucket 2.0"
And run:

terraform plan
Terraform compares:

The desired state (my .tf file)
The actual state (AWS resources) And says:

0 to add, 1 to change, 0 to destroy
This state-management capability is what makes Terraform so powerful.

Key Learnings From Day 3

How to use official Terraform docs effectively
Understanding resource blocks and provider blocks
Running init, plan, apply, and destroy
Importance of globally unique S3 bucket names
How the Terraform state file tracks real AWS infrastructure
How Terraform automatically identifies changes and updates resources

Final Thoughts

Today was the moment where Terraform “clicked” for me.
Seeing an actual AWS resource being created from a simple .tf file feels like unlocking a new superpower.

Terraform removes the manual clicking and turns infrastructure into repeatable, version-controlled automation — something every DevOps engineer must master.

Terraform Providers: Day2 — Explained Super Simply

Amit Singh Deora — Sat, 20 Dec 2025 17:06:49 +0000

This is my Day 2 of 30daysofawsterraform. Thanks to
Piyush Sachdeva for the amazing series. So, let’s begin.

Before writing Terraform code or creating any AWS resources, you must understand Terraform Providers — because providers are the heart of Terraform.

What is a Terraform Provider?

A provider is a plugin that connects Terraform with the external service you want to manage.

Think of it like a translator:

You write Terraform in HCL (HashiCorp Configuration Language)
AWS, Azure, GCP, Docker, Kubernetes — they don’t understand HCL
So the provider converts your Terraform code → into the API calls that AWS/Azure/GCP understand.

Example:
If you write Terraform to create an S3 bucket, Terraform uses:

AWS provider
Which calls the AWS S3 API
And creates the bucket for you So Terraform never creates resources directly — the provider does it for you.

Terraform has 3 types of providers:

Official Providers Maintained by HashiCorp Examples:

AWS
Azure
GCP

Partner Providers Maintained by the official company but not HashiCorp Example:

Cloudflare
Datadog

Community Providers Maintained by the open-source community Example:

Random
HTTP provider
Local provider

Where Providers Live: registry.terraform.io

When you search “Terraform AWS provider” on Google, you see:

registry.terraform.io/providers/hashicorp/aws
This page shows:

All services supported by the AWS provider
All available resource types (EC2, VPC, IAM, S3, etc.)
All version numbers
Documentation
Example usage

How Does Terraform Download a Provider?
When you run:
terraform init
Terraform:

Reads your provider block
Contacts the Terraform Registry
Downloads the correct provider version
Stores it in a folder called .terraform

This folder contains:

Provider plugin (binary)
Lock files
Based on OS, the plugin file(provider) format changes; created after “tf init”:
Windows → .exe
Mac → .darwin
Linux → .linux

Provider Block Explained

A basic provider block looks like:

terraform {
  required_providers {
    aws = {
      source  = "hashicorp/aws"
      version = "~> 6.0"
    }
  }
}

provider "aws" {
  region = "us-east-1"
}

Key Points:

required_providers
Defines:

Which providers Terraform should use
Version of each provider

⚠️ Never hard-code AWS access key + secret key inside provider block — security risk.

Provider Version vs Terraform Version

There are TWO versions:

Terraform Core version
Example:
required_version = ">= 1.0"
Provider version
Example:
version = "~> 6.0"
These versions are independent, meaning:

Terraform core is maintained by HashiCorp
AWS provider is maintained by AWS Because both are maintained separately → compatibility issues can happen That’s why we lock provider versions.

Version Constraint Operators (Very Important)

You saw symbols like:

= Equal to
!= Not equal
> / < Greater/less
~> Pessimistic operator (most used)
Most important one: ~> (tilde greater-than)
Example:
version = "~> 6.0"
This means:
Accept version 6.0.x
Accept version 6.1, 6.2… 6.10
❌ BUT don’t accept 7.0+ (major version changes)
This protects you from breaking changes.

Why Not Always Use Latest Provider Version?

Because:

New versions may introduce breaking changes
Some resources may behave differently
Your Terraform code may break So we lock versions until we test the newer ones in a dev environment.

Creating Resources Using Providers

A resource example:

resource "aws_vpc" "example" {
  cidr_block = "10.0.0.0/16"
}

Explanation:

resource → Terraform keyword
"aws_vpc" → resource type from provider
"example" → local Terraform name (internal reference) You can refer to this resource elsewhere:

vpc_id = aws_vpc.example.id

Commands Used

Initialize provider terraform init
Check what Terraform will create terraform plan Shows:

What will be added
What will be changed
What will be destroyed
Apply changes (create actual resource) terraform apply

Why Your Plan Failed?

It failed because:

Your IAM user only had S3 access
But you tried to create VPC
So AWS denied it Terraform plan doesn’t call the API → but apply will fail.

Terraform State (not explained deeply here)

Terraform creates a file:
terraform.tfstate
This file:

Tracks what resources Terraform manages
Compares real environment vs Terraform code
Ensures idempotency (same outcome every time) State is a very big topic — later in your series.

Summary (Super Easy)

Terraform with AWS- Day1: Why Terraform Matters & How It Really Works

Amit Singh Deora — Thu, 18 Dec 2025 19:41:22 +0000

What Is Infrastructure as Code (IaC)?

Infrastructure as Code (IaC) means you write code to create and manage your cloud infrastructure.

Infrastructure as Code simply means:

Using code to create and manage cloud resources
instead of clicking buttons on the cloud console.

Normally, to create a server or a database on AWS, you open the console and click through 10–20 screens. With IaC, you just write something like:

Example:
resource "aws_instance" "demo" { ami = "ami-12345" instance_type = "t2.micro" }

Why IaC approach is good to go:

Repeatable
Consistent
Version-controlled
Automated
Error-free
Team-friendly

And this is exactly the reason DevOps engineers love IaC.

Tools Used for IaC

You’ll find many IaC tools out there, but they fall into two categories:

Multi-Cloud Tools

Terraform ⭐ (most popular)
Pulumi

Cloud-Specific Tools

AWS CloudFormation, CDK, SAM
Azure ARM, Bicep
GCP Deployment Manager Terraform is universal, meaning it works with AWS, Azure, GCP, Kubernetes, and dozens of other platforms.

That’s why almost every DevOps roadmap begins with Terraform.

Why Do We Even Need Terraform?

Good question — because AWS already gives us a beautiful console, right?
So why write code?

To understand this, let’s imagine a very common architecture.

The Problem: Manual Infrastructure Doesn’t Scale
Let’s consider a simple 3-tier application:

Web tier
App tier
Database tier
To deploy this, you need to create:
VPC
Subnets
EC2 instances
Auto Scaling Groups
Load Balancers
RDS Database
Route 53
Security groups
And more…
👉 Doing this manually takes ~2 hours per environment

Now multiply that:
1 Application = 6 environments

(dev, staging, prod)

2 hours × 6 = 12 hours per app

And in real companies?

They don’t run 1 or 2 apps.
They run hundreds.

This makes manual provisioning:

Time-consuming
Expensive
Error-prone
Inconsistent
Impossible to track

Let’s break down the real-world issues 👇

Challenges of Manual Cloud Provisioning

Too slow
Teams wait for infrastructure → delayed releases.
Too many people required
Hiring a large infra team = huge cost.
Too many human errors
Wrong AMI, wrong subnet, wrong IP → outages.
No consistency
Dev ≠ Staging ≠ Prod
This leads to the classic:
“It works on my machine!”
No version control
No history, no audit, no rollback.
This is where Terraform shines.

Terraform: The Ultimate Solution

Terraform allows you to:

Write infrastructure code once
Reuse it for any number of environments
Keep everything consistent
Automate deployments
Eliminate human errors
Track all changes through Git
Destroy environments automatically to save cost And all this with just a few .tf files. Terraform brings speed, safety, repeatability, and control to cloud infrastructure.

How Terraform Actually Works

Terraform uses a declarative language called HCL (HashiCorp Configuration Language).
You write.tf files to describe what you want.

Example:
resource "aws_vpc" "main" { cidr_block = "10.0.0.0/16" }

Then you run 4 important commands:

terraform init

Downloads the provider plugins (like AWS provider).
This is always the first command.

terraform validate

Checks if your Terraform files are correct syntactically.

terraform plan

Shows a preview of:

what Terraform will create
what it will modify
what it will delete
This is like a “safety check” before deployment.

terraform apply

Actually creates infrastructure in AWS via API calls.

terraform destroy

Removes everything mentioned in your .tf files. Removes all resources defined in your Terraform project.
Useful for dev/testing environments.

Terraform + Git = Pure Magic

Using Git with Terraform gives you:

Full version history
Rollbacks
Pull request approvals
Collaboration
Faster Approval
CI/CD automation

Infrastructure becomes predictable, secure, and auditable.

Installing Terraform (Quick Summary)

Install using Homebrew / apt / yum / Chocolatey
Confirm using:
terraform version
Install VS Code extension → HashiCorp Terraform
Set alias tf=terraform for easy typing
You’re ready to start!

Starting My 30 Days of Terraform (AWS Edition) – From Basics to Advanced Projects

Amit Singh Deora — Wed, 01 Oct 2025 10:04:31 +0000

Hey folks,
I’ve decided to kick off a 𝟯𝟬-𝗱𝗮𝘆 𝗧𝗲𝗿𝗿𝗮𝗳𝗼𝗿𝗺 𝗖𝗵𝗮𝗹𝗹𝗲𝗻𝗴𝗲 where I’ll be learning, practicing, and sharing everything from the fundamentals to advanced AWS projects.

The goal isn’t just to get comfortable writing Terraform, but also to understand how it’s applied in real-world infrastructure—building things that are scalable, reusable, and production-ready.

What to expect

• Starting with the 𝗯𝗮𝘀𝗶𝗰𝘀 𝗼𝗳 𝗧𝗲𝗿𝗿𝗮𝗳𝗼𝗿𝗺 and gradually leveling up
• Working through 𝗔𝗪𝗦 𝘀𝗲𝗿𝘃𝗶𝗰𝗲𝘀 𝗮𝗻𝗱 𝘀𝗲𝘁𝘂𝗽𝘀 (VPCs, IAM, EC2, S3, RDS, EKS, etc.)
• Diving into 𝗮𝗱𝘃𝗮𝗻𝗰𝗲𝗱 𝗧𝗲𝗿𝗿𝗮𝗳𝗼𝗿𝗺 𝗽𝗿𝗮𝗰𝘁𝗶𝗰𝗲𝘀 like modules, remote state, CI/CD integration, and infra testing
• Wrapping it all up with 𝗽𝗿𝗼𝗷𝗲𝗰𝘁𝘀 𝘁𝗵𝗮𝘁 𝗲𝘃𝗲𝗿𝘆 𝗗𝗲𝘃𝗢𝗽𝘀/𝗖𝗹𝗼𝘂𝗱 𝗲𝗻𝗴𝗶𝗻𝗲𝗲𝗿 𝘀𝗵𝗼𝘂𝗹𝗱 𝗸𝗻𝗼𝘄

Why Terraform + AWS?

Terraform is pretty much the go-to tool for infrastructure as code today, and AWS gives the perfect ecosystem to try out real-world use cases. It’s where most of us end up using it on the job anyway.

Join me on this journey
• If you’re new, this series might help you get started with a strong foundation.
• If you’re already experienced, maybe you’ll find some practical tips—or even share a few of your own.
• Either way, let’s learn in public together 🚀
I’ll be posting updates here on 𝗱𝗲𝘃.𝘁𝗼 and sharing insights along the way. Hopefully, by the end of these 30 days, we’ll all have a stronger Terraform + AWS toolkit 💪.

*Let’s do this! *