Every cloud provider comparison you can find online opens the same way: a table of services, a column per platform, a lot of green ticks. It is the least useful way to make the decision, because every major platform ticks almost every box. What actually separates them is how well their defaults match the thing you are about to build, and defaults do not fit in a table.
Here is a framework that holds up. Four questions, in order. Price is deliberately last.
1. What shape is the workload?
Cloud platforms are not general-purpose in practice, whatever they are on paper. They have a centre of gravity, and work that sits near it is cheaper, simpler and better documented than work that sits at the edge.
- A handful of long-running Linux servers. This is the most common shape and the one where the difference between platforms is largest in your favour: providers built around straightforward virtual machines will do it with less ceremony and less cost than the hyperscalers. Hetzner, Linode, UpCloud and DigitalOcean all live here.
- Managed everything. Queues, managed databases, serverless functions, identity, streaming. The more of the platform you intend to consume rather than run, the more the breadth of AWS or Azure earns its complexity.
- Data and machine learning. If the centre of the project is a large dataset and models over it, Google Cloud‘s analytics stack is the one people migrate to, not away from.
- Windows and Microsoft identity. If the organisation already runs on Active Directory and Microsoft licensing, Azure is not a preference, it is the path of least resistance.
- Bursty, unpredictable compute. Per-resource sizing — pick vCPU and RAM independently rather than from a fixed menu — is Kamatera‘s distinguishing trait, and it matters when your instances do not fit standard shapes.
Write down the shape before you look at any provider. If the answer is “a few servers and a database”, you have just eliminated most of the reasons to accept hyperscaler complexity.
2. Where does it have to run?
Region is the constraint people discover last and regret first. Three separate things hide inside it:
- Latency to your users. Physics, not marketing. A round trip from Frankfurt to Sydney is roughly 250 ms no matter whose logo is on the data centre.
- Where the data is allowed to be. If you handle EU personal data, or operate under a sector rule that names a jurisdiction, the region is decided for you. This is the reason OVHcloud exists as a distinct choice rather than a cheaper alternative.
- What the region can actually do. Not every service is in every region, and the newest ones rarely are. On the big platforms, checking service availability in your target region before committing saves a migration later.
On this site, region and IP location are part of the configuration name for exactly this reason — it is not a detail to discover after checkout.
3. Which billing model can you live with?
There are effectively two, and the gap between them is wider than any feature difference.
Flat-rate pricing gives you a server for a stated monthly figure with a generous bandwidth allowance. You know the bill in advance. Hetzner, Linode, DigitalOcean and UpCloud broadly work this way. The trade is that idle capacity is your problem: a server you are not using still costs the same.
Consumption pricing meters everything — compute-seconds, storage, requests, and above all data transfer out. AWS, Google Cloud and Azure are built this way. The trade is the inverse: you pay for what you use, and you find out what you used at the end of the month.
Neither is better. But if a surprise bill would be a genuine problem rather than an annoyance, that is a hard constraint, and it points at flat-rate. If you cannot predict load at all, metering is the honest model. See how cloud billing works for the mechanics.
4. Who operates it?
The last question is the one nobody asks. Every managed service you adopt is work you are not doing; every raw VM is work you are. If the answer to “who patches this, who watches it, who gets paged” is “me, in the evenings”, optimise for fewer moving parts. Managed services on a more expensive platform can be cheaper than self-managed services on a cheap one once your own time is priced in.
Only now, price
Once the shape, region, billing model and operational burden are settled, you will usually be looking at two or three viable platforms rather than ten — and at that point price comparison is meaningful, because you are comparing like with like.
The comparison tool puts configurations side by side with their vCPU counts, regions and prices, so the last step is the easy one. The first four are the ones worth the thinking.
A short worked example
A team ships a Rails application with a Postgres database and a background job queue. Traffic is European, steady on weekdays, near zero at weekends. Two engineers, neither of whom wants to be on call.
Shape: a few long-running servers, one managed database. Region: EU, for latency and for data residency. Billing: predictable is worth more than optimal, because the weekend trough is not large enough to justify autoscaling complexity. Operations: minimal — so a managed database rather than self-hosted Postgres.
That reasoning lands on a flat-rate European provider with a managed database option, and it took four questions rather than a feature matrix. The price comparison that follows is between two candidates, not ten.