You cannot compare cloud compute on the on demand price alone, because the instances underneath those prices differ in how a vCPU is defined, the memory to core ratio, the processor generation, and what storage and network are bundled in. A like for like comparison takes three steps: normalise the specification so you are pricing equivalent capability, compare the effective rate after the commitment discount each provider realistically offers, and then account for the costs that never show in a compute rate, above all data transfer. Done this way the ranking often changes from the one the sticker prices suggested, because the headline rate is the least reliable input in the whole calculation. Specificity is everything here, and the cheapest sticker rarely wins on the effective basis that actually hits the bill.
Here is the method, the instruments that set the effective rate, and the hidden lines that decide the real answer.
Why is the on demand rate misleading?
Two instances with the same name length and similar headline prices can deliver very different work. A vCPU may map to a full physical core on one platform and a hardware thread on another. Memory per core varies by family, so a workload that is memory bound pays for cores it does not use unless you pick the right shape. Processor generation matters: a newer generation often delivers more performance per dollar, and on AWS the Graviton families change the economics again. Bundled local storage and baseline network throughput differ too. Comparing the sticker rate without normalising for all of this is comparing two different products and calling it a price comparison.
What is the effective rate, and how do commitments set it?
The number that belongs in a comparison is the effective rate: what you pay per unit of normalised compute after the discount instrument you will realistically use. Every provider offers one, and they discount roughly 20 to 72 percent against on demand in exchange for the buyer carrying utilization risk.
| Cloud | Primary compute commitment | Character |
|---|---|---|
| AWS | Savings Plans and Reserved Instances | Savings Plans trade flexibility for a spend commitment; Reserved Instances trade specificity for a deeper rate. Graviton and gp3 migrations add standing savings on top. |
| Azure | Reservations and the Azure Savings Plan | Reservations can be exchanged; Hybrid Benefit and Dev Test pricing change the maths; the MACC drawdown shapes purchasing. |
| GCP | Committed Use Discounts | Spend based and resource based CUDs differ; sustained use discounts also apply automatically, lowering the effective rate without a commitment. |
| OCI | Universal Credits | Annual flex or pay as you go; flexible compute shapes allow precise sizing; Support Rewards offset Oracle support fees. |
The table summarises the instruments, not a price ranking: discount ranges are indicative and depend on term, payment option, coverage, and the specific family. The point is that the effective rate is set by the instrument you actually buy, so a comparison that ignores commitments compares a price no mature buyer pays.
Which hidden lines decide the real cost?
Compute is rarely the whole bill, and the lines outside it often decide the comparison.
- Data transfer and egress. The largest distorter. OCI egress is materially cheaper than the hyperscalers, while on AWS data transfer and NAT gateway charges are quiet budget eaters that can rival the compute they support.
- Bundled versus separate storage. Local instance storage included on one shape but billed separately on another changes the true cost of an equivalent node.
- Automatic discounts. GCP sustained use discounts lower the effective rate with no commitment, which a sticker comparison misses entirely.
- Licence treatment. Azure Hybrid Benefit and licence included versus bring your own licence on OCI databases move the real cost well away from the compute rate.
A comparison that stops at compute is incomplete; the egress and licence lines are where a seemingly cheaper cloud can turn out more expensive for a given workload.
A worked example
A European SaaS company was about to move a data heavy service to whichever cloud showed the lowest on demand compute rate. Normalising the instance specification first, equal usable vCPU and memory on current generation shapes, narrowed the gap considerably. Applying the effective rate each provider would actually deliver under a realistic commitment closed it further. The decision then flipped entirely once egress was modelled: the service moved large volumes of data out, and the cheapest sticker rate carried the most expensive egress, while a provider with a higher headline compute rate and materially cheaper egress was the lower total cost. Choosing on the effective and fully loaded basis avoided a costly migration to the wrong platform. Figures are verified against billing data and anonymised, and pricing references should always be checked against each provider's current pricing page.
How should you run the comparison in practice?
Build the comparison in three passes. First, normalise: define the workload by usable vCPU, memory, storage, and network, then map each cloud to the shape that meets it on current generation hardware. Second, price the effective rate: apply the commitment instrument you would realistically buy at a defensible coverage level, not the sticker rate. Third, load the hidden lines: add data transfer, egress, bundled storage differences, automatic discounts, and licence treatment for the actual traffic pattern. Verify every list figure against the provider's current pricing page rather than memory, and label anything modelled as indicative. The output is a total cost for an equivalent workload, which is the only number worth deciding on.
Frequently asked questions
Can you compare cloud compute on the on demand price alone?
What is the effective rate?
Which hidden costs distort a compute comparison?
Compare clouds on the number that matters
Our cross cloud cost optimization playbook lays out the normalisation, effective rate, and fully loaded comparison method we use to evaluate AWS, Azure, GCP, and OCI for a given workload. We take zero provider commissions and answer only to you. Download the guide, and read the cross cloud pillar for the full method.
Put a defensible number on your cloud spend.
No provider in the room, no published price list. Tell us your footprint and we will scope the savings against your billing data — we reduce your cloud spend or we reimburse our service fee.
The Cloud Spend Navigator: what changed in cloud pricing, commitments, and FinOps — no vendor spin.