Dmitry Yackevich
2026-04-12 · FinOps · 8 min

How I've saved $10M+ in AWS spend — a playbook

by Dmitry Yackevich

Across Miro, Flo Health, and earlier roles I've driven more than $10M in AWS savings. Here's the honest, unflattering version of how it actually happens — and the traps that will eat 80% of the upside if you don't see them coming.

The five levers, ranked by ROI

1. Architecture — the only lever with 10x potential

Every other FinOps lever trims the bill by 10-30%. Architecture trims it by 2-10x. Moving from over-provisioned EC2 fleets to right-sized EKS with autoscaling. Replacing self-managed Cassandra with managed DynamoDB for the right workload. Cutting a cross-AZ data transfer pattern that's bleeding six figures a year. Changing a chatty service mesh that's duplicating every request.

These are the wins that move P&Ls. They are also the ones most FinOps teams can't touch because they aren't staffed with senior engineers. This is why FinOps programmes fail when they're placed inside Finance and succeed when they're placed inside Infrastructure.

2. Commitment coverage done properly

Savings Plans and Reserved Instances are the easiest lever to misplay. The common mistake is over-committing early, then watching workloads migrate and leaving stranded commitments for the next year. The correct way is to run a rolling 3-month workload analysis, buy commitments only up to the floor of confirmed baseline, and let the rest float at on-demand until the baseline grows.

Target 70-85% commitment coverage on baseline compute. Above 90% you're betting against your own roadmap. Below 60% you're leaving 20-30% on the table.

3. Right-sizing and idle clean-up

Boring. Necessary. Compounds. Most orgs have 20-40% of their compute running at under 10% utilization — dev environments that nobody turned off, idle RDS replicas, over-provisioned nodes, forgotten NAT gateways bleeding $45/month each. A quarterly right-sizing sweep, automated and owned, tends to deliver 8-15% of spend.

The non-obvious part: right-sizing is a culture problem, not a tooling problem. The tools will tell you what to cut. Getting engineers to actually cut it requires the cost to show up on their team's dashboard, not in a centralised FinOps report.

4. Data lifecycle — the silent killer

S3 and CloudWatch Logs quietly become the largest line items in mature orgs. Nobody reads the 90-day-old logs. Nobody queries the 2-year-old Parquet files. Lifecycle policies, Intelligent-Tiering, and compaction on the warehouse side typically cut storage by 30-60% in the first pass.

Do this before you start any cost conversation with Engineering. It's high-leverage, low-risk, and it buys you credibility for the harder conversations.

5. Vendor negotiation — the last 10%

EDP and PPA negotiations matter, but they're the last move, not the first. Going into a discount negotiation with a sprawling, under-optimised footprint just means you're paying a discounted rate on waste. Optimise first, then negotiate from a credible forecast. A 15% enterprise discount on a cleaned-up bill is worth more than a 25% discount on a bloated one.

The failure modes that eat most FinOps programmes

Reporting without ownership. A beautiful dashboard that nobody is accountable to is a cost, not a saving. Costs have to be assigned to engineering teams by tag, with a budget, with a consequence for overrun. Without this, every FinOps win reverts in two quarters.

FinOps in Finance, not Engineering. Finance can monitor. Finance cannot re-architect a data pipeline. If the programme lives outside Engineering, its ceiling is the right-sizing / commitments layer — real money, but not the 10x money.

Over-indexing on tooling. You don't need Cloudability, Vantage, and Kubecost to save your first $1M. You need a tagging strategy, an owned budget per team, and one engineer whose job for a quarter is to drive architecture changes.

Measuring savings against a moving baseline. If your usage doubles while your unit cost halves, the bill still goes up — and Finance will (correctly) not believe you're saving anything. Measure unit cost (cost per active user, per transaction, per GB stored) not absolute spend.

The honest framing

$10M+ sounds like a heroic one-time achievement. It isn't. It's the result of doing the unglamorous work every quarter for years — architecture reviews, commitment rebalancing, lifecycle policies, painful conversations with engineering managers whose costs are trending the wrong way. The heroic move is keeping the discipline when the savings stop showing up as easy wins.

The same discipline is how you'll contain the AI bill in 2026. I wrote about that here.


Based in Amsterdam. Available to talk FinOps with engineering leaders — get in touch.

Working on the same problems? Let's talk.

✉ Email me