The cloud bill comes down
one named resource at a time.
Twenty-six named checks run across twelve cloud and data platforms. Every finding is a specific resource, an owner who can approve the change and a threshold you set. The governance layer then keeps the waste from growing back.
Answered on one platform. One data model across ITAM, SAM, SaaS, Cloud and AI.
Optimization run
IllustrativePool · engineering · last 24 hours
26 of 26 checks evaluated
- Instances in Stopped State for a Long Time stopped ≥ 14 days, still allocated
- 40
- Obsolete Snapshot Chains root image deregistered
- 7
- Kubernetes Rightsizing requests vs observed usage
- 12 ns
- Reserved Instances Opportunities steady-state 150 days
- 18
- Tag correlation violation owner set, cost-centre missing
- 3
Every finding carries
threshold · exclusions · skips
The problem
Every cost dashboard ends one question short of a decision.
An action needs a resource, an owner and a date. Cost by service gives you none of the three, so the meeting ends where it started.
29%
of cloud spend is wasted — up for the first time in five years
An industry average, drawn from somebody else’s environment. In yours, every point of it arrives with a resource name attached.
- 01 no owner, no action
Everyone agrees the rightsizing is correct. Nobody is allowed to approve it.
The instance belongs to an account that belongs to a team that reorganised last year. Without ownership the finding sits in a backlog until somebody renames it technical debt.
Assignment rules with nine condition types for automatic ownership Cloud Management
- 02 the tagging project never finishes
Your tagging standard is a wiki page and forty per cent of resources.
Allocation waits for a tagging programme that will not complete, so showback never starts, so nobody feels the cost of anything they run.
Virtual tagging computed independently of cloud-native tags Cloud Management
- 03 sized for requests
Kubernetes is one line on the invoice and half the cluster.
Nodes are sized for the requests developers declared. The cluster runs at a third of what it reserves and the bill does not break down by namespace.
Kubernetes cost and utilisation by namespace, node and service Cloud Management
- 04 the saving that grew back
You cleaned it up in March. It was back by June.
Nothing had a lifetime, no limit was set, and no policy fired when the same class of resource reappeared. Optimisation without governance is a standing quarterly project.
Resource TTL with automatic lifecycle enforcement Cloud Management
- Waste is a list you work through, and then a policy that stops the list rebuilding itself.
Three of the five disciplines.
Each runs standalone and shares one asset model, so the parts of this that span products need no integration work.
- Primary CerteroX Cloud Management Twenty-six named checks, one cost model across twelve platforms, and policy that enforces. Product page
- Also applies CerteroX AI Management The same recommendation engine pointed at GPU fleets and ML executors. Product page
- Also applies CerteroX ITAM Cloud instances reconciled against the same asset record as everything else you own. Product page
Four moves, and only one of them is finding the waste.
Most tools do the second one. The first decides whether anything gets actioned, and the fourth decides whether it stays fixed.
-
Attribute every pounddollareuro
Ownership comes before optimisation, because a finding without an owner is trivia.
- Cost pools typed as budget, business unit, team, project, CI/CD or asset Cloud Management
- Assignment rules with nine condition types for automatic ownership Cloud Management
- Virtual tagging computed independently of cloud-native tags Cloud Management
- Native FOCUS support — the FinOps open cost and usage specification Cloud Management
- Pool-based showback and chargeback with forecast-aware overspend states Cloud Management
-
Find the waste by name
Every finding is a named check on a named resource, with the threshold that fired it. Nothing is reported as “potential savings identified”.
- Abandoned instances, images, load balancers, S3 buckets and Kinesis streams Cloud Management
- Obsolete images, IPs, snapshots and snapshot chains Cloud Management
- Instances stopped but not deallocated, and volumes long unattached Cloud Management
- Instance rightsizing and underutilised RDS detection Cloud Management
- Kubernetes rightsizing and object-storage duplicate finder Cloud Management
- Per-check thresholds, pool exclusions and account skips Cloud Management
-
Commit at the right moment
Commitment discounts are the largest single lever and the easiest to buy six months late.
- Reserved Instance and Savings Plan coverage analysis Cloud Management
- Reserved Instance and Savings Plan purchase opportunities Cloud Management
- Instance generation upgrade and cross-region migration opportunities Cloud Management
- Short-living instances flagged as spot and preemptible candidates Cloud Management
- VM power schedules for automated start and stop Cloud Management
-
Hold the line
This is the half of FinOps most tools skip: policy that fires before the invoice does.
- Resource TTL with automatic lifecycle enforcement Cloud Management
- Total and daily expense limits per resource or pool Cloud Management
- Expense anomaly detection against a rolling daily average Cloud Management
- Tag compliance: required tags, prohibited tags and correlation rules Cloud Management
- Resource count anomaly detection and resource quota policies Cloud Management
- Constraint violation history and detected-constraints tracking Cloud Management
Ask to see any one of these running in the product itself, on the screen where it happens.
What good looks like.
You can tell a mature FinOps practice from its meetings. Nobody argues about the total.
- 01
Every finding has a name and an owner.
Abandoned Kinesis Streams, by that name. The resource, the pool it belongs to and the person who can approve the change are all on the same row.
- 02
Every check has its own threshold.
Thresholds, pool exclusions and account skips are set per check, so the disaster-recovery footprint stops generating findings without anyone disabling the check that protects everything else.
- 03
Allocation does not wait for tagging.
Virtual tags compute from account, region, service, name pattern or owner today, while the tagging policy brings the real tags into line behind them.
- 04
The cleanup does not need repeating.
TTLs expire the sandbox, expense limits cap the pool, anomaly detection catches the spike, and the violation history shows exactly what fired and when.
- 05
Your cost model outlives your vendor.
FOCUS is ingested natively and queryable directly, so the cost model is an open standard you own.
Questions worth asking us.
Not the one you came with? Ask it directly and we will answer it in writing.
We already use the native cost tools in each cloud. What does this add?
Native tools are excellent inside their own boundary and blind outside it. This builds one cost model across twelve cloud and data platforms, Kubernetes, Databricks and Snowflake among them, with one allocation scheme, one policy engine and one recommendation set. It also runs the checks the billing consoles do not: snapshot chains, abandoned streams, stopped-but-not-deallocated instances, short-living spot candidates.
Our tagging is a mess. Do we have to fix it first?
No. Virtual tagging is computed independently of cloud-native tags, so allocation works from account, region, service, name pattern or owner from day one. The tag compliance policy (required tags, prohibited tags and correlation rules) then fixes the underlying mess in the background.
How do we stop developers treating this as a cost-cutting exercise done to them?
Give them the pool and the budget. Cost pools are typed as budget, business unit, team, project, CI/CD or asset, each with its own budget, thresholds and Slack alerts. Shareable environments with booking, SSH keys and CI/CD webhooks mean the same system that bills them is the one that gets them a test environment.
Does this cover Kubernetes properly, or just the nodes underneath it?
Cost and utilisation break out by namespace, node and service, and Kubernetes rightsizing is one of the twenty-six named checks, because clusters are almost always sized for declared requests, well above what the pods ever use. The same pools, budgets and policies apply to a namespace as to a subscription.
What about the GPU spend? That is our fastest-growing line.
ML executors are cloud instances, so abandoned-resource detection, rightsizing, generation upgrade and spot migration all apply to them automatically, and ML/AI workloads can have their own cost pools and budgets. That is CerteroX AI Management, on the same engine.
Watch the checks run.
Leave with a list of names.
A populated cloud position at real scale, walked finding by finding: check by named check, resource by resource, owner by owner. Tell us which platforms you run and which of the twenty-six you would argue with.
No obligation and no gated PDF. All twenty-six checks, and someone on the call who can answer for every one of them.