Situation at a glance
- Industry: financial technology, with an existing Kubernetes operating model.
- Platform decision: use EKS where Kubernetes skills and requirements were justified.
- Outcome framing: public outcomes remain qualitative until approved proof supports stronger claims.
Context and Kubernetes fit
Core points
- A fintech team already had Kubernetes capability and needed a migration path that respected that investment.
- The goal was to move from Azure pressure points to AWS without forcing engineers to relearn the operating model from scratch.
- The decision was about preserving justified Kubernetes skills while improving control around the AWS platform foundation.
EKS architecture and service choices
Core points
- The platform moved to Amazon EKS on EC2 managed node groups so the team could keep Kubernetes while improving AWS control.
- VPC design, IAM, CloudWatch, Application Load Balancer, and RDS for SQL Server supported networking, access, observability, application traffic, and stateful services.
- Fargate remained a future evaluation option for workloads where operating model and cost fit could be proven.
Delivery milestones and operating controls
Core points
- The migration kept the team's operating model familiar while improving cluster control, networking, scaling, access, and observability.
- SQL Server services stayed visible in the wider platform path instead of becoming a disconnected migration concern.
- Future optimisation stayed evidence-led, so compute choices could follow workload fit rather than launch-day assumptions.
Skunk tip
- Validate that Kubernetes is a real operating requirement before selecting EKS for a migration.
Measured outcomes and lessons
Core points
- The platform direction preserved Kubernetes skills while giving the team more control over AWS networking, scaling, cluster operations, and observability.
- Public outcomes remain qualitative unless approved proof supports exact performance or savings claims.
- The lesson is that Amazon EKS fits best when Kubernetes capability is already valuable and the surrounding AWS partner services controls are designed deliberately.
A good migration does not always replace the team's operating model; sometimes it gives that model a safer foundation.
