Skip to content
Notifications
Clear all

Results after forcing our agency to use our own analytics tools

1 Posts
1 Users
0 Reactions
1 Views
(@cost_cutter_ray)
Estimable Member
Joined: 2 months ago
Posts: 113
Topic starter   [#6873]

A recent, and frankly painful, internal audit of our martech analytics infrastructure revealed a staggering degree of cost leakage and architectural inefficiency. Our agency, which operates at a scale of approximately 2.5 billion monthly events and a hybrid business model of managed services plus a proprietary SaaS platform, was provisioning analytics tools for clients through a patchwork of third-party vendors. The decision was made to mandate the use of our own consolidated analytics stack, built on AWS, for all client engagements. The financial and operational results were illuminating, and I believe they serve as a critical case study for any organization operating at a similar scale.

The primary cost drivers we identified in the previous multi-vendor model were:
* **Data Egress and Duplication:** Each vendor ingested the same raw event streams, multiplying bandwidth and processing costs. The egress fees alone, when clients needed to access their own data, were a significant and often hidden line item.
* **Inflexible Pricing Tiers:** We were consistently over-provisioned on "enterprise" plans to accommodate peak traffic for a subset of clients, paying for capacity that sat idle for the majority.
* **Opaque Compute Allocation:** We had zero visibility into the underlying compute resources (e.g., Kinesis Shards, Lambda invocations, Redshift clusters) our spend was actually funding, making optimization impossible.

Our migration path involved building a core pipeline on AWS, designed with cost as a first-class architectural principle:
* **Ingestion:** API Gateway & AWS Lambda for initial receipt and validation, writing raw payloads to S3 (Infrequent Access tier after 30 days).
* **Transformation & Enrichment:** A purpose-built, auto-scaling ECS Fargate cluster running our enrichment logic, triggered by S3 Event Notifications. We use a mix of Spot and Reserved capacity here.
* **Query Layer:** Amazon Athena for ad-hoc exploration and aggregated datasets moved to Aurora Serverless for dashboard and application consumption.

The configuration for our cost-critical Fargate service is emblematic of the approach:

```json
{
"serviceName": "event-enrichment",
"capacityProviderStrategy": [
{
"capacityProvider": "FARGATE_SPOT",
"weight": 4,
"base": 0
},
{
"capacityProvider": "FARGATE",
"weight": 1,
"base": 1
}
],
"taskDefinition": "enrichment-task:5",
"schedulingStrategy": "REPLICA",
"deploymentConfiguration": {
"maximumPercent": 200,
"minimumHealthyPercent": 50
}
}
```

The outcomes, measured over a full quarter post-migration, were as follows:
* **Direct Infrastructure Cost Reduction:** 67% decrease in our core analytics infrastructure spend, moving from a blended vendor cost of ~$84k/month to a fully allocated AWS cost of ~$28k/month.
* **Granular Cost Allocation:** We can now attribute costs down to the individual client project via AWS Cost Allocation Tags (e.g., `ProjectID`, `ClientName`, `Environment`), enabling true showback and informing our pricing strategy.
* **Performance & Latency:** The 95th percentile latency for data availability in the query layer improved from 12 minutes to under 90 seconds, a function of removing multiple intermediary vendor queues and batch processes.

The critical takeaway is that for businesses operating at a high event volume with a service-based model, the economic and strategic advantages of controlling your own analytics destiny are profound. The initial engineering investment was recouped in under five months. The leverage gained from applying FinOps principles—right-sizing, committing via Savings Plans for the base Fargate load, and utilizing Spot capacity for interruptible workloads—transformed this stack from a cost center into a competitive moat.

- cost_cutter_ray


Every dollar counts.


   
Quote