Total Cost of Ownership

The invoice that only tells you the price of the meter

In 2022, 37signals, the company behind Basecamp and the email service Hey, decided its AWS and Google Cloud bills had become one of the most expensive parts of running the business, and began moving that infrastructure back into its own data centers. By 2024, its annual cloud bill had dropped from $3.2 million to $1.3 million, a reported $2 million a year in savings, after an upfront hardware purchase of around $700,000, with the company projecting more than $10 million saved over 5 years. That is a real, well-documented case of owning hardware costing less than renting the equivalent capacity, for that company's specific, steady, predictable workload.

It is also, on its own, an incomplete comparison, and understanding why is exactly what total cost of ownership is for.

What TCO actually means

Total cost of ownership is the complete cost of acquiring, running, and maintaining a system over a defined period, usually 3 to 5 years, not just the price of any single line item. A cloud invoice shows the meter: compute, storage, and data transfer, billed for the month just used. A hardware quote shows the sticker price of the box. Neither one is TCO. TCO is what you get once you add everything that surrounds that visible number on both sides of the comparison.

Direct costs versus the costs nobody puts on the invoice

The direct, metered costs are the ones a cloud bill already shows: compute, storage, and data transfer. Data transfer deserves a specific note, because it is not symmetric. AWS, like most providers, does not charge to move data into its cloud, but does charge, on a tiered basis, to move data out, called egress. A workload that reads a small amount of data but exports large amounts of it regularly can carry a much bigger data-transfer bill than its compute costs alone would suggest.

Everything else is an indirect cost, and it sits on both sides of the comparison, not just one. On the cloud side: the one-time work of migrating or re-architecting a workload to run there, staff time spent configuring, monitoring, and optimizing cloud resources, the cost-management and monitoring tooling bought specifically to track that spend, and security or compliance tooling layered on top. On the on-premises side: power and cooling for the room the hardware sits in, the real estate itself, a hardware refresh every few years as equipment ages out, and staff time spent racking, patching, and eventually disposing of retired equipment, the same maintenance burden the first lesson in this domain described as one of the original reasons the cloud exists.

The trap: comparing only what's easy to compare

It is tempting to run this comparison by looking up 2 numbers, this quarter's cloud bill and the sticker price of equivalent server hardware, and declaring whichever one is smaller the winner. Neither number is TCO. The cloud bill leaves out the staff and tooling built up around it. The hardware sticker price leaves out power, cooling, and the refresh cycle that arrives again in 3 to 5 years.

The 37signals case is a useful, real example of how easy this trap is to fall into even when a company is genuinely trying to be rigorous. Independent reporting on the move specifically noted that its published savings figures did not yet account for future hardware refresh costs, the additional operations staff the move required, or the ongoing cost of running data center space, power, and cooling. That is not a criticism of 37signals's decision, which may well still hold up once those categories are counted. It is a demonstration that even a company publicly making the case for owning hardware had not, at the point those figures were reported, finished counting every category a full TCO comparison requires.

Worked example: a 3-year comparison, done honestly

Take a workload with steady, predictable traffic and compare 3 years of on-premises ownership against 3 years in the cloud, counting the indirect costs on both sides.

For this specific, steady workload, the honest 3-year comparison favors on-premises hardware, by about $56,000, and not simply because the cloud's metered bill is bigger than the hardware's sticker price. It only becomes clear once staffing and tooling are counted on both sides. This is the same shape of decision 37signals made, at a much larger scale.

Change one assumption and the answer can flip. Give this workload a traffic pattern that spikes to 3 times its baseline for 2 weeks a year, and the on-premises side now needs hardware sized for a peak it uses for 2 weeks and leaves idle the rest of the year, the exact overprovisioning problem the cloud was built to remove. The cloud side, by contrast, simply scales up for those 2 weeks and back down afterward, paying only for the extra capacity it actually used. That single change in workload shape is often enough to tip the comparison the other way. Neither "the cloud is always cheaper" nor "the cloud is always a ripoff" is a rule you can memorize; TCO is a calculation you run for a specific workload, not a verdict that transfers from one company's case to another's.

FinOps: the discipline that keeps TCO from going stale

A TCO calculation is a snapshot, priced once for a decision made at one point in time. Cloud spending does not stay still after that decision: it changes every time an engineer spins up a new resource, which is exactly what makes it different from a fixed annual data center budget set once and left alone. FinOps is the discipline built to manage that difference. The FinOps Foundation defines it as an operational framework and cultural practice that maximizes the business value of technology, enables timely, data-driven decisions, and creates financial accountability through collaboration between engineering, finance, and business teams, rather than treating cost as something only a finance department reviews after the fact.

This is the same idea AWS's own Well-Architected Framework points at with its cost optimization principles: implementing cloud financial management as a real organizational capability, and continuously analyzing and attributing expenditure so a workload's owner can see, and act on, what it actually costs. FinOps is what it looks like to run that analysis continuously instead of once a year.

Where this leaves you

A cloud invoice and a hardware quote are both partial answers. Before comparing 2 ways of running a workload, list every direct and indirect cost on both sides, price them over the same multi-year window, and only then compare totals. Get that habit right once, in a spreadsheet, and FinOps is simply what it looks like to keep doing it continuously instead of once.

That closes out the economics of the cloud: what problem it solves, how you pay for it, and what it actually costs to run. The next domain leaves cost behind and turns to the services themselves, starting with the 3 ways cloud providers package what they sell: IaaS, PaaS, and SaaS.