Total cost of ownership is every cost of running a workload over a fixed period, usually 36 months: compute, storage, backup, egress, IP addresses, licences, support, staff time, one-off migration costs and, for owned hardware, purchase minus resale value. Compare options on the same period and the same workload, then test which assumptions flip the answer.
Assumptions and when this method does not apply
This method compares hosting options for a workload you can describe today: a set of servers, storage, traffic and the people who look after them. It assumes the workload is roughly stable or growing in a way you can estimate, and that you are choosing between running it on cloud virtual machines, on rented bare-metal servers, or on hardware you own in your office or a colocation facility.
It is the wrong tool in a few cases:
- Very spiky or short-lived workloads. A batch job that runs for two days a month, or an event that needs ten times normal capacity for a week, is better modelled as cost per run than as a 36-month total.
- Strategic constraints that override cost. Data residency, a regulator's requirement or a contract can decide the answer before money does.
- Accounting treatment. This method compares cash and effort. Whether a cost is capital or operating expense, and how it is depreciated, matters to your finance team; ask them. For reference, IRS Publication 946 classes computers and peripheral equipment as 5-year property for US depreciation.
Every number in this guide's examples is a hypothetical assumption chosen to show the method. None is a BroadNet price or any provider's price. Replace them with figures from your own quotes and invoices; BroadNet quotes show the price in writing Price shown at quote.
The cost lines that belong in a TCO
A useful TCO is a complete list, not a precise one. Leaving out a line biases the result far more than estimating it roughly. These are the lines to include for each option, and the ones people forget.
| Cost line | Cloud VMs | Rented bare metal | Owned (on-prem or colo) | How to estimate |
|---|---|---|---|---|
| Compute | Per instance, per hour or month | Per server, per month | Hardware purchase minus residual value | Size from monitoring, not from old hardware |
| Storage | Per GB-month, plus performance tiers | Often local disks included; extra arrays priced | Disks in the purchase; spares | Used capacity plus 12-36 months growth |
| Backup | Snapshots and backup storage per GB | Backup service or your own target | Backup hardware, off-site copy | Retention x change rate, plus one off-site copy |
| Egress (outbound data) | Usually metered per GB | Often an included allowance, then metered | Your internet circuit | Last 3 months of outbound traffic, plus growth |
| Public IPv4 | Some providers charge per address | Small block often included; extra priced | From your carrier or registry | Count addresses actually needed |
| Licences | OS, database, control panel | Same | Same, plus hypervisor | Per-core licences change with server shape |
| Support | Provider support plan | Provider support terms | Hardware warranty and vendor support | What response you actually need, in writing |
| Facility | Included | Included | Power, cooling, space, connectivity | Measured power draw, colo contract |
| Staff time | Patching, monitoring, cost reviews | Plus hardware incidents via provider | Plus hardware, spares, site visits | Hours per month x loaded hourly cost |
| One-offs | Migration, re-architecture | Migration, setup | Migration, installation, racking | Project estimate; see the migration guide |
| Refresh | None | None | Replacement at end of life | Count it if the period crosses the refresh date |
Staff time is the line most often left out and usually the one that changes the answer. Use a loaded hourly cost (salary plus benefits and overheads), not a salary divided by working hours. If your team will not actually do the work, the cost is real anyway: it shows up later as incidents.
Egress deserves its own estimate from real traffic data. A content-heavy site, a backup that copies off-platform every night, or an API that returns large responses can make egress the largest line on a cloud bill.
Utilization: what you pay for versus what you use
Total cost only tells you what you spend. To compare fairly, divide by what you actually use. A server that averages 25 % CPU utilization costs four times as much per unit of work as the same server at 100 %. Owned and rented servers are paid for whether they are busy or idle; cloud instances can be resized or switched off, but only if someone does it.
Worked example: cost per used core
Assumptions: a server with 32 cores costing USD 700 per month (hypothetical), averaging 25 % utilization.
Cost per core = 700 / 32 = USD 21.88 per month.
Cost per used core = 21.88 / 0.25 = USD 87.50 per month.
A cloud option at USD 40 per core-month (hypothetical) that can be right-sized to the 8 cores actually used costs 8 x 40 = USD 320, less than half the idle server. At 80 % utilization the owned server costs 21.88 / 0.8 = USD 27.35 per used core, and the cloud option loses.
The lesson is not "cloud is cheaper" or "bare metal is cheaper". It is that utilization decides. Measure average and peak usage over at least a month before you trust any comparison, and use the cloud unit cost tool to turn totals into cost per user, request or GB.
Worked example: one workload, three options, 36 months
The workload: a web application with a database, about 16 cores and 64 GB RAM of real demand, 2 TB of storage, 5 TB of outbound traffic per month and four public IPv4 addresses. All figures below are hypothetical assumptions chosen to show the method; they are not quotes from BroadNet or any provider.
| Line | Cloud VMs | Rented bare metal | Owned in colo |
|---|---|---|---|
| Compute | 600 (4 VMs x 150) | 700 (2 servers x 350) | See purchase below |
| Storage | 160 | 0 (local disks included) | 0 (in purchase) |
| Backup | 60 | 80 | 80 |
| Egress | 250 (5,000 GB x 0.05) | 0 (within assumed 20 TB allowance) | 300 (internet circuit) |
| Public IPv4 | 16 (4 x 4) | 16 | 0 (with circuit) |
| Licences | 50 | 50 | 100 (adds hypervisor) |
| Support / warranty | 100 | 100 | 75 |
| Facility (power, space) | 0 | 0 | 450 |
| Staff time at 75/h | 600 (8 h) | 1,050 (14 h) | 1,500 (20 h) |
| Monthly total | 1,836 | 1,996 | 2,505 |
Worked example: 36-month totals
Cloud VMs: 1,836 x 36 = 66,096, plus an assumed migration one-off of 6,000 = USD 72,096.
Rented bare metal: 1,996 x 36 = 71,856, plus an assumed migration and setup one-off of 8,000 = USD 79,856.
Owned in colo: 2,505 x 36 = 90,180. Hardware purchase assumed at 18,000 with a 20 % resale value after 36 months, so net hardware = 18,000 - 3,600 = 14,400. Migration and installation assumed at 10,000. Total = 90,180 + 14,400 + 10,000 = USD 114,580.
On these assumptions, cloud is cheapest, rented bare metal is about 11 % more, and owned hardware is about 59 % more, mostly because of staff time and facility costs. The next section shows how fragile that ranking is.
Sensitivity analysis: which assumption flips the answer?
A TCO result is only as good as its weakest assumption. Change one input at a time, by an amount you think is plausible, and see whether the ranking changes. The inputs worth testing first are the ones that are uncertain and large: egress, staff time, utilization and growth.
| Change | Cloud VMs | Rented bare metal | Owned in colo | Cheapest |
|---|---|---|---|---|
| Base case | 72,096 | 79,856 | 114,580 | Cloud |
| Egress 20 TB/month | 99,096 | 79,856 | 114,580 | Bare metal |
| Staff time +50 % | 82,896 | 98,756 | 141,580 | Cloud |
| Cloud compute right-sized nights (-200/month) | 64,896 | 79,856 | 114,580 | Cloud |
Worked example: the egress break-even
At 20 TB per month, cloud egress = 20,000 GB x 0.05 = USD 1,000 per month, 750 more than the base case. Over 36 months: 750 x 36 = 27,000, so cloud rises to 72,096 + 27,000 = 99,096.
Where do the two lines cross? The base-case gap is 79,856 - 72,096 = 7,760 over 36 months, or 7,760 / 36 = about 215.6 per month. At 0.05 per GB that is 215.6 / 0.05 = about 4,311 GB of extra egress. So under these assumptions, once outbound traffic passes about 9.3 TB per month (5 TB + 4.3 TB), rented bare metal with an included allowance becomes cheaper.
Finding the break-even point is more useful than the totals themselves. It turns the decision into a question you can check: "Will our egress pass 9 TB a month in the next three years?" Run your own inputs and break-even tests in the TCO calculator.
When cloud tends to win, and when bare metal does
Cloud tends to win when
Demand is variable or unknown, so paying for peak all the time wastes money. The team is small and managed services remove real hours. Egress is modest. You need to start quickly and may change shape often. The workload is early and could be retired.
Bare metal tends to win when
Utilization is high and steady. Egress is heavy and the server price includes a large allowance. Licences are per core and you can consolidate onto fewer, larger machines. You need consistent disk and CPU performance without neighbors. The team is comfortable operating servers.
Owned hardware tends to win when
You already have the facility and staff, utilization is high, hardware will be used past the 36-month horizon, and there are reasons to keep the equipment in your own hands. Count the refresh you will face at the end of its life.
Many teams end up with a mix: steady base load on bare metal or a reserved VPS, burst and experiments on cloud. That mix is often the cheapest answer, but it adds the cost of running two environments, which belongs in the staff-time line. See choosing a hosting type for the non-cost factors.
TCO checklist
- Same workload, same period (36 months), same service level for every option.
- Sizing from at least a month of monitoring data, not from the current hardware.
- Every cost line in the table above present, even if estimated at zero.
- Egress taken from real traffic logs, including backups and replication that leave the platform.
- Staff time in hours per month at a loaded hourly cost, for every option.
- One-off costs: migration, setup, training, overlap months running both environments.
- Owned hardware: purchase, residual value, spares, warranty, refresh if inside the period.
- Renewal terms: does the price change after the first term? Is it written in the quote?
- Growth: storage and traffic at month 36, not month 1.
- Sensitivity: egress, staff time, utilization and growth each tested; break-even points written down.
- Every input labelled with its source: quote, invoice, measurement or assumption.
Common mistakes
- Comparing list price per server. It ignores storage, egress, backup, IPs and people.
- Sizing the cloud option to match old hardware. Old servers are usually oversized; the cloud estimate inherits the waste.
- Leaving out staff time because the people are already on payroll. Their hours have a cost and an alternative use.
- Ignoring the overlap period. During migration you pay for both environments, often for one to three months.
- Using first-term prices for 36 months. Check renewal terms and contract escalators.
- Counting owned hardware at full purchase with no residual value, or assuming it lasts forever with no refresh.
- Treating one total as the answer. Without a sensitivity check you do not know how close the options are.
Frequently asked questions
Why 36 months?
It is long enough to spread one-off migration costs and short enough that hardware refresh and price changes stay predictable. Use 60 months if you plan to keep owned hardware for five years, but then include the refresh.
How do I estimate staff time?
List recurring tasks (patching, monitoring, backup checks, incidents, cost reviews, hardware issues) with hours per month for each option, then multiply by a loaded hourly cost. Check it against a few months of real ticket or timesheet data if you have it.
Is egress really that important?
For content-heavy, API-heavy or backup-heavy workloads it can be the largest single line. It also varies most between pricing models, so it is often the input that flips the result.
Should reserved or committed-use discounts be included?
Yes, as a separate scenario. They lower the monthly rate but remove flexibility, so compare them at the utilization you actually expect, and include the cost of unused commitment.
How do I compare a quote with an on-prem budget?
Put both on the same sheet with the same lines and period. For the quote, use the inclusions, renewal terms and allowances written in it; for on-prem, include facility, staff, spares and residual value.
Where can I run my own numbers?
Use the TCO calculator for the 36-month comparison and the cloud unit cost tool for cost per user, request or GB.
Sources
- FinOps Framework, FinOps Foundation
- Cost Optimization Pillar, AWS Well-Architected Framework, Amazon Web Services
- Well-Architected Framework: cost optimization, Google Cloud
- Azure Well-Architected Framework: Cost Optimization, Microsoft
- SP 800-145: The NIST Definition of Cloud Computing, NIST
- Publication 946: How To Depreciate Property, Internal Revenue Service