# Terraform & Our Infrastructure

# 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:

| Day | What it means | Example |
| --- | --- | --- |
| **Day 0** | Planning & setup. Concepts, tools, mental model. | "What are we building and with what?" |
| **Day 1** | Build & deploy. Create the thing. | "Run the command, the cluster appears." |
| **Day 2** | Run & maintain. Keep it healthy, change it safely. | "Scale up, patch, fix, monitor." |

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.

```plaintext
   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:

| Kit (module) | What it builds | In plain words |
| --- | --- | --- |
| `vpc` | Virtual Private Cloud | The private network everything lives inside |
| `eks` | Kubernetes cluster | The "engine room" where apps actually run |
| `eks-addon` | A bundle of cluster tools | One call installs deployment, logging, secrets & more |
| `iam-policy` | Permissions | Who and what is allowed to do what |
| `acm` | TLS certificates | The lock https padlock for your URLs |
| `ecr` | Image registry | The warehouse for your app's container images |
| `ec2` | Virtual servers | Plain cloud computers when you need them |
| `ebs-csi` | Disk storage | Hard drives that Kubernetes apps can use |
| `alb` | Traffic router | Sends visitors to the right app |
| `security-group` | Firewall rules | What traffic is allowed in and out |
| `tgw` / `tgw-attachment` | Network bridges | Lets two private networks talk to each other |

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.

| Consumer stack | What it is |
| --- | --- |
| `platform-infra` | The core environment — network + cluster |
| `platform-addons` | The add-ons layer for that cluster (ArgoCD, logging, etc.) |
| `monitoring-runner-cluster` | A shared cluster for monitoring + CI/CD runners |

### The picture

```plaintext
          ┌──────────────────────────────────────────────┐
          │        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.*