A cloud cost optimization service is an ongoing, productised engagement where a provider continuously finds and removes waste in your cloud spend, usually combining a platform, a recurring review cadence, and some amount of hands-on remediation. It sits between buying a tool, which reports and does nothing, and hiring a consultant, which builds a capability and leaves.
That middle position is why the category is confusing. Providers describe themselves interchangeably as platforms, consultancies, and managed services, and the pricing models attached to each differ enough to change what the provider is incentivised to do for you.
This is about the service specifically. If you’re evaluating a bounded engagement to build an internal practice, FinOps consulting: what to look for covers that purchase, and the two are worth reading together because the failure modes are different.
Key takeaways
- A service is not a tool. If the deliverable is a dashboard and a monthly PDF, you bought a licence with a meeting attached.
- Ask what happens after the recommendation. Most of the value gap between providers is whether anyone implements anything.
- Percentage-of-savings pricing has a defined baseline problem. Who defines it, and against amortized or list cost, changes the fee by multiples.
- Ask whether they resell your cloud. A provider earning margin on consumption has a financial interest in the number you hired them to reduce.
- Kubernetes is the test. If the service can’t attribute cost to a namespace, it can’t see inside the largest line item most teams have.
- Wasted spend is rising, not falling. Flexera put it at 29% in 2026, the first increase in five years.
Why this is a category
The waste is real and it stopped improving. Flexera’s 2026 State of the Cloud Report, its 15th edition, based on 753 cloud decision-makers, put self-reported wasted IaaS and PaaS spend at 29% and described it as the first increase in five years, attributed largely to AI workloads.
Meanwhile the thing most teams spend the most on became the thing they can see the least. The CNCF’s 2025 survey found 82% of container users now run Kubernetes in production, and Datadog’s State of Cloud Costs 2024 found 83% of container spend associated with idle resources.
So: more waste, in a layer standard billing tools weren’t built to see, at a moment when finance is asking harder questions about AI spend. That’s the demand. The supply is several hundred companies with materially different offerings and near-identical websites.
The four delivery models
Pin down which one you’re being sold. The word “service” covers all four.
1. Platform plus advisory
You license a cost platform, and the vendor adds a periodic review with a named analyst. Common, and often good value if you’ll actually use the platform.
What you get: visibility, anomaly alerting, recommendations, and someone to talk to. What you don’t: implementation. Every recommendation lands in your engineering backlog. Watch for: the advisory being a quarterly call that reads the dashboard aloud.
2. Managed optimization
The provider operates continuously: monitors, recommends, and implements the safe subset (idle cleanup, storage lifecycle, orphaned resources) under a change process you’ve agreed.
What you get: actual remediation, not just findings. What you don’t: architectural change, which still needs your engineers. Watch for: how “safe subset” is defined, and who’s liable if a change causes an incident.
3. Commitment management
A narrow, specialised service covering reserved instances, savings plans, and committed use discounts. Continuous portfolio management, laddering, and sometimes marketplace resale.
What you get: rate optimization done by people who do it daily. What you don’t: anything about usage. Commitments make waste cheaper, not smaller. Watch for: this is the one model where percentage-of-savings genuinely fits, because the baseline is unambiguous.
4. Full FinOps as a service
The provider runs the practice: allocation, showback, forecasting, governance, and optimization, reporting into your finance and engineering leadership.
What you get: a functioning practice without hiring for it. What you don’t: internal capability. You’re renting this indefinitely. Watch for: whether anything transfers to your team, and whether you’d want it to.
| Model | Implements changes? | Covers usage waste? | Covers rate waste? | Builds internal capability? |
|---|---|---|---|---|
| Platform + advisory | No | Reports it | Reports it | Slightly |
| Managed optimization | Safe subset | Yes | Sometimes | No |
| Commitment management | Yes, in its lane | No | Yes | No |
| FinOps as a service | Yes | Yes | Yes | Only if contracted |
Key insight: The most useful question in a first call is “what happens between you finding a $40K/month saving and the money actually stopping?” Providers who implement will describe a change process. Providers who don’t will describe a report. Both are valid purchases at very different prices.
Why “we’ll cut your bill 30%” is structured that way
The savings-guarantee pitch is everywhere, it’s rarely dishonest, and it’s worth understanding structurally before you evaluate it.
The baseline is where the money is decided.
Savings are measured against something, and the provider usually helps define what. If the baseline is on-demand list price for everything, savings look enormous and include discounts you’d have negotiated anyway. Insist the baseline is your actual amortized cost for the trailing three months, defined in writing before work begins.
A worse starting position pays better.
A provider walking into 40% waste earns far more than one walking into 8%. Nobody is being dishonest; the model simply rewards finding you late rather than keeping you efficient. It also means the second year is structurally harder to price, because the easy savings are gone. Ask what year two looks like.
Savings are usually self-reported.
The provider’s platform calculates the number the provider is paid on. Require validation against actual invoices rather than tool-estimated figures.
One-time savings get annualised.
Deleting an idle cluster saves $8K once a month. Some contracts count that as $96K of annual savings and take a percentage of all of it, sometimes for multiple years. Define whether savings count once or annually, and for how long.
Nobody is paid to tell you to spend more.
Which is sometimes the right answer — moving a job to a pricier instance family that finishes in a third of the time can be the correct call. A pure savings-linked provider has no way to bill for that advice.
| Pricing model | Fits when | Watch for |
|---|---|---|
| Fixed monthly fee | Scope is ongoing and defined | Scope creep as change orders |
| Percentage of savings | Commitment management, narrow scope | Baseline definition, self-reported savings, annualisation |
| Percentage of total spend | Rarely | You’re paying more as the bill grows |
| Platform licence + services | You’ll genuinely use the platform | Licence renewing whether or not you do |
| Bundled with cloud reselling | Rarely | Margin on the spend they’re cutting |
The reseller question
Ask on the first call, and ask for the answer in writing: do you resell our cloud capacity, or receive margin, rebates, or partner incentives tied to our consumption?
Many capable providers are also resellers or MSPs and do good work. But a provider earning a percentage of your bill has a financial interest in that bill, and you’re engaging them to reduce it. It isn’t disqualifying. It’s something to know, weigh, and factor into how you read their recommendations — particularly on commitment purchases and workload placement, where the incentive bites hardest.
The same applies to platform partnerships. A provider with a reseller agreement for a particular cost platform will find that your requirements suit that platform.
Eight checks before you sign
1. Can they attribute cost to a Kubernetes namespace?
Ask exactly how. If the answer only involves billing data, they can’t. Cloud bills split compute below the node now, but GCP’s allocation is requests-based and blind to idle, AWS reaches pod level for EC2 CPU, memory and accelerators but nothing beyond EC2, and Azure stops at namespace.
Real namespace-level attribution needs cluster telemetry. With 82% of container users on Kubernetes in production, a service that can’t do this is optimising around your biggest line item. Kubernetes cost management tools covers what’s actually possible here.
2. What’s their AI and GPU story?
98% of FinOps practitioners now manage AI spend, up from 31% two years earlier (State of FinOps 2026). Ask how they attribute a shared model endpoint across product teams and how they measure idle GPU hours. “We’re building that” is an honest answer that tells you the scope.
3. Do they implement, or only recommend?
Covered above. Get it explicit.
4. What’s the baseline, in writing?
Amortized, trailing three months, before work starts.
5. Are savings validated against invoices?
Not against their own tool.
6. What’s their platform relationship?
Reseller, partner, or neutral, and what they’d do if you refused to buy anything.
7. Who specifically works on your account?
Named people, with the work they’ve done, and whether they’ll still be there in month six.
8. What does month 13 look like?
The easy savings are gone by then. A provider who has thought about the steady state will describe governance and unit economics. One who hasn’t will repeat the year-one pitch.
Warning: A recommendation count is not a performance metric. “We generated 8,000 recommendations” measures the verbosity of a tool. Ask for the percentage actioned within 30 days, with the denominator visible. 200 actioned out of 8,000 looks identical in a slide to 200 out of 210.
Service, tool, or consultant?
| Cost optimization service | Cost platform (tool) | FinOps consulting | |
|---|---|---|---|
| Duration | Ongoing | Ongoing licence | Bounded |
| Deliverable | Continuous savings and operation | Reporting | A capability you keep |
| Best when | You want the outcome, not the practice | Allocation already works | You’ll build this internally |
| Main risk | Permanent dependency, misaligned pricing | Paying to visualise bad data | Deck with no implementation |
| Internal effort | Low to moderate | High (you operate it) | High during, low after |
The most expensive common mistake in this whole area: buying a platform before allocation works. The platform will faithfully visualise your 62% tag coverage in an attractive interface, and you’ll have spent six figures to look at the same problem more comfortably. If a service’s first proposal is a licence, ask what your current allocation coverage is. If they don’t know, they haven’t looked.
What good looks like at 90 days and at a year
By day 90:
- A measured allocation baseline, not an estimated one
- Idle and orphaned resources removed, with the savings visible on an actual invoice
- Commitment portfolio reviewed against real utilization
- Namespace or workload-level cost visible for your Kubernetes estate
- An anomaly alert that reached the team that caused it, not just finance
By month 12:
- Cost per unit of business value, not just total spend
- Engineers changing design decisions citing a cost number
- Forecast accuracy inside 10%
- Savings validated against invoices
- Something that would survive the provider leaving
That last one is the real test, and it’s uncomfortable for the vendor, which is why it’s worth asking about early. Obsium’s guide to FinOps KPIs that matter covers how to measure each of these without inventing targets.
What to take away
- Decide whether you’re buying reports or outcomes. Both are legitimate; they cost very differently.
- Define the baseline before work starts. Amortized, trailing three months, in writing.
- Validate savings against invoices. Not against the provider’s own tool.
- Ask about reseller margin on the first call. Either answer is workable. Not knowing isn’t.
- Test them on Kubernetes. Namespace-level attribution is the honest competence check.
- Don’t buy a platform before allocation works. You’ll pay to visualise incomplete data.
- Ask what month 13 looks like. Year one is the easy part.
Where Obsium fits
Most teams who come to us have already bought something. The dashboard exists, the recommendations arrive, and the bill hasn’t moved, because the biggest line item is a Kubernetes estate the tooling can only see the outside of.
We build that visibility on open-source Prometheus and Grafana, sitting next to the reliability data engineers already have open, so the cost number appears where the decision gets made. And we’d rather tell you the fix is a fortnight of work on infrastructure you already own than sell you a subscription.
Book a free 30-minute consultation. No sales deck. An engineer will look at your setup and tell you whether a service is the right purchase at all.
Related reading: FinOps consulting: what to look for · What is FinOps · 10 best FinOps consulting companies · FinOps best practices for cloud cost optimization · FinOps KPIs and metrics that matter · Why cloud costs grow faster than revenue
FAQs
What are cloud cost optimization services?
An ongoing engagement where a provider continuously finds and removes cloud waste, usually combining a platform, a recurring review cadence, and some hands-on remediation. It sits between a tool, which reports and does nothing, and consulting, which builds a capability and ends.
How much do cloud cost optimization services cost?
Pricing models vary more than prices do: fixed monthly fee, percentage of savings, percentage of total spend, or platform licence plus services. Ask for the total cost of a defined outcome rather than a rate, and if any part is savings-linked, get the baseline definition in writing first.
Is percentage-of-savings pricing a good deal?
It fits narrow, unambiguous scopes such as commitment portfolio management. It fits poorly for broad optimization, because the baseline is negotiable, savings are usually self-reported by the provider’s own tool, one-time wins get annualised, and nobody is paid to recommend spending more where that’s correct.
What’s the difference between a cloud cost optimization service and a FinOps consultant?
The service is ongoing and delivers outcomes; the consultant is bounded and delivers a capability your team keeps. Choose the service if you want the result without building the practice, and consulting if you intend to run it internally.
Can these services optimize Kubernetes costs?
Some can, many can’t, and few will volunteer which. Ask specifically how they attribute cost to a namespace. Native cloud allocation has real gaps — GCP allocates on requests rather than usage, AWS splits EC2 compute including accelerators but nothing beyond EC2, Azure stops at namespace — so genuine workload-level attribution requires cluster telemetry.
Do we need one if we already have a cost management tool?
Only if the gap is action rather than visibility. If your tool produces recommendations nobody implements, a service can close that. If allocation is broken, fix that first — neither a tool nor a service produces trustworthy numbers on incomplete data.
Should we ask whether a provider resells our cloud?
Yes, on the first call, with the answer in writing. Many good providers do resell, but margin on your consumption is a financial interest in the number you’re paying them to reduce. It matters most on commitment purchases and workload placement decisions.
How quickly should we see savings?
Idle cleanup and rate optimization typically show on an invoice within the first quarter. Allocation accuracy, forecasting, and unit economics take two to four quarters because they depend on tagging discipline and data quality rather than a purchasing decision.
