AWS with Terraform (Day 03)

 

Provisioning My First Real Resource (S3 Bucket)

Today was exciting. After two days of learning fundamentals like providers, versioning, and workflow, Day-03 was finally hands-on — provisioning my first actual AWS resource using Terraform: an S3 bucket.

No console clicks. No manual setup. Just clean Infrastructure as Code. This is the moment where Terraform stops being a theory and becomes real power.

Why Start with an S3 Bucket?

S3 is simple but fundamental. Almost every application touches S3 — for static hosting, logs, backups, artifacts, or data pipelines.

Starting with S3 makes sense:

  • Easy to understand

  • Clear outcome

  • Immediate feedback in AWS console

  • Perfect place to validate workflow

If IaC were learning to drive, this is starting the engine for the first time.

Environment Setup Before Coding

Inside VS Code, I opened my Day03 folder from the challenge repo and copied my existing main.tf from Day-02. Terraform detects any file ending with .tf, which keeps things flexible.

Before running Terraform, I ensured my AWS authentication was configured:

aws configure

Entered Access Key, Secret Key, Region, Output Format.
Tested it by listing buckets:

aws s3 ls

Credentials → Secure & ready. Never hardcode inside Terraform files.

Writing the Resource Block – Creating the S3 Bucket

Went to the Terraform Registry → searched aws_s3_bucket → copied example structure and customized it.

My sample code:

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

resource "aws_s3_bucket" "first_bucket" {
  bucket = "adnan-terraform-learning-bucket-demo"

  tags = {
    Name        = "MyFirstTerraformBucket"
    Environment = "dev"
  }
}

A couple things clicked for me here:

  • aws_s3_bucket = resource type

  • first_bucket = logical name for referencing

  • Bucket name must be globally unique

  • Tags make infra readable in production

Executing the Terraform Workflow

Inside terminal:

Init

terraform init

Downloads the AWS provider plugin & prepares working directory.

Plan

terraform plan

Dry run preview — shows + create action & exact resource details.

Apply

terraform apply

Confirmed with yes and within seconds…

S3 bucket created successfully in AWS Console 

There is something magical about seeing real infra appear from a few lines of code.

Understanding Change Detection & State

I updated a tag and ran plan again:

Name = "UpdatedBucketName"

Terraform showed:

~ update in-place

That symbol ~ now makes total sense — updating existing infra without recreating it.
State file tracks everything. Terraform compares real vs desired.

Destroying Infrastructure

Cleanup was simple:

terraform destroy

Bucket gone. Infra clean.
From creation → update → deletion — full lifecycle understood.

Day-03 Key Takeaways

ConceptLearning
ProvidersThe real engine behind cloud actions
terraform initPrepares plugins and backend
terraform planSafe preview of upcoming changes
terraform applyProvisions actual cloud resources
terraform destroyRemoves infra cleanly
State fileTracks reality vs configuration

Diagram



What’s Next?

Day-04 moves into more AWS resources and dependencies, building on this foundational victory.
Excited to scale up from single resources to complex architectures.

This journey already feels powerful — and this is just Day-03.

Final Thought

Creating infrastructure with zero console clicks felt like the true spirit of DevOps —
automation over manual, repeatable over risky, code over chaos.

Terraform is already proving its value.

See you in Day-04 

Here is the video link:


Comments

Post a Comment

Popular posts from this blog

AWS with Terraform (Day 01)

Image
  Terraform Fundamentals – Day 01 (My Learning Notes as a DevOps Engineer) Today I wrapped up Day-01 of my Terraform with AWS series, and even with my DevOps background, this session helped me tighten my fundamentals and rethink how I approach cloud provisioning. Terraform is something I’ve used before, but today was more about understanding why IaC matters at scale and why Terraform continues to dominate in real-world DevOps ecosystems. Understanding Infrastructure as Code (IaC) As a DevOps engineer, IaC is not new to me. But today’s session broke it down in a way that clarified its real value. IaC = Infrastructure represented as code. Instead of building resources manually through AWS/Azure/GCP consoles, we define everything in .tf files. This ensures our setup is predictable, repeatable, and version-controlled. What I liked most is how clearly the contrast was shown: Cloud-Agnostic Tools (Terraform / Pulumi) Work across AWS, Azure, GCP, Kubernetes, GitHub, etc. ...
Read more

AWS with Terraform (Day 02)

Image
  AWS with Terraform – Day 02 Deep Dive into Providers, Versioning & the Real “Bridge” Between Code and Cloud Today’s session took me from simply writing Terraform code to actually understanding the engine behind it — the Provider layer . And honestly, once this clicks, Terraform stops feeling like just a tool and starts feeling like a real engineering system. Here’s what I learned and how I’ve started applying it. Providers: The Plugin That Makes Terraform Real The simplest way I now understand it: Terraform writes the story. Providers translate it into cloud actions. Before today, I treated the provider block as just two lines of mandatory code. Now I see it as the translator that turns HCL into actual AWS API calls . Example: I write: resource "aws_s3_bucket" "demo" { bucket = "my-app-demo" } The AWS provider turns that into the exact S3 API request. This layer saves us from manually hitting APIs, building payloads, or juggling ...
Read more

AWS with Terraform (Day 06)

Image
Mastering Terraform File Structure: Best Practices for Scalable AWS Infrastructure as Code You've built your first AWS resources with Terraform in one big main.tf file. It works fine at first. But as your project grows, that single file turns into a mess. Resources pile up. Variables hide in plain sight. Debugging takes forever. Good news. You can fix this now. Split your Terraform files the right way. Follow HashiCorp's tips for a clean setup. This boosts readability. It helps teams work together. Plus, it scales for big AWS setups like VPCs, EC2s, and S3 buckets. Stick with me. You'll see hands-on steps to organize your root module today. The Anatomy of a Well-Organized Terraform Root Module The root directory acts as your Terraform project's heart. It's the root module. Here, you keep all key files. No strict rules exist for names. But smart choices make life easier. Start simple. Break one fat main.tf into focused files. This stops resource clutter. You n...
Read more