How to compare cloud costs across providers properly

Why do published prices tell you so little?

Because they are the starting point of a negotiation rather than a price. Any organisation with meaningful spend has a commitment agreement, and the discount attached to it depends on volume, term and how much of the estate is covered. Two providers quoting similar rates on their websites can end up substantially apart once agreements, credits and migration incentives are applied, in either direction.

Comparisons also ignore that discount structures interact with your architecture. Commitment-based discounts reward steady, predictable consumption, so a workload that scales to zero overnight benefits far less from them than a fleet running continuously. A provider whose list price is higher can be cheaper for your particular consumption pattern, and no calculator knows your pattern.

The practical implication is procedural. Get indicative pricing from both providers for your actual projected consumption before doing any engineering analysis, and include the migration credits both will offer. Those credits are real and often significant in the first year, which also means a first-year comparison flatters whichever provider you are moving to. Compare year two.

Why is a vCPU not a vCPU?

Because the definition differs, the underlying silicon differs, and what is bundled with it differs. On some instance families a vCPU is a hardware thread sharing a physical core with another thread; on others it is a full core. Two machines with the same vCPU count and memory can therefore differ substantially in the work they complete, and the difference varies by workload rather than being a fixed ratio.

Processor generation compounds this. The same nominal size can be served by several processor families depending on region and instance type, and providers refresh at different times, so a comparison made on one date may be comparing a current generation against a previous one. Memory to core ratios also differ between families, which forces you to buy a larger machine on one platform to reach the memory your application needs.

What is included with the instance is the third variable and the most frequently missed. Local NVMe storage, network bandwidth allocation and the availability of burst behaviour vary by family and by size. An instance that appears cheaper can require separately provisioned network storage and separately purchased throughput to match what another includes, and that difference does not appear in an hourly rate comparison at all.

Which costs sit outside the calculator?

The ones that scale with behaviour rather than with capacity, which is why estimates built from instance counts are consistently low. These categories routinely account for a large share of a real bill and are the usual source of the gap between a modelled figure and an invoice.

How do the discount instruments differ?

All three major providers sell cheaper capacity in exchange for commitment, and the flexibility of that commitment varies in ways that matter more than the headline percentage. Some instruments commit you to a spend rate and apply automatically to whatever you run; others commit you to a specific machine family or region and lose value if your architecture changes. Some providers additionally discount long-running usage automatically without any commitment at all.

The right comparison is therefore not the maximum discount but the discount you would actually capture given how much your estate changes. A platform team that rearchitects frequently loses more to resource-specific commitments than it gains from their higher rate, while a stable fleet can safely take the deepest option. Ask each provider what proportion of your current usage their instrument would have covered over the past year, using your own billing data.

Splitting an estate across providers affects both agreements at once, and this is the calculation most often skipped. Enterprise-level discounts are tiered by committed volume, so moving a third of your spend elsewhere can reduce the rate applied to the two thirds that remain. Get both providers to quote at the split volumes you are contemplating, not at your current total.

What is the only comparison that settles it?

Running the workload on both, with the same load, for long enough to include a full weekly cycle. Everything else is inference. Two weeks with a representative traffic profile, real data volumes and the same performance target on each side produces a number nobody can argue with, and it usually costs less than the meetings that would otherwise be spent debating the estimate.

Measure cost per unit of work rather than cost per hour. Cost per thousand requests, per completed job, per tenant, per gigabyte processed: any of these captures the interaction between price, performance and efficiency that hourly rates hide. A machine that costs more per hour and completes forty percent more work is cheaper, and only a unit measure shows it.

Hold the performance target constant, not the machine size. The temptation is to run identical specifications on both sides, which merely reproduces the vCPU problem in a live environment. Instead, fix the latency and throughput your service must meet, size each platform to meet it with the same headroom, and compare what that costs. That is the question the business is actually asking.

How do you keep costs comparable once you run both?

By deciding on one allocation model and forcing both providers into it. Each platform exports billing data with its own schema, its own granularity and its own idea of what a service is, so a common set of tags or labels applied identically on both sides is the only thing that makes team, environment and product costs comparable. Agree that vocabulary before the second provider is populated, because retrofitting tags across a live estate is slow and never quite completes.

Then report in unit economics rather than in provider totals. Cost per tenant, per transaction or per active user is comparable across platforms and meaningful to people outside engineering, whereas a chart of two provider bills invites the wrong conversation about which vendor is cheaper in the abstract. It also surfaces the multi-cloud overhead honestly, since the fixed foundation on each side shows up as a worse unit cost on the smaller estate.

Finally, review placement annually rather than continuously. Prices, discounts and capabilities move, but moving workloads to chase a rate difference costs engineering time and introduces risk, and the traffic charges between the two sides frequently erase the saving. A yearly review with a real threshold, expressed as a percentage of the workload's total cost including people, keeps the estate honest without turning placement into a permanent project.