Skip to content
The gap How it works Results Pricing About FAQ
Get started

Your FinOps dashboards found the waste, but nobody is acting on it.

FinOps implementation for AWS teams: a senior engineer whose only job is working on the cost tickets your engineering team keeps pushing down the backlog.

Get started

Savings ledger

One FinTech client, nine changes, about $1M a year in savings.

Databases for a cancelled client
$378,000
RDS rightsizing and RI coverage
$161,000
EBS on the wrong tier (code bug)
$156,000
Aurora Serverless on a flat load
$125,000
ElastiCache rightsizing, Redis to Valkey
$86,000
Four smaller changes
$82,000

Total

$988,000/yr

LeanerCloud is a FinOps implementation team, led by Cristian Magherusan-Stanciu. He started it after more than 12 years in AWS cost optimization in different capacities, some of them at AWS itself, in the EC2 team, as a Specialist Solutions Architect for Spot and Graviton. He also built AutoSpotting, the open-source alternative to commercial AWS cost optimization tooling like Spot.io, used by teams at Samsung, Expedia and Mozilla.

We work with teams spending upwards of $100k/month on cloud. We specialize in AWS, and cover Azure and GCP through other handpicked team members.

The FinOps Foundation has a working group dedicated to getting engineering to take action.

Most FinOps ticket queues have a few of these sitting in them: unused RIs, oversized instances, orphaned volumes, an idle database or two, all filed months ago and still open, still costing money every day they sit there.

Around 40% of FinOps practitioners say the same thing, that they can't get engineering to act on what they find. The hard part isn't finding the waste, it's getting it fixed, which is more or less what the name of the Foundation's working group says: "Encouraging Engineers to Take Action."

Top challenge cited by FinOps practitioners: "getting engineers to take action"

Source: FinOps Foundation, State of FinOps.

The same alert, seven months in a row
  • Jan 15Unused RDS, est. $31.5k/mo
  • Feb 15Unused RDS, est. $31.5k/mo
  • Mar 15Unused RDS, est. $31.5k/mo
  • Apr 15Unused RDS, est. $31.5k/mo
  • May 15Unused RDS, est. $31.5k/mo
  • Jun 15Unused RDS, est. $31.5k/mo
  • Jul 15Unused RDS, est. $31.5k/mo

Seven months of the same open alert adds up to $220,500, spent while everyone agreed it was a problem, and this one is real: it's the top line of the ledger further down.

The survey doesn't say why this happens, and in our experience it isn't laziness or incompetence, the engineers are doing what they're paid to do. They're measured on features shipped rather than on dollars saved, so every cost ticket you file goes into planning and loses to the roadmap, in pretty much every company we've seen, because that's how the incentives were set up. Nobody gets promoted for decommissioning a forgotten database, so it doesn't get decommissioned.

You've probably been through all of this already, with the dashboard, the report, the ticket, the follow-ups and the escalation, and the waste is still running while you're the one explaining to the CFO why the number hasn't moved.

So the savings target sits with you, and the people who could implement the changes are booked on the roadmap.

You've heard all of this before

"Our dashboard gives you better visibility."

Visibility isn't what you're short of, and another dashboard doesn't get a single change made.

"We will produce a cost optimization report."

You can write your own reports, and another one doesn't get anything implemented either.

"AI-powered cost optimization."

Nobody at your scale is letting an unsupervised model loose in production, and they're right not to.

"Our consultants will review your infrastructure."

You've probably had consultants already, and they produced a PDF and left, so getting engineering to implement it was still your job.

"We saved company X $500k."

Every vendor claims something like this, but rarely says who did the implementation work.

"Shift left, and have your engineers own their cloud costs."

Your engineers already have plenty on their plate, and nobody specializes in every AWS service on the side. It's the same reason you bring in a pen tester rather than expecting every developer to become a security researcher.

None of it fixed the problem, and the reason is the same in each case. They all try to get your engineering team to do the work, with better data, better reports, more persuasion or plain pressure, and none of them add anyone who does the work itself.

The missing piece is an engineer to do the work

Imagine having a senior engineer dedicated to the cost work sitting in your backlog: the config changes, the rightsizing, the migrations and the cleanup. The savings your dashboards have been pointing at for months then show up on next month's bill. That engineer is what LeanerCloud provides.

You get your own engineer

An engineer who isn't borrowed from the product team and pulled onto a feature next sprint, and whose only priority is your cost queue, so you stop depending on engineering's goodwill to get your job done.

The waste you already found gets cut now

The person doing it doesn't compete with the roadmap, so the work doesn't wait for a quarter in which engineering happens to have bandwidth.

Your existing practice gets more valuable

This doesn't replace your FinOps practice, it gives its output somewhere to go, since your dashboards and reports now feed a queue that somebody works through.

Plus what your tools never surfaced

We also bring our own tooling, built up over 12 years of doing this work across many clients, which finds optimizations that most commercial dashboards miss.

The savings you're measured on show up on the bill instead of staying in a report.

How it works

There's no transformation program and no lengthy assessment, just a scoped project with a specific set of implementations and the savings named up front, and then the work itself.

  1. 1

    A call, with the paperwork already signed

    With the NDA signed up front, a short call to walk through your stack, your existing analysis, and which tickets have been stuck the longest.

  2. 2

    Read-only access

    Scoped, read-only access to the AWS account, with no standing admin and minimal IAM, and we only ask for more per change, when the work needs it.

  3. 3

    We start from your analysis, then go deeper

    Your dashboards and tickets are the starting point, so we work through what you've already identified first, then run our own tooling over the account to find what they didn't surface.

  4. 4

    The changes get made

    We make the changes ourselves: config changes, instance migrations, resource cleanup, and small pull requests that are quick to review. We try to limit involvement from your engineers to occasional questions about the application and reviewing small pull requests, offloading the bulk of the work, because waiting on engineering is the bottleneck this whole approach exists to get around.

  5. 5

    It shows up on the bill

    Measured per change against your billing data from before it landed, over a period we agree up front, and the effect usually shows up on the same month's bill. Each week you get a short note of what landed and what it saved.

We work with your security and procurement process. Everyone who touches your account is under NDA, and we're happy to sign your MSA and DPA, go through your security reviews. It's also why client names are anonymized in our case studies.

Why your FinOps team doesn't already have this

Most senior engineers don't want this work: config changes and migrations don't look good on a resume, and the role reports to the people the engineering org privately calls bean counters. So it rarely gets created, and the tickets stay open.

The other reason the tickets never close

Most of what's left after the headline items is small: a few hundred dollars a month each, low risk, no migration project. None of them on their own justify pulling an engineer off the roadmap for half a day to research, execute and verify, which is why they never get done.

On our side the tooling is already built, so that half day costs us about half an hour.

Forty of those at $250 a month each is $120,000 a year that no dashboard is going to implement for you. One piece of that tooling, our EBS Optimizer, is available on its own. There's more on the AWS cost optimization and FinOps consulting pages.

The long tail of small savingsA few large savings on the left, and a wide band of many small savings on the right whose combined area is larger.Headline winsThe long tail (bigger in total)
Illustrative: the small wins add up to more than the headline items.

No AI touches your production account

We use AI for analysis and for building the deterministic tooling we run, since it lets one engineer cover a lot more ground, but every production change is made and verified by hand.

The amounts at stake are too large and the changes too dependent on the details of each account for anything else, and you wouldn't sign off on it either.

How we're engaged

Start with one scoped project, and if it works, it continues.

Scoped project

The usual starting point: small in hours, with the savings named up front

  • A specific set of implementations agreed up front
  • Flat fee, no open-ended engagement
  • A first project before committing to ongoing work

Monthly retainer

An engineer working through your FinOps queue

  • An agreed block of engineering hours each month
  • Priced case by case, against your scope and what you need
  • Your queue, worked through in your priority order

Share of savings

For teams who'd rather pay only out of results

  • A share of what each change measurably saves
  • Our fee for each change ends after its first 12 months
  • Measured automatically from before-and-after billing data

How the savings share works

Get started

Most teams start with a scoped project, because it's the fastest way to find out whether this works without a budget conversation. All three can also be billed through AWS Marketplace, so it comes out of the cloud budget you already have rather than needing one of its own.

About LeanerCloud

LeanerCloud is a FinOps implementation team, founded in 2022 by Cristian Magherusan-Stanciu, after three years at AWS where he worked in the EC2 team as a Specialist Solutions Architect for Spot and Graviton. He's spent 12 years in AWS cost optimization in different capacities, and he created AutoSpotting, the open-source alternative to commercial AWS cost optimization tooling like Spot.io.

Most of his time goes into building cost optimization tooling, and client work is where that tooling gets used. What looks like grunt work from the outside is where he puts those tools to work. He left AWS for much the same reason, having gotten bored of PowerPoint and wanting to do the hands-on work instead.

He spent years on the other side of this problem, waiting on engineering teams to implement work that never reached the top of a sprint, so the whole approach here is built around needing as little of their time as possible. Cristian runs every engagement himself and brings in freelancers he has worked with before, with decades of combined AWS experience when the work calls for it.

We specialize in AWS, and cover Azure and GCP through other handpicked team members, and we're always open to talented cloud professionals interested in joining us.

Cristian Magherusan-Stanciu

Cristian Magherusan-Stanciu

Chief Engineer, ex-AWS EC2

LinkedIn Join us

Cristian also shares what he learns along the way on the LeanerCloud podcast and YouTube channel.

From the blog

Cost optimization work from real engagements, with the numbers, anonymized by scale and spend, and every figure measured against the bill before the change.

RDS

Finding and cutting unused and idle RDS databases

Zero-connection databases across dozens of instances and five regions, and over $50k/month of savings potential in a single account.

Aurora

Converting Aurora Serverless to provisioned for cost and performance

A conversion that cut database cost from $450 to $100 a day and improved query latency at the same time.

ElastiCache

ElastiCache cost optimization: rightsizing, Valkey, and reserved instances

Cutting cost over 6x across 200+ clusters, and why rightsizing before committing matters.

Serverless

Moving bursty Fargate and EC2 workloads to Lambda

When moving bursty Fargate and EC2 workloads to Lambda makes sense, and what it saved in one case.

S3

Slashing S3 costs with the right storage class and lifecycle rules

Old logs in S3 Standard quietly cost thousands a month, and a few lifecycle rules cut one bill by over 90%.

Networking

The cross-AZ data transfer costs hiding in your database traffic

Instances talking to databases across an AZ boundary cost $20k/year here, found by tag and fixed with a same-AZ replica.

CloudWatch

Cutting CloudWatch Logs costs hiding in a few log groups

A single VPC flow log group cost $8k/year, and retention and log class changes on a handful of groups fixed it.

Read all posts on the blog

Start a conversation

Tell us where AWS costs are getting stuck, and we'll suggest a practical first step.

Get started

Frequently Asked Questions

Common questions about working with LeanerCloud

We already have dashboards that show us where the waste is.

Good, that’s the right starting point and we wouldn’t redo it. We go through what your tools already surface and work through that first. Then we run our own tooling over the account to find what dashboards tend to miss: EBS volumes that got expensive because of an upstream code bug, Aurora Serverless running a flat workload that should have been Provisioned, or commitments sized before the rightsizing that should have come first.

Can't our own engineers handle the implementation?

They can, and some teams do. In practice cost tickets lose to product work in planning, which is why getting engineers to act on cost recommendations is the top FinOps challenge in the Foundation’s State of FinOps survey, cited by around 40% of respondents. We take on the tickets your team doesn’t have time to implement.

We tried consultants before and they just produced reports.

That’s the usual consulting model, where they assess and recommend and getting engineering to implement the PDF is still your job. We skip straight to implementation and do the config changes, the migrations and the small pull requests ourselves. You still get a short note each week, but it lists what already got done rather than what somebody else ought to do.

What about AI-powered optimization?

We use AI for analysis, since it lets one engineer cover a lot more ground, but every production change is made and verified by hand. No AI agent runs on your infrastructure and nothing runs unsupervised, because the amounts at stake are too large and the changes too dependent on the details of each account for that.

How do you implement without disrupting engineering?

We pick changes that need limited engineering involvement: config changes, instance type migrations, resource cleanup, work that doesn’t touch application code. When a small code change is needed, which is rare, it comes as a minimal pull request that’s quick to review. Cristian spent years waiting on engineering teams himself, so the whole approach was built around not having to.

What if we're already doing some optimization internally?

Keep doing it, since this is the engineer your FinOps practice is missing rather than a replacement for it: your team finds the waste and manages the commitments, and we do the engineering work that turns that into savings on the bill.

What does it cost?

Most teams start with a scoped project: a specific set of implementations with the expected savings named up front, for a flat fee. If it works, it becomes a monthly retainer, an agreed block of engineering hours each month, priced case by case against your scope and what you need. We can also work on a share of the savings instead, typically 10% to 30%, with a lower percentage for larger AWS customers, billed per change for its first 12 months and measured from your real before-and-after billing data. On that model, a change that saves nothing isn’t charged for. All three can also be billed through AWS Marketplace.

Do we need to find a new budget for this?

Usually not. We can also bill through AWS Marketplace, and that way it comes out of the cloud budget you already have instead of needing its own line item and its own procurement cycle. The budget argument doesn’t rest on that anyway, since the money comes out of the same cloud budget this work is shrinking.

What size client do you work with?

We work best with teams spending upwards of $100k a month on cloud. It’s a guideline rather than a hard floor: somewhat below it, a hands-on engagement can still be worth it if the waste is concentrated, so it’s worth asking. Well below that, self-serve automation is usually the better fit, and we can refer you to partners who take on smaller clients.

How much access do you need?

Read-only first, so we can work through your existing analysis and run our own. Then scoped write access per change, with minimal IAM and no standing admin. Anything that touches a repository goes through your own review and rollout process.

How do you handle security and procurement?

We work with your process. Read-only access first, then least-privilege, per-change write access with no standing admin. Everyone who touches your account works under NDA. We’re happy to sign your MSA and DPA, go through your security reviews and questionnaires, and provide references under NDA. Every engagement is under NDA, which is why our case studies are anonymized.

How are the savings measured?

Automatically, from your actual before-and-after billing data: per change, against the bill from before that change, over a period we agree up front. It’s driven by the real bill rather than an estimate, and each week you get a short note of what landed and what each change saved.

What if a change causes an incident?

Changes are low risk by selection and reversible, with a rollback defined per change. Where a change is destructive, like deleting stale snapshots or unattached volumes, we agree the retention rule and get explicit sign-off before anything is removed. Anything touching a repository goes through your review. Major architecture changes are rare and always discussed in advance, and we don’t touch anything that isn’t worth the risk. If something does go wrong we help put it right, and we carry insurance to cover damages.

Which cloud providers do you cover?

AWS is where we have the deepest expertise: Cristian’s spent 12 years in AWS cost optimization in different capacities, some of them at AWS itself, in the EC2 team, as a Specialist Solutions Architect for Spot and Graviton. We also cover Azure and GCP through other handpicked team members.

What if we already bought commitments?

We work around them, and convertible Reserved Instances can often be exchanged. We size any new commitments, and where it fits an Enterprise Discount Program or private pricing agreement, against the footprint you’ll have after the optimization rather than before it.

Why not just buy a Savings Plan?

Commitments are the easy win, an afternoon of work, but they only ever cover part of the bill. Storage, logging and networking aren’t covered by any Savings Plan or Reserved Instance, so they only get cheaper when somebody optimizes them. We go through the whole stack first, then size commitments to the footprint you’ll actually run. That way you don’t lock in years of paying for resources we’d have removed.

Is this just about cutting costs?

A lower bill is the visible outcome, but the bigger win is efficiency, meaning more capacity, performance and reliability out of each dollar you spend.

What if the bill doesn't drop because we're growing?

For fast-growing customers the absolute bill often keeps rising because the business is growing, but the cost per customer or per transaction drops, so the spend turns into more value rather than waste. We measure per change against the bill from before that change, so growth elsewhere doesn’t obscure what the work delivered.

What happens when you leave?

The savings are already in your infrastructure and the self-hosted tooling stays yours, so you don’t need an ongoing subscription to keep the benefits. If you want continued coverage, we also offer ongoing monitoring for configuration drift and further savings opportunities.

How do we get started?

Tell us where the costs are getting stuck. We take read-only access and come back with a scoped project: what we’d implement, and what it’s worth.

Still have questions?

Send them over and we'll get back to you.

Email us Get started