Armakuni Contact us
← All case studies

A campaign slipping on Monday
showed up in the numbers on Thursday.

A U.S. insurance lead-generation business tracked every consumer interaction to the click, and none of it could leave its production MySQL database. Every insight was a manual export. We gave it a governed AWS foundation, a data lake fed continuously from MySQL, and plain-language analytics leaders can use without an engineer.

Before

Click-level data, locked in one database.

Leaders queued behind engineers.

After
70%faster data access for non-technical leaders, as reported
45,000+consumer records in the data lake

Click-level data, locked in one database

The business runs digital lead generation and remarketing for the insurance industry. Its PHP application and MySQL database recorded every form fill, handoff and campaign touchpoint, at the click level.

None of that could reach another tool. It couldn't feed a model or a dashboard. Comparing traffic sources meant exports and joins by hand, with no shared definition of the measures campaign teams wanted to compare. By the time a trend was visible, the campaign had moved on, and bids, carrier choices and targeting were set on old data.

Leaders queued behind engineers

Every data question needed an engineer and became a ticket. The leaders who most needed the numbers couldn't get them without going through someone else.

Underneath, the AWS environment had grown without a plan: no landing zone, no shared access model, and production sitting beside everything else. Connecting anything to the data meant connecting to production. And the company wanted to bring its email in-house, but Amazon SES had turned down its use case, leaving no obvious AWS route.

Separate the data from production, then let anyone ask

The order was foundation first, before any BI: govern the accounts, move the data out of production into a lake built for analysis, and only then put analytics on top. That way, every later tool, such as a dashboard, a model or an email engine, plugs into one governed layer rather than into production.

How we built it

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

  1. One management plane, before any data moves
  2. MySQL changes stream into a separate analytics lake
  3. Campaign definitions become QuickSight Q topics
  4. An email platform the business owns

One management plane, before any data moves

Built withControl TowerIdentity CenterSecurity HubS3
Control Tower: one plane DataAI/MLAnalyticsSandbox separate accounts, one set of guardrails
The engineering

We restructured the environment into a proper multi-account landing zone:

  • AWS Control Tower brought every account under one management plane, with consistent guardrails and centralized billing.
  • Identity Center supplies single sign-on (SSO) and standard roles (Admin, Developer and Read-Only) across every account.
  • Separate accounts for data, AI/ML, analytics and sandbox workloads keep experiments away from live data.
  • Security Hub and a dedicated security account centralize findings across the organization.
  • Cross-region S3 replication supports disaster recovery from the start.

Why: every workload after this one inherits these boundaries, so this is the cheapest place to get them right.

MySQL changes stream into a separate analytics lake

Built withDMSMySQLKinesis Data FirehoseS3GlueAthena
MySQL changesDMS and FirehoseThe S3 lakeAthena for analysts
The engineering

The data needed to leave production without anyone exporting it:

  • AWS DMS captures changes from MySQL, and Kinesis Data Firehose delivers them into S3 with date-based partitions, so the interaction history is available beyond the production database.
  • Glue catalog tables describe prospect interactions and campaigns, and EMR Spark jobs produce enriched datasets, including engagement measures and campaign aggregates.
  • Lake Formation controls which workloads can see which datasets, and Athena gives analytics and machine learning one common query interface.
  • The platform holds more than 45,000 consumer records, with raw and enriched datasets available through the governed analytics layer.

Campaign definitions become QuickSight Q topics

Built withQuickSightIdentity CenterAthena
A campaign question QuickSight Q topics defined answers
The engineering

Natural-language questions only work if the system knows what "lead quality" means to the business. Amazon QuickSight dashboards cover campaign performance, lead quality and engagement, with views for the organization and for each customer. The team built QuickSight Q Topics around the questions the business actually asks, and refined the definitions against the underlying datasets.

QuickSight signs users in through Identity Center, so each person sees a governed view for their role, and dashboards read live data through Athena. Scheduled reports send the right views to internal teams. An integration with the existing PHP bidding and configuration systems brings operational changes into the reporting, so a decision can be seen beside its results. With bids and their results in the same view, a team can see what its decisions actually did.

An email platform the business owns

Built withPostgreSQLSageMaker
next phaseAn email platform it ownsIts own sendingReplies sorted as they come
The engineering

With SES not an option, we designed an owned email platform: outbound campaign sequences, classification of replies, interaction history and reporting. It includes dedicated sending infrastructure and email authentication, a PostgreSQL interaction store, and SageMaker-based segmentation and send-time optimization. Deploying the email platform and its models is the next phase.

What we'd tell another CTO

1Build the account structure before the data platform, because everything after it inherits the boundaries. And stream from production instead of querying it: DMS and Firehose kept analytics off the live database.
2Give natural language the business's own definitions in Q Topics, and put decisions beside their results, as the bidding changes in the reporting did. When the obvious service said no, we designed around it, and an owned email platform replaced the blocked route.

What else changed

  • A governed landing zone: one management plane, single sign-on with standard roles, separated accounts, centralized security and cross-region recovery.
  • Dashboards and Q Topics built on the business's own definitions, with scheduled reports and bidding changes alongside results.
  • A designed email platform, ready to build.

What comes next

The owned email platform and its models, and QuickSight extended into analytics the company's own customers can use.

How we'd do it today

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

Axiom would give "lead", "qualified lead" and "conversion" one meaning in a catalogue on Amazon DataZone, so every AI agent and every dashboard reads them the same way, with row-level access through AWS Lake Formation. The send-time and segmentation models would have to beat today's results on a golden set of past campaigns with their real outcomes, and on a sealed set nobody tunes to, before going live.

Classifying replies and drafting follow-ups is AI agent work, and a reply is untrusted input, because one hidden instruction in an email can steer an AI agent. So each AI agent would get its own identity and only the tools it needs, and none that reads replies could also send data out on its own. AK Run's AI agents would take the first look at every pipeline alert and draft the fix, for a named engineer to confirm and ship with a test.

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