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

A developer has open-sourced a Multi-Cloud FinOps Engine built with Python and FastAPI that normalizes AWS, GCP, and Azure billing data into the FOCUS 1.0 standard and uses machine learning to detect cost anomalies. The engine is self-hosted to keep billing data private, and it streams large datasets to handle millions of rows efficiently.

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. 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. 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. The engine natively works with: 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: 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. 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. 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: through ThreadPools . The goal is to keep the FastAPI event loop responsive while the heavy work happens outside the main execution path. 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 entire system is designed with containerized and Kubernetes-based deployments in mind. 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. Cloud cost optimization shouldn't require manually jumping between: 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. 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 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: And, of course, tear the codebase apart. That's what open source is for. 🙂 Cloud waste rarely comes from one massive mistake. It's usually a collection of small things: 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. 🙃