My tiny Flask app — just a “hello” page that showed my name and the current time — ran perfectly on my laptop. I wrote a Dockerfile, ran docker build -t myapp . and docker run -p 5000:5000 myapp, then opened http://localhost:5000 and there it was: clean, fast, mine. Confident that I’d cracked “build once, run anywhere,” I spun up a free-tier EC2 instance, installed Docker per the docs, pulled my image from Docker Hub, and ran the exact same command. The container started with no errors, but the page never loaded.

I sat watching the browser’s loading spinner and felt that familiar sinking realization — you thought you understood this, but you clearly don’t.

I really believed Docker would handle everything

At the start I was so confident. Docker had made my app portable, right? “Build once, run anywhere.” I’d read that sentence at least ten times. My laptop and the EC2 instance were both Linux under the hood (well, sort of — mine was Ubuntu). Same image, same command. What could possibly go wrong?

I genuinely thought the only difference was location. Local = laptop, cloud = faster and public. That was it.

That’s when the confusion kicked in

I SSH’d into the instance and checked the usual things:

• docker ps showed my container happily running

• docker logs looked identical to what I saw at home

• No crash, no permission errors, nothing

I even curled localhost:5000 from inside the EC2 instance and got the hello page instantly. So the app was alive.

But from my laptop, using the public IP and port 5000? Dead silence.

I spent the next forty minutes googling variations of “docker works locally but not on aws.” I restarted the container. I rebuilt the image on the server. I tried running it with sudo. I checked the Dockerfile for the hundredth time. Nothing changed.

This is where I got stuck. My brain kept looping: Docker is broken on EC2. Or maybe AWS hates me.

This is where I had to slow down

I forced myself to stop typing commands and actually think.

I asked one simple question: If the container is running and responding on the instance itself, where is the traffic getting blocked?

That single question shifted everything. I stopped looking inside Docker and started looking at the machine around Docker.

I remembered something I’d skimmed in the AWS console when I launched the instance — a box called “Security groups.” I had left it on default because… well, the launch wizard said “SSH is already allowed, you’re good.” I never touched it again.

Here’s what the system was actually doing

The security group is basically a cloud firewall. By default it says: “Only let traffic in on port 22 (SSH). Everything else? Denied.”

My laptop has no such firewall for localhost — I can talk to my own machine freely. But an EC2 instance lives in Amazon’s network, and Amazon is paranoid (for good reason). Every packet from the outside world has to be explicitly invited in.

Docker had done its job perfectly: it mapped port 5000 on the container to port 5000 on the host. The host was listening. But the cloud was standing at the door saying “nope.”

I had assumed the environment was the same. It wasn’t. The difference wasn’t Docker. It was the invisible layer I’d never thought about.

The moment it clicked

I went back to the AWS console, clicked on the security group, and added one rule:

• Type: Custom TCP

• Port: 5000

• Source: Anywhere (0.0.0.0/0) — just for learning, I know it’s not secure forever

I saved it, waited ten seconds, refreshed my browser… and there was my little hello page, glowing on the public internet.

I actually laughed out loud in my room. Not because it was clever, but because it was so simple. The fix took thirty seconds once I stopped blaming the tool.

These are the things that stayed with me

In the end I learned the hard but useful lesson behind the punchline: “It worked on my machine” is a confession, not a guarantee. Docker made my app portable, but it didn’t magically eliminate differences in networking, firewall rules, or how my app bound to interfaces. The container was running — the problem was that nothing outside the EC2 instance could reach the Flask server. Once I stopped assuming “same image = same environment” and methodically checked the layers (app bind address, Docker port mapping, EC2 security group, and host firewall), the fix was obvious and quick.

If you take anything away, let it be these practical points:

• Ensure your app listens on 0.0.0.0 (not 127.0.0.1) when running in a container.

• Confirm Docker port mappings (docker run -p host:container) and verify with docker ps

• Open the EC2 security group for the port you’re using (or use a load balancer/proxy on standard ports).

• Check the instance firewall (ufw/iptables) and test connectivity from inside and outside the machine (curl, nc).

• Automate environment parity (Docker Compose, CI builds, infrastructure as code) and add health checks so you catch these issues earlier.

Above all, stay humble and curious: debugging deployment problems teaches you more about the stack than an easy first run ever could.

By the time I reached Day 10, Terraform had already stopped feeling like a tool for “just creating resources.”
 Days 8 and 9 changed that mindset completely. Meta-arguments taught me how Terraform scales resource creation, and lifecycle rules taught me to respect change.

Day 10 took things one step further.
 This day wasn’t about adding more resources at all — it was about writing better Terraform.

Cleaner. Smarter. More intentional.

GitHub - ars0a/30-Days-Of-Terraform: This repo contains my journey where I learn Terraform from…
*This repo contains my journey where I learn Terraform from scratch and share my progress every single day. Each day has…*github.com

From Static Configs to Decision-Making Infrastructure

Up to now, most of my Terraform configurations were static. Variables helped, but the structure was still fairly rigid. Day 10 introduced the idea that Terraform configs can make decisions.

Conditional expressions were the first thing that clicked.

The syntax itself is simple:

condition ? true_value : false_value

But the impact is big. Suddenly, the same Terraform code can behave differently based on environment, region, or intent — without copying files or branching logic everywhere.

I started thinking less in terms of “dev code” and “prod code” and more in terms of one codebase that adapts.

Conditional Expressions — Small Logic, Big Clarity

What stood out to me wasn’t just that conditionals exist, but where they make sense.

Using them for things like instance sizes, monitoring flags, or resource counts felt natural. Instead of maintaining multiple versions of the same resource, Terraform now expresses intent clearly: if this condition is true, do this — otherwise, do that.

At the same time, Day 10 made something else clear:
 Not everything should be conditional.

When logic starts getting complex, it stops being readable. That’s when locals or higher-level structure is a better choice. This was an important balance to learn — just because Terraform allows logic doesn’t mean you should overuse it.

Dynamic Blocks — The First Time Duplication Really Disappeared

Dynamic blocks were probably the most satisfying part of Day 10.

Before this, repeating nested blocks felt unavoidable. Security group rules, IAM policies, route definitions — they all required copy-paste with minor changes. It worked, but it felt clumsy.

Dynamic blocks changed that.

Instead of repeating blocks, Terraform now generates them from data. A list or map defines the structure, and Terraform handles the repetition. Adding or removing rules becomes a data change, not a structural rewrite.

What I liked most here was how naturally this fits with variables. Infrastructure starts to look data-driven instead of hardcoded.

At the same time, I learned to be careful. Dynamic blocks are powerful, but they can hurt readability if overused. Day 10 reinforced an idea that keeps coming up: clarity matters more than cleverness.

Splat Expressions — Seeing Terraform Think in Lists

Splat expressions were quieter, but they completed the picture.

resource_list[*].attribute

This single line replaces loops, indexing, and manual extraction. Once I understood it, I started noticing how often Terraform deals with lists of things — instances, subnets, IDs, ARNs.

Splat expressions feel like Terraform saying:
 “I already know this is a collection — let me handle it.”

This made outputs cleaner, resource linking simpler, and overall configurations easier to read. It’s one of those features that doesn’t look impressive at first, but once you use it, you don’t want to go back.

Where I Got Stuck (and What I Learned)

The main friction on Day 10 wasn’t syntax — it was judgment.

When should I use a conditional vs a variable file?
 When does a dynamic block improve clarity, and when does it hide intent?
 Is this expression making the code better, or just more complex?

I found myself rewriting sections just to make them more readable. That process taught me that Terraform isn’t just about making things work — it’s about making them understandable to future you.

How Day 10 Connects to the Bigger Picture

Looking back, Day 10 ties together everything learned so far:

• Variables (Day 5) made configs flexible

• Modules (Day 6) made them structured

• Workspaces (Day 7) made them environment-aware

• Meta-arguments (Day 8) made them scalable

• Lifecycle rules (Day 9) made them safe

• Expressions (Day 10) made them intelligent

This was the day Terraform started to feel less like configuration and more like design.

What I Really Took Away from Day 10

Day 10 wasn’t about memorizing syntax. It was about learning how to express intent clearly in Terraform.

Conditional expressions taught me how to handle differences without duplication.
 Dynamic blocks showed me how to let data drive structure.
 Splat expressions helped me think in collections instead of individual resources.

Most importantly, I learned that good Terraform isn’t just correct — it’s readable, intentional, and maintainable.

Takeaway

Day 10 reinforced a simple idea:
 Terraform is powerful, but power needs discipline.

Expressions make Terraform flexible and expressive, but only when used thoughtfully. The goal isn’t to write clever configurations — it’s to write infrastructure that makes sense six months later.

This day felt less like learning a new feature and more like learning how to write Terraform properly.

I knew a load balancer distributes traffic to prevent any single server from becoming a bottleneck. I understood that Auto Scaling Groups (ASGs) dynamically adjust the number of instances based on demand. I’d read about private subnets shielding resources from the public internet and NAT gateways enabling outbound connections without exposing those resources. But reading is one thing; watching these elements collaborate to handle failures and spikes in load is entirely another.

This project was my opportunity to bridge that gap. I set out to deploy a simple web application on AWS using Terraform, focusing exclusively on networking, compute, scaling, and fault tolerance. No databases involved — just a stateless Django app running in Docker containers. The goal wasn’t to create a production-ready monolith but to observe how these components behave when pushed. I wanted to move from theoretical knowledge to empirical understanding, seeing the system self-heal and adapt in real time.

Designing the Foundation: Networking First

Every robust cloud architecture starts with a strong networking base, and in AWS, that means the Virtual Private Cloud (VPC). I began by provisioning a VPC with Terraform, ensuring DNS support and DNS hostnames were enabled. Why? Without these, even basic resolutions — like accessing the load balancer’s endpoint — could fail, leading to frustrating connectivity issues that derail the entire setup.

To infuse redundancy, I divided the VPC into four subnets: two public and two private, each spanning a different Availability Zone (AZ). This wasn’t arbitrary; AZs are physically isolated data centers within a region, so spreading resources across them ensures that a failure in one — like a power outage or network disruption — doesn’t take down the whole application. If AZ1 goes dark, AZ2 picks up the slack seamlessly.

The public subnets housed internet-facing resources: the Application Load Balancer (ALB) for handling incoming traffic and NAT Gateways for outbound connectivity from private resources. Meanwhile, the private subnets were dedicated to the EC2 instances running my web app. These instances were configured without public IP addresses, adhering to the principle of least privilege — exposing only what’s necessary to the outside world.

An Internet Gateway (IGW) was attached to the VPC to facilitate inbound and outbound traffic for public subnets. But the private EC2 instances still needed to reach the internet — for pulling Docker images from public repositories or fetching software updates. Enter NAT Gateways: I deployed one in each public subnet (one per AZ) to provide high-availability outbound routing. This setup routes traffic from private instances through the NAT, masking their origins and keeping them secure.

At this point, the networking layer felt tangible. Unlike my earlier toy projects with flat, single-subnet VPCs, this had deliberate separation of concerns, built-in redundancy, and a clear security posture. It was a foundation that screamed “enterprise-ready,” even for a modest app.

Putting the Load Balancer in Front

With the network skeleton in place, it was time to add the traffic director: the Application Load Balancer. Using Terraform, I configured the ALB to listen on port 80 (HTTP) and forward requests to a target group comprising my EC2 instances. The ALB was placed in the public subnets, making it the sole public entry point — users would never directly hit the backend servers.

Health checks were a critical detail here. I set them up on the root path (“/”) with a 200–299 success code threshold. This means the ALB periodically pings each instance; if it doesn’t get a healthy response, it stops sending traffic there. It’s a simple mechanism, but as I’d soon discover, it’s the linchpin for fault tolerance.

This configuration enhanced security by hiding the instances behind the ALB and improved resilience by intelligently routing around problems. Traffic flow: Internet → IGW → ALB → Healthy EC2 instances in private subnets. No direct exposure, no single point of failure — elegant in its simplicity.

Launch Templates and Auto Scaling

Behind the ALB, the real magic happens with the compute layer. I created a Launch Template to define the blueprint for EC2 instances: an Amazon Linux 2 AMI, t3.micro instance type (cost-effective for testing), appropriate security groups (allowing inbound from the ALB on port 80), and a user data script.

The user data script was the automation glue. On boot, it installed Docker, pulled my Django app image from Docker Hub, and ran the container with port mapping — exposing the app’s port 8000 to the host’s port 80. This ensured the ALB could communicate with the containerized app without fuss.

Next, the Auto Scaling Group. I configured it to use the Launch Template, spanning both private subnets (and thus both AZs). Minimum capacity: 1 instance; desired: 2; maximum: 4. Scaling policies were tied to CloudWatch metrics, specifically average CPU utilization. Scale out if CPU > 70% for 2 minutes; scale in if < 30% for 5 minutes. Warm-up and cooldown periods prevented rapid oscillations.

On paper — or in Terraform code — this looked flawless. But infrastructure as code is only as good as its runtime behavior. Would it actually scale under load? Handle failures gracefully? That was the litmus test.

Watching Health Checks in Action

After a terraform apply, the stack came to life. The ALB’s DNS name resolved in my browser, serving the Django app. Success! But digging into the AWS Console revealed a hiccup: one instance in the target group was marked “unhealthy.”

Panic set in briefly — was my config broken? Then, the ASG kicked in: it terminated the unhealthy instance and spun up a replacement. The new one initialized, passed health checks after a few cycles, and joined the pool.

The culprit? Bootstrapping time. The user data script took ~2–3 minutes to install Docker, pull the image (a few hundred MB), and start the container. During this window, health checks failed, triggering the ASG’s replacement logic. It wasn’t a bug; it was the system self-healing.

This moment was revelatory. High availability isn’t about perfection — it’s about detection and recovery. The infrastructure wasn’t brittle; it was resilient, proactively addressing issues before they impacted users.

Applying Load with Apache JMeter

Theory validated, now for scalability. I fired up Apache JMeter on my local machine to simulate traffic. Starting with 10 concurrent users ramping to 100, I hammered the ALB endpoint with GET requests.

At first… crickets. No new instances launched. CloudWatch showed CPU peaking at 40% — below my 70% threshold. Lesson learned: Scaling isn’t triggered by “busy-ness” alone; it’s metric-driven. The app was handling the load efficiently, so why add capacity?

To force the issue, I temporarily lowered the threshold to 50% and re-ran the test. CPU spiked, alarms fired, and the ASG bumped desired capacity to 3. I watched in the console as the new instance launched, bootstrapped, registered with the target group, passed health checks, and started receiving traffic. The ALB distributed requests evenly, CPU stabilized, and the system hummed.

It was exhilarating — seeing abstract concepts like “elasticity” manifest in logs and metrics.

Observing Scale-In and Connection Draining

Post-test, I halted JMeter. CPU plummeted, triggering the scale-in policy. But termination wasn’t abrupt: The ASG initiated connection draining, giving active sessions (up to 300 seconds) to complete before deregistering the instance from the ALB.

No dropped connections, no user disruption — just a graceful contraction. This underscored controlled scaling: Not just growing, but shrinking efficiently to optimize costs without chaos.

Understanding What “Highly Available” Really Means

Pre-project, I equated high availability with “multiple servers.” Now, I see it as a symphony of interdependent components:

• The ALB distributes load and enforces health, acting as the vigilant gatekeeper.

• The ASG monitors and adjusts capacity, replacing failures automatically.

• CloudWatch metrics and alarms provide the intelligence for proactive decisions.

• NAT Gateways ensure backend connectivity without compromising security.

• Private subnets enforce isolation, minimizing attack surfaces.

It’s about clear roles and failover paths. AZ failure? Traffic reroutes. Instance crash? Auto-replacement. Load surge? Scale out. Downtime? Minimal, if any.

The beauty is in the predictability — no heroics required; the system adapts quietly.

Closing the Loop

With testing complete, a terraform destroy wiped the slate clean, reclaiming resources and closing the experiment. This project transformed my perspective: Cloud architecture isn’t rote memorization of services — it’s designing for behavior under stress.

For aspiring DevOps engineers or cloud architects, I recommend this: Build it, break it, observe it. Documentation pales against the clarity of real-time metrics and auto-recovery in action. High availability isn’t a checkbox; it’s a lived experience that builds intuition for crafting truly resilient systems.

At first, it felt like a puzzle I could solve with enough trial and error. I’d Google the error messages, copy-paste fixes from Stack Overflow, and rerun everything. But nothing stuck. The container would crash again, and I’d feel that familiar frustration building. It wasn’t just the code; it was me, wondering if I was cut out for this Cloud stuff.

This happens a lot when you’re starting out in DevOps. You think the tools are the barrier—learning Kubernetes or Terraform seems daunting—but really, it’s the moments when things break that test you. And that’s where debugging comes in, or at least where I thought it did.

My Initial Belief About Debugging

I used to see debugging as a toolkit. Grab the right command, point it at the problem, and watch it resolve. In my mind, it was like being a mechanic: diagnose with kubectl describe or aws ec2 describe-instances, then fix with a tweak here or there. It made sense because that’s how tutorials present it. They say, “Run this to check logs,” or “Use that flag to inspect resources.”

I assumed that with enough practice, I’d memorize these commands and become efficient. Why wouldn’t I? In programming bootcamps, debugging is often reduced to breakpoints and print statements. Extending that to Cloud and DevOps felt logical—scale it up to infrastructure, but the process stays the same.

It felt reasonable because early successes reinforced it. When a script failed due to a missing environment variable, echo $VAR revealed the issue quickly. I’d pat myself on the back, thinking, See? Commands are key.

Where It Started Breaking

But then came this one deployment hiccup that wouldn’t budge. I was experimenting with a CI/CD pipeline on GitHub Actions, pushing code to an AWS ECR repository, then pulling it into an EC2 instance. Simple in theory. The build passed, the push succeeded, but the container on EC2 kept failing with a vague “permission denied” error.

I hammered away with commands: aws ecr describe-repositories, docker pull, sudo chmod on files. Nothing. The error persisted, mocking me. I even restarted the instance, thinking maybe it was a transient glitch. Hours slipped by, and I got confused—why weren’t the tools working?

The confusion deepened when I realized I was looping. I’d try a fix, fail, search for similar issues, apply another command, and repeat. It felt like chasing shadows. That’s when doubt crept in: Am I missing some advanced flag? Or is this just how DevOps is—endless firefighting?

Slowing Down and Thinking

Eventually, I stopped typing. I closed my terminal and just sat there, staring at the error message: “Error response from daemon: unauthorized: authentication required.” It was an auth issue, but I’d already checked my AWS credentials with aws configure list. They looked fine.

This is where I got stuck, but also where I started to shift. Instead of more commands, I asked myself basic questions. What assumptions was I making? I assumed the credentials were propagating correctly from my local setup to the EC2 instance. But why? Because I’d set them up once and they worked before.

I jotted down what I knew:

• Local pull worked fine.

• ECR policy allowed public pulls, but wait, was it public? No, I’d set it private.

• Instance role—did it have the right IAM permissions?

Step by step, I reasoned through the flow. The pipeline pushes to ECR using my personal access keys, but the EC2 pulls using its instance profile. Were they synced? I hadn’t explicitly attached the ECR read policy to the instance role.

It wasn’t a command that revealed this; it was tracing the mental model of how AWS auth works. I recalled from a video that instance roles are separate from user credentials. So, I visualized the chain: code commit → GitHub Actions (with secrets) → ECR push → EC2 pull (via role).

What the System Was Actually Doing

The system wasn’t broken; it was following rules I’d overlooked. ECR repositories default to private, requiring specific IAM policies for access. My instance role had basic EC2 permissions but nothing for ECR. So, when Docker tried to pull, it hit an auth wall—not because of bad commands, but because the identity wasn’t authorized.

In plain terms, it’s like trying to enter a locked building with the wrong key card. You can jiggle the handle (run commands) all day, but without questioning if you have access at all, you’re stuck outside. The error message was a symptom, not the cause. The real behavior was AWS enforcing least-privilege security, which is great in theory but invisible until you think about identities separately from actions.

I avoided diving into jargon here, but terms like “IAM role” popped up naturally in my head because they’re how Cloud systems think about trust. It’s not magic; it’s layered checks.

The Turning Point

What finally worked was simple, but it came from that pause. I logged into the AWS console—not to run commands, but to visually inspect the instance role. Sure enough, no ECR policy attached. I added AmazonEC2ContainerRegistryReadOnly, saved, and tried the pull again. It worked.

Why did it work? Because I addressed the assumption, not the surface error. The commands were secondary; I could have used CLI to attach the policy (aws iam attach-role-policy), but the insight was in realizing the mismatch between push and pull identities. That click happened when I drew a quick diagram on paper—arrows from GitHub to ECR to EC2, with question marks on the auth steps.

It wasn’t triumphant; it was relieving. And partial—I still wondered about best practices, like using temporary credentials. But it moved me forward.

What This Taught Me

• Assumptions hide in the setup: I learned that early configurations, like roles and policies, often cause downstream failures. It’s not about the debug command; it’s questioning if the foundation is solid.

• Thinking builds a map: By slowing down, I started seeing DevOps as interconnected systems, not isolated tools. Each piece affects others, and debugging is redrawing that map when it doesn’t match reality.

• Confusion is a signal: Getting stuck isn’t failure; it’s a prompt to step back. Rushing with commands often deepens the hole, while reflection uncovers the why.

• Simplicity over complexity: The fix was basic, but it required peeling away my rushed mindset. This makes me approach new setups with more caution now.

In the end, debugging in Cloud and DevOps isn’t about mastering a list of commands. It’s about cultivating patience to think through the invisible layers. I’m still a beginner, making plenty of mistakes, but these moments remind me that understanding grows from reflection, not speed. Next time something breaks, I’ll try to remember: pause first, assume less. What hidden assumption might be tripping you up right now?

A few months ago, I signed up for an AWS account. The promise of the cloud felt almost magical — servers I could spin up in minutes, no hardware to buy, just pay for what I use.

I launched my first EC2 instance, a tiny t2.micro, to practice deploying a simple Node.js app. I spent a Saturday afternoon on it: installed Nginx, cloned a repo, got everything running. When I was satisfied, I closed the SSH window and the AWS console tab. Done, I thought. Back to regular life.

Two weeks later, I opened an email from AWS. Subject line: “Your bill is ready.” It wasn’t a huge amount — maybe $12 — but it was money I hadn’t planned to spend. I stared at the breakdown, confused. The charges were almost entirely for “EC2: Running Hours.”

I hadn’t touched that instance in days. Why was it still costing me?

What I Believed About the Cloud

I had pictured “pay as you go” like electricity in an empty house. If no one’s home, the meter barely moves. I assumed that when I wasn’t actively using the instance — no SSH, no traffic, no processes I was running — the cost would drop to nearly zero.

The free tier reinforced that feeling. 750 hours a month sounded like more than enough for learning. I figured a single small instance left idle wouldn’t matter.

I also thought closing the browser or the terminal was enough to “pause” things. It felt intuitive — like logging out of a website.

The First Crack in That Picture

Logging back into the EC2 console, I saw the instance status: running. Green checks everywhere.

I clicked around. No obvious “power off” button that I remembered using. I started second-guessing myself. Had I forgotten to shut it down? Was there a setting I missed?

The billing dashboard showed a steady line of hourly charges, day after day, even though I hadn’t connected once.

That’s when the unease settled in. The system wasn’t broken. I had misunderstood something basic.

Trying to Understand What Was Actually Happening

Instead of panic-deleting everything, I slowed down.

I read the EC2 documentation carefully, line by line. I looked up blog posts from other beginners. I opened Cost Explorer and filtered to just that instance.

What I found was simple but jarring:

• An EC2 instance in “running” state is a virtual machine that is fully powered on, 24 hours a day, until I explicitly stop or terminate it.

• Being idle doesn’t reduce the compute cost. The clock keeps ticking because the provider is reserving CPU, memory, and network for me.

• The free tier gives 750 hours per month, but those hours are consumed whether I’m using the instance or not.

In other words, I had rented a server and left the lights on.

I ran a small experiment. I selected the instance and chose Stop. Within minutes, the compute charges stopped appearing. Storage (the EBS volume) still had a tiny cost, but the big hourly line went flat.

Then, feeling brave, I Terminated it. Everything disappeared. The cost line went to zero.

I launched a fresh instance, did a quick task, and terminated it immediately after. No surprise charges.

The Moment It Clicked

The shift wasn’t in finding a clever trick. It was realizing the cloud isn’t a magic utility that senses when I’m done. It’s infrastructure I control.

The responsibility for turning things off sits entirely with me.

No timeout. No gentle reminder. Just whatever state I last left it in.

That small realization changed how I see every resource now — instances, databases, storage buckets. They all have their own metering rules, and silence doesn’t equal free.

What This Experience Is Teaching Me

• Inactivity isn’t the same as off. Resources keep costing until I explicitly stop or delete them.

• Assumptions are expensive when untested. I filled a knowledge gap with intuition, and intuition was wrong.

• Early visibility matters. I now check the billing dashboard weekly, even when I think I’m being careful.

• Small habits prevent big surprises. I started adding calendar reminders or simple scripts to terminate test instances after a few hours.

I still don’t know everything about cloud costs — far from it. But this mistake forced me to confront a quiet assumption I didn’t even know I had.

Now, every time I launch something, I pause and ask: How long do I actually need this to stay on?

That question feels small. But it’s already saving me money — and, more importantly, it’s making me think more clearly about the systems I’m building on.

By the time I reached Day 9, Terraform had already started changing the way I think about infrastructure. Day 8 was a big moment — meta-arguments like count and for_each showed me how Terraform can generate infrastructure dynamically instead of forcing me to copy and paste blocks over and over again. It felt powerful, almost like programming infrastructure instead of just describing it.

But Day 9 slowed everything down.

It wasn’t about creating more resources or scaling faster. It was about understanding what really happens when infrastructure changes — and why Terraform sometimes behaves in ways that feel surprising if you’re not paying attention.

When a Small Change Is Not a Small Change

Up until this point, I had been making changes fairly casually. Modify a variable, tweak a resource, run terraform plan, apply, and move on. Most changes felt safe because Terraform handled them smoothly.

Then I hit a moment where a minor-looking update caused Terraform to plan a destroy and recreate action. Nothing was technically wrong, but it forced me to stop and think. If this were a production environment, that single change could have meant downtime or data loss.

That’s when it really clicked for me: Terraform doesn’t think in terms of “small” or “big” changes. It thinks in terms of state transitions. If a resource cannot be updated in place, Terraform replaces it. And it will do that confidently, unless you tell it otherwise.

How Terraform lifecycle rules protect resources, control replacement order, and manage change safely over time.

Discovering the lifecycle Block

Day 9 introduced the lifecycle block, and at first it looked deceptively simple. A few extra lines inside a resource definition didn’t seem like a big deal. But the more I experimented, the more I realized how much control this block gives you over Terraform’s behavior.

The first rule I explored was prevent_destroy. Adding it felt almost like putting a lock on a resource. Terraform didn’t stop managing it, but it refused to delete it without explicit intervention. The moment Terraform failed a plan because destruction was blocked, I understood its value.

A basic example:

resource "aws_s3_bucket" "example" {
bucket = "my-app-bucket"

lifecycle {
prevent_destroy = true
    }
}

Adding this immediately changed Terraform’s behavior. When I tried an operation that would delete the bucket, Terraform failed the plan instead of proceeding.

That failure wasn’t an error. It was Terraform protecting me from myself.

Thinking About What Should Never Be Deleted

Once I saw prevent_destroy in action, my mindset shifted. I started thinking less about how to build resources and more about which ones should never disappear automatically.

S3 buckets with data. Core networking components. Anything that holds state or traffic. These aren’t resources you want disappearing because of a refactor or an accidental variable change.

Terraform gives you power, but Day 9 made it clear that responsibility comes with it. Guardrails aren’t optional — they’re part of good infrastructure design.

Learning How Terraform Replaces Resources

Another important realization came from create_before_destroy. Before this, I hadn’t paid much attention to the order in which Terraform replaced resources. I assumed updates were mostly in-place.

Seeing Terraform destroy first and then create made me uncomfortable — and that discomfort was useful. It forced me to think about availability and continuity.

The create_before_destroy rule flips that order:

lifecycle {
create_before_destroy = true
}

Terraform now ensured the new resource existed before removing the old one.

1. Creates the new resource

2. Switches dependencies

3. Destroys the old one

This pattern is essential for high-availability setups and rolling replacements.

Using create_before_destroy changed the sequence completely. This wasn’t just a configuration tweak; it was a way of designing for reliability instead of hoping for it.

Accepting That Not All Drift Is a Problem

One of the quieter lessons of Day 9 came from ignore_changes. I noticed Terraform repeatedly trying to “fix” things that weren’t actually broken — tags modified manually, attributes adjusted by AWS itself.

At first, I thought Terraform was being strict. Later, I realized it was being honest. Terraform doesn’t know which changes matter unless you tell it.

That’s where ignore_changes helps:

lifecycle {
ignore_changes = [tags]
}

Using ignore_changes felt like acknowledging reality: not all infrastructure is perfectly controlled, and not all differences require correction. This was an important step toward using Terraform pragmatically instead of dogmatically.

How Day 9 Connected Everything Before It

Looking back, Day 9 made sense only because of the days before it.

Day 6 taught me to structure infrastructure using modules. Day 7 showed how environments should be isolated using workspaces. Day 8 explained how Terraform creates and orders resources dynamically. Day 9 tied all of that together by answering a harder question: what happens when those resources change over time?

Terraform wasn’t just building infrastructure anymore. It was managing its lifecycle.

What I Actually Learned

Day 9 didn’t teach me new commands as much as it taught me caution. It taught me to slow down and read terraform plan carefully. It taught me that Terraform will do exactly what you ask — even if that means deleting something important.

Lifecycle rules aren’t shortcuts or hacks. They are deliberate tools to make change safer, clearer, and more intentional.

This was the day Terraform stopped feeling like a convenience tool and started feeling like something that deserves respect.

Takeaway

Day 9 was about learning to control change instead of reacting to it. Terraform gives you the power to create, destroy, and replace infrastructure, but lifecycle rules help you decide when and how those actions should happen.

At this point in the journey, Terraform feels less like a script that builds infrastructure and more like a system that helps manage it responsibly over time.

Day 8 was one of those days where you suddenly see Terraform not just as a way to describe infrastructure, but as a tool that can generate it — based on patterns and inputs instead of copy-paste blocks.

Up until now, each AWS resource we created lived inside its own block. Want two S3 buckets? You wrote two blocks. Need three EC2 instances? That meant three resource definitions. That works at first, but as soon as you start thinking about scale, you see its limitations. On Day 8, I learned how Terraform’s meta-arguments — especially count, for_each, and depends_on — change that game entirely.

What Meta-Arguments Really Do

Meta-arguments are special arguments built into Terraform itself — not part of a provider like AWS. They let you control how many resources are created and in what order, without repeating block definitions.

How Terraform uses meta-arguments to dynamically create and order infrastructure.

Before Day 8, I might write:

resource "aws_s3_bucket" "bucket1" {
bucket = "my-app-bucket-1"
tags = var.tags
}
resource "aws_s3_bucket" "bucket2" {
bucket = "my-app-bucket-2"
tags = var.tags
}

That’s simple and clear — until you need ten buckets. It’s then that repetition gets ugly, error-prone, and hard to maintain.

Meta-arguments give you a better pattern.

Leveraging count for Repetition

The count meta-argument lets you turn one resource block into many:

resource "aws_s3_bucket" "buckets" {
count = length(var.bucket_names)
bucket = var.bucket_names[count.index]
tags = var.tags
}

Here’s what’s nice about this:

• One block generates multiple resources

• count.index gives each instance its place

• You can control names through variables

This makes the infrastructure elastic without duplication.

When for_each Makes More Sense

for_each is similar to count, but more stable when your list of values doesn’t map cleanly to numerical indexes.

resource "aws_s3_bucket" "buckets" {
for_each = toset(var.bucket_names)
bucket = each.value
tags = var.tags
}

This pattern is especially useful when:

• You need stable resource identity over time

• The order may change but you don’t want Terraform to recreate everything

• You derive the list from maps or sets

That predictability matters in production.

Controlling Dependencies with depends_on

Terraform usually figures out dependencies automatically — based on references in the code. But there are real scenarios where the order matters even when there’s no direct reference.

For example:

• An S3 bucket must exist before a policy attache

• A VPC must be fully created before subnets

• Custom IAM roles need to be in place before resources depend on them

In these cases, depends_on gives you explicit control:

resource "aws_s3_bucket" "example" {
bucket = "my-tf-bucket"
tags = var.tags
depends_on = [
aws_vpc.main
    ]
}

This forces Terraform to create the VPC before the bucket — even if otherwise they don’t depend on each other.

What This Changes in Your Terraform Workflow

By the end of Day 8’s exercise, a few clear shifts happened in my thinking:

• I no longer write the same resource block 5–10 times accidentally

• I treat Terraform like a mini programming language for infrastructure

• Dependencies become safer to manage, not accidents waiting to happen

• I see patterns in infrastructure that can be abstracted and repeated consistently

This is where Terraform starts feeling smart, not just convenient.

A Real-World Example (Beyond S3)

Imagine you’re provisioning multiple security groups, or spinning up clusters with a variable number of instances. With count or for_each, you can scale your HCL just like you scale resources:

• Create n subnets dynamically

• Generate multiple IAM users from a list

• Provision network ACLs for each AZ

• Build tags or naming conventions that adapt by environment or workspace

These patterns are the difference between a one-off script and infrastructure that grows with requirement changes.

Takeaway

Day 8 wasn’t just a lesson on Terraform syntax — it was about thinking differently:

1. count and for_each replace repetition with pattern-based infrastructure

2. depends_on gives you safety when implicit linking isn’t obvious

3. Terraform starts to feel like a declarative automation language, not just a config tool

Once you stop copying code and start writing patterns with meta-arguments, your infrastructure becomes cleaner, safer, and closer to real engineering.

By Day 7, Terraform usage starts to resemble real production workflows. You now have structured code, reusable modules, variables, and clean repositories. The next problem becomes obvious: how do you manage multiple environments without duplicating everything?

Development, staging, and production environments almost always need similar infrastructure with slightly different values. Day 7 focuses on Terraform workspaces, a feature designed to solve this exact problem by isolating state while reusing the same configuration.

The Environment Problem in Infrastructure as Code

Without a clear strategy, teams often handle environments by copying directories:

dev/
staging/
prod/

Each folder contains nearly identical Terraform code with small changes. This approach works initially, but it introduces serious problems:

• Code duplication

• Drift between environments

• Risky manual edits

• Difficult automation

Terraform workspaces offer a cleaner alternative by separating state, not code.

What Terraform Workspaces Actually Are

A Terraform workspace is a separate state associated with the same configuration.
The code stays the same, but Terraform tracks infrastructure independently for each workspace.

Conceptually:

• Same Terraform files

• Different state files

• Isolated infrastructure per environment

You can list workspace using:

terraform workspace list

Create a new one:

terraform workspace new dev

Switch between them:

terraform workspace select prod

Each workspace maintains its own state, which means changes in one environment never affect another.

Terraform Workspaces and Environment Isolation

How Terraform Uses Workspaces Internally

Terraform automatically exposes the active workspace name via:

terraform.workspace

This value becomes incredibly useful when combined with variables, locals, and naming logic.

For example:

locals {
environment = terraform.workspace
}

Now your infrastructure becomes environment-aware without extra configuration.

Using Workspaces for Resource Customization

Once the workspace name is available, it can influence resource behavior.

Example:

resource "aws_s3_bucket" "example" {
bucket = "my-app-${terraform.workspace}-bucket"

tags = {
    Environment = terraform.workspace
    }
}

With this setup:

• dev workspace creates my-app-dev-bucket

• prod workspace creates my-app-prod-bucket

Same code. Different infrastructure. Clean separation.

Workspaces and Remote State

When combined with a remote backend like S3, workspaces become even more powerful. Terraform automatically namespaces state files by workspace:

s3://terraform-state-bucket/project-name/dev/terraform.tfstate
s3://terraform-state-bucket/project-name/prod/terraform.tfstate

This ensures:

• No state collisions

• Safe parallel usage

• Clean environment isolation

This pattern is commonly used in real-world Terraform deployments, especially when paired with CI/CD pipelines.

When Workspaces Make Sense (and When They Don’t)

Workspaces are excellent for:

• Environment separation (dev, staging, prod)

• Small-to-medium projects

• Teams sharing the same codebase

They are not ideal for:

• Completely different architectures per environment

• Very large organizations with strict account separation

• Scenarios requiring separate Terraform repos

Understanding this trade-off is part of using Terraform responsibly.

The Real Lesson of Day 7

Day 7 isn’t about memorizing workspace commands. It’s about thinking in environments.

Instead of writing different code for different environments, you design infrastructure that:

• Adapts based on context

• Isolates risk through state separation

• Encourages consistency

That mindset is what allows Terraform to scale beyond personal labs into real systems.

Takeaway

Day 7 introduced a critical Terraform capability:

1. Workspaces separate state, not code

2. The same configuration can safely manage multiple environments

3. Combining workspaces with variables and remote state enables production-grade workflows

With workspaces, Terraform moves from “infrastructure provisioning” to environment management — a key milestone in any DevOps journey.

By Day 6, Terraform starts to demand a different mindset.
Up until now, writing everything in a single directory worked fine. Variables improved flexibility, remote state improved reliability, but the structure was still flat. That approach breaks down quickly as infrastructure grows.

Day 6 was about Terraform modules — not as a feature, but as a design philosophy. This is the day where Terraform stops feeling like configuration files and starts behaving like a real infrastructure framework.

Why Modules Exist at All

Without modules, Terraform encourages repetition. You define the same VPC logic, security groups, or tagging patterns again and again across environments. That repetition creates drift, inconsistency, and eventually fear of change.

Modules solve this by introducing encapsulation. They allow you to define infrastructure once and reuse it everywhere with different inputs. Instead of copying code, you compose infrastructure.

This mirrors good software design:

• Functions instead of duplicated logic

• Interfaces instead of hardcoded values

• Inputs and outputs instead of hidden assumptions

What a Terraform Module Really Is

At its core, a module is just a directory with Terraform files. There’s no special syntax, no magic wrapper. Terraform treats any directory with .tf files as a module.

A typical module structure looks like this:

Day-6/
├── main.tf
├── variables.tf
├── locals.tf
├── outputs.tf
├── providers.tf
└── modules/
└── vpc/
├── main.tf
├── variables.tf
├── outputs.tf

Inside the module, resources are defined normally. What changes is how values enter and leave the module.

Defining Inputs and Outputs

Modules communicate through variables and outputs. This explicit interface is what makes them safe and reusable.

Inside a VPC module, you might see:

variable "cidr_block" {
type = string
}
resource "aws_vpc" "this" {
cidr_block = var.cidr_block
}

And an output:

output "vpc_id" {
value = aws_vpc.this.id
}

The module itself doesn’t care where it’s used. It only knows what inputs it receives and what outputs it exposes. That separation is intentional and powerful.

Using a Module from the Root Configuration

At the root level, modules are called explicitly:

module "vpc" {
source = "./modules/vpc"
cidr_block = "10.0.0.0/16"
}

This is where composition happens. The root module orchestrates infrastructure by wiring together smaller, focused modules. Each module solves one problem well.

If you need multiple VPCs or environments, you don’t rewrite the module. You reuse it with different inputs.

Why This Changes Everything

Modules force discipline. They push you to:

• Separate concerns

• Define clear boundaries

• Avoid hidden dependencies

• Treat infrastructure like reusable building blocks

They also make Terraform safer. When logic lives in one place, fixes and improvements propagate automatically. When something breaks, you know where to look.

From a team perspective, modules enable collaboration. One person can maintain networking modules while another consumes them without needing to understand every internal detail.

Local vs Remote Modules

Day 6 typically starts with local modules, sourced from directories in the same repo. That’s intentional. It builds understanding before introducing complexity.

Later, these same modules can live in:

• Git repositories

• Versioned module registries

• Shared internal platforms

The interface stays the same. Only the source changes.

That consistency is one of Terraform’s strongest design decisions.

The Mental Shift of Day 6

The biggest takeaway from Day 6 wasn’t syntax. It was architectural thinking.

Instead of asking:

“How do I create this resource?”

You start asking:

“How do I design this so it can be reused safely?”

That’s the difference between infrastructure that works today and infrastructure that scales tomorrow.

Takeaway

Day 6 introduced the idea that Terraform is not about writing files — it’s about composing systems.

• Modules encapsulate infrastructure logic

• Variables and outputs define clean interfaces

• Reuse replaces duplication

• Structure replaces chaos

Once you start thinking in modules, every Terraform project becomes easier to reason about, safer to change, and far more professional.

This is where Infrastructure as Code begins to feel like engineering, not configuration.

GitHub - ars0a/30-Days-Of-Terraform: This repo contains my journey where I learn Terraform from…
*This repo contains my journey where I learn Terraform from scratch and share my progress every single day. Each day has…*github.com

The First Bill That Changed Everything

It was small about $8 but it shook me. I had been careful, or so I thought. I’d only spun up a few virtual machines, stored some files, and run a couple of experiments. Nothing extravagant.

Yet there it was: charges for data transfer, storage, and something called a NAT gateway that I barely remembered creating.

I spent an evening digging through the billing dashboard, trying to match line items to my actions. That was the moment the “free” part started to feel conditional.

Patterns That Appear Only With Practice

Over the next year, as I kept practicing — building small projects, tearing them down, making mistakes, rebuilding — I began to see patterns.

The surprises weren’t random; they followed predictable rules that weren’t obvious from the promotional pages. The free tier wasn’t a trap, but it also wasn’t a blanket safety net. It had gaps, and those gaps taught me more about cloud economics than any tutorial ever could.

Idle Resources: The Silent Meter

One of the earliest patterns I noticed was around idle resources.

I’d launch a virtual machine to test something, get distracted, and forget about it. A few days later I’d see it still running. The free tier in AWS, for example, gives you 750 hours per month of t2.micro or t3.micro usage. That sounds like a lot — roughly one instance running continuously.

But if you launch two instances, even small ones, the hours add up across all of them. The meter runs on total usage, not per instance. I learned this the hard way when I left a second instance running for a weekend “just in case” I needed it.

Storage Isn’t Just About Space

Storage works similarly.

You get a certain amount of free object storage (like S3 or Cloud Storage), but every object you upload counts until you delete it. I once created multiple buckets while experimenting with static websites, forgot to empty them, and slowly accumulated gigabytes.

The storage itself stayed free for a while, but retrieval requests and eventual overflow pushed me over the limit.

Region Choices Have Real Costs

Region mistakes were another recurring surprise.

I initially assumed pricing and free tier eligibility were consistent across the world. They’re not. Some services have different limits or costs depending on the region.

More importantly, data transfer between regions — or out to the internet — often costs money, even when the compute or storage is free. I once deployed a small database in a region close to me for lower latency, then copied data from a tutorial bucket in a US region. The egress charges appeared quietly in the bill.

The cloud providers optimize their infrastructure regionally, so moving data across those boundaries has a real cost for them, which they pass on.

Resources That Charge Just for Existing

Another subtle one: certain resources have minimum charges regardless of usage.

NAT gateways and load balancers, for example, bill by the hour they exist, not just when traffic flows through them. I created a NAT gateway while following a guide on private subnets, then deleted the tutorial environment but forgot that one piece.

It sat there, idle, costing a few cents per hour — enough to add up over a month.

What “Free Tier” Actually Means

Through all these small incidents, my understanding evolved from “free means zero cost” to “free means heavily discounted with sharp edges.”

The system is logical once you see it: providers want to attract learners and startups, so they subsidize common learning workloads. But they also need to protect themselves from abuse and cover real infrastructure costs.

The free tier boundaries are drawn where typical experimentation ends and production-like usage begins. Idle high-bandwidth resources, cross-region data movement, and long-lived networking components all resemble production patterns more than learning ones, so they fall outside the subsidy.

The Trade-Offs Nobody Talks About

There are trade-offs, of course.

The free tier encourages hands-on practice, which is invaluable. Without it, far fewer people would learn cloud skills. But it also trains a kind of vigilance early on.

You learn to check regions deliberately, to tag resources, to set reminders or scripts to clean up. The alternative — truly unlimited free usage — would either bankrupt the providers or force them to impose heavy restrictions that would hurt learning more than occasional small bills do.

How This Changed My Approach to Cloud Work

This experience quietly changed how I approach cloud work.

I no longer assume an action is free just because I’m on a new account. I check the pricing page for the specific service and region before I click “create.” I make a habit of reviewing running resources every few days.

I even started using the billing alarms that most providers offer — simple thresholds that email you if spending crosses a limit. None of this feels like extra work anymore; it feels like part of understanding the platform.

The Real Value of Those Small Bills

Looking back, those small unexpected bills were some of the most effective teachers I had. They carried real-world consequences — not large enough to hurt, but enough to focus attention. The fear of another surprise charge made me read documentation more carefully, ask better questions, and notice details I’d previously skimmed over.

In a way, the hidden costs of the free tier aren’t hidden at all once you’ve paid them a few times. They’re just the tuition for learning how cloud pricing actually works.

By Day 5 of this journey, you’ve already stood up infrastructure, handled remote state, and built a foundation of reusable Terraform configurations. But real Infrastructure-as-Code isn’t just about what you build — it’s about how flexibly you build it.

Day 5 was all about variables — input, output, and locals — and how they give your configurations real muscle. Instead of hardcoding values everywhere, you learn to write Terraform that adapts, scales, and responds to different environments or use cases without changing the code itself. This shift — from static definitions to dynamic infrastructure — changes how you think about IaC forever.

Why Variables Matter

In your early days with Terraform, you probably hardcoded simple values like CIDR blocks, bucket names, or instance sizes. That’s fine for a lab. But once you start building real environments — dev, staging, prod — hardcoding becomes a liability: it requires copy-paste, invites errors, and makes maintenance painful.

Variables let you write one configuration that can behave differently depending on context. They turn Terraform from a single-purpose script into a reusable definition of intent.

The official curriculum for Day 5 lists the key areas covered: input variables, output variables, locals, variable precedence, and variable files (*.tfvars). All of these pieces come together to make your code reusable and safe at scale.

Input Variables — Your Terraform Knobs

The simplest form of variability in Terraform comes from input variables. These let you parameterize your configuration without rewriting code. A basic variable definition looks like this:

variable "region" {
    description = "The AWS region to deploy into"
    type = stringdefault = "us-east-1"
}

This declares a named variable with a type and a default. When you run Terraform, you can override the default using a .tfvars file or command-line flags.

For instance, a terraform.tfvars file might contain:

region = "us-west-2"

This pattern decouples values from logic, making your configs far more flexible. It also lets teammates or automation pipelines inject values without touching code.

Output Variables — Sharing Useful Data

Once resources are created, you often want to expose information from them — maybe an IP, a DNS name, or a resource ARN. Terraform’s output variables are designed precisely for that.

Here’s a typical output:

output "vpc_id" {
    description = "The ID of the created VPC"
    value = aws_vpc.example.id
}

By exposing outputs, you turn Terraform into not just a builder of infrastructure, but a data provider. Outputs can feed other automation, be shown to users, or be passed into remote systems in CI/CD pipelines.

Locals — Refactoring and Reuse

When you find yourself repeating expressions or values derived from multiple variables, Terraform’s locals help you collapse that repetition into a single source of truth.

For example:

locals {
    common_tags = {
    Environment = var.environment
    }
}

You can reference local.common_tags anywhere. This isn’t just a convenience — it reduces duplication, minimizes risk of drift, and makes refactoring safer.

Variable Precedence and Files

Terraform evaluates variables in a well-defined order: defaults, environment variables, .tfvars files (like terraform.tfvars), and command-line flags. Understanding this precedence lets you design configurations that behave predictably in different contexts — local development, automated tests, or production pipelines.

Variable files (*.tfvars) let you maintain separate configurations for dev vs prod without changing any HCL. They’re especially useful in automation, where different environments need different inputs but share the same underlying module logic.

How This Changes Your Mental Model

What made Day 5 a real shift wasn’t just learning syntax, but the intent behind variables:

• They detach environment-specific settings from code

• They encourage reuse and modular design

• They make automation robust, predictable, and safe

With variables, your Terraform configurations stop being brittle scripts and start looking like declarative interfaces to infrastructure.

Takeaway

Day 5 was where Terraform truly began to feel like real Infrastructure-as-Code:

1. Input variables let configurations adapt without rewriting code.

2. Outputs and locals make data reusable and configurations reusable.

3. Understanding variable precedence and tfvars makes environments manageable and pipelines reliable.

Once you think in terms of inputs and outputs instead of hardcoded values, Terraform stops being a set of commands and becomes a framework for predictable, reusable, and automated infrastructure.

#Terraform #DevOps #AWS #IaC #30DaysOfTerraform #InfrastructureAsCode

By Day 4, I already know how to define AWS resources in Terraform and apply them. But real infrastructure work depends on something deeper: state. Terraform’s internal snapshot of your infrastructure determines what exists, what needs to change, and what should be destroyed. Understanding how state works, why it matters, and how to manage it beyond local files becomes a pivot point in any serious Terraform workflow.

If Day 3 was about building resources, Day 4 was about trusting them.

Why Terraform State Matters

At first glance, Terraform seems straightforward: declare resources and let Terraform create them. Under the hood, Terraform needs a way to track infrastructure across runs. It does that through the state file, a structured map of resource metadata that tells Terraform what’s already deployed and how future changes should be applied.

Local state works while you’re experimenting alone. The moment you introduce collaboration, CI/CD pipelines, or long-lived environments, storing state on your laptop stops being viable. On Day 4, I moved that state into AWS using an S3 backend. It’s a small change in configuration, but a major change in how Terraform workflows behave in a team environment.

What Terraform State Really Is

Every terraform apply updates a file called terraform.tfstate. This file maps your HCL configuration to real cloud resources. Think of it as Terraform’s memory. Without it, Terraform would have to guess what exists, and that’s unacceptable in any production environment.

The file contains:

• Resource identifiers (like VPC IDs, bucket names, etc.)

• Resource relationships and dependencies

• Computed values and outputs

• Provider and metadata information

This allows Terraform to compute accurate diffs during plan and execute safe updates during apply or destroy. Commands like terraform plan and terraform destroy rely entirely on this file.

By default, it lives locally as:

terraform.tfstate
terraform.tfstate.backup

Fine for a solo lab. Not fine for a multi-developer environment.

Architecture at a Glance

Here’s the architecture I used on Day 4:

• Terraform CLI: local execution and configuration

• AWS S3: remote backend for the terraform.tfstate

• AWS resources: VPCs, S3 buckets, etc.

How it fits together:

1. Backend configuration tells Terraform where to store state.

2. terraform init sets up the backend and migrates existing state.

3. plan and apply use the remote state for consistent diffing and changes.

Terraform operates locally as the control plane, but its memory — the state — lives in S3 where it’s shared, durable, and safely accessible.

Setting Up a Remote Backend in Code

Here’s the backend block I used:

terraform {
    backend "s3" {
    bucket = "aditya-tf-day3-3d879655"
    key = "dev/terraform.tfstate"
    region = "us-east-1"
    encrypt = true
    use_lockfile = true
    }
}

This tells Terraform to push its state into the S3 bucket under the dev/terraform.tfstate key. encrypt = true ensures encryption at rest. use_lockfile = true introduces native locking so multiple operations don’t collide.

After running:

tf init

Terraform prompted me to migrate my existing local state, then initialized successfully. From this point onward, tf plan and tf apply behave the same, but now with shared state stored in AWS is ideal for any real DevOps pipeline.

Resources and the Code That Matters

After configuring the backend, I created real AWS resources:

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

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

I also created a bucket with a generated suffix for uniqueness:

resource "random_id" "suffix" {
byte_length = 4
}

resource "aws_s3_bucket" "example" {
bucket = "aditya-tf-day3-${random_id.suffix.hex}"
force_destroy = true
}

Two practical lessons here:

• Terraform doesn’t need hard-coded names generated IDs to avoid conflicts.

• force_destroy = true lets Terraform delete buckets even when objects exist.

This style of writing infrastructure feels natural once you start thinking declaratively: define intent, let Terraform translate it into API calls.

Small Insights That Matter

Terraform’s state file isn’t just a bookkeeping tool it’s the source of truth. With a remote backend, Terraform doesn’t recreate resources unnecessarily because it checks state first. That’s more than convenient; it’s the safety layer that keeps teams from stepping on each other’s work.

Another insight from Day 4: S3 as a backend isn’t just storage. With locking enabled, Terraform avoids race conditions when two users apply changes at the same time. That capability alone makes remote state mandatory for any serious deployment workflow.

Takeaways from Day 4

By the end of the day, I hadn’t just written more HCL I had changed how Terraform relates to infrastructure. Moving state into S3 gave me shared, durable Terraform memory. I saw how backend configuration interacts with AWS during initialization and planning, and I deployed real resources while watching Terraform track them reliably through state.

Day 4 was about mastering state, not just creating resources and that’s a turning point in understanding how Terraform scales beyond a personal lab.

GitHub - ars0a/30-Days-Of-Terraform: This repo contains my journey where I learn Terraform from…
*This repo contains my journey where I learn Terraform from scratch and share my progress every single day. Each day has…*github.com

See you tomorrow…

By Day 3 of working with Terraform, the focus naturally shifts from writing configuration to understanding behavior. Provisioning an S3 bucket or a VPC is not the hard part. The real learning starts when something fails, partially succeeds, or behaves differently than expected.

This day was about building AWS infrastructure with Terraform, but more importantly, about understanding how Terraform thinks: how it plans, applies, tracks state, and reacts to failure. That mental model is what separates copy-paste infrastructure from reliable Infrastructure as Code.

The Architecture: Simple by Design, Intentional by Choice

The architecture for Day 3 was deliberately minimal:

• An AWS VPC, representing foundational network infrastructure

• A private S3 bucket, representing a globally scoped AWS resource

• Terraform state managing both resources

Terraform acting as the control plane, provisioning and managing AWS VPC and S3 resources through the AWS provider.

There is no direct dependency between a VPC and an S3 bucket, and that’s precisely why this setup is useful. It allows Terraform’s execution model to be observed clearly. Each resource exists independently, yet both are governed by the same state file. That shared state is what ties everything together.

Terraform’s job is not to “run commands” against AWS. Its job is to continuously reconcile three things: configuration, state, and real infrastructure. Once you see Terraform through that lens, many confusing behaviors start making sense.

Writing the Configuration

The starting point was straightforward. An AWS provider and a basic VPC definition:

provider "aws" {
region = "us-east-1"
}
resource "aws_vpc" "example" {
cidr_block = "10.0.0.0/16"
}

Nothing unusual here. The complexity emerged with S3.

Unlike most AWS resources, S3 buckets live in a global namespace. A name that looks unique locally may already exist somewhere else in the world. This is where many Terraform beginners get stuck, and where Terraform’s behavior becomes educational.

An initial hardcoded bucket name predictably failed with aBucketAlreadyExists error. Terraform stopped execution, but it did not roll anything back. The VPC, if already created, remained. This is not a bug. It’s a design decision.

Terraform is declarative, not transactional.

Solving the S3 Naming Problem Properly

The correct solution is not to keep guessing bucket names. The correct solution is to design uniqueness into the configuration.

Terraform provides a clean way to do this using the random provider:

resource "random_id" "suffix" {byte_length = 4}
resource "aws_s3_bucket" "example" {
bucket = "aditya-tf-day3-${random_id.suffix.hex}"

tags = {
    Name = "My bucket"
    Environment = "Dev"
    ManagedBy = "Terraform"
    }
}

This approach guarantees global uniqueness while keeping names readable and predictable. The important detail is that random_id is stable once created. Terraform does not regenerate it on every apply. That stability is what allows consistent infrastructure over time.

Adding this resource also surfaced another subtle concept: provider management. Introducing random_id required running terraform init -upgrade to sync the dependency lock file. Terraform is strict here by design, and that strictness pays off in long-term reproducibility.

State Is the Real Engine

One of the most important lessons from Day 3 was how Terraform state behaves during partial failures.

If Terraform successfully creates a VPC but fails to create an S3 bucket, the state file reflects exactly that. On the next run, Terraform does not “start over.” It resumes. The plan only includes what is missing or drifted.

The same applies to updates. When tags were added to the existing VPC, Terraform detected the difference and planned an in-place update. No recreation. No downtime. Just a controlled change reflected cleanly in state after apply.

This is why terraform plan is non-negotiable. It is not a suggestion. It is the single most accurate description of what Terraform is about to do.

Destruction Is Just Another State Transition

Running terraform destroy is not a special mode. It is simply another plan, with the desired end state being “nothing.” Terraform destroys only what exists in state, in a safe order, with explicit confirmation.

That predictability is what makes Terraform safe to use at scale.

GitHub - ars0a/30-Days-Of-Terraform: This repo contains my journey where I learn Terraform from…
*This repo contains my journey where I learn Terraform from scratch and share my progress every single day. Each day has…*github.com

Takeaway

Day 3 reinforced a critical truth: Terraform is less about writing .tf files and more about understanding state-driven change.

By working through real failures, name collisions, provider mismatches, and in-place updates, the infrastructure stopped feeling magical and started feeling mechanical — in the best possible way. Once you trust the plan, respect the state, and design for uniqueness and clarity, Terraform becomes a reliable system rather than a fragile tool.

That shift in mindset is where real DevOps learning begins.

Continuing my journey into the #30DaysOfAWSTerraform challenge, Day 2 shifted from conceptual foundations into the first real Terraform building blocks — providers, configuration blocks, and declaring resources.

If you are new to this series, Day 1 focused on understanding what. Terraform is, Infrastructure as Code, and the basic Terraform workflow.

Day 2 moves one level deeper. This is where Terraform stops being just configuration files and starts behaving like a system that expects discipline.

Terraform Providers: How Terraform Talks to the Cloud

Terraform does not communicate with AWS, Azure, or any cloud platform directly.
It relies on providers.

Providers translate Terraform configuration into cloud API calls.

A provider is essentially a plugin that understands how to translate Terraform configuration into cloud-specific API calls. When we say Terraform is cloud-agnostic, providers are the reason why.

Without a provider — Terraform is just a language and a workflow.
With a provider — Terraform becomes capable of creating real infrastructure.

A simple provider configuration looks like this

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

This tells Terraform which cloud platform to talk to and where. At this point, Terraform still doesn’t know which version of the provider it should trust. That question becomes important very quickly.

Terraform Core Version vs Provider Version

One of the first confusing things on Day 2 is realizing that Terraform itself has a version, and providers also have their own versions.

They are related, but they are not the same.

• Terraform core version
  This is the Terraform CLI you install on your machine. It controls how Terraform parses files, builds dependency graphs, and executes plans.

• Provider version
  This controls how Terraform interacts with a specific platform, such as AWS APIs.

Terraform core is the engine.
Providers are the plugins.

This separation gives flexibility, but it also introduces risk if versions are not managed properly.

Terraform Core and providers are versioned independently.

Why Versioning Matters in Terraform

A natural question at this stage is:
Why not just use the latest version of everything?

The answer becomes clear when you think about Infrastructure as Code seriously.

Cloud APIs evolve. Providers evolve. Behavior changes. If Terraform silently upgrades a provider, your infrastructure could behave differently without you changing a single line of code.

That breaks one of the core promises of IaC: predictability.

Terraform’s solution to this problem is explicit version control.

Version Constraints: Making Infrastructure Predictable

Terraform allows you to define version constraints using the terraform block.

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

This block does several important things at once:

• Ensures Terraform runs only on compatible CLI versions

• Locks the provider to a safe version range

• Prevents accidental upgrades that could introduce breaking changes

Terraform evaluates these constraints during terraform init.
If versions don’t match, Terraform refuses to proceed.

This may feel strict at first, but it’s intentional.

Understanding Version Constraint Operators

Terraform supports several operators for version constraints, but the most commonly used ones are:

• = → exact version

• >= → minimum acceptable version

• ~> → pessimistic constraint

The ~> operator is especially important:

version = "~> 5.0"

This allows updates within the same major version (for example, 5.1, 5.2) but blocks breaking changes like 6.0.

In practice, this strikes a balance between:

• Stability

• Receiving safe improvements and fixes

This is why you’ll often see ~> recommended in real Terraform codebases.

Resource Blocks: Where Infrastructure Is Actually Defined

Once the provider is configured and version constraints are in place, Terraform is finally ready to describe real infrastructure. This is done using resource blocks.

A resource block defines what Terraform should create and what the desired state should look like. Terraform does not create anything immediately; it records intent and acts only when the workflow is executed.

resource "aws_instance" "example" {ami = "ami-0c02fb55956c7d316" # Amazon Linux 2 (us-east-1)instance_type = "t2.micro"

tags = {Name = "Terraform-Day2-EC2"Environment = "Learning"}}

In this block:

• aws_s3_bucket is the resource type provided by the AWS provider

• example is a local name Terraform uses to track this resource

• The configuration inside the block describes the desired state

What’s important is the dependency chain here. Resource blocks rely on providers. Without the AWS provider being configured and versioned correctly, Terraform would not know how to interpret or create this resource.

This is where the earlier discussion about providers and versions becomes concrete.

Providers define how Terraform talks to the cloud.

Resource blocks define what Terraform wants to exist.

Providers and Modules: Where Versions Belong

Once providers and versions enter the picture, another design question appears:
Should provider configuration live inside modules or outside?

The recommended approach is:

• Provider configuration and version constraints live in the root module

• Reusable modules only declare which providers they require, without pinning versions

Inside a module, you might see:

terraform {
        required_providers {
        aws = {source = "hashicorp/aws"
        }
    }
}

This keeps modules reusable across

Different regions

Different accounts

Different provider versions

Version control stays centralized and intentional.

Provider configuration belongs in the root module.

Best Practices That Start Making Sense on Day 2

Day 2 makes several Terraform best practices feel logical rather than arbitrary:

• Pin provider versions early

• Never rely on implicit “latest” versions

• Keep provider configuration in the root module

• Treat Terraform code like application code, not scripts

• Let terraform init enforce consistency

These practices matter more as infrastructure grows and more people interact with the same codebase.

What Changed for Me on Day 2

Day 1 made Terraform understandable.
Day 2 made Terraform serious.

Providers and version constraints introduced the idea that Infrastructure as Code is not just about automation, but about control and predictability over time.

Terraform started feeling less forgiving, and that’s exactly why it’s trusted in real systems.

Closing Thoughts

Day 2 didn’t add much visible infrastructure, but it added something more important: structure.

Understanding providers and version management early prevents subtle problems later, when real resources and real costs are involved.

Huge thanks to Piyush Sachdeva for designing the challenge in a way that builds understanding before complexity.

This challenge is slowly reinforcing the idea that good infrastructure isn’t just created, it’s maintained intentionally.

Introduction

I’ve clicked buttons in the AWS console before. A lot of them.
Sometimes things worked, sometimes they didn’t, and most of the time I couldn’t confidently explain why something was set up the way it was.

That’s one of the reasons I decided to start the #30DaysOfAWSTerraform challenge.

Day 1 wasn’t about deploying servers or writing complex code. It was about slowing down and understanding what Infrastructure as Code really means, and why tools like Terraform exist in the first place. This post is a reflection of what clicked for me on Day 1, and what still feels a little unclear.

What Is Terraform?

Terraform is a tool that helps create and manage cloud infrastructure using code instead of manual steps in the cloud console.

Instead of repeatedly clicking through AWS to create servers, networks, or databases, we write configuration files that describe the infrastructure we want. Terraform then reads this code and takes care of creating or updating resources for us.

This approach reduces manual effort and makes infrastructure easier to manage, especially as systems grow.

Infrastructure as Code (IaC)

This way of managing infrastructure is known as Infrastructure as Code (IaC).

IaC means treating infrastructure the same way we treat application code:

• It can be stored in version control

• It can be reused

• It can be recreated whenever needed

If something breaks or needs to be rebuilt, the same code can be used again instead of setting everything up manually from scratch. This makes infrastructure more consistent and reliable.

Cloud-Agnostic Nature of Terraform

One interesting thing about Terraform is that it is cloud-agnostic.

This means Terraform itself is not limited to AWS. It can also work with Azure, GCP, and many other platforms. Terraform does this using providers.

A provider tells Terraform which cloud platform it should communicate with. For example, the AWS provider allows Terraform to interact with AWS services. Providers act as a bridge between Terraform and the cloud.

How Terraform Thinks and Works

Terraform follows a declarative approach. Instead of telling Terraform how to build infrastructure step by step, we describe the final state we want.

We define what resources should exist, and Terraform figures out how to reach that state.

Terraform also maintains a state file, which keeps track of the resources it manages. This state helps Terraform understand what already exists and what needs to change. The internal working of the state file is still a bit confusing to me, but I expect it will become clearer as I move forward in this challenge.

Terraform Workflow (The Core Commands)

Every Terraform project follows a basic workflow:

terraform init

This command initializes the project. It downloads required provider plugins and prepares the directory for Terraform to work.

terraform plan

This command shows what Terraform will do before making any real changes. Think of it as a dry run or preview.

terraform apply

This command actually creates or updates infrastructure based on the configuration files.

Even though Day 1 does not involve creating real infrastructure, understanding this workflow is essential because it is used in every Terraform project.

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

This small piece of code tells Terraform:

• Use AWS as the cloud provider

• Deploy resources in the specified region

At this stage, the goal is not to write complex code but to understand how Terraform configurations are structured.

Understanding the Terraform State File

Terraform maintains a state file, which keeps track of the resources it manages. This file helps Terraform understand:

• What already exists

• What needs to change

• What needs to be created or destroyed

One thing that is still slightly confusing is how Terraform internally compares the state file with real infrastructure. This is something I expect to understand better as the challenge progresses.

At this stage, I don’t fully understand how Terraform compares the state file with real infrastructure, and that’s okay. I’m treating this as something that will make sense once I start breaking and fixing things in later days.

How Terraform Fits Together

How Terraform works with AWS

This diagram shows how Terraform uses providers to communicate with AWS and manage infrastructure using code.

Key Learnings from Day 1

• Terraform allows infrastructure to be managed using code

• Infrastructure as Code improves consistency and repeatability

• Providers connect Terraform with cloud platforms

• The *init → plan → apply* workflow is fundamental

• Day 1 is about understanding concepts, not deploying resources

Conclusion

Day 1 was less about doing and more about thinking. No infrastructure was created, but the foundation was set.

If you’re also starting with Terraform or thinking about Infrastructure as Code, I’d genuinely recommend spending time on these basics before rushing ahead. I’m sharing this journey publicly to stay consistent, learn from others, and hopefully connect with people who are on a similar path.

Thanks to Piyush Sachdeva for creating this challenge and pushing the community toward hands-on, structured learning.

If you’re following the challenge too, I’d love to hear how Day 1 felt for you.

But lately, the conversation has shifted. More teams are openly talking about moving away from microservices and back toward monolithic or modular monolithic systems. That raises an uncomfortable question, especially for anyone learning DevOps:

If microservices are so important for DevOps, why are some companies abandoning them? And if monoliths are making a comeback, does DevOps become less relevant?

The short answer is no.
The long answer is more interesting.

Why Microservices Became So Closely Tied to DevOps

Microservices didn’t rise because monoliths were inherently flawed. They rose because certain problems started appearing at scale, and existing architectures struggled to handle them.

As teams grew, a single codebase became a coordination nightmare. Small changes required full application deployments. Release cycles slowed down, and failures became high-risk because everything was tightly coupled. From a DevOps perspective, this meant longer pipelines, bigger blast radiuses, and more stressful releases.

Microservices aligned perfectly with DevOps goals. They allowed teams to deploy independently, scale only what needed scaling, and recover from failures without impacting the entire system. Infrastructure could be automated around smaller, well-defined units, and ownership became clearer.

In large organizations with dozens or hundreds of engineers, this shift wasn’t optional. It was the only way to keep delivering quickly without breaking everything.

The Problems Microservices Actually Solve (And the Ones They Don’t)

At their best, microservices solve real, concrete problems. They reduce deployment bottlenecks. They allow teams to move independently. They make scaling more efficient and failures easier to isolate. For DevOps teams, this enables continuous delivery at scale and better control over reliability.

But microservices also introduce a different kind of complexity.

Every service needs a pipeline. Every service needs monitoring. Services need to find and talk to each other reliably. Logs and metrics are no longer centralized by default. Costs rise, not just in cloud spend, but in cognitive load.

This is where many teams ran into trouble. They adopted microservices early, expecting speed, but ended up spending most of their time managing the platform instead of delivering features.

Why Some Teams Are Moving Back to Monoliths

When companies talk about “going back to monoliths,” they’re usually not returning to the old, tightly coupled messes of the past. What they’re actually choosing is a modular monolith: one deployable unit with strong internal boundaries.

This approach works well when teams are small or medium-sized. It reduces operational overhead, simplifies deployments, and dramatically lowers infrastructure costs. Debugging is easier. Observability is simpler. On-call rotations are less exhausting.

In these environments, microservices weren’t solving a problem. They were creating one.

This isn’t a rejection of microservices as a concept. It’s a recognition that architecture should match scale, not ambition.

So… Does DevOps Matter Less Without Microservices?

This is the wrong question, and it’s an easy trap to fall into.

DevOps does not exist because of microservices.
DevOps exists because software needs to be delivered reliably and repeatedly.

When systems move back to monoliths, DevOps doesn’t disappear. It shifts.

Instead of managing dozens of services, DevOps focuses on improving build times, making deployments safer, managing environments, controlling costs, and improving observability at the application level. Release strategies like blue-green or canary deployments become even more important because failures affect a larger surface area.

In some ways, DevOps becomes more visible in monolithic systems because mistakes are harder to hide.

DevOps Focus Shift: Monolithic vs Microservices Architecture

How DevOps responsibilities shift between monolithic and microservices architectures while the core principles remain the same.

How DevOps Responsibilities Change with Architecture

In microservice-heavy systems, DevOps work leans toward platform engineering. Kubernetes, service meshes, distributed tracing, and standardized pipelines dominate the landscape. The challenge is taming complexity without slowing teams down.

In monolithic systems, the focus shifts to stability and efficiency. Faster builds, safer releases, environment consistency, and cost control become central. The work is less flashy, but no less critical.

The goal doesn’t change. Only the tools and emphasis do.

The Real Lesson Behind the Trend

The microservices-to-monolith conversation isn’t about right or wrong architecture. It’s about maturity.

Early-stage teams benefit from simplicity. Large organizations need decoupling. Most systems live somewhere in between. The mistake many teams made was adopting microservices as a default instead of a response to real constraints.

DevOps maturity isn’t measured by how distributed your system is. It’s measured by how well you can change it safely.

Takeaway

Microservices are powerful when the problem demands them. Monoliths are powerful when simplicity matters more than scale. DevOps thrives in both environments, because its core purpose never changes: shorten feedback loops, reduce risk, and keep systems reliable.

Architecture should follow needs, not trends.
DevOps isn’t about choosing sides — it’s about making whatever you choose work well.

The Rabbit Hole Begins

The first time I opened the AWS console, it felt like stepping into a control room with too many switches. EC2, IAM, VPC, S3, RDS… all these services with serious names and no hand-holding. Overwhelming, but also weirdly exciting.

So I started with the simplest possible thing: one EC2 instance and a tiny app. When it finally worked, something clicked. The world of software doesn’t end at code. It begins at deployment.

What AWS Actually Taught Me

Tutorials tell you where to click. AWS teaches you patience and curiosity. It forces you to care about networking, security, storage, and the consequences of misconfigurations. It rewires how you think.

EC2: Servers Aren’t Just Machines

Launching an EC2 instance sounds straightforward until you misconfigure a security group and spend an hour wondering why you can’t SSH into your own server. That’s how I learned about inbound/outbound rules, key pairs, and why opening port 22 isn’t just a “checkbox.”

Small mental model that saved me later:

[ Your Laptop ] ---> [ Internet ] ---> [ EC2 Instance ]
(SG allows only port 22)

IAM: The Gatekeeper You Can’t Ignore

IAM humbled me quickly. The first time I deployed a pipeline, it failed with a single word: AccessDenied. No explanation, no mercy. Later I discovered that IAM isn’t just about granting permissions, it’s about being precise. The “least privilege” principle exists for a reason, and “AdministratorAccess” is not the solution (even when you’re tired).

Three concepts that changed how I read AWS:

Users vs Roles
Policies vs Permissions
Why "AdministratorAccess" is not the solution (even if you're tired)

S3: Simplicity With Hidden Depth

S3 looks harmless at first glance: drop files into a bucket and call it a day. Then you stumble onto bucket policies, object ACLs, static hosting, lifecycle rules, versioning, and replication. Suddenly S3 stops feeling like Dropbox and starts feeling like infrastructure.

VPC: The Invisible Skeleton

Networking was the moment I realized the cloud isn’t magic. It’s just layers of routing and boundaries you can no longer ignore. Subnets, route tables, NAT gateways, internet gateways — none of it sounds exciting until your private subnet can’t reach the internet and your app quietly breaks.

[VPC]|
|-- 
Public Subnet (EC2 + IGW)
|
|-- 
Private Subnet (RDS + NAT)

Once I understood that, half of my networking confusion evaporated.

The Real Lesson

AWS didn’t just teach me services. It taught me how software leaves your laptop and becomes something people can actually use. It taught me that failures are part of the journey, and most of the learning hides inside those failures: SSH timeouts, IAM errors, containers refusing to talk, private subnets with no exit route, pipelines that fail without context.

And weirdly, that’s what made it fun.

I didn’t fall into the cloud because it was trendy. I fell in because it changed how I see software: not as files, but as systems that breathe, break, and evolve.

I’m still learning. Still deploying. Still debugging. And that’s the story I’ll keep telling here.