⚠️ Read this first: this is a composite, not a client's bill. The starting number, the split, and the per-lever savings are drawn from patterns I see repeatedly on cloud data platforms, combined and rounded so nothing identifies a client. The method is exactly what I use; the numbers are illustrative and will differ for your workload. As with the feasibility matrix, I'd rather show a transparent composite than an anonymised real bill you can't check.
The first move is always attribution, not cutting
Almost every "we need to cut cloud cost" conversation starts with someone wanting to turn something off. That's the second step. The first is attribution: you cannot manage a bill you cannot break down. A single line item that says "$48,000 — Compute" is not actionable. The same $48,000 split by warehouse, by team, by job, and by environment is a to-do list.
So the teardown starts by tagging every resource and mapping spend to a workload. On most platforms that means resource tags plus the query/usage history — Snowflake's QUERY_HISTORY and warehouse metering views, Databricks system tables, or the cloud provider's own cost allocation tags. Until spend is attributable to a team and a job, any cut is a guess, and guesses in FinOps tend to break a pipeline someone depended on.
The composite bill, before
A mid-size company on a cloud warehouse, roughly $52,000/month on the data platform. Attributed, it looked like this:
| Where the money goes | $/mo | Share | What's really happening |
|---|---|---|---|
| Always-on / idle warehouses | 15,600 | 30% | Warehouses that never auto-suspend, billing through nights and weekends |
| Oversized warehouses | 10,400 | 20% | An XL doing an M's work "to be safe"; the size was never revisited |
| Full-refresh pipelines | 9,400 | 18% | Hourly jobs rebuilding entire tables instead of incrementally |
| Storage & long retention | 7,800 | 15% | Old raw data and time-travel/clones nobody set a TTL on |
| Genuinely useful compute | 8,800 | 17% | Real analytical work — the part you're not trying to cut |
The shape is typical: the largest line is almost never the useful work. Idle and oversized compute together were half the bill, and neither produced a single query result. That's the good news — the biggest savings are in waste, not in capability, so they don't cost you anything you were using.
The four levers, applied
FinOps on a data platform comes down to four levers. Here's each one against this bill, with what it removed.
1. Auto-suspend & schedules — the free money
Every warehouse got an aggressive auto-suspend (60 seconds of idle), and the batch warehouses got schedules so they weren't warm 24/7 for jobs that run for two hours a day. This is the single highest-return change in FinOps and it changes nothing a user sees. Removed ~$7,800/mo of the idle spend — the remaining idle is the unavoidable spin-up cost of genuinely bursty interactive use.
2. Right-sizing — measure, don't guess
The oversized warehouses were profiled against their actual queries. Most "we made it XL to be safe" decisions don't survive contact with the query profiler: the jobs weren't spilling, so the extra size bought nothing but a bigger per-second rate. Dropped two tiers where the data supported it, kept one large where a genuine join needed the memory. Removed ~$4,600/mo.
💡 The right-sizing rule I actually use: a bigger warehouse is only cheaper if it finishes more than proportionally faster (because you pay per second at a higher rate). If doubling the size doesn't roughly halve the runtime, you're paying for capacity the query can't use. Test it on your slowest job before you standardise a size.
3. Incremental over full-refresh — the engineering lever
The full-refresh pipelines were the one that took real work: converting hourly full rebuilds to incremental models that only process changed data. This is where the analytics-engineering discipline pays for itself directly. Not every table converted cleanly — some genuinely need a full rebuild — but the heavy ones did. Removed ~$3,900/mo, and as a side effect the pipelines got faster, which nobody complained about.
4. Storage lifecycle — the quiet one
TTLs on raw landing zones, shorter time-travel windows where compliance allowed, and cleaning up abandoned clones and dev copies. Individually small, collectively real. Removed ~$1,700/mo.
The waterfall is the honest picture of a FinOps engagement: two of the four levers (auto-suspend and right-sizing) do most of the work and cost nothing in capability, while the incremental-pipeline lever takes the most engineering for a smaller-but-real cut. Total: about $52k → $34k/mo, ~35%, against a lift-and-shift baseline.
The number that matters more than the percentage
A 35% cut is a good headline and a bad target, because "spend less" isn't actually the goal — spend less per unit of value is. A platform whose bill grows because it's serving twice the queries is healthy; one whose bill is flat because usage is collapsing is dying cheaply.
So the deliverable isn't the one-time cut. It's a unit-economics view the team keeps after I leave: cost per active user, cost per thousand queries, cost per pipeline run. Those are the numbers that tell you whether next quarter's bill increase is growth or waste, and they're what stop the bill drifting back up six months later — which, without them, it reliably does.
⚠️ The failure mode of FinOps is that it doesn't stick. A one-off optimization pass saves money for a quarter and then entropy wins: new warehouses get created oversized, new pipelines default to full-refresh, retention creeps back up. The cut is the easy part. The durable part is putting the guardrails in as defaults — the same argument as the onboarding accelerator — so the next data product starts efficient instead of being optimised later.
What I'd want you to push back on
The percentage is workload-specific. A platform that's already been through a FinOps pass has 5–10% left, not 35%. A greenfield sprawl might have 50%. The composite here is a first-pass on an un-optimised estate, which is where the big numbers live and where most teams actually are.
Some of these cuts trade latency for cost. A warehouse that auto-suspends aggressively has a cold-start on the next query. For a batch job that's free; for an interactive dashboard a user is staring at, it's a real trade-off you have to make deliberately, not by policy.
Attribution has a cost too. Tagging discipline and cost-observability tooling aren't free, and on a small bill the overhead can outweigh the savings. Below roughly $10k/month I'd think twice before building a full FinOps practice — the money's real but so is the effort.
📊 This is the FinOps method as it runs in an engagement. If your platform bill has grown faster than your usage, that gap is usually the four levers above sitting unpulled. Schedule a briefing and bring your last three months of spend — you'll leave with a read on where yours actually goes.