Delivery engineering · Platform & infrastructure · Security & compliance

From source to EKS: cloud-native delivery on AWS

Personal engineering work · public repository

Focus: Delivery engineering · Platform & infrastructure · Security & compliance
Evidence: 4 documented proof points
Decision record: Firsthand trade-off included

The brief

What was built

An expense-tracking API delivered from source to Amazon EKS: a non-root Node.js container, MySQL on RDS, layered Terraform for the network and platform, and a Jenkins and Helm delivery path with SonarQube quality gates and Nexus artefact storage.

Evidence

Implemented evidence

Separated compute and state across private EKS nodes and MySQL RDS database subnets, with public traffic terminating at an ACM-backed Application Load Balancer
Split infrastructure into ordered Terraform stages with S3 remote state and SSM Parameter Store contracts between VPC, security groups, bastion, RDS, EKS, ACM, ALB and ECR
Defined immutable, scan-on-push ECR repositories and a non-root Node.js image, then packaged the workload in Helm with two replicas and HPA scaling from one to ten pods at 70% CPU
Structured the Jenkins delivery path around a shared library, SonarQube quality gates, Nexus artefact storage and an optional downstream deployment job

Decision record

Kubernetes runs the application; RDS owns the state

I kept MySQL outside the EKS cluster in Amazon RDS rather than treating the database as another Kubernetes workload. The application pods are disposable and can scale between one and ten replicas, while the data layer sits in dedicated database subnets and only accepts MySQL traffic from the EKS nodes or the bastion path. This removes database storage, backups and lifecycle from the cluster's operational burden. The trade-off is tighter AWS coupling and a separate managed service to provision and pay for, but application rollouts and node replacement no longer share a failure domain with the database.

Return to all work