What does a server really cost? A transparent TCO calculation

Start by comparing equivalent services

A server costing €3,600 cannot be compared directly with a monthly cloud charge. One quote includes hardware; the other may include computing time and data-centre operation. Either may exclude backups, support and licences. Start with a service specification: applications, usable capacity, working hours, allowable data loss and the longest tolerable interruption.

Core count is not a common unit of performance either. Shared virtual CPU capacity, dedicated cores and an older processor you own may behave differently with the same application. A comparison should successfully handle a defined workload and meet the same recovery targets. Otherwise, the cheaper quote may simply be smaller or accept less responsibility.

The AWS Well-Architected Framework treats cost optimisation as an ongoing task, connecting usage, organisational responsibility and resource selection. This approach also applies to owned servers: a budget needs an owner and regular review, not just approval at purchase. AWS: Cost Optimization Pillar ↗

An open calculation model over five years

Our example is a small server in an existing equipment room. We assume a one-off €3,600 for hardware and €600 for setup and a documented handover. The period is five years, each with 8,760 operating hours. The device is assumed to draw an annual average of 180 watts at the socket; the assumed energy price is €0.30 per kilowatt-hour.

The formula here is: €4,200 one-off + 5 × €3,053.04 recurring = €19,465.20 over five years. Spread over 60 months, this is €324.42 per month. This monthly figure is a comparison value; it is neither the actual monthly payment nor financing. Due to the purchase, the first year costs €7,253.04; subsequent years each incur the assumed operating costs.

Hardware alone accounts for around 18.5 per cent of the total in this model. The assumed support already costs €9,600 over five years. This is not a general market proportion but the consequence of our openly stated inputs. The calculation shows why a cheaper device helps little if unclear configurations create extra work every month.

Measure electricity rather than reading the power-supply label

A 750-watt power supply can deliver that output; the figure does not describe a server's average electricity consumption. A CPU's thermal design rating is not a measurement of the whole system either. Energy drawn at the socket and actual operating hours matter for the calculation. A week's reading that includes typical backups says more than a short idle measurement immediately after startup.

In our model, 180 watts over a year means 1,576.8 kWh. If a test server genuinely runs only twelve hours on five days a week, use its actual runtime instead of a blanket 8,760 hours. First check whether shutting it down is compatible with backups, updates and required access times. A computer that supposedly can be switched off in the evening but imports data overnight has a different load profile.

UPS losses, cooling and an allocated share of network equipment may be additional items. The example calculation excludes them, and that must remain visible in the comparison. If a measured overall site allowance is used, do not count the same losses again as separate items. For a server in an office, room temperature, noise and heat output are also practical limits that the energy bill alone does not capture.

Which assumption changes the result most?

This sensitivity analysis is often more useful than an initial table precise to the cent. Ask first which inputs are uncertain. If nobody knows whether support takes two or six hours each month, discussing ten euros of electricity achieves little. Record actual working time by activity: routine work, incidents, user support and further development.

The operating period deserves a separate comparison. At only three years, the unchanged model gives 4,200 + 3 × 3,053.04 = €13,359.12. Over 36 months, this is around €371.09 per month. Longer use spreads the purchase cost but may later require repairs, extended support and migration. Do not extend the calculation without checking the operational consequences.

Items often listed separately in quotes

• Backup: protected data volume, retention period, a separate copy and the effort of recovery tests.
• Software: operating system, database, backup software, required access rights and the specific licence metric offered.
• Site: equipment room, UPS, cooling, network, internet connection and any on-site visits.
• Cloud and hosting: storage, requests, data transfer, additional IP addresses, support packages and unused resources.
• Lifecycle: introduction, documentation, training, contract renewal, data export and an orderly replacement.
• Availability: a second system or spare parts, monitoring and staff availability during the agreed period.

A provider may operate the hardware and data centre while your team remains responsible for the guest operating system, applications and configuration. AWS explicitly describes this division for EC2. A rented computer therefore does not automatically mean managed application operations; the agreed scope determines that. AWS: Shared Responsibility Model ↗

Show outage consequences alongside the budget

An outage belongs in the decision, but without reliable probabilities it is difficult to include as a supposedly exact annual figure. First describe a scenario: four hours without the business management system affects five employees. At a self-selected internal rate of €40 per hour, this ties up €800 of working time. Lost orders, rework and contractual consequences are not yet included.

This scenario does not automatically imply a recommendation for an expensive high-availability system. Perhaps the team can work for two hours using a prepared fallback process. Perhaps even one hour is critical. The appropriate investment follows from the business processes actually affected and a tested recovery, not a blanket downtime-cost formula.

Finish with a decision sheet that can be checked

Compare at least a baseline scenario and a less favourable variant with more data, a higher energy price or extra support time. Mark whether each item comes from a quote, a measurement or an assumption. Separate investment from recurring payments so the result also fits available liquidity.

The result is a clear scope, the five largest cost drivers and the conditions under which you would reconsider. For example, growth beyond the available RAM capacity may trigger a second expansion. A change in the support model may alter the calculation more than a new server quote. These triggers turn a one-off price list into useful operational planning.