DEV Community: Priya Ranjan Sahu

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

Priya Ranjan Sahu — Fri, 28 Aug 2026 15:20:48 +0000

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.

🙃

One storage security audit suite for Azure, AWS, and GCP

Priya Ranjan Sahu — Wed, 19 Aug 2026 10:38:54 +0000

Every cloud environment I've touched has the same two storage problems: a bucket someone made public and forgot, and a storage account that should be behind a private endpoint but isn't. The checks differ slightly per provider, but the question is always the same — "is this storage reachable by someone who shouldn't see it?"

I got tired of answering that question with ad-hoc scripts that died in one environment and were rewritten in the next. So I built one suite that covers all three clouds and writes every result to the same CSV/JSON shape.

What it checks

AWS (S3) — the three ways a bucket becomes public:

Public Access Block fully enabled
Bucket policy reported as IsPublic
ACL grants to AllUsers / AuthenticatedUsers

Plus a security-config audit for default encryption (SSE-S3/SSE-KMS) and versioning.

GCP (Cloud Storage) — IAM bindings to allUsers / allAuthenticatedUsers, uniform bucket-level access, and public access prevention.

Azure (Storage Accounts) — accounts with and without Private Endpoints, plus TLS version, secure transfer, and public network access posture.

Everything is read-only. No module creates, modifies, or deletes anything — you run it, get a report, fix what it flags.

Running it

# AWS: only the public buckets, as JSON
python aws/s3/audit-public-buckets/audit_public_buckets.py --only-public --format json --output-file public.json

# GCP: security configuration matrix
python gcp/storage/audit-security-config/audit_bucket_security.py --project my-project --output-file compliance.csv

# Azure: storage accounts with no private endpoint
./azure/storage/audit-missing-private-endpoints/audit-storage-without-pe.ps1 -OutputPath exposed.csv

The Azure side also ships Bash and KQL variants so you can run the same check from Resource Graph in the portal.

The report contract

Every module writes the same shape — CSV or JSON — with a boolean "finding" column you actually act on:

Provider	Finding column
AWS public buckets	`is_public`
AWS / GCP security config	`hardened`
GCP public IAM	`public`
Azure (no PE)	`PrivateEndpointCount == 0`

Summaries go to stderr, so stdout stays clean for automation. Redacted example outputs for every module are in docs/samples/, and the full field contract is in docs/report-format.md.

The bug that cost me half a day

The AWS and GCP scripts in each provider are named the same — audit_public_buckets.py, audit_bucket_security.py. That's fine until your test files import both. Python imports by module name, so once pytest cached the AWS version, the GCP tests silently imported the wrong code and failed with the most confusing TypeError.

The fix was loading the modules by explicit file path instead of leaning on sys.path:

spec = importlib.util.spec_from_file_location(name, path)
module = importlib.util.module_from_spec(spec)
spec.loader.exec_module(module)

Half a day, gone, over a naming collision.

Keeping it honest

Pester validates the Azure modules (parse, parameters, read-only guarantees)
pytest (mocked cloud clients) covers the AWS/GCP modules
CI runs PSScriptAnalyzer, ShellCheck, ruff, markdownlint, and yamllint on every push
Test coverage sits at 85% and is published via Codecov

The first CI run failed in four jobs at once — the lesson being that lint rules move under you (a newer PSScriptAnalyzer started flagging Write-Host as a warning I'd never seen before).

Where it lives

The whole thing is free and open source:

https://github.com/priyaranjan-sahu/multi-cloud-automation-scripts

If you manage storage across more than one cloud, it's probably a better starting point than whatever script you were about to rewrite for the fifth time. PRs and issues welcome.