From a legacy monolith to a maintainable EKS delivery platform.

The challenge

A legacy monolithic application ran on Amazon EC2. Scaling and rollbacks were difficult, and a distributed engineering team had to coordinate every change across the delivery process.

The constraints

Infrastructure and delivery had to change together. Fixing one without the other would only have moved the bottleneck.

Decisions & tradeoffs

We brought Amazon EKS, Terraform, Helm, GitHub Actions and Argo CD together so that infrastructure and delivery configuration became explicit, versioned parts of the engineering workflow.

Kubernetes and GitOps also bring responsibilities, so platform ownership, access control and configuration maintenance were defined from the start rather than discovered later.

The implementation

Amazon EKS runs the application platform and Terraform defines the infrastructure. Helm packages the services, GitHub Actions builds them, and Argo CD deploys them from Git. External Secrets manages secret configuration, Prometheus monitors the services, and Backstage documents them and their owners.

01 / REFERENCE ARCHITECTUREAWS · EKS · GITOPS

GitHub + GitHub ActionsCommit, test, and build a container image

Amazon ECRVersioned images, pulled by EKS workloads

AWS VPC

Application Load BalancerHTTPS traffic through public subnets

Amazon EKSApplication pods in private subnets

Availability zone AAvailability zone B

Argo CD / GitOpsReads Helm configuration from Git and reconciles it through the Kubernetes API.

Prometheus / ObservabilityScrapes workload metrics and evaluates alert rules.

Illustrative reference topology.

Outcomes

One structured platform and delivery workflow replaced hand-run deployments. Changes are versioned, reviewed and repeatable, and returning to an earlier version is a change in Git.

Handover & ongoing ownership

Documentation and clear ownership were part of the delivery, so the client's own team operates the platform.