Day 20 was one of the most challenging and important days in my #30DaysOfAWSTerraform journey.

Until this point, I was comfortable writing Terraform code and creating AWS resources.
But today was different.

👉 Day 20 was not about “making EKS work”
👉 It was about learning how real production infrastructure is designed

This day completely changed how I think about:

• Terraform modules

• Root vs child responsibility

• AWS EKS architecture

• Infrastructure wiring

---

🎯 Objective of Day 20

The main goal of Day 20 was to:

Design and deploy an AWS EKS cluster using Terraform modules, following real-world best practices.

This included:

• Modular Terraform design

• Clean separation of concerns

• Reusable infrastructure

• Preparing EKS for autoscaling, ingress, and secure access

---

🧠 The Biggest Mindset Shift

The most important thing I learned today was:

Terraform modules are not just folders.
They are architectural boundaries.

Before this day, I used modules mainly for reuse.
Now I understand they are mandatory for scalable, production-grade infrastructure.

---

🏗️ High-Level Architecture

The infrastructure was divided into three main modules:

1. VPC Module – Networking

2. EKS Module – Kubernetes control plane

3. Node Group Module – Worker nodes

And one Root module that connects everything.

VPC  →  EKS  →  Node Group
  ↑        ↑
  └── Root wiring ──┘

---

📂 Project Structure

day20/
├── main.tf          # Root module (wiring only)
├── variables.tf     # Environment inputs
├── outputs.tf       # Exposed values
├── providers.tf
└── modules/
    ├── vpc/
    │   ├── main.tf
    │   ├── variables.tf
    │   └── outputs.tf
    ├── eks/
    │   ├── main.tf
    │   ├── variables.tf
    │   └── outputs.tf
    └── nodegroup/
        ├── main.tf
        ├── variables.tf
        └── outputs.tf

🔑 Key Rule Followed

• Root module → does NOT create AWS resources

• Child modules → create AWS resources

• Root only connects modules together

---

🌐 VPC Module – Foundation Layer

The VPC module was responsible for all networking:

What it created:

• Custom VPC

• Public subnets (3 AZs)

• Private subnets (3 AZs)

• Internet Gateway

• Route tables

Why this matters:

• EKS worker nodes should run in private subnets

• Public access should be controlled and minimal

• Multi-AZ setup ensures high availability

Region & AZs used:

• Region: ap-south-1

• AZs: ap-south-1a, ap-south-1b, ap-south-1c

---

☸️ EKS Module – Control Plane

The EKS module was responsible for:

• Creating the EKS control plane

• IAM role for the cluster

• Connecting EKS to the VPC private subnets

Important realization:

The EKS module does NOT know how the VPC is built.

It only receives:

• subnet_ids

This enforces loose coupling and makes the module reusable.

---

🧩 Node Group Module – Worker Nodes

The node group module handled:

• Managed EKS worker nodes

• Scaling configuration (min, max, desired)

• IAM role for nodes

Autoscaler Preparation

Required autoscaler tags were added:

k8s.io/cluster-autoscaler/enabled = true
k8s.io/cluster-autoscaler/<cluster-name> = owned

👉 Terraform does not install autoscaler
👉 Terraform only prepares the infrastructure

---

🔄 Module Communication (MOST IMPORTANT LEARNING)

This was the hardest but most valuable concept.

❌ What modules CANNOT do

• Modules cannot talk to each other directly

• A module cannot read another module’s outputs

✅ How data flows

Module Output → Root Mapping → Module Input

Example:

• VPC outputs: private_subnet_ids

• Root maps:

•   subnet_ids = module.vpc.private_subnet_ids
  

• EKS consumes: subnet_ids

👉 Root module acts like a wiring layer

This cleared all my confusion about Terraform modules.

---

🔐 IRSA – IAM Role for Service Account

Day 20 also introduced IRSA, which is critical for production EKS.

What IRSA solves:

• Avoids giving AWS permissions to entire worker nodes

• Allows specific pods to assume IAM roles securely

Key concepts learned:

• EKS uses OIDC

• Kubernetes ServiceAccount → IAM Role

• Secure access to AWS APIs from pods

Terraform prepares:

• OIDC provider

• IAM role and trust policy

Kubernetes uses it.

---

🌍 Ingress Controller – Conceptual Understanding

Another important takeaway:

Terraform does not create load balancers for Kubernetes apps.

Instead:

• Terraform prepares IAM permissions

• Kubernetes ingress controller creates ALB dynamically

This clean separation keeps infrastructure manageable.

---

✅ What I Learned on Day 20

• Real-world Terraform module design

• Root vs child module responsibility

• How EKS architecture works internally

• Preparing infrastructure for autoscaling and ingress

• Secure AWS access using IRSA

• Thinking like a DevOps engineer, not just writing code

---

🎥 Day 09 Video ( link )

🏁 Final Thoughts

Day 20 was not easy, but it was worth it.

This day taught me that:

Good infrastructure is not about more code —
it’s about correct design and clear boundaries.

Everything that comes next (CI/CD, monitoring, ingress, autoscaling) will build on this foundation.

🔖 Tags

#30DaysOfAWSTerraform #30dayterraformchallenge #Terraform #AWS #EKS #DevOps #InfrastructureAsCode #Kubernetes #CloudComputing #LearningInPublic