I got tired of surprise AWS bills, so I open-sourced a Multi-Cloud FinOps Engine.

Let's be honest.

Cloud billing is broken.

If you're running an engineering team across AWS, GCP, and Azure, trying to figure out exactly what's costing you money can sometimes feel like you need a PhD in spreadsheet management.

By the time you realize that a forgotten database cluster has been burning $50 a day, the month is already over and the invoice has already been generated.

I got tired of this.

I wanted a simple way to just ping a single API and ask:

"Am I spending money on something stupid today?"

So, I built one.

And today, I'm open-sourcing it.

Meet the Multi-Cloud FinOps Engine

I built a unified Python + FastAPI engine that connects to your cloud accounts, normalizes billing data into the FOCUS 1.0 standard, and uses local machine learning to detect cost anomalies.

The goal is simple:

One API. Multiple clouds. One normalized view of your cloud spend.

Here's what I prioritized while building it.

1. No External SaaS

You shouldn't have to send sensitive billing telemetry to a third-party startup just to understand your own cloud spending.

The engine is designed to be self-hosted.

Your billing data stays within your infrastructure.

No external FinOps SaaS dependency.

2. True Multi-Cloud Support

The engine natively works with:

• AWS Cost Explorer
• GCP BigQuery Billing Exports
• Azure Cost Management

Instead of maintaining three completely different billing implementations, the engine brings the data into a common model.

That makes it much easier to answer questions like:

• Which cloud is costing us the most?
• Which service increased spending this week?
• Where are our biggest cost anomalies?
• What resources are unexpectedly expensive?

3. FOCUS 1.0 Normalization

One of the biggest challenges with multi-cloud FinOps is that every cloud provider represents cost data differently.

AWS, GCP, and Azure all have different billing schemas, dimensions, terminology, and metadata.

The engine normalizes the data into the FOCUS 1.0 standard so downstream applications don't need completely different logic for every cloud provider.

This gives you a consistent foundation for analytics and automation.

4. Zero Memory Spikes During Large Exports

Billing datasets can become huge.

If you're dealing with millions of rows, loading the entire dataset into memory before returning it is a great way to make your API server unhappy.

In the v1.1.0 release, I implemented FastAPI StreamingResponse generators for large billing exports.

Instead of doing this:

Load everything → Store everything in RAM → Return response

the API can stream the data progressively:

Fetch → Generate → Stream → Repeat

This allows the engine to handle millions of rows of billing telemetry without unnecessarily spiking RAM usage.

5. Non-Blocking Machine Learning

Running Scikit-Learn models such as Isolation Forest against large datasets can become expensive.

And if you run CPU-heavy workloads directly inside your FastAPI event loop, you can quickly turn your asynchronous API into a bottleneck.

To avoid that, I routed:

• Machine learning workloads
• External cloud SDK calls
• Other blocking operations

through ThreadPools.

The goal is to keep the FastAPI event loop responsive while the heavy work happens outside the main execution path.

The Architecture

At a high level, the flow looks like this:

                   ┌─────────────────────┐
                   │      API Client     │
                   └──────────┬──────────┘
                              │
                              ▼
                   ┌─────────────────────┐
                   │     FastAPI API     │
                   └──────────┬──────────┘
                              │
              ┌───────────────┼────────────────┐
              │               │                │
              ▼               ▼                ▼
        ┌──────────┐    ┌──────────┐    ┌──────────┐
        │   AWS    │    │   GCP    │    │  Azure   │
        │   Cost   │    │ BigQuery │    │   Cost   │
        │ Explorer │    │ Billing  │    │Management│
        └────┬─────┘    └────┬─────┘    └────┬─────┘
             │               │                │
             └───────────────┼────────────────┘
                             ▼
                  ┌─────────────────────┐
                  │  FOCUS 1.0          │
                  │  Normalization      │
                  └──────────┬──────────┘
                             │
                  ┌──────────┴──────────┐
                  ▼                     ▼
          ┌──────────────┐      ┌──────────────┐
          │ Cost Analysis│      │ ML Anomaly   │
          │              │      │ Detection    │
          └──────────────┘      └──────────────┘

The idea is to keep the provider-specific logic at the ingestion layer and expose a consistent interface to everything above it.

The Stack

API

• FastAPI
• Pydantic v2

Data & Machine Learning

• Pandas
• Scikit-Learn
• Isolation Forest

Infrastructure

• Docker
• Kubernetes
• KEDA for autoscaling
• Terraform

The entire system is designed with containerized and Kubernetes-based deployments in mind.

The "Open Core" Model

The core aggregation API and FOCUS 1.0 normalization are completely free and open-source.

For enterprise teams that need more advanced capabilities, I've implemented a cryptographic RS256 JWT license gate for the advanced rightsizing engines.

The idea is to keep the foundation open while providing a path for organizations that need enterprise-level FinOps capabilities.

Why I Built This

Cloud cost optimization shouldn't require manually jumping between:

• AWS Cost Explorer
• GCP Billing
• Azure Cost Management
• Spreadsheets
• Dashboards
• Custom scripts
• And five different browser tabs

I wanted something that could answer a much simpler question:

"What's costing me money, and is anything unusual happening right now?"

That's the problem I'm trying to solve.

Try It Yourself

The project is open-source, and I'd genuinely love feedback.

You can check out the repository here:

GitHub: https://github.com/priyaranjan-sahu/multi-cloud-finops

If you're running AWS, GCP, or Azure, try it against your own environment.

I'd especially love feedback on:

• Architecture
• FOCUS 1.0 normalization
• Multi-cloud cost modeling
• Anomaly detection
• Performance
• Kubernetes deployment
• FinOps workflows

And, of course, tear the codebase apart.

That's what open source is for. 🙂

Final Thoughts

Cloud waste rarely comes from one massive mistake.

It's usually a collection of small things:

• An unattached resource
• An oversized instance
• An idle database
• A forgotten environment
• A test cluster that nobody shut down
• A resource that quietly grew over time

Individually, they don't look like much.

Together, they can become a surprisingly large bill.

So I'd love to hear from you:

What's the worst cloud billing horror story you've experienced?

Mine was leaving an unattached Elastic IP running for six months.

🙃