Read summarized version with
About project
Working time:
2024 – 2026
Industry:
FinTech, Crypto compliance / RegTech
The service:
Managed Services,Amazon EKS Modernization
Overview
Our client is a compliance company for the cryptocurrency industry. Its solution combines on-exchange and on-chain transaction data to deliver in-depth analytics and help clients stay compliant. The infrastructure behind it is small in footprint but made up of many independently versioned components: Amazon EKS, Amazon RDS, self-hosted GitHub Actions runners, a Prometheus, Loki and Grafana monitoring stack, and several cluster add-ons. Each follows its own release and deprecation cycle.
Keeping up with those cycles took specialized DevOps expertise and ongoing attention, which pulled the team away from developing the product. Without regular maintenance, deprecated runner versions could break deployments, outdated add-ons would accumulate vulnerabilities, and EKS and RDS versions would move into more expensive AWS Extended Support. CI pipelines also relied on long-lived AWS credentials.
Dedicatted managed and monitored the client’s cloud infrastructure. We established six documented maintenance flows, each with a defined frequency, a clear upgrade procedure and a recommended next step. We maintained the monitoring stack behind VPN with alerts delivered to Slack, and set up GitHub Actions to access AWS via OIDC. Along the way, we kept the client informed about planned maintenance and recommended improvements. We also handed over documentation so the client’s own team could manage secrets, Amazon SES, CI access and alerting. The client got a predictable upgrade process and a long-term infrastructure partner, without hiring a full-time DevOps engineer.
The Challenge
The environment was small in footprint but made of many independently versioned components and each one had its own release and deprecation clock. Without a dedicated owner, that kind of setup drifts quietly and then fails expensively.
1.Too many lifecycles to track by hand. Amazon EKS, Amazon RDS, the GitHub Actions runners, the monitoring stack and several cluster add-ons (AWS Load Balancer Controller, Metrics Server, Cluster Autoscaler, External Secrets) all ship on separate schedules. Upgrading one often depends on the version of another, for example, add-ons must be compatible with the Kubernetes version the cluster moves to.
2. Version drift has a direct cost. AWS gives each Kubernetes version 14 months of standard support on EKS. After that, clusters move automatically into Extended Support, where the control plane fee rises from $0.10 to $0.60 per cluster per hour – six times more. Amazon RDS works the same way: databases on a major engine version past end of standard support are enrolled in RDS Extended Support and billed per vCPU-hour on top of the instance cost
3.Outdated runners can break delivery. GitHub requires self-hosted runners with auto-update turned off to be updated within 30 days of a new release; after that, GitHub Actions stops queuing jobs to them. For a team shipping through self-hosted runners, a missed update means deployments simply stop.
4. Unpatched add-ons accumulate vulnerabilities. Cluster components that sit at old versions collect known CVEs: an unacceptable position for a company whose own business is compliance.
5. Long-lived credentials in CI. CI pipelines authenticated to AWS with long-lived access keys. It is a common pattern, but static keys stored in CI must be rotated manually and, if leaked, give an attacker persistent access to the AWS account.
The goal: a reliable, predictable way to run all of this, with senior DevOps expertise on call, without hiring a full-time engineer, so the in-house team could stay focused on the product.
Technology & Approach
Pillar 1: A recurring maintenance framework
We replaced ad-hoc updates with six documented maintenance flows. Each flow has a defined frequency, a step-by-step upgrade procedure (including compatibility checks against the components it depends on) and a recommended next step, so every upgrade starts from a known state and ends with a plan for the next one.
The result is a predictable cadence: versions move forward on schedule instead of in emergencies, and the customer avoids deprecated releases, known vulnerabilities and Extended Support costs.

Pillar 2: Monitoring and Alerting
We maintained a full observability stack running inside the cluster:
- Prometheus (deployed via kube-prometheus-stack) collects metrics from the cluster, nodes and workloads.
- Loki stores logs, with Grafana Alloy as the collection agent shipping logs and telemetry from the cluster.
- Grafana brings metrics and logs together in one place for dashboards and troubleshooting.
- Slack alerting routes alerts straight to the team’s channel, so issues surface where engineers already work.
The monitoring endpoints are reachable only through AWS VPN, keeping operational data off the public internet
Pillar 3: Secure, streamlined CI/CD
We rebuilt the delivery pipeline around short-lived credentials and self-managed runners:
- OIDC federation instead of static keys. Each GitHub Actions workflow requests a signed OIDC token from GitHub and exchanges it with AWS STS for temporary credentials tied to an IAM role. No long-lived AWS access keys live in CI, so there is nothing to rotate and nothing persistent to leak.
- Self-hosted runners on Kubernetes. Runners are managed by Actions Runner Controller (ARC) on Amazon EKS, so CI capacity runs inside the customer’s own AWS environment.
- A controlled runner image. The runner image is built and pushed to Amazon ECR, giving every job the same, versioned toolchain and making runner updates part of the maintenance cycle.
Step 4: Zero-downtime EKS modernization
The Dedicatted Managed Services team worked inside the customer’s existing workflows. The customer received regular updates on ongoing work, advance notice of planned maintenance and recommendations for infrastructure improvements. Requests were handled promptly and within agreed timelines.
We also handed over documentation so the customer’s team can manage secrets, Amazon SES, CI access and alerting on its own, reducing dependency on any single person, including us.

Business impact
The customer gained a long-term infrastructure partner and a predictable, documented operating model, without adding a full-time DevOps engineer to the payroll.
- Predictable upgrades. Repeatable procedures for EKS, RDS, runners, monitoring and add-ons reduce the risk of running deprecated versions and paying EKS or RDS Extended Support fees.
- Visibility into the environment. A working Prometheus, Loki and Grafana stack, accessible only via VPN, with alerts delivered to Slack for faster troubleshooting.
- A more secure delivery pipeline. CI authenticates to AWS through OIDC with short-lived credentials, and runners use a controlled image stored in Amazon ECR.
- Team self-sufficiency. Documentation lets the customer’s engineers manage secrets, Amazon SES, CI access and alerting on their own.
- Focus on the product. With infrastructure operations handled, the in-house team put its time into development and other project priorities.

Is your EKS running on extended support?
Small Kubernetes environments are rarely complex – they are busy. A handful of components, each on its own release clock, is enough to create steady upgrade work that a product team cannot absorb. On AWS, letting that work slide is not free: EKS and RDS Extended Support turn version drift into a line on the bill. A managed services model fits this profile: a documented maintenance cadence, monitoring that is actually watched, and a secure delivery pipeline, delivered by an experienced team for a fraction of the cost of a dedicated hire. Talk to our experts today
