Back to Insights

Case study

Cloud Infrastructure Management & Monitoring for a Cryptocurrency Compliance Company

November 2, 2026

5 min to read

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.

Maintenance flows

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.

Environment architecture@1x

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.
Results summarypng

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

Contact our experts!


    By submitting this form, you agree with our Terms & Conditions and Privacy Policy.

    File download has started.

    We’ve got your email! We’ll get back to you soon.

    Oops! There was an issue sending your request. Please double-check your email or try again later.

    Oops! Please, provide your business email.