OVHcloud bills the way it does for structural reasons, and the line item that surprises people is rarely the one on the pricing page they read first. This guide sets out what actually drives a OVHcloud bill and what to do about it.
The shape of the bill
On OVHcloud, products are organised into distinct universes — Public Cloud, Bare Metal, Web Hosting — and they behave differently enough that it is worth knowing which one you are in. That structure is what determines whether your monthly figure is knowable in advance or only in arrears.
Before optimising anything, be clear which of the two situations you are in. A platform that meters everything rewards attention to usage; a platform with published monthly pricing rewards attention to what is left running.
What usually drives the number up
For OVHcloud accounts, the recurring culprits are additional public IP addresses, snapshots, and object storage kept beyond its usefulness.
Beyond the platform-specific items, the same short list applies almost everywhere:
- Unattached storage volumes. Deleting a server frequently does not delete its disk, and the disk carries on billing.
- Snapshots and backups. Automatic, incremental, and accumulating for as long as the retention policy allows.
- Reserved public IP addresses. Most platforms charge for an address that is allocated but not attached.
- Resources left running after a project ends. Usually the single largest avoidable item on any bill.
Make the bill visible before it is final
Use the billing section of the control panel; most products are billed at a fixed monthly rate, so the forecast is largely the sum of what is running. Set a figure, alert well below it, and route the alert to a person. This is free on every platform and it is the difference between noticing a problem in week one and noticing it in the invoice.
Region affects price too
OVHcloud runs in a European core with additional locations in North America and Asia-Pacific — the European coverage, and the jurisdiction that comes with it, is the reason most people choose the platform. The same resource can cost meaningfully different amounts in different regions, so once latency and any data-residency requirement have narrowed the field, price is a legitimate tie-breaker between what remains.
Size against measurements, not intentions
The most reliable saving is not a discount, it is not running something you did not need. A method that works:
- Start smaller than you think. Scaling up is a reboot; over-provisioning is a bill you keep paying.
- Measure for a week under real traffic — CPU steal, memory pressure and disk wait, not just CPU utilisation.
- Resize against what you measured. Peak utilisation sitting under 20% is money going nowhere.
- Only then buy headroom, and buy it where the measurement pointed.
What vCPU actually means explains why the headline number is not the whole story.
Where to go next
- Getting started with a OVHcloud account
- Buy OVHcloud Account — every configuration in stock with its own price
- How cloud billing works — the platform-agnostic mechanics
- OVHcloud documentation
Questions
Frequently asked
Why is my OVHcloud bill higher than expected?
On OVHcloud the usual causes are additional public IP addresses, snapshots, and object storage kept beyond its usefulness, followed by resources nobody deleted after the project that needed them ended. Checking what exists against what is actually in use is the fastest way to find the difference.
How do I set a spending limit on OVHcloud?
Use the billing section of the control panel; most products are billed at a fixed monthly rate, so the forecast is largely the sum of what is running. Note that an alert warns you — it does not stop spending — so route it somewhere a person will see it the same day.
Does choosing a different region make it cheaper?
Often, yes — the same resource is priced differently by region. Weigh it after latency and any data-residency requirement, not before.