Skip to content

Technology

Cloud Costs vs Total Cost of Ownership: What Each Model Misses

A monthly cloud estimate and a five-year build-vs-buy comparison are answering two different questions — mixing them up produces the wrong one.

Published by UseKitl · Last reviewed 7 September 2026

Cloud cost estimation and total cost of ownership (TCO) modelling get treated as the same exercise — "how much will this cost" — but they answer different questions on different timescales, and each has a specific, predictable blind spot.

Cloud spend: the line people forget is egress

A monthly cloud estimate is the sum of independently metered lines: compute (instance count × hourly rate × hours running), storage (provisioned capacity × rate, charged whether used or not), and data transfer out — egress. Providers generally charge for data leaving their network but not for data arriving, which is exactly why moving data or workloads away later is expensive, and it's the line simple estimates leave out most often.

monthly = (instances × hourly rate × hours) + (GB stored × storage rate) + (GB egress × transfer rate)

In a representative example — four always-on instances at £0.096/hour, 2 TB storage at £0.021/GB, 500 GB monthly egress at £0.075/GB — compute costs about £280/month, storage about £43, and egress about £38. Egress is nearly as large as storage here, which is the point: it is a real line, not a rounding error, and a committed-use discount applied to compute alone (the usual structure) does nothing to it.

TCO: the line people forget is their own staff time

TCO sums every cost over an ownership period, not just the invoice: one-off costs (implementation, migration, integration, initial training) land in year one; recurring costs (licensing, support, hosting) repeat annually with a growth rate, because renewal prices rarely hold flat; internal staff time is costed at a loaded rate, because it is real cost even though no invoice arrives for it; and an exit cost lands in the final year, because leaving a system is itself a project.

TCO = one-off costs + Σ (annual recurring × (1 + growth)^year) + internal staff cost + exit cost

Worked comparison: the period decides the winner

A £60,000/year SaaS platform (£40,000 implementation) against a £180,000 one-off perpetual licence (£90,000 implementation, £27,000/year support, growing 5% annually):

Comparison periodOption A (SaaS)Option B (perpetual licence)
5 years≈£395,538≈£479,192 — 21% more
7 yearsconverge to within ≈2%converge to within ≈2%
10 yearsmore expensivecheaper of the two

Over five years, the subscription option is clearly cheaper — the perpetual licence's larger upfront cost, higher support percentage and greater internal administration outweigh the fact that it stops paying a recurring licence fee. Extend the comparison to ten years and the conclusion reverses. Neither five nor ten years is the "right" answer in general — the right period is however long you genuinely expect to run the system, decided honestly before the model is run, not chosen afterwards because it favours a preferred option.

Which model answers which question

  • Use a cloud cost estimate to plan monthly infrastructure spend, compare on-demand against committed-use pricing, and see which metered line — compute, storage or transfer — actually dominates a bill.
  • Use a TCO comparison to decide between two different products or approaches (build vs buy, SaaS vs licence, Option A vs Option B) over a multi-year ownership period.
  • A cloud estimate is a planning envelope for one system's running cost, not a decision between two options; a TCO comparison assumes a period long enough that one-off costs and recurring costs both have time to matter.

Common mistakes

  • Comparing headline licence cost only, and skipping internal staff time — usually the largest cost nobody put a number on.
  • Choosing a comparison period that happens to favour the answer already wanted, rather than how long the system will actually run.
  • Assuming committed-use cloud discounts reduce the whole bill, when they typically apply to compute only.
  • Treating a TCO gap of a few percent as decisive. If two totals land within roughly 10% of each other, it is closer to a tie on cost than a clear winner — decide on capability, reliability and exit difficulty instead.

Limitations

  • Both models use nominal figures with no discount rate applied, so they understate the advantage of deferring spend.
  • Cloud rates used in planning tools are illustrative — always validate against your actual provider's calculator before committing budget.
  • TCO measures cost only. It says nothing about capability, reliability or fit — a cheaper option that cannot do the job has no meaningful TCO advantage.

Found an error or something outdated in this guide? Report a correction.