terraform-on-aws-eks is a 55 demo Terraform course for EKS

A course repository, not a reusable module

terraform-on-aws-eks is the code for a course titled Terraform on AWS EKS Kubernetes IaC SRE, with 50 real-world demos in the title and 55 modules actually listed. The project description names the format plainly, and the homepage is stacksimplify.com with a link to the course page.

What the repository is, structurally, is a directory per demo, numbered and named after what it does. The listing starts with the Terraform language itself and ends with monitoring:

01. Infrastructure as Code (IaC)
02. Terraform Install Tools, Command and Language Basics
03. Terraform Settings, Providers and Resources
04. Terraform Input Variables, Output Values, Datasources
05. Terraform Loops, MetaArguments, Splat Operator and Functions
06. AWS VPC 3-Tier Architecture Design using Terraform
07. Bastion Host AWS EC2 Instances, Security Groups, TF Provisioners with Terraform

and the tail of the list is modules 54 and 55, AWS EKS Monitoring and Logging with kubectl and the same thing with Terraform.

The important thing for an evaluator is that this is teaching content, not a library or a product. The code is arranged so that each concept can be shown in isolation, which is exactly what makes it useful for learning and exactly what makes it awkward to reuse. The repository has no GitHub releases, and the licence field on the repository is not filled in, so there is no stated grant for redistribution in the metadata.

The learning curve runs Terraform first, then Kubernetes

The module ordering is the pedagogical argument. The first five modules are pure Terraform, covering installation, the command line and language basics, then the settings, providers and resources blocks, then input variables, output values and datasources, and then loops, meta-arguments, the splat operator and functions.

Only at module six does it touch AWS, with a three tier VPC architecture designed in Terraform, followed by a bastion host with EC2 instances, security groups and Terraform provisioners at module seven. The EKS cluster with public and private node groups is module eight, and Kubernetes fundamentals arrive at module nine, with a deployment and service written in YAML at module ten.

From there the Terraform Kubernetes provider is used to do the same thing in Terraform, and the pattern of paired demos continues throughout. A deployment exists as YAML in one directory and as Terraform in the next, an EBS sample application appears as 15-EBS-Kubernetes-SampleApp-YAML and then 16-EBS-Kubernetes-SampleApp-Terraform, and the IAM admin user modules appear as 19, 20, 21, 22 and 23, each showing a different way of granting EKS admin.

The README also lists what students are said to learn: Terraform basics for 4.5 hours, Kubernetes fundamentals for 3 hours, 25 or more Kubernetes concepts and 25 or more Terraform concepts across 55 demos on AWS Cloud.

What the module list actually covers

The breadth is worth mapping, because the list tells you what a team would get from working through it.

On the AWS side, beyond the VPC and EKS cluster, there is remote state storage in S3 and DynamoDB at module 12, IAM Roles for Service Accounts at 13, the EBS CSI driver with a self-managed add-on option at 14, and the EBS CSI EKS add-on at 18. The Load Balancer Controller is installed with the Terraform Helm provider at module 26, and ExternalDNS at module 30. There are Fargate profiles at 43, running workloads on Fargate at 44, and a Fargate only EKS cluster at 45. The EFS CSI controller and both static and dynamic provisioning follow at 46 to 48, and the file system mount for Fargate workloads at 49.

On the Kubernetes side, the concept list covers 24 items, from Deployments and Pods through Service of Type LoadBalancer and ClusterIP, Ingress Service and Ingress Class, Storage Class, Persistent Volume and Persistent Volume Claim, RBAC with Roles, Role Bindings, Cluster Roles and Cluster Role Bindings, the three autoscalers, DaemonSets, Namespaces, Service Accounts, Groups, ConfigMaps, Requests and Limits, and Worker Nodes.

The Ingress block is the deepest single area, with modules 27 to 39 covering context path routing, SSL and SSL redirect, name based virtual host routing, SSL discovery, ingress groups, target type IP, internal load balancer and cross namespace ingress, followed by Network Load Balancer demos with TLS and ExternalDNS at 40 to 42.

Six providers, and why the choice matters

The providers the course uses are listed explicitly, and the list is short enough to be a real design decision rather than an accident.

There is the AWS provider, the Kubernetes provider, the Kubectl provider, the HTTP provider, the Null provider and the Helm provider.

The Kubernetes provider is the one that does the work of applying manifests and custom resources, the Helm provider is what makes the Load Balancer Controller and ExternalDNS installs reproducible, the Kubectl provider covers the commands that have no Terraform equivalent, the HTTP provider handles the cases where something has to be called over the network, and the Null provider exists to give dependencies a target.

For someone learning Terraform, the point of that list is that it shows the boundary. Not everything in a Kubernetes workflow is a Terraform resource, and a course that demonstrates the Kubectl and HTTP providers alongside the Kubernetes one is teaching that boundary rather than hiding it.

The Terraform concept list is equally deliberate, running from the settings block and providers block through multiple providers usage and the dependency lock file, to resources syntax and the four meta-arguments depends_on, count, for_each and lifecycle, then input variables in their several forms, the file function, output values, local values, datasources, backends and remote state storage, the three provisioners, the null resource, modules from the public registry, the element function, and the remote state and Terraform datasources.

Where the repository is not a finished platform

The directory listing ends with three directories that are not numbered demos at all: BACKUP-BEFORE-DEC2023, BACKUP-BEFORE-JULY2025 and BACKUP-BEFORE-MAY2023.

Those are snapshots, and their presence tells you something a course module list cannot. The code changes over time as AWS services and Terraform versions move, and the author keeps earlier states so that a course follower on an older video, or someone returning to a demo, can find the version that matched when it was recorded.

It is a good practice and it is also a warning. A repository with three dated backup trees is a repository where the current state of the code and the state that worked when the course was filmed are not the same thing, and the difference shows up as errors when you run a demo against current AWS.

The two module sets on monitoring make the same point. Module 54 does EKS monitoring and logging with kubectl and module 55 does it with Terraform, and the README describes both as part of the same 55 demo course. The back-to-back pairing is the teaching device, and the backups are the maintenance cost of that device.

What adopting this actually costs

The realistic evaluation is that this is a paid course with an open repository of code, and the code is the free part.

The AWS cost is the concrete number to plan for. These demos provision a three tier VPC, a bastion host, an EKS cluster with both public and private node groups, load balancer controllers, EBS and EFS storage, Fargate capacity and autoscaling. Each of those is billable AWS infrastructure, and the course expects you to run them.

The second cost is the drift between the recorded demos and the live services. The module list references an AWS EBS CSI EKS add-on, IAM admin provisioning and Load Balancer Controller installs, and all three of those have moved in the years since the earlier versions of the course were recorded. The backup directories exist precisely because of that.

The third is what the repository is not. It is not a maintained module, it has no versioned releases, and the licence is not stated in the repository metadata. If what you need is infrastructure code to run in production, a maintained module collection or the official provider documentation is a better starting point than 55 teaching directories.

If what you need is to learn the shape of an EKS platform, including how a three tier network, an ingress stack and a storage layer fit together, the directory names alone are a decent map of the territory, and the code gives you a working example for each stop.

Editorial conclusion

terraform-on-aws-eks suits a developer who learns infrastructure by working through a working example rather than by reading reference documentation, since each numbered directory is a runnable slice of the same platform. It is the wrong starting point if you want a production EKS module to copy, since the code is arranged for teaching rather than for reuse. Before working through it, read the module list in the README against the directory names, check the BACKUP-BEFORE directories for what the course looked like at earlier points, and plan for the AWS cost of the demos, because the cluster, node groups and storage layers are all provisioned for real.

Frequently asked questions

Official sources

1. Issues
2. Project website
3. README
4. stacksimplify/terraform-on-aws-eks on GitHub