CloudHealth vs Hypermeter

At a glance

What CloudHealth does that Hypermeter doesn’t

It can act on your cloud, not only report on it. If you enable them, CloudHealth’s policies can start, stop or terminate instances on AWS, Azure and Google Cloud, on their own or after an approver signs off, and Savings Automator manages AWS convertible reservations. Its rightsizing covers the three big clouds and vSphere. Hypermeter has no actions on your infrastructure and will not change anything you run.

It manages commitments. CloudHealth has dedicated reservation and Savings Plan management for AWS and Azure. Hypermeter does not manage commitments and will not exchange or purchase them for you.

Its connectors are built in. CloudHealth connects natively to AWS, Azure, Google Cloud and Oracle Cloud, takes Alibaba Cloud bills by upload, runs a collector in your Kubernetes clusters, and costs vSphere in its data centre module, all without configuring a source. In Hypermeter, each source is set up against its own export or API.

It has deep multi-level access control. FlexOrgs give up to ten levels of organisational units with inherited roles, built for holding companies and MSPs with many tenants.

Where Hypermeter is the better choice

The number will be challenged and you have to answer. CloudHealth’s Perspectives assign each asset to a group by rule, and shared cost moves through percentage or proportional reallocation. Hypermeter’s allocation is a pipeline you can read: shares weighted by a measure you choose, allocated rows that sum exactly to the group total, and the weights and remainders kept as evidence. When a team disputes its share of a shared platform, you open the calculation and show the rows behind it.

You want a cost tool that never acts on your infrastructure. Hypermeter has no actions: it will not resize, schedule, stop or reconfigure anything, and its connections read data with credentials you issue. Whether a cost vendor may change production is a real question in many organisations. For teams whose answer is no, a tool that cannot act is simpler to approve than one where actions are a setting away.

Ownership and data residency are part of the decision. CloudHealth has had three owners since 2018, and Broadcom documents it as SaaS only, with hosting in the US, Germany and the UK on its sub-processor list. Exivity is an independent EU company with no investors outside the EU. Hypermeter is hosted in Germany, and Exivity Core runs in your own environment, including air-gapped, where your data policy needs it.

Private infrastructure goes beyond vSphere. CloudHealth costs vSphere in its data centre module; anything else arrives as a file you build. Hypermeter pulls usage from the platform’s own API, whether that is vSphere, Nutanix Prism, OpenStack or Redfish on bare metal, without waiting for a predefined connector. It rates that usage at the rate you set, or one you derive from capital, facilities and support cost, and the result sits in the same model as the cloud bill. Hypermeter runs as SaaS, so the API has to be reachable from it; where it is not, Exivity Core meters on-site.

You need to know how the forecast was made. CloudHealth forecasts with machine learning and publishes no error history. In Hypermeter, a forecast is a calculation in your own pipeline, so its method, training window and error history can be published alongside it, and anyone who checks can see how the number was made.

The differences that decide it

Act on the cloud, or explain it

This is the biggest split. CloudHealth is built to find savings and, where you allow it, take them: rightsizing, reservation management, policies with actions. Hypermeter is built to attribute cost to whoever caused it and to defend that attribution. Decide whether a cost tool that can change production is a feature or a risk in your organisation, and the shortlist gets shorter.

How an allocation is explained

Both products keep cost they cannot place visible, rather than hiding it. The difference is what sits behind a team’s number. In CloudHealth it is the rule that put an asset in a group, and the reallocation that moved shared cost. In Hypermeter it is a calculation in your own pipeline, with its weights and remainders kept as evidence. If chargeback disputes are a monthly event, ask both vendors to walk one disputed charge back to its source, on your data.

Where private cost comes from

CloudHealth’s data centre module collects vSphere resources and prices them by benchmark or by cost drivers you set. Other platforms come in as uploaded files. Hypermeter reads usage from any platform API it can reach and rates it in the same model as the cloud, with tiered, graduated or contract rates, or a rate derived from what the infrastructure costs to run. That matters most for organisations mid-migration, where cost per workload on each side of the boundary is the business case for moving it.

Service providers

CloudHealth’s Partner Platform bills end customers for AWS, Azure and Google Cloud, with price books, markups and statements; custom price books are AWS only. Hypermeter rates each customer’s usage, cloud and private infrastructure alike, with tiered, graduated and contract pricing, and reports margin per customer. For the invoice itself, Exivity Core produces invoice-ready output, keeps a rate card per level of a reseller hierarchy, and runs self-hosted. The difference is scope: private infrastructure on the same invoice as cloud, and billing that runs in your own environment.

Migration and coexistence

CloudHealth and Hypermeter can run side by side, and during a migration they should. Both read the same billing exports from your own cloud accounts, so nothing has to come out of CloudHealth before you start. Moving means re-expressing Perspectives as a Hypermeter model. Expect to gain an allocation you can trace and a tool that never acts on your infrastructure; expect to lose rightsizing, reservation management and automated actions.

Before you leave CloudHealth: the checklist

Write these down before you sign with anyone, including us.

1. Contract. Renewal and notice dates, and what the contract says about getting your data out.

2. Allocation logic. Every Perspective and its rules, your FlexOrgs, and how tags map to teams. The part you do not want to rebuild from memory.

3. Reports people open. Not every report you have. The ones finance and engineering open each month. Ask them.

4. Alerts and policies. Budgets, anomaly alerts and governance rules, and who receives each one. Note which policies take actions.

5. Commitments. How reservations and Savings Plans are tracked, and who decides on purchases.

6. Integrations. API consumers, SSO, BI exports, and any custom data fed in from outside the cloud bill.

7. Customer billing. For service providers: price books, markups, and the rules behind each customer statement.

8. History. How many months you need for forecasts and audits, and where the raw billing exports sit in your own cloud accounts. Export the CloudHealth reports you need for audit, through FlexReports or the API, before the contract ends.

In detail