Cost-Optimized Multi-Env EKS Web Platform

This architecture uses a single Amazon EKS cluster to host both development and production workloads while keeping them logically separated through Kubernetes namespaces. The cluster contains an app-dev namespace for development deployments and an app-prod namespace for production workloads. This approach reduces fixed infrastructure cost compared to running separate EKS clusters for each environment, while still allowing separate deployments, resource limits, secrets, and access controls for dev and prod. Application traffic enters through Route 53, which manages DNS records for the frontend and backend domains. Public requests are routed to an AWS Application Load Balancer created and managed by the AWS Load Balancer Controller inside the EKS cluster. The ALB handles Layer 7 routing, TLS termination through AWS Certificate Manager, and routes traffic to the correct Kubernetes services based on hostnames such as app.example.com, api.example.com, web.dev.example.com, and api.dev.example.com. AWS WAF is placed in front of the Application Load Balancer to provide common web protection and rate limiting. This removes the need for a self-managed proxy such as HAProxy or an NGINX Ingress Controller. Kubernetes Ingress resources define the routing rules, while the AWS ALB provides the actual public load balancing layer. This keeps the architecture simpler, more AWS-native, and easier to operate. The Next.js web application runs inside Kubernetes as a Dockerized Node.js service using Next.js standalone output. Because the app uses Next.js server-side functionality, it does not require Nginx inside the frontend container. The web service runs as Kubernetes pods behind a ClusterIP service, and public traffic is routed to it through the shared ALB and Kubernetes Ingress. The backend API also runs as a Dockerized Kubernetes deployment. It is exposed internally through a Kubernetes service and externally through its own Ingress hostname. The backend connects privately to Amazon RDS PostgreSQL for persistent relational data and Amazon ElastiCache Redis for caching, sessions, queues, and application-level rate limiting. These data services are deployed in private subnets and are not publicly accessible. To reduce cost, the development environment uses smaller resources than production. Dev can run with one replica of the web app, one replica of the backend, a small Single-AZ PostgreSQL instance, and either a small Redis instance or an in-cluster Redis deployment for non-critical testing. Production uses multiple replicas, stronger resource limits, Multi-AZ PostgreSQL, managed Redis, backups, monitoring, and stricter security controls. GitLab CI/CD is responsible for building and deploying the applications. Each repository builds a Docker image, pushes it to Amazon ECR, and deploys to EKS using kubectl and Kustomize. The develop branch deploys automatically to the dev namespace, while the main branch builds production images and requires a manual approval step before deploying to production. GitLab uses AWS IAM OIDC roles instead of long-lived AWS access keys. Secrets are stored in AWS Secrets Manager and synced into Kubernetes using External Secrets Operator. This allows application pods to consume values such as database URLs, Redis URLs, JWT secrets, and application secrets without storing sensitive data in GitLab or committing secrets into source control. Observability is handled through CloudWatch, ALB metrics, WAF logs, EKS logs, RDS metrics, and Redis metrics. Logs should have short retention in development and longer retention in production. Alerts should monitor unhealthy ALB targets, high 5xx errors, pod restarts, CPU and memory pressure, RDS connection usage, Redis memory usage, and WAF blocking spikes. Overall, this design keeps the system production-capable while controlling cost. It avoids unnecessary infrastructure duplication, shares the EKS cluster and ALB where appropriate, keeps managed databases and Redis private, and uses AWS-native services for routing, TLS, security, secrets, and monitoring.