AWS with Terraform (Day 20)

Terraform Custom Modules for EKS: From Zero to Production

As Terraform projects grow, a single flat configuration quickly becomes hard to manage, review, and scale. This becomes especially clear when provisioning complex platforms like Amazon EKS, where networking, IAM, cluster configuration, and secrets management are tightly coupled but conceptually separate concerns.

On Day 20 of my AWS with Terraform journey, I focused on designing and using custom Terraform modules to build a production-ready EKS architecture. This day was less about writing individual resources and more about learning how to structure infrastructure like real engineering systems.

Why Terraform Modules Matter in Production

Terraform modules allow you to package infrastructure logic into reusable, versioned units. Instead of duplicating the same VPC, IAM, or EKS code across environments and repositories, modules let you encapsulate complexity behind well-defined inputs and outputs.

In production environments, this provides several advantages:

  • Consistent infrastructure patterns across teams and environments

  • Reduced blast radius by controlling what consumers can configure

  • Safer upgrades through versioned module releases

  • Cleaner root configurations focused on orchestration, not implementation

Modules are not just a convenience feature. They are foundational to scalable Infrastructure as Code.

Root Module vs Custom Modules

Terraform always starts execution from the root module, which is simply the directory where you run terraform init and terraform apply. Any subdirectory referenced using a module block becomes a child module.

Key principle:
Modules never talk to each other directly.

All communication flows through the root module using inputs and outputs:

  • Root passes values into a module using variables

  • Module exposes results using outputs

  • Root reads outputs and passes them to other modules

This design enforces loose coupling and makes infrastructure behavior explicit.

Production-Style EKS Module Architecture

For a clean and maintainable EKS setup, I followed a modular architecture that separates responsibilities clearly.

Typical module boundaries:

VPC Module

  • VPC creation

  • Public and private subnets

  • Internet gateway and NAT gateway

  • Route tables and associations

  • Subnet tagging for Kubernetes

IAM Module

  • EKS cluster role

  • Node group roles

  • Policy attachments

  • Instance profiles

EKS Module

  • EKS cluster

  • Managed node groups

  • OIDC provider for IRSA

  • Kubernetes versioning

Secrets Module

  • Secrets Manager or Parameter Store

  • Centralized handling of sensitive values

  • Outputs only expose ARNs or names, never secrets

This structure mirrors how production teams design infrastructure ownership and boundaries.

How Data and Values Flow Between Modules

A common real-world pattern used in this setup:

  1. Root module uses data sources to fetch availability zones

  2. Root passes AZs into the VPC module

  3. VPC module creates subnets and outputs subnet IDs

  4. Root reads subnet IDs and passes them into the EKS module

  5. EKS module uses those subnets to create the cluster and node groups

This keeps modules reusable and region-agnostic while allowing the root module to control environment-specific logic.

Key Terraform Patterns Used

Several important Terraform patterns become critical when working with modules:

  • Typed variables such as list(string), map(string), and bool

  • Merging standard tags with module-specific tags using merge()

  • Keeping data sources in the root module where possible

  • Exposing only necessary outputs to reduce coupling

  • Pinning module versions using Git tags for stability

These patterns significantly reduce surprises during upgrades and reviews.

Best Practices Learned

  • Start with small modules and expand incrementally

  • Do not over-expose variables; lock down what should not change

  • Version modules and always reference them using tags

  • Document module inputs and outputs clearly

  • Treat modules like internal libraries, not copy-paste folders

The moment you think of Terraform modules the same way you think of application packages, infrastructure design becomes much clearer.

Diagram




Final Thoughts

Custom Terraform modules transform infrastructure from scripts into systems. For EKS in particular, modular design is the difference between a demo cluster and a production-grade platform.

By separating VPC, IAM, EKS, and secrets into well-defined modules and letting the root module orchestrate them, infrastructure becomes reusable, testable, and safe to evolve.

Day 20 reinforced an important lesson:
Good infrastructure is not just about what you provision, but how you structure and control it.

Here is the session link : 


 

Comments

Post a Comment

Popular posts from this blog

AWS with Terraform (Day 01)

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

AWS with Terraform (Day 27)

Image
Automating AWS Infrastructure Using Terraform and GitHub Actions Infrastructure automation is where DevOps truly becomes real. Writing Terraform code is only half the story—the real value comes when infrastructure changes are version-controlled, reviewed, scanned, approved, and applied automatically . On Day 27 of my DevOps journey, I implemented a production-grade CI/CD pipeline to automate AWS infrastructure using Terraform and GitHub Actions , following best practices used in real-world teams. This blog walks through the architecture, workflow design, safety controls, and lessons learned . Why Automate Terraform with CI/CD? Running Terraform manually from a laptop works for learning, but it quickly breaks down in team and production environments: Local state files are risky and hard to share Credentials scattered across machines No standardized reviews or approvals No security or policy checks before apply No clear audit trail By integrating Terraform with G...
Read more

AWS with Terraform (Day 02)

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