Cloud Cost Optimization Platform

A fast-growing 200-person B2B SaaS company was managing $2.3M in annual cloud spend across AWS, GCP, and Azure — but had zero unified visibility. Finance manually exported CSV files from three billing consoles, spending 15+ hours per week reconciling different currencies, service names, and region codes — and two days at every month-end producing the consolidated report. By the time they produced reports, the data was 48 hours old and budget overruns had already happened.

The real cost wasn't wasted time — it was missed opportunities. A development environment had been running unnoticed for three months — $24,600 — and was only found when the platform's first collection run flagged it. Reserved instance coverage sat at 12% because nobody could track utilization across providers. EC2 instances ran at 8% CPU. Storage volumes sat unattached. Cost anomalies went undetected for weeks.

When their CFO demanded better — current visibility by customer, feature, and team, with alerts before budget overruns — they evaluated enterprise FinOps platforms. One enterprise FinOps suite quoted ~$50K/year. Another needed a six-month rollout. Neither fit a 127-account environment that needed answers in weeks, at a price that made sense against $2.3M of spend.

They needed production-grade multi-cloud visibility without enterprise pricing or timeline.

We built a cloud-native, multi-tenant cost optimization platform that unifies AWS, GCP, and Azure into one view. Near-real-time collection every 15 minutes, ingestion-time normalization, statistical forecasting, automated anomaly detection, and actionable savings recommendations — all running at $239/month in infrastructure run cost (excluding the one-time build).

The architecture follows three guiding principles: separate what changes from what doesn't (provider-specific logic isolated behind clean interfaces), optimize for the common path (pre-aggregated views for fast dashboards, async pipelines for slow provider APIs), and treat cost as a first-class constraint (every service choice evaluated against a $300/month infrastructure budget). The result delivers the capabilities of an enterprise FinOps suite at a fraction of its run cost.

This architecture powers six core capabilities that work together to give finance and engineering teams complete control over their multi-cloud spend.

No more CSV exports. No more billing console hopping. No more budget surprises.

The platform handles two fundamentally different workloads: interactive dashboard queries that must respond in under 500 ms, and background data collection from cloud provider APIs that can take up to 30 seconds per request. Rather than forcing both through the same path, we designed separate, optimized pipelines — a fast synchronous path for user-facing requests and an async queue-driven pipeline for data ingestion — connected through a shared data layer with pre-computed views.

The three diagrams below trace a request through each path and show how our multi-cloud abstraction layer normalizes data from providers with fundamentally different APIs, rate limits, and data models.

While dashboards serve pre-computed data in milliseconds, the real complexity lives in how that data gets collected, normalized, and analyzed behind the scenes. The collection pipeline runs every 15 minutes, processing data from 127 cloud accounts across three providers without ever blocking a user request.

The hardest engineering problem wasn't building the pipeline — it was making three fundamentally different cloud APIs look identical to the rest of the system. AWS, GCP, and Azure use different authentication models, return data in different formats, and enforce rate limits that vary by 50×. The abstraction layer below is what makes "multi-cloud" a reality rather than a marketing claim.

Building a working prototype is straightforward. Building a system that handles sensitive financial data across 127 cloud accounts — where a security breach exposes cost structures, a data loss corrupts compliance records, or a silent failure means missed budget alerts — requires a fundamentally different engineering approach.

We designed three production layers from day one, not as afterthoughts bolted onto a prototype: a data architecture with strict tenant isolation and encryption at every boundary, resilience patterns that gracefully handle the inevitable failures of external cloud APIs, and a high-availability infrastructure with full observability so the client's existing platform team can operate it confidently without a dedicated FinOps engineer.

Security protects data at rest. Resilience protects the system in motion — when cloud provider APIs throttle requests, return errors, or go down entirely. The platform interacts with external APIs thousands of times per day, and each call is an opportunity for failure. The patterns below ensure that no single provider outage, API timeout, or rate limit breach can compromise data integrity or degrade the user experience.

Resilience patterns handle individual failures. The infrastructure layer ensures the entire platform stays available — even when an AWS Availability Zone goes down — and gives the operations team clear visibility into system health without requiring 24/7 manual monitoring.

After six months in production managing $2.3M in annual cloud spend across 127 accounts, the platform has delivered measurable impact across every dimension the client's CFO originally defined as success criteria. The numbers below are a production snapshot at month six: latency and uptime are measured; savings are labelled identified (found and quantified by the platform) rather than realised, and the reserved-instance and Savings Plan coverage gap flagged in the Challenge is the platform's next recommendation.

What the client received. The platform's source and infrastructure-as-code, the CloudWatch dashboards and alert definitions, runbooks for the failure modes described above, the decision notes behind every "Key Design Decision" on this page, and a handoff to their own platform team — the system is theirs to run, extend, or replace.