ECS to EKS: Rebuilding a FinTech Platform for Scale and Compliance

Project Overview

Firmway builds financial automation software for enterprises and auditors. They handle reconciliation, confirmation, and audit workflows that generate evidence and audit trails. As the platform and its workloads grew, its infrastructure needed to keep up. They needed better scalability, smoother deployments, and clearer visibility into production.

Cloud Solitaire Technologies helped migrate the platform from Amazon ECS to Amazon EKS, improve the delivery pipeline, and strengthen reliability and recovery for financial workflows at scale.

Challenges

As Firmway’s platform and its workloads grew, the cracks in its ECS-based infrastructure were growing. There were multiple structural problems:

• Manual deployments that took up engineering time
• Workloads that got difficult to scale and manage
• No mature backup or disaster recovery path
• Little visibility into what was happening in production when things went wrong
• Debugging across multiple systems to find the root cause
• Cloud costs that kept increasing in step with usage, without matching reliability

These were not isolated issues. A release could take several hours, rapid growth in usage could strain the team, and when something broke there was no single place to look. For a platform that manages reconciliation, confirmation, and audit data, recovering from a failure relied more on assumptions than established procedures - a gap that becomes evident during a customer security review.

Our Approach

We split the work into five pieces: move the platform from ECS to Amazon EKS, replace manual infrastructure work with code, automate the deployment process, add monitoring and real visibility, and improve reliability while reducing cost.

We sequenced the work so that each step made the next one cheaper and safer to do.

Solutions

Platform Migration & Infrastructure as Code

We designed the Kubernetes setup, migrated the workloads from Amazon ECS to Amazon EKS, and improved how applications are deployed and managed. We completed the move with zero downtime. The underlying infrastructure is managed by Terraform, with Terragrunt keeping dev, staging, and production consistent. All changes are reviewed before reaching production, and the same setup can be rebuilt from scratch.

CI/CD & Delivery

GitLab CI/CD runs the pipelines, and FluxCD keeps the clusters in step with Git. Manual deployment steps have been removed, so releases are predictable and repeatable.

Observability & Monitoring

Elasticsearch and Kibana handle logs, Elastic APM covers application performance, and Prometheus and Grafana provide metrics. The team has to look in only one place when something breaks.

Reliability & Disaster Recovery

MongoDB is configured to keep running even if one of its nodes fails, so the database continues to operate without taking the whole system down. Velero backs up cluster state and volumes on a schedule, with restores that can actually be tested. A documented disaster recovery path closes one of the major identified gaps.

Cost Optimization

Four improvements were built into the platform from the start:

• ARM-based Graviton instances, which cost less per unit of performance than equivalent x86
• Spot Instances for interruption-tolerant workloads, at a fraction of on-demand pricing
• Karpenter autoscaling, which adds and removes nodes to match real demand
• Automatic shutdown of non-production environments when they are not in use

Technologies & Tools Used

Results

• Migration: the move from Amazon ECS to Amazon EKS was completed with zero downtime.
• Reliability: losing a database node no longer takes the platform down with it.
• Observability: from little visibility into production to logs, metrics, and traces in one place, built in before it was needed rather than during the next incident.
• Recovery: Velero-backed cluster backups and a documented disaster recovery path the team can actually test.
• Cost: costs now match actual usage through ARM and Spot Instances, autoscaling, and automatic shutdown of idle non-production environments.
• Delivery: all workloads on EKS, infrastructure defined in Terraform, releases running through GitLab CI and FluxCD without manual steps.

Key Takeaways

A successful ECS to EKS migration for a fintech platform needs the migration, infrastructure-as-code, CI/CD, observability, reliability, and cost work sequenced deliberately, so each step makes the next one cheaper and safer.

Backup and disaster recovery can’t only be documented for platforms handling reconciliation, confirmation, or audit data. They have to be something the team can actually test - Velero backups and MongoDB high availability make that possible.

Cost optimization is built into the infrastructure from the start, so savings keep working without manual effort.

The stack uses open-source tools and AWS services, so there is no vendor or consultancy lock-in.

This was not the first attempt. Cloud Solitaire has already run an ECS-to-EKS migration of this kind - containerized workloads, Terraform-managed infrastructure, cost controls, and observability built in from the start.

Frequently Asked Questions

What does migrating a FinTech platform from ECS to EKS involve? Designing the Kubernetes setup, migrating workloads to Amazon EKS, rebuilding infrastructure as reusable Terraform and Terragrunt modules, automating deployment pipelines with GitLab CI/CD and FluxCD, and layering in observability, reliability, and cost controls.

Can an ECS to EKS migration be done with zero downtime? Yes, by careful sequencing of the Kubernetes setup and workload migration. It is done as part of a broader modernization plan rather than a single cutover.

Why does backup and disaster recovery matter more for financial automation platforms? These platforms are subject to customer security reviews, where an untested backup is treated as no backup at all. High-availability databases, scheduled and tested backups, and a documented recovery path turn disaster recovery into a rehearsed procedure rather than an assumption.

Does moving to Kubernetes reduce AWS costs automatically? Not by itself. Cost reduction happens by combining the migration with specific levers such as ARM Graviton instances, Spot Instances, autoscaling tools like Karpenter, and automatic shutdown of idle non-production environments.