An open, opinionated, five-engine FinOps toolkit for Azure. Replaces Advisor's average-based recommendations with peak-aware decisions, finds the hidden waste Advisor doesn't price, sizes Compute Reservations / Savings Plans and Storage Reservations against a configurable cancellation-exposure buffer, and turns every finding into an approve-ready, per-owner remediation queue — all from
az login, no agents, no SaaS.
Most FinOps tools fall into one of two camps:
- Reactive dashboards that re-state what Azure already shows you (Cost Management, Advisor) without changing the decision quality.
- Black-box SaaS platforms that ingest your billing data, charge a percentage of savings, and still hand-off to your engineers to actually act on the findings.
The FinOps Engine is neither. It is five small, deterministic Python engines that reproduce — and significantly improve on — the analysis a senior FinOps practitioner would do by hand:
| Engine | Replaces / improves on | Headline output |
|---|---|---|
rightsizing-peak |
Azure Advisor's average-based VM rightsizing | A list of Advisor recommendations that would have been unsafe under P95/P99 peak data |
hidden-waste |
Manual orphan / lifecycle hunts in Cost Management | Twelve categories of waste, priced against actual £, plus a starter Azure Policy pack |
ri-coverage |
Portal Reservations → Recommendations (single-SKU view) | A risk-scored VM RI / Compute Savings-Plan shortlist that fits inside your cancellation-exposure buffer |
storage-coverage |
Azure Monitor's 200-account-capped Storage insights view | A tenant-wide Storage Reserved-Capacity shortlist (Blob + Files) grouped by service × region × redundancy × tier, bounded by the same buffer |
context-enricher |
Spreadsheet round-trips between FinOps and domain teams | Per-owner GitHub Issue bodies — auto-routed via CODEOWNERS |
Every engine is read-only. None of them delete or modify resources. They emit Markdown, CSV, and (where appropriate) Azure Policy / Azure Workbook JSON. Remediation is always a human decision.
The absolute numbers vary wildly between tenants — a 50-subscription enterprise looks nothing like a 5-subscription startup. The shape of the findings, however, is remarkably consistent. On a tenant of any size you should expect, in a single afternoon:
- A small handful of Advisor downsize recommendations flagged as unsafe — workloads with bursty or batch profiles that Advisor's average-based logic would have downsized into a peak-hour outage. Even one is worth the run.
- A material chunk of recoverable hidden waste that Advisor doesn't price — typically dominated by old snapshots, empty App Service Plans, unattached premium disks (especially ASR seed disks), idle public IPs, and stopped-but-not-deallocated VMs. Single-digit-percent of monthly spend is a normal first-pass result.
- A risk-scored RI / Savings-Plan shortlist that fits inside whatever cancellation-exposure buffer your procurement function has set — and a quantified view of how much additional commitment would be unlocked by raising that buffer. The binding constraint is almost always procurement policy, not the data.
- One GitHub Issue per domain owner the next morning, with
accept/defer/rejectcheckboxes — replacing whatever recurring spreadsheet walkthrough your FinOps function does today.
The samples under samples/ show the full report set against
a synthetic Contoso tenant so you can see the output shape before you run
anything against your own data.
git clone https://github.com/prbeegala/FinOpsEngine.git
cd FinOpsEngine
# 1. Authenticate to Azure (Reader + Cost Management Reader is enough)
az login
az account set --subscription <default-sub-id>
# 2. Run any engine standalone — pick your scope
# --subs <a,b,c> explicit list
# --all-subs every enabled sub in the current tenant
# (add --exclude-subs / --tenant / --include-disabled as needed)
python tools/rightsizing-peak/rightsizing_peak.py `
--all-subs `
--days 30 `
--out-dir ./out/peak-rightsizing
python tools/hidden-waste/hidden_waste.py `
--all-subs `
--out-dir ./out/hidden-waste
python tools/ri-coverage/ri_coverage.py `
--all-subs `
--months 3 `
--refund-buffer 5000 `
--out-dir ./out/ri-coverage
python tools/storage-coverage/storage_coverage.py `
--all-subs `
--days 60 `
--refund-buffer 5000 `
--out-dir ./out/storage-coverage
# 3. Join everything into per-owner remediation queues
python tools/context-enricher/context_enricher.py `
--hidden-waste-csv ./out/hidden-waste/hidden-waste-<date>.csv `
--rightsizing-csv ./out/peak-rightsizing/tenant-peak-rightsizing-savings-<date>.csv `
--out-dir ./out/enrichedTip. Pin a sandbox or two for your first run rather than going tenant-wide. Use
--subs "<one-id>"and grow the scope once you're happy with the output.--all-subs --exclude-subs "<sandbox-id>"is the safest tenant-wide default.
Linux / macOS users: substitute \ for the PowerShell line-continuation
backtick. The Python is portable; only the shell quoting differs.
- Python 3.10+ (standard library only — no
pip installstep needed). - Azure CLI 2.55+ (
az --versionto check). - Permissions on the in-scope subscriptions:
Reader(Resource Graph, Monitor metrics, Advisor)Cost Management Reader(/queryREST API)- Optional:
Microsoft.Capacity/reservationOrders/readto subtract existing RI cover from the coverage gap (the engine works without it; the gap is then relative to measured PAYG rather than PAYG net of RI).
The engines never write to Azure. They issue GET / POST /query calls only.
┌───────────────────────────────────┐
│ Azure (your tenant) │
│ • Resource Graph │
│ • Azure Monitor metrics │
│ • Cost Management /query │
│ • Advisor │
└───────────────┬───────────────────┘
│ az CLI (read-only)
┌──────────────────┬─────────────────┼─────────────────┬──────────────────┐
▼ ▼ ▼ ▼ ▼
┌──────────────┐┌──────────────┐┌──────────────┐┌──────────────────┐
│rightsizing- ││hidden-waste ││ri-coverage ││storage-coverage │
│peak ││ ││ ││ │
│ P95/P99 vs ││ 12 waste ││ Family×region││ Blob + Files RI │
│ Advisor diff ││ classes + ││ VM RI / SP ││ per svc×reg× │
│ ││ Policy pack ││ shortlist + ││ redund×tier + │
│ ││ ││ buffer ││ buffer │
└──────┬───────┘└──────┬───────┘└──────┬───────┘└──────┬───────────┘
│ CSV + MD │ CSV + MD │ CSV + MD │ CSV + MD
└───────────────┴───────┬───────┴───────────────┘
▼
┌──────────────────────────────────────────┐
│ context-enricher │
│ • joins findings ↔ tags via Resource │
│ Graph │
│ • HIGH / MED / LOW confidence scoring │
│ • per-owner GitHub Issue bodies │
└────────────────────┬─────────────────────┘
│
▼
┌──────────────────────────┐
│ automation/finops- │
│ nightly.yml (GitHub │
│ Actions: 05:00 UTC) │
│ → opens / updates │
│ per-owner Issues │
└──────────────────────────┘
FinOpsEngine/
├── tools/
│ ├── rightsizing-peak/ Peak-aware VM rightsizing engine + Workbook
│ ├── hidden-waste/ Orphan & lifecycle waste finder + Policy pack
│ ├── ri-coverage/ Compute Reservation / Savings Plan shortlist
│ ├── storage-coverage/ Storage Reserved-Capacity shortlist (Blob + Files)
│ └── context-enricher/ Tag join + per-owner Issue generator
├── automation/
│ └── finops-nightly.yml GitHub Actions: nightly refresh + Issues
├── samples/ Synthetic example outputs (runnable without Azure)
│ ├── peak-rightsizing/
│ ├── hidden-waste/
│ ├── ri-coverage/
│ ├── storage-coverage/
│ └── enriched/
├── docs/ Methodology, FAQ, troubleshooting
├── LICENSE
├── requirements.txt
└── README.md (this file)
The samples in
samples/are synthetic — generated to illustrate the output shape. None of the resource IDs, subscriptions, or numbers represent a real environment.
1. Peak-aware rightsizing — combined report (full file)
# Peak-Aware Rightsizing — Combined Pilot Report
| Subscription | VMs | Downsize | Keep | Upsize warn | Insufficient | Advisor unsafe |
|----------------|----:|---------:|-----:|------------:|-------------:|---------------:|
| ContosoApp.Prod| 7 | 1 | 6 | 0 | 0 | 0 |
| ContosoBatch | 22 | 7 | 5 | 9 | 1 | 1 |
| **Total** |**29**| **8**|**11**| **9** | **1** | **1** |
## The headline number
**1** of Azure Advisor's downsize recommendations across the pilot trio
would have been **unsafe** according to peak (P95/P99) workload data — the
manual-validation overhead this engine eliminates.2. Hidden waste — by category (full file)
# Hidden Waste & Lifecycle
- Subscriptions scanned: 20
- Findings: **1,196**
- Estimated monthly £ recoverable: **£12,952** (~£155,424 / yr)
| Category | Count | Monthly £ | Annualised £ |
|--------------------------------|------:|----------:|-------------:|
| Unattached managed disks | 592 | £4,845 | £58,143 |
| Old snapshots (>90d) | 54 | £3,053 | £36,635 |
| Hot-tier storage accounts (cold workload) | 11 | £2,210 | £26,520 |
| Empty App Service Plans | 20 | £1,717 | £20,607 |
| Oversized premium file shares | 6 | £820 | £9,840 |
| Under-utilised App Service Plans | 1 | £178 | £2,136 |
| Unused public IPs | 46 | £91 | £1,098 |
| Idle Standard load balancers | 2 | £30 | £360 |
| Stopped-not-deallocated VMs | 1 | £6.67 | £80 |
| Orphan NICs | 420 | £0.00 | £0.00 |
| Untouched blob containers (>90d) | 38 | £0.00 | £0.00 |
| Idle Container Apps (warm replicas) | 5 | £0.00 | £0.00 |3. Compute RI / SP shortlist (full file)
# RI / Savings-Plan Risk-Scored Shortlist
Buffer: **£5,000** cancellation exposure (configurable).
| # | Family×Region | Product | Annual £ committed | Annual savings | Exposure |
|--:|------------------|---------------|-------------------:|---------------:|---------:|
| 1 | Dsv5 / uksouth | Compute SP 1Y | £18,200| £3,094 | £2,184 |
| 2 | Esv5 / uksouth | RI 1Y | £14,800| £4,440 | £1,776 |
| 3 | Bs / uksouth | RI 1Y | £6,400| £1,920 | £768 |
| 4 | Fsv2 / westeu | Compute SP 1Y | £2,200| £374 | £264 |
| | **Buffer used** | | | **£9,828** | **£4,992** |4. Storage Reserved-Capacity shortlist (full file)
# Storage Reserved-Capacity Risk-Scored Shortlist
Buffer: **£5,000** cancellation exposure. Storage has **no Savings Plan** —
only RI 1Y / RI 3Y variants per (service × region × redundancy × tier).
| # | Service/Region/Redund./Tier | Product | Yr commit | Yr savings | Cancel exp. |
|--:|----------------------------------|----------------------|----------:|-----------:|------------:|
| 1 | files / uksouth / lrs / premium | Premium Files RI 1Y | £38,400 | £9,600 | £4,608 |
| 2 | blob / westeurope / lrs / hot | Blob Storage RI 3Y | £2,160 | £605 | £259 |
| | **Buffer used** | | | **£10,205**| **£4,867** |5. Per-owner remediation queue (full file)
# FinOps remediation queue — contoso-app-team — 2026-01-01
**14 findings · ~£1,230 / month (£14,760 / yr) recoverable.**
| Resource | Category | Env | £/mo |
|-----------------------|--------------------------------|------|-----:|
| pip-fe-prod-uks-08 | Unused public IPs | Prod | £3|
| disk-bkp-2024-q4 | Old snapshots (>90d) | Prod | £312|
| asp-legacy-portal-001 | Empty App Service Plans | Prod | £180|
| vm-batch-night-04 | Rightsize Standard_E16ds_v5 → | Prod | £420|
| | Standard_E8ds_v5 | | |
| ... | ... | ... | ... |
> Reply `accept`, `defer`, or `reject` per row.
> Generated by the FinOps Engine. Each row links back to the source engine.Each engine has its own README with full documentation:
tools/rightsizing-peak/README.md— P95/P99 decision tree, Advisor diff, downsize ladders.tools/hidden-waste/README.md— the twelve waste classes, pricing fallbacks, Policy pack.tools/ri-coverage/README.md— Compute Reservation / Savings Plan risk model, buffer guardrail, limitations.tools/storage-coverage/README.md— Storage Reserved-Capacity sizing (Blob + Files), meter-string classifier, non-reservable callout.tools/context-enricher/README.md— tag conventions, confidence scoring, GitHub Issue routing.automation/README.md— GitHub Actions deployment guide.
For the why behind the engines (rather than the how), see:
docs/methodology.md— peak-vs-average, the £-buffer mental model, deterministic-first / LLM-later.docs/troubleshooting.md— common permission errors, throttle behaviour, Windows quoting.docs/faq.md— frequently-asked questions.
Every engine calls az billing account list once at startup and
renders amounts in the tenant's billing currency (USD, EUR, SEK,
etc.). If detection fails (no Billing Reader, offline run,
multi-currency setup), the engine falls back to £ and prints a
one-line provenance message. Override with --currency-symbol '<glyph>'
on any engine.
Where the £ figures come from. Mostly your actual bill via Cost
Management ActualCost, not public retail price. EA / MCA discounts,
regional pricing, Hybrid Benefit, and dev/test rates are all baked in.
Public list price is only used as a thin fallback for never-attached disks
in hidden-waste (which never produce a billing record) and is explicitly
tagged estimate in the output. rightsizing-peak also uses Cost
Management ActualCost for its current_payg_cost /
recommended_payg_cost columns (issue #55); there is no retail-price
fallback for a recommended SKU absent from the tenant's billing history —
the cell stays blank with pricing_status = "no_data_for_recommended".
See the FAQ entry on pricing source
for the per-engine breakdown.
The engines are intentionally small and dependency-free. Common extensions:
- Different cloud / billing system — replace the Cost Management /query call with whichever billing API your platform exposes; the rest of the pipeline (CSV → enrichment → Issues) is generic.
- Different ticketing system —
context-enricherwrites Markdown bodies per owner underissues/. Swap thegh issue createstep infinops-nightly.ymlforjira,azure boards, ServiceNow, etc. - Different tag taxonomy — edit the
*_KEYStuples at the top ofcontext_enricher.py. Case-insensitive, first match wins. - LLM-ranked rationale — the README of
context-enricherwalks through layering a small model on top of the deterministic rationale once HIGH/MED accept rates are trusted.
The public backlog of new detectors, engine improvements, integrations, and
multi-cloud work lives in ROADMAP.md. Items are grouped by
theme and badged with rough size and risk. Open an Issue if you'd like
something bumped or want to pick one up.
A 12-slide overview deck — punchy, customer-facing, no real data — lives at
docs/finops-engine-overview.pptx.
Use it to introduce the engine to a customer or internal team. The
generator script (docs/build_overview_pptx.py)
is checked in too; edit and re-run with python docs/build_overview_pptx.py
(requires python-pptx — a docs-only dependency; the engines themselves
remain stdlib-only).
This project follows Semantic Versioning applied to
four explicit public contracts (CLI flags, output file shape, Workbook /
Policy IDs, Issue body shape). The full policy — including the deprecation
cycle, branch model, and v1.0.0 shipping criteria — is in
VERSIONING.md. The release-by-release history is in
CHANGELOG.md.
If you are pinning the engine in CI or a downstream Workbook, read
VERSIONING.md first.
Issues and PRs welcome. The engines deliberately avoid third-party Python dependencies (the standard library plus the Azure CLI is the contract); please keep that property if you submit a PR.
MIT.