Armakuni Contact us
← All case studies

Reports could only refresh from 6 a.m. to 7 p.m.
Outside those hours, everyone read yesterday.

A healthcare care-management software provider ran its reporting through two ETL vendors, hand-run scripts and a warehouse that no longer fit, across the U.S. and Canada. In a four-to-five-week MySQL-to-Redshift proof of value, on sample data and outside production, we tested one AWS-native pipeline: one ingestion pattern, transformations inside the warehouse, refreshes on a schedule rather than a reporting tool's hours, and the regional boundary kept intact. The customer paid $1,700 of the $10,000 cost.

Before

Every new database was another integration.

Reporting kept office hours.

After
Any hourfor scheduled refreshes, where extracts had to fit 6 a.m. to 7 p.m.
  • A measured comparison of Redshift Serverless and provisioned capacity on its own BI workload.

Every new database was another integration

The company's platform supports care providers across the United States and Canada, with Amazon RDS MySQL databases in three regions. Its reporting ran through two different vendors: U.S. data used Hevo, while the Canadian operation used Fivetran, and both fed a Snowflake environment. Every schema change, or every new client database, meant coordinating two tools across two separate systems.

Coverage was incomplete, because only the databases someone had configured for extraction made it into reporting. Python scripts, run by hand on EC2, pushed the rest in, with no scheduler, no lineage and no way to confirm a load had worked.

Reporting kept office hours

Tableau extracts ran only between 6:00 a.m. and 7:00 p.m., so a report outside that window used stale data, a side effect of the infrastructure that nobody had chosen for the product.

There was a compliance question too. Healthcare data-residency obligations need a clear line between U.S. and Canadian data, and nothing in the pipeline could show that line was kept.

One pattern, tested before anything changes

The answer was one AWS-native pipeline pattern that any database, in any account, could join, with the regional boundary built into it. And because this was patient-care data, the proof had to happen on sample data in separate accounts, never on the live systems.

How we built it

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

  1. Two sample databases, two accounts, one ingestion pattern
  2. Freshness, regional separation and extract reliability

Two sample databases, two accounts, one ingestion pattern

Built withSnowflakeTableauRDSMySQLDMSRedshift
MySQL, account 1MySQL, account 2 Redshift one ingestion pattern
The engineering

The proof of value used sample datasets in separate AWS accounts. It did not connect to the live customer databases, the Snowflake environment or the production Tableau dashboards:

  • Data from two RDS MySQL databases in separate accounts entered one common ingestion pattern through AWS Database Migration Service (DMS), a single AWS-managed service in place of two vendor tools.
  • Amazon Redshift was the target warehouse, with Serverless and provisioned/reserved-capacity options compared against the customer's real BI workload patterns, so the production choice is based on measurement.
  • Two to three mid-complexity transformations ran inside Redshift, taking processing away from manually run EC2 scripts.
  • Scheduled queries, with zero-ETL integration, set the refresh cadence independently of the old Tableau extract window.

The team compared the Redshift output with the selected Python transformations before deciding whether to retire the existing ETL paths. The rule was that the new path had to reproduce the old one's numbers before anything was switched off.

Freshness, regional separation and extract reliability

Built withMySQL
Each extractFreshnessU.S. and Canada kept apartExtract reliability
The engineering

Validation followed the data from MySQL through ingestion and transformation into the reporting output, for data freshness, regional separation between U.S. and Canadian data and extract reliability, against the customer's compliance and operational requirements.

The work also set a repeatable cross-account connection pattern for onboarding more customer databases, so a new client or a new region reuses the pattern and needs no engineering project of its own. Documentation and training sessions gave the internal data team what it needs to run and extend the design.

Why: data residency is easier to prove when the architecture enforces it than when a process promises it.

What we'd tell another CTO

1Prove a data platform on sample data, in separate accounts, before anything live is at risk, and measure serverless against provisioned capacity on your own BI workload instead of a rule of thumb.
2Where two vendor tools do the same job, one pattern should replace both, because otherwise every change is coordinated twice. Transformations belong in the warehouse too, since a script run by hand on EC2 leaves no lineage.
3Build the residency boundary into the architecture, so it's something you can show an auditor.

What else changed

  • A validated reference architecture for one ingestion and transformation pattern across AWS accounts and regions.
  • Regional separation, freshness and extract reliability validated on sample data.
  • Documentation and training for the internal data team, and a production decision it can make from evidence.
  • AWS funding of $8,300 against a $10,000 cost, so the customer paid $1,700.

What comes next

Rollout across the customer databases and regions, followed by retiring the remaining manual scripts and the old integration paths.

How we'd do it today

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

With the data in one warehouse, Axiom would keep one catalogue on Amazon DataZone so every AI agent and report reads "visit", "client" and "caregiver" the same way, with AWS Lake Formation enforcing the regional boundary as a rule on rows. The remaining databases would move in waves on our AWS method: AI agents find every database and whatever quietly reads it, dependent workloads move together, and the old path keeps running until the new one has closed a month-end.

Once it's live, AK Run's AI agents would take the first look at every pipeline alert and draft the fix, and a named engineer would confirm the cause and ship it with a test, while AK AI Factory's controls record their own evidence for the residency obligation as they run.

Modernize with AI AI-Native Managed Services

More work like this

  1. DataPlain EnglishA Canadian eCommerce analytics platformquestions answered with a chartSix attribution models, and no one in the shop to read them.70–80 web pages tested for ranked fixes2–3 dashboards in the first proof of valueOn AWS QuickSight · Lambda · S3 · Fargate
  2. Data40%A U.S. outdoor and fitness brandhigher return on targeted campaigns, as reportedThe same customer bought the gear, ran the event and joined the club. The brand saw three strangers.2× loyalty participation5× engagement across channelsOn AWS DynamoDB · Redshift · Glue · CloudWatch
  3. DataWorkingA U.S. data intelligence companyclean-room prototype, with every security boundary testedIts value was in combining data with partners. Every partnership started from scratch.4–6 weeks to a working clean-room prototype2 machine-learning patterns inside the clean roomOn AWS Redshift · Glue · S3 · Athena

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