Day 0 — Terraform & Our Infrastructure, Explained Simply

Series: Zero to Production on AWS EKS with Terraform — Part 1 · Day 0 The "before we touch any code" episode.

Welcome to Day 0. 👋

Before we write a single line of Terraform together in the coming posts, let's slow down and answer the boring-but-important questions: What is Terraform? Why do we use it? And what does our infrastructure actually look like?

No prior DevOps experience needed. If you can read a recipe, you can follow this.

What is "Day 0" anyway?

In the infrastructure world, people talk about three days:

This post is Day 0. We're not building yet — we're getting our heads straight first. Future posts are where the fun (the actual building) happens.

The problem we're solving

Imagine your company needs a place on the cloud to run its apps. That "place" isn't one thing — it's dozens of pieces that all have to fit together:

• A private network so things can talk safely.
• A cluster where the apps actually run.
• Permissions deciding who can do what.
• Certificates so your website shows the 🔒 padlock.
• Storage for container images.
• Monitoring so you know when something breaks.

Now imagine setting all that up by hand, clicking through the AWS web console. Hundreds of clicks. Then your boss says: "Great, now make an identical copy for staging."

You'd have to remember every click. You'd miss a few. Staging would be subtly different from dev. Six months later nobody can answer "are these two environments actually the same?" without crying.

This is the headache. Terraform is the cure.

What is Terraform? (the one-paragraph version)

Terraform lets you describe your cloud infrastructure as text files instead of clicking buttons. You write what you want ("I want a network with these settings"), and Terraform talks to AWS and makes it real. This idea has a name: Infrastructure as Code (IaC).

Think of it like the difference between:

• Cooking from memory every time (clicking the console) — works, but inconsistent and easy to forget a step.
• Following a written recipe (Terraform) — same result every single time, anyone can reproduce it, and you can email the recipe to a friend.

The recipe is text. Text can be saved in Git, reviewed by teammates, and re-run a thousand times with the same result.

The 4 words you'll hear in every post

You only need four ideas to follow this whole series:

1. Resource — one single thing in the cloud. A network, a server, a certificate. The atom.
2. Module — a reusable bundle of resources, packaged together. Like a LEGO kit instead of loose bricks. (This is the star of our show.)
3. State — Terraform's memory. A file where it records "here's everything I've created so far," so next time it knows what already exists and only changes what's needed.
4. Plan & Apply — Terraform's two-step safety dance:
   • terraform plan → "Here's what I'm about to change. Look before you leap."
   • terraform apply → "Okay, do it for real."

That's it. Resource, Module, State, Plan/Apply. Everything else is detail.

Why modules? (the IKEA analogy)

Here's the big idea behind our whole setup.

A raw Terraform resource is like a single screw. Useful, but you need hundreds of them and you have to know exactly how they fit. A module is like an IKEA flat-pack kit — the hard, finicky engineering is already done, the parts are labeled, and you just fill in your details (color, size, name) and assemble.

We built a library of these kits called devops-terraform-modules. Each kit creates one major piece of infrastructure. When a new project needs a network, they don't reinvent it — they open the vpc kit, type in their settings, and it's done.

   Loose screws (raw resources)        A LEGO/IKEA kit (a module)
   ────────────────────────────        ──────────────────────────
   100 things to get right             1 thing: fill in your name & size
   Easy to make a mistake              Mistakes already solved once
   Copy-paste for each new project     Reuse the same kit everywhere

The payoff: a fix or security patch made once in the kit reaches every project automatically the next time they build. No "we forgot to update prod" disasters.

Meet our infrastructure (the map)

Our setup has two halves, and understanding this split is 80% of understanding everything.

Half 1 — The Library (the kits)

This is devops-terraform-modules. It builds nothing on its own — it's just the shelf of reusable kits. Here's the catalog, in plain English:

The shelf also holds smaller kits for serverless and edge work (lambda, s3, sqs, cloudfront, waf, secrets-manager, iam-role). This series focuses on the ones above, because together they build a full Kubernetes platform.

Inside that eks-addon bundle live the day-to-day workhorses:

• ArgoCD — pushes new app versions from Git to live, automatically.
• ALB controller — turns "I want a website" into a real URL.
• External Secrets — pulls passwords from AWS safely into the cluster.
• Karpenter — adds servers when apps need room, removes them when they don't.
• Loki + Grafana + Promtail — collects logs and shows live dashboards.
• Prometheus agent + Tempo — ships metrics and request traces to a central place.
• GitHub Actions Runner Controller — runs our CI/CD jobs inside our own cluster.

Half 2 — The Consumers (the projects that use the kits)

These are the actual environments. They don't contain the engineering — they just point at the library and say "build me a vpc with these values, an eks with those values." Each is basically a small config file.

The picture

          ┌──────────────────────────────────────────────┐
          │        devops-terraform-modules               │
          │        THE LIBRARY  (reusable kits)           │
          │                                               │
          │   vpc · eks · iam · acm · ecr · ec2 · tgw      │
          │   eks-addon (ArgoCD, ALB, logging, secrets…)   │
          └──────────────────────────────────────────────┘
                 ▲                ▲                 ▲
                 │ "build me a    │                 │
                 │  vpc + eks"    │                 │
        ┌────────┴──────┐ ┌───────┴────────┐ ┌──────┴──────────────┐
        │ platform-     │ │ platform-      │ │ monitoring-runner-  │
        │ infra         │ │ addons         │ │ cluster             │
        │ a config file │ │ a config file  │ │ a config file       │
        └───────────────┘ └────────────────┘ └─────────────────────┘
                 │                │                 │
                 ▼                ▼                 ▼
           Real, running infrastructure on AWS

One library. Many consumers. Change the library once → every consumer benefits.

What a "deploy" actually looks like

To make Day 1 feel less scary, here's the whole loop in five lines:

1. Open a consumer's config file and fill in your values (name, region, sizes).
2. Run terraform plan → read what it will do.
3. If it looks right, run terraform apply.
4. Go get a coffee. ☕ AWS does the heavy lifting (~15–20 min).
5. Come back to a full, running environment: network, cluster, pipelines, monitoring — the lot.

That's a week of manual work, compressed into one command plus a coffee break.

Day 0 cheat-sheet (save this)

• Terraform = describe your cloud as text, then let it build the real thing.
• IaC = Infrastructure as Code = the recipe instead of cooking from memory.
• Module = a reusable kit of cloud parts. Our library is full of them.
• Two halves: the library (kits) and the consumers (projects that use the kits).
• plan then apply = look before you leap, then leap.
• The win: consistent, repeatable, reviewable infrastructure — and fixes that roll out everywhere from one place.

What's next?

That's Day 0 — the mental model. You now know what Terraform is, why modules matter, and how our infrastructure is shaped.

Coming up next (Part 2 — The Final Picture): before building anything, we'll look at the finished platform end to end, so every later post has a place on the map. Then, from Day 1, we roll up our sleeves and build it piece by piece, starting with the vpc network.

See you in the next post.

This series walks through devops-terraform-modules — a real, production module library. If you're building cloud infra and tired of copy-paste between environments, follow along.