How is the cloud waste estimate calculated?
Five inputs, three numbers, no hidden model. Monthly spend drives the waste range; revenue per hour and current uptime drive the downtime figure. The cloud and industry inputs don’t change any dollar amount: the industry picks the line items the result tells you to check first, and the cloud only names the provider in that message. Every figure is arithmetic you can redo by hand.
| Output | Formula | Assumption behind it |
|---|---|---|
| Waste, conservative floor | monthly spend × 20% | A deliberately conservative floor |
| Waste, client average | monthly spend × 45% | InfraZen’s published client average across FinOps engagements (see the case-studies disclaimer); where you land depends on how much has already been optimized |
| Annualized range | both monthly figures × 12 | Spend held flat for the year: no growth, no seasonality |
| Downtime gap | revenue per hour × (hours down per year at your uptime − hours down per year at 99.99%) | 8,766 hours in a year (365.25 days × 24); every hour down costs the full revenue per hour; 99.99% is the reference line. With revenue per hour left blank, this row is not shown |
| Where to look first | picked by the industry input | A starting checklist, not a finding; the cloud input only names the provider in the message |
Hours down per year is 8,766 × (1 − uptime), so each uptime option implies a fixed gap against 99.99%:
| Current uptime | Hours down per year | Gap vs 99.99% |
|---|---|---|
| 99% | 87.7 | 86.8 hours |
| 99.5% | 43.8 | 43.0 hours |
| 99.9% | 8.8 | 7.9 hours |
| 99.95% | 4.4 | 3.5 hours |
| 99.99% | 0.9 | 0 hours |
The industry input picks the starting checklist the result prints:
| Industry | Check first |
|---|---|
| B2B SaaS | multi-tenant compute headroom, per-environment sprawl, unused commitments |
| Fintech / BFSI | compliance-driven over-provisioning, audit log storage tiers, DR duplication |
| E-commerce | peak-sized fleets running 24×7, image and CDN egress, search clusters |
| AI / ML-heavy | idle GPU pools, always-on inference, training-job spot coverage |
| Other | idle non-prod, oversized databases, NAT and egress, missing commitments |
The interactive result is rounded for display: to the dollar below $1K, to the nearest $1K from $1K, to one decimal place in millions from $1M, and to whole millions from $10M.
Worked example: $80K a month on Azure
A hypothetical e-commerce team spends $80,000 a month, mostly on Azure, runs at 99.5% uptime and books about $10,000 of revenue an hour. This is what the calculator does with those inputs:
- Conservative floor: $80,000 × 20% = $16,000 a month.
- Client average: $80,000 × 45% = $36,000 a month.
- Annualized: $16,000 × 12 = $192,000 and $36,000 × 12 = $432,000, shown as $192K – $432K/yr.
- Downtime gap: 99.5% uptime is 8,766 × 0.5% = 43.83 hours down a year; 99.99% is 8,766 × 0.01% = 0.88 hours. The gap is 42.95 hours (shown as 43.0), and 42.95 × $10,000 is about $429,500, shown as $430K/yr at risk.
- Where to look first: for e-commerce, peak-sized fleets running 24×7, image and CDN egress, and search clusters.
Read the result as a bracket, not a forecast. Where this team actually lands between $16K and $36K a month depends on how much has already been optimized, and only its billing data can show that. Run the same inputs above to check the arithmetic.
What to do with the number
The range is a conversation starter, not an invoice. If it's big enough to matter, the next step is replacing the estimate with evidence: a read-only bill audit that maps exactly where the waste sits (commitments, rightsizing, storage tiers, NAT, Kubernetes bin-packing and seven other line items) and ranks the fixes by ROI. Written findings land within 48 hours of access.
If you'd rather understand the discipline before talking to anyone: What is FinOps? explains the operating model, and the Cloud Billing & FinOps engagement page shows how the 90-day optimization actually runs. The methodology and the 45% figure carry the site-wide disclaimer on case studies.