Skip to content

Cloud Management
FinOps

Twenty-six ways
your cloud bill
is wrong.

A named, tunable optimization engine across twelve cloud and data platforms, with the policy, budget and lifecycle controls to stop the waste coming back next month.

Walk the twenty-six checks See the engine

One of five asset classes on the CerteroX platform. Same data model as ITAM, SAM, SaaS and AI.

Anomaly detection

Illustrative

Daily spend

rolling 7-day average ±15%

+48% day 1 day 30

Constraint

Expense anomaly

Pool

engineering

Action

Owner alerted

The problem

The cloud bill went up again.

The dashboard has the total, and underneath it sit the forty stopped-but-not-deallocated VMs, the snapshot chains nobody can delete because an obsolete AMI references them, and the reserved instance you should have bought in March.

So the meeting becomes a negotiation about the total. A named check turns it into a list of resources with names, owners and a delete date.

29%

of cloud spend is wasted — up for the first time in five years

wasted

  • Not on the dashboard

  • 01 still billing

    40 VMs stopped last quarter. None of them deallocated.

    The console shows a healthy stopped state. The reserved compute, the attached disks and the static IPs keep billing exactly as before.

    Instances in Stopped State for a Long Time

  • 02 chain of custody

    A snapshot nobody is allowed to delete.

    It is referenced by an image that was deregistered eleven months ago, which is referenced by two more snapshots behind it. Delete order matters, so nobody touches any of it.

    Obsolete Snapshot Chains

  • 03 five months late

    The reserved instance you should have bought in March.

    Steady-state usage, flat for a hundred and fifty days, paying the on-demand rate the entire time because nobody was watching for the commitment window.

    Reserved Instances Opportunities

  • Three of the twenty-six named checks. Each finding names a resource, an owner and a decision to make about it.
named recommendation types
26 named recommendation types
cloud and data platforms
12 cloud and data platforms
governance policy types
6 governance policy types
open cost spec, natively
FOCUS open cost spec, natively
Optimization

Every finding, with the reason attached.

Pick a family of checks, then pick a finding. Each one carries the threshold that produced it, the pools it ignores and the accounts it skips.

  • Named The finding carries the name of the check that produced it.
  • Evidenced The reason it fired is on the record beside it.
  • Tunable Thresholds, exclusions and skips are yours to set.

Recommendations

Illustrative interface · sample data

16 open recommendations

est. monthly saving £4,370$5,865€5,106

Visibility to Governance

Governance is the layer almost nobody reaches.

Four layers take a FinOps programme from a chart to an enforced policy. Each one names what it actually contains.

Visibility

One cost model across every provider, in an open standard.

This is the cost model, where every provider is reduced to one set of columns you can query, export and argue with.

Stop here and you have a dashboard.

8 named capabilities

  • Cost Explorer by owner, pool, service, region, account and day
  • Interactive geographic Cost Map
  • Resource inventory across 12 first-class resource types
  • Kubernetes cost and utilisation by namespace, node and service
  • Reserved Instance and Savings Plan coverage analysis
  • Inter-region data transfer and traffic expense breakdown
2 more in Visibility
  • Native FOCUS support — the FinOps open cost and usage specification
  • Raw billing export to external BI, plus scheduled email reporting

Optimization

Twenty-six named checks, every one of them tunable.

The engine sits here: twenty-six named checks, each with its own thresholds, exclusions and account skips.

Stop here and the same waste is back next quarter.

10 named capabilities

  • Abandoned instances, images, load balancers, S3 buckets and Kinesis streams
  • Obsolete images, IPs, snapshots and snapshot chains
  • Instance rightsizing and underutilised RDS detection
  • Instances stopped but not deallocated, and volumes long unattached
  • Instance generation upgrade and cross-region migration opportunities
  • Reserved Instance and Savings Plan purchase opportunities
4 more in Optimization
  • Short-living instances flagged as spot and preemptible candidates
  • Kubernetes rightsizing and object-storage duplicate finder
  • VM power schedules for automated start and stop
  • Per-check thresholds, pool exclusions and account skips

Management

Allocation and ownership that keep themselves current.

Allocation happens at this layer, so ownership survives a reorg: assignment rules compute it from the resource itself.

Stop here and acting on the finding is still optional.

7 named capabilities

  • Cost pools typed as budget, business unit, team, project, CI/CD or asset
  • Assignment rules with nine condition types for automatic ownership
  • Virtual tagging computed independently of cloud-native tags
  • Shareable environments with booking, SSH keys and CI/CD webhooks
  • Slack bot for pool alerts, TTL management and expense tracking
  • Three built-in roles across five permission groups
1 more in Management
  • Thirty-plus notification templates with custom SMTP and branding

Governance

Policy that fires before the invoice does.

Enforcement is the last layer, where policy fires at the resource and leaves a violation history you can hand to audit.

This is the layer that stops it happening again.

9 named capabilities

  • Expense anomaly detection against a rolling daily average
  • Expiring and recurring budget policies
  • Resource count anomaly detection and resource quota policies
  • Tag compliance: required tags, prohibited tags and correlation rules
  • Resource TTL with automatic lifecycle enforcement
  • Total and daily expense limits per resource or pool
3 more in Governance
  • Constraint violation history and detected-constraints tracking
  • Security signals: inactive IAM users, unused console access, open security groups
  • Pool-based showback and chargeback with forecast-aware overspend states

Thirty-four named capabilities across the four layers. The same four layers govern ITAM, SAM, SaaS and AI on the same platform, so five asset classes run on one model.

Why this one

A cloud cost dashboard cannot do these three things.

01 / Named checks

The recommendations have names

The engine never reports “potential savings identified”. It reports Abandoned Kinesis Streams, Obsolete Snapshot Chains and Instances in Stopped State for a Long Time. All twenty-six checks are individually tunable, with their own thresholds, pool exclusions and account skips.

Twenty-one of the twenty-six, by name

  • Abandoned Instances
  • Abandoned Images
  • Abandoned Load Balancers
  • Abandoned S3 Buckets
  • Abandoned Kinesis Streams
  • Obsolete Images
  • Obsolete IPs
  • Obsolete Snapshots
  • 13 more, by name Show fewer
    • Obsolete Snapshot Chains
    • Instance Rightsizing
    • Underutilised RDS Instances
    • Kubernetes Rightsizing
    • Instances in Stopped State for a Long Time
    • Volumes Not Attached for a Long Time
    • Instance Generation Upgrade
    • Cross-Region Instance Migration
    • Reserved Instances Opportunities
    • Savings Plan Opportunities
    • Short Living Instances
    • Object Storage Duplicate Finder
    • VM Power Schedules

02 / Open cost model

FOCUS-native, down to the collector

A collector of its own ingests the FinOps Open Cost and Usage Specification, and cost data can be queried against it directly. Your cost model stays portable and auditable.

FinOps Open Cost and Usage Specification, ingested as-is

  • BillingAccountId
  • ChargePeriodStart
  • ChargeCategory
  • ServiceCategory
  • ResourceId
  • BilledCost
  • EffectiveCost
  • ListCost

Column names from the published FOCUS specification, FinOps Foundation. A provider that emits FOCUS is costed correctly without a bespoke connector.

03 / Enforcement

Governance that acts automatically

Resource TTL, daily and total expense limits, tag correlation rules with effective dates, and anomaly detection on both spend and resource count. Policies enforce at the resource level, with a violation history you can hand to audit.

  • 01 Expense anomaly
  • 02 Resource count anomaly
  • 03 Expiring budget
  • 04 Recurring budget
  • 05 Resource quota
  • 06 Tagging policy

Six constraint types, plus resource TTL, total and daily expense limits, and a violation history per constraint.

Verification

Certified by the body that publishes the standard.

The FinOps Foundation writes the FOCUS specification this product ingests, and it certifies the platforms and the providers that implement it. Both certifications and the membership are in its public directory.

Certero Limited, company number 06387180, incorporated 2 October 2007. Privately owned and independent.

Certified by the FinOps Foundation

  • FinOps Certified Platform

    CerteroX Cloud Management, FinOps Foundation

  • FinOps Certified Service Provider

    Certero FinOps Managed Service, FinOps Foundation

Foundation membership

  • FinOps Foundation

    General Member

All three listed at finops.org/members/certero

Also certified

  • ISO 27001:2022
  • Cyber Essentials Plus
  • SOC 2 Type 1
  • ServiceNow Certified App

The Foundation certifies people too.

Five FinOps qualifications, held across Certero and listed in the Foundation’s own member directory.

Source: FinOps Foundation member directory, finops.org/members/certero. Checked 2 August 2026. Counts are per certification, not per person.

  • FinOps Certified Practitioner

    24

  • FinOps Certified Professional

    4

  • FinOps Certified Engineer

    16

  • FinOps FOCUS Analyst

    31

  • FinOps for AI

    3
Connects to

All twelve billing platforms
land in one cost model.

Billing and usage are pulled from the platforms themselves. Everything else is signal, workflow and delivery, because a finding has to travel through all of it before it becomes a change.

All integrations

Cost and usage sources: 9 of 12 billing types, named

  • AWS
  • Microsoft Azure
  • Google Cloud
  • Alibaba Cloud
  • Oracle Cloud (OCI)
  • Nebius
  • Kubernetes
  • Databricks
  • Snowflake

Signal, workflow and delivery

  • Datadog
  • GitHub
  • Slack
  • Terraform
  • Jenkins
  • GitLab
  • Jira
FOCUS

Plus anything that emits the FinOps Open Cost and Usage Specification. The open standard is a first-class input, so a provider does not need a bespoke connector to be costed correctly.

Cloud, specifically

Questions worth asking us

The six that decide whether this is worth a meeting.

What does “twenty-six named checks” actually mean in practice?

Every recommendation the engine produces comes from a specific module with a specific name: Abandoned Kinesis Streams, Obsolete Snapshot Chains, Instances in Stopped State for a Long Time. You see which check fired, on which resource, and why. Each one carries its own thresholds, pool exclusions and account skips, so you set what fires and what it passes over.

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. CerteroX Cloud Management 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 set of recommendations. It also runs the optimisation checks the native billing consoles leave out: snapshot chains, abandoned streams, stopped-but-not-deallocated instances, short-living spot candidates.

What is FOCUS, and why does it matter to us?

FOCUS is the FinOps Open Cost and Usage Specification, an open standard for cost and usage data that every major provider can emit. A dedicated collector ingests it natively and cost can be queried against it directly, so you can query the model, audit it and hand the same columns to your BI team.

Our tagging is a mess. Can we still allocate cost to teams?

Yes, and you do not have to fix the tags first. Cost pools are typed as budget, business unit, team, project, CI/CD or asset. Assignment rules with nine condition types put resources into pools automatically, and virtual tagging is computed independently of cloud-native tags. Allocation therefore works from account, region, service, name pattern or owner, while the tagging policy brings the real tags into line behind it.

Does it cover Kubernetes properly, or just the underlying nodes?

Cost and utilisation are broken out by namespace, node and service, and Kubernetes rightsizing is one of the named checks, because requests are usually set well above what the pods go on to use. The same cost pools, budgets and policies apply to a namespace as to a subscription.

How do we stop the waste coming back next month?

That is the job of the governance layer. Resource TTL with automatic lifecycle enforcement, total and daily expense limits per resource or pool, expiring and recurring budgets, tag compliance with required, prohibited and correlation rules, and anomaly detection on both spend and resource count. Every violation is kept in history, so you can show what fired and when.

Not on the list

Send it over and you get an answer with the check names in it, and a working session if you want one.

Ask a question
Start with the bill nobody can explain

The twenty-six checks
each name a resource.

The demo runs them against a populated cloud environment at full scale: check by named check, resource by resource, with the reasoning attached to each finding.

Book a working session Model your savings

No obligation, no gated PDF. Demo data, a real cost model, and nothing to connect first.