Armakuni Contact us
← All case studies

One brand's biggest campaign
could slow the platform for everyone else.

A U.S. AI marketing platform ran global brands' campaigns on hardware that took weeks to add to. We moved it to AWS while the campaigns kept running, with 99.99% uptime through the migration. Then we went back and made it cheaper to run: GitOps releases for its services, four clean AWS accounts instead of nine, and compute down 48%.

Before

The busiest customer set the limit for everyone.

Every big customer brought a legal review.

After
40%lower latency
75%more capacity
50%faster feature delivery

From the migration and modernization, as the platform reported.

The busiest customer set the limit for everyone

The company's codeless AI platform lets global brands generate creative, choose audiences and optimize campaigns, with hundreds of campaigns running at once. Customers need current analytics while their campaigns run, even when another brand's traffic peaks.

The on-premises environment underneath was becoming the limit, because capacity took weeks to provision and a major campaign could use up infrastructure other customers depended on. Deployments needed manual coordination across staging, QA and production, and the cost base grew with hardware rather than with revenue.

Every big customer brought a legal review

The other limit was trust. Brand customers' legal and compliance teams ask exactly how consumer data, campaign datasets and ML models are accessed and shared, as a condition of signing. The platform couldn't answer those questions with its architecture, so reviews dragged on and held up enterprise deals.

The migration kept campaigns live and left the platform leaner afterward

There was never going to be a quiet weekend for this migration, because customers' campaigns don't stop. So the move had to happen in stages with the platform live. And once it was on AWS, the next problem was the bill and the release process, which needed their own round of work.

How we built it

7 decisions, in the order we made them. Each one says what we did and why, with what it did drawn beside it.

  1. The platform moved to AWS in stages while campaigns kept running
  2. Answer the legal team with architecture
  3. The team tested recovery and capacity before trusting the design
  4. Then: every service released the same way
  5. Nine accounts, split by what they're for
  6. Scale to real use, and see what it costs
  7. Security that doesn't depend on two people

The platform moved to AWS in stages while campaigns kept running

Built withEC2EKSKubernetesTerraform
Old hostingAWS DatabasesDatabasesServersServersServices on EKSServices on EKS 99.99% through the migration
The engineering

A traditional cutover would have meant a pause in live campaigns, and lost ad spend for customers, so the team used staged application and database migration instead, keeping the business live while workloads moved:

  • AWS Database Migration Service moved the databases, and AWS Server Migration Service moved the application servers.
  • Amazon EC2, with Auto Scaling and Elastic Load Balancing, gave capacity that expands with campaign traffic and shrinks after it.
  • Services were containerized on Amazon EKS (Kubernetes), so deployment and scaling decisions are made per service.
  • Terraform recorded environment configuration in version control, removing the manual differences between development, QA and production.

There were no scheduled outage windows, and uptime held at 99.99% through the migration and the operating period after it, because the platform runs other companies' campaigns and any gap during that time becomes their problem too.

Answer the legal team with architecture

Built withEKSS3RedisElastiCacheLambda
One platform BrandBrandBrand each customer's workloads isolated
The engineering

The controls sit in the runtime and storage layers, where an auditor can see them in place:

  • Role-based access and isolated EKS environments restrict access to each customer's workloads and datasets.
  • Amazon S3 stores models, datasets and static assets, with tagging policies for consistent data classification and governance.
  • Redis caching on Amazon ElastiCache cuts repeat work in the analytics path, alongside elastic compute for changing demand, so analytics come back inside the campaign rather than the next day.
  • AWS Lambda takes on event-driven integration and operational tasks that don't need dedicated always-on compute.

The team tested recovery and capacity before trusting the design

Built withCloudWatchSecurity HubCloudTrailAWS Backup
The new platformRecovery testedLoad testedCosts right-sized
The engineering

With containerized workloads and infrastructure as code in place, we added the controls the team needed to run it:

  • Amazon CloudWatch shows application and infrastructure behavior, for investigating performance and deciding capacity.
  • AWS Security Hub brings security findings into one view, and AWS CloudTrail records AWS activity for investigation and audit.
  • AWS Backup supports the recovery approach, and load testing shows how the platform behaves under demand, because a design document can't tell you that.
  • Cost visibility and right-sizing tie consumption to real workload needs as the customer moved away from fixed hardware.

Then: every service released the same way

Built withArgo CDEKSTerraform
ServiceServiceService One pipeline
The engineering

Once the platform was on AWS, the next bottleneck was shipping. Its services, more than 50 of them across four products, were deployed by hand, with each product running 15 to 30 services. We moved them onto Argo CD on Amazon EKS in about two months. Releases became GitOps: consistent, automated, with full history and rollback, and Terraform modules keep the infrastructure from drifting.

Nine accounts, split by what they're for

AccountAccountAccount… nine By purpose
The engineering

The infrastructure had spread across nine AWS accounts, with no clear line between production, staging and internal environments. We restructured it into four product-aligned AWS accounts, with dedicated accounts for shared services and security. That improved isolation and governance, and made billing readable by product for the first time.

Scale to real use, and see what it costs

Built withKarpenterKEDAEKS
Real useKarpenter nodes
The engineering

AI workloads were scaled by hand, so they were over-provisioned when quiet and slow during spikes:

  • Karpenter schedules pods onto the right nodes, and KEDA scales workloads on events.
  • The workloads moved to AMD-based instances in the Mumbai region, cutting waste for the AI workloads.
  • AWS cost tags and budget alerts track spend by product and team, with cost dashboards (AWS CUDOS) showing where money goes, so waste shows up early.
  • The EKS workloads were right-sized.

Security that doesn't depend on two people

Built withSecurity HubGuardDutyTerraformEKS
Security HubGuardDutyA finding Team alerts to Slack
The engineering

Security had relied on a few individuals, which made them a single point of failure. AWS Security Hub and Amazon GuardDuty now run across the accounts, with real-time Slack alerts for critical events, and the policies are enforced through Terraform. Prometheus and Grafana inside the EKS clusters show performance and resource use. Developers can also act on AWS and EKS from Slack, for example to stop idle resources, without extra tooling.

Why: a rule written in Terraform applies every time, while a rule that lives only in someone's head applies only when that person happens to be there.

What we'd tell another CTO

1When customers never pause, migrate in stages. DMS and SMS let the platform move while campaigns ran, and load testing proved the new capacity before any customer relied on it.
2Split the accounts by product before trying to cut the bill. Nine accounts with no clear lines made cost impossible to attribute, and the 48% compute saving came after the four-account structure, cost tags and event-driven scaling with KEDA and Karpenter were in place, scaling on events instead of CPU.

What else changed

From the migration and modernization, as the platform reported.

  • 99.99% uptime through the migration and the operating period after it, with no scheduled outage windows.
  • 25% lower infrastructure costs moving off fixed on-premises hardware, and 30% lower hardware costs from serverless automation and right-sized compute.

Then, from the release and cost work, as published on armakuni.com.

  • Cloud spend down 25%, and compute cost down 48%.
  • 99.996% uptime through the migration and cost work.
  • The services moved to GitOps releases in about two months, and nine AWS accounts realigned to four product accounts plus shared services and security.

What comes next

MLOps for the platform's own AI: model lifecycle, training-data lineage and inference auditability. Also automated right-sizing and forecasting, wider anomaly detection and budget alerts, and compliance mapped to regional and sector frameworks, so the platform can sell into regulated industries without reworking its architecture.

How we'd do it today

This project came before our current offers. Here's how we'd approach the same work now.

Two of our offers fit this platform directly, both run on AK AI Factory's controls. With Managed services, AK Run, which is AI-native, would have its AI agents take the first look at every alert and draft the fix, a named engineer would confirm the cause and ship it with a test, and Agent ControlPlane would make Amazon Bedrock AgentCore Gateway the only route to a model, recording who called which model and what it cost, while AWS Service Control Policies refuse any model that hasn't been approved, AWS CloudTrail ties each call to a person and AWS Cost Explorer shows cost by team. With AI Inference Engineering, the platform's routine model requests would move to a model it owns on Amazon SageMaker AI, at about a tenth of the price, while the hard ones stayed on a frontier model, which for a company whose product is AI goes straight to gross margin.

Modernize with AI AI-Native Managed Services AI Inference Engineering

More work like this

  1. AI MSP80–90%A global CRM and order-management providerless manual resource allocation, as reportedEvery busy day needed an engineer to add servers. Every quiet one needed an engineer to move customers back.7–8 weeks to move 900+ tasks and 5 servers to AWS<5 minutes to scale database workloadsOn AWS Secrets Manager · EKS · EC2 · CloudWatch
  2. AI MSP60 hoursA Canadian direct-to-consumer insurerto explain outages that had gone on for 6–10 monthsAn outage nobody could explain for months. Explained in 60 hours.~800 MySQL queries behind each request150 threads per server, the ceilingOn AWS RDS
  3. Modernization95%A U.S. live video auction platformless downtime across live auctions, as reportedThe biggest auction of the night was the one most likely to fall over.60% more revenue25% higher engagementOn AWS Lambda · ECS · Fargate · RDS

All case studies →

Have a problem like this one?

A free workshop: a few hours with the architects who'd do the work, on your own systems. No cost.

Book a free workshop