Cloud Cost Fundamentals: CapEx, OpEx, TCO and ROI

Cloud cost arguments are usually lost on finance terms rather than technical ones. This page covers the vocabulary, so that the AWS pages that follow can assume it.

CapEx and OpEx

Capital expenditure (CapEx) is money spent acquiring a long-term asset: a data centre, a rack of servers, a storage array. It is paid up front and depreciated over the asset’s life, so it hits the balance sheet once and the profit-and-loss account gradually.

Operating expenditure (OpEx) is the ongoing cost of running the business. It is variable, it scales with usage, and it is expensed as incurred.

Cloud consumption is OpEx. That is not automatically an advantage — the point is that it is a different shape, and a business case that compares a cloud monthly bill against a server’s purchase price without accounting for depreciation, refresh cycles and everything in the TCO section below is comparing the wrong things.

The problem with buying capacity in advance

Traditional infrastructure budgeting runs on multi-year refresh cycles, typically five. A large purchase is scrutinised heavily, made once, and then has to last. That forces a capacity prediction years ahead of the demand it serves, and there are only three ways it can land:

• Demand roughly matches capacity. The ideal, and the rarest. Cost is fixed regardless of how much of the capacity is used.
• Capacity exceeds demand. Assets sit idle and depreciate. The money is spent either way; the opportunity cost is whatever else it could have funded.
• Demand exceeds capacity. Emergency purchases at list price, without the bulk discount of the planned buy, producing a mixed estate of hardware generations that is more expensive to maintain than either generation alone.

Consumption-based pricing removes the prediction. Capacity tracks demand, and the commitment mechanisms — Savings Plans and Reserved Instances — let you trade some of that flexibility back for a lower rate where demand is predictable. That is the actual choice on offer, and it is more nuanced than “pay-as-you-go versus buying servers”.

Note that not everything sold as cloud behaves this way. A fixed-fee hosting contract with a multi-year term has the commitment profile of CapEx wearing OpEx clothing, whatever it is called.

Total cost of ownership

TCO is the full cost of a decision over its life, not the purchase price. The costs teams reliably forget are the indirect ones:

• Power, cooling and the electricity to run both.
• Floor space, and the building it is in.
• Fire suppression, physical security, insurance.
• Network connectivity and its redundancy.
• Hardware maintenance contracts and spares.
• The staff time spent racking, patching, replacing failed disks and testing failover.
• The cost of capacity that is provisioned but idle.

A TCO comparison that counts only instance hours against server purchase price will favour the servers, and it will be wrong. Building the comparison with the finance team rather than for them is what makes it survive scrutiny — they own the depreciation schedule and the cost-of-capital assumptions.

Return on investment

ROI is what the organisation expects to get back. It is not always a positive return: avoiding a loss, or de-risking an outage that would have cost more than the project, is a legitimate ROI argument, and often an easier one to evidence than a revenue claim.

Migration is more expensive before it is cheaper

Every cloud business case should show the trough. There is a period during which you are running both estates, staff are learning, architectures are still lift-and-shift rather than cloud-native, and costs are higher than either the old world or the eventual new one. Modelling that period honestly is what stops a programme being declared a failure six months in.

Business plans layer assumption on assumption — projected demand, migration velocity, staff retention, market conditions — and the confidence interval widens with each one. Say which assumptions the plan is most sensitive to, and revisit them on a schedule rather than at the end.

For AWS-specific modelling, the AWS Pricing Calculator produces a per-service estimate, and Cost Explorer gives you the actuals to compare it against once you are running.