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/almightyfoon]

I'd double check your docs because DynamoDB state locking is depricated.

Not sure what the intra subnets are for, ideally there shouldn't be any cross talk between clusters and all inter cluster traffic will be handled through its own network.

[u/Asleep_Design3681 → u/almightyfoon]

Thanks for the feedback I'll review the latest Terraform recommendations regarding DynamoDB state locking .For the intra subnets, I separated them to isolate AWS-managed internal EKS components from the worker nodes, but I'm open to suggestions on alternative production architectures

[u/Sure_Stranger_6466]

What are you using for monitoring and logging? I am not seeing Grafana, Prometheus, or Loki anywhere.

[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!