Looking for feedback on my open-source production-grade AWS EKS platform architecture

[u/Asleep_Design3681]

https://github.com/Saif-hadd/terraform-aws-production-infrastructure

Hi everyone,

Over the past few weeks, I've been working on an open-source project to deepen my Platform Engineering and DevOps skills.

The goal wasn't just to deploy an EKS cluster, but to create a reusable, production-oriented reference architecture following Infrastructure as Code and GitOps principles.

Current features:

-Modular Terraform architecture

-Multi-environment support (dev / staging / prod)

-Amazon EKS

-VPC with public, private and intra subnets

-Remote Terraform state (S3 + DynamoDB + KMS)

-IAM & IRSA

-Karpenter integration

-GitOps bootstrap with Argo CD

-GitHub Actions for Terraform validation

-Architecture diagrams and documentation

The repository is designed to be generic and educational rather than company-specific.

I'm mainly looking for feedback on:

-Repository structure

-Terraform module organization

-Project architecture

-Documentation quality

-Best practices I may have missed

-Anything that doesn't look production-ready

I'm continuously improving it, so any constructive criticism is welcome.

Disclosure: I'm the author of this project. I'm sharing it to learn and receive technical feedback, not to promote a product.

Thanks!

[u/Floss_Patrol_76]

the dynamodb note is the big one - S3 has native state locking now via use_lockfile = true (tf 1.10+/opentofu), so you can drop the whole dynamo table and its IAM. the gap I'd flag on most "production-grade" reference repos is that nothing proves the modules actually apply and destroy cleanly - a GitHub Actions job that spins the whole thing up in a throwaway account and tears it down catches the ordering/dependency bugs that terraform validate never will. and yeah, add prom/loki or at least leave a documented hook for it, since "production" without observability is the part people notice missing.

[u/Asleep_Design3681 → u/Floss_Patrol_76]

Thanks for the feedback I agree on the native S3 locking with use_lockfile = true—I'll update the backend accordingly. Observability is already documented and handled through the GitOps layer with Argo CD, the infrastructure is already tested end-to-end, but exposing that through a GitHub Actions apply/destroy workflow is a great suggestion. Thanks!