{"slug": "i-got-tired-of-surprise-aws-bills-so-i-open-sourced-a-multi-cloud-finops-engine", "title": "I got tired of surprise AWS bills, so I open-sourced a Multi-Cloud FinOps Engine.", "summary": "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.", "body_md": "Let's be honest.\n\n**Cloud billing is broken.**\n\nIf 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.\n\nBy 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.\n\nI got tired of this.\n\nI wanted a simple way to just ping a single API and ask:\n\n\"Am I spending money on something stupid today?\"\n\nSo, I built one.\n\nAnd today, I'm **open-sourcing it.**\n\nI 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.\n\nThe goal is simple:\n\n**One API. Multiple clouds. One normalized view of your cloud spend.**\n\nHere's what I prioritized while building it.\n\nYou shouldn't have to send sensitive billing telemetry to a third-party startup just to understand your own cloud spending.\n\nThe engine is designed to be **self-hosted**.\n\nYour billing data stays within your infrastructure.\n\nNo external FinOps SaaS dependency.\n\nThe engine natively works with:\n\nInstead of maintaining three completely different billing implementations, the engine brings the data into a common model.\n\nThat makes it much easier to answer questions like:\n\nOne of the biggest challenges with multi-cloud FinOps is that every cloud provider represents cost data differently.\n\nAWS, GCP, and Azure all have different billing schemas, dimensions, terminology, and metadata.\n\nThe engine normalizes the data into the **FOCUS 1.0** standard so downstream applications don't need completely different logic for every cloud provider.\n\nThis gives you a consistent foundation for analytics and automation.\n\nBilling datasets can become **huge**.\n\nIf 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.\n\nIn the `v1.1.0`\n\nrelease, I implemented FastAPI `StreamingResponse`\n\ngenerators for large billing exports.\n\nInstead of doing this:\n\n```\nLoad everything → Store everything in RAM → Return response\n```\n\nthe API can stream the data progressively:\n\n```\nFetch → Generate → Stream → Repeat\n```\n\nThis allows the engine to handle **millions of rows of billing telemetry** without unnecessarily spiking RAM usage.\n\nRunning Scikit-Learn models such as **Isolation Forest** against large datasets can become expensive.\n\nAnd if you run CPU-heavy workloads directly inside your FastAPI event loop, you can quickly turn your asynchronous API into a bottleneck.\n\nTo avoid that, I routed:\n\nthrough **ThreadPools**.\n\nThe goal is to keep the FastAPI event loop responsive while the heavy work happens outside the main execution path.\n\nAt a high level, the flow looks like this:\n\n```\n                   ┌─────────────────────┐\n                   │      API Client     │\n                   └──────────┬──────────┘\n                              │\n                              ▼\n                   ┌─────────────────────┐\n                   │     FastAPI API     │\n                   └──────────┬──────────┘\n                              │\n              ┌───────────────┼────────────────┐\n              │               │                │\n              ▼               ▼                ▼\n        ┌──────────┐    ┌──────────┐    ┌──────────┐\n        │   AWS    │    │   GCP    │    │  Azure   │\n        │   Cost   │    │ BigQuery │    │   Cost   │\n        │ Explorer │    │ Billing  │    │Management│\n        └────┬─────┘    └────┬─────┘    └────┬─────┘\n             │               │                │\n             └───────────────┼────────────────┘\n                             ▼\n                  ┌─────────────────────┐\n                  │  FOCUS 1.0          │\n                  │  Normalization      │\n                  └──────────┬──────────┘\n                             │\n                  ┌──────────┴──────────┐\n                  ▼                     ▼\n          ┌──────────────┐      ┌──────────────┐\n          │ Cost Analysis│      │ ML Anomaly   │\n          │              │      │ Detection    │\n          └──────────────┘      └──────────────┘\n```\n\nThe idea is to keep the provider-specific logic at the ingestion layer and expose a consistent interface to everything above it.\n\nThe entire system is designed with containerized and Kubernetes-based deployments in mind.\n\nThe **core aggregation API** and **FOCUS 1.0 normalization** are completely free and open-source.\n\nFor enterprise teams that need more advanced capabilities, I've implemented a cryptographic **RS256 JWT license gate** for the advanced rightsizing engines.\n\nThe idea is to keep the foundation open while providing a path for organizations that need enterprise-level FinOps capabilities.\n\nCloud cost optimization shouldn't require manually jumping between:\n\nI wanted something that could answer a much simpler question:\n\n\"What's costing me money, and is anything unusual happening right now?\"\n\nThat's the problem I'm trying to solve.\n\nThe project is open-source, and I'd genuinely love feedback.\n\nYou can check out the repository here:\n\n**GitHub:** [https://github.com/priyaranjan-sahu/multi-cloud-finops](https://github.com/priyaranjan-sahu/multi-cloud-finops)\n\nIf you're running AWS, GCP, or Azure, try it against your own environment.\n\nI'd especially love feedback on:\n\nAnd, of course, **tear the codebase apart.**\n\nThat's what open source is for. 🙂\n\nCloud waste rarely comes from one massive mistake.\n\nIt's usually a collection of small things:\n\nIndividually, they don't look like much.\n\nTogether, they can become a surprisingly large bill.\n\nSo I'd love to hear from you:\n\n**What's the worst cloud billing horror story you've experienced?**\n\nMine was leaving an **unattached Elastic IP running for six months.**\n\n🙃", "url": "https://wpnews.pro/news/i-got-tired-of-surprise-aws-bills-so-i-open-sourced-a-multi-cloud-finops-engine", "canonical_source": "https://dev.to/priyaranjansahu/i-got-tired-of-surprise-aws-bills-so-i-open-sourced-a-multi-cloud-finops-engine-1ckc", "published_at": "2026-08-28 15:20:48+00:00", "updated_at": "2026-08-28 15:50:28.000511+00:00", "lang": "en", "topics": ["developer-tools", "machine-learning"], "entities": ["AWS", "GCP", "Azure", "FOCUS 1.0", "FastAPI", "Python", "Scikit-Learn", "Isolation Forest"], "alternates": {"html": "https://wpnews.pro/news/i-got-tired-of-surprise-aws-bills-so-i-open-sourced-a-multi-cloud-finops-engine", "markdown": "https://wpnews.pro/news/i-got-tired-of-surprise-aws-bills-so-i-open-sourced-a-multi-cloud-finops-engine.md", "text": "https://wpnews.pro/news/i-got-tired-of-surprise-aws-bills-so-i-open-sourced-a-multi-cloud-finops-engine.txt", "jsonld": "https://wpnews.pro/news/i-got-tired-of-surprise-aws-bills-so-i-open-sourced-a-multi-cloud-finops-engine.jsonld"}}