--- title: "Colocation or cloud: building a cost comparison that survives scrutiny" description: "How to model owned hardware in colocation against public cloud over three to five years: the unit of comparison, the missing line items, the breakeven." url: "https://nixit.io/resources/colocation-or-cloud/" lang: "en" --- # Colocation or cloud: building a cost comparison that survives scrutiny Most colocation versus cloud comparisons end as two totals on one slide. One comes from a provider's pricing calculator, the other from a hardware quote, and whichever is smaller becomes the recommendation. The exercise looks quantitative and is mostly an assumption wearing a spreadsheet. A comparison worth acting on is not a verdict about cloud. It is a model of one defined workload, over a stated horizon. What follows is the method rather than the answer, because the answer changes with the workload. ## Fix the unit of comparison before anything else The most common structural error is comparing a server to an instance. Compare the total annual cost of running a bounded workload, at an explicitly equal service level, in both places. Equal service level is the part that gets skipped. If one option includes redundancy across two facilities, automated failover and a tested restore path and the other does not, the cheaper one is cheaper for a reason. Write the service level down first: availability target, recovery point, recovery time, retention, and who is on call at three in the morning. Then price both sides to meet it. ## The hourly rate is the least informative number on the page An instance rate and a server purchase price would be comparable if they were the only costs involved, which they never are. For data-heavy workloads, compute is frequently the smaller part of a cloud invoice. For owned infrastructure, the server is frequently the smaller part of a five-year total. There is also a units problem. An hourly rate becomes an annual cost only through a utilisation assumption, and that assumption, not the price, drives the result. An instance running eight hours a day has no hardware equivalent, and this is where most wrong conclusions originate in both directions. ## What the cloud side of the model usually omits **Egress.** Data leaving the provider's network is billed per gigabyte and, at volume, can exceed the compute line entirely. Estimate it from measured traffic rather than from an impression of how much the application sends. **Inter-availability-zone traffic.** Spreading services across zones for redundancy generates cross-zone traffic that is typically charged in both directions. A synchronously replicated database produces this continuously, not occasionally. **Snapshots and orphaned volumes.** Snapshot chains with no lifecycle policy, volumes left by deleted machines, reserved addresses nobody released. Nobody plans for these, and every environment older than a year has them. **Hourly resources that are not servers.** Load balancers, NAT gateways, private endpoints, public addresses. Individually trivial, collectively significant once there are four environments. **The managed service premium.** A managed database costs more than the same database on an instance. The difference buys patching, backups and failover, and it is frequently money well spent. It still belongs in the model as a line rather than an assumption. **Support plans.** Usually a percentage of spend, scaling with the bill, and not optional for production. **Provisioned IOPS and throughput.** Fast storage is billed separately for capacity and for performance. A database that needs provisioned performance can cost several times what the per-gigabyte price suggests. **Licensing that travels with the workload.** Commercial database and Windows licensing carries its own mobility rules, and treatment differs between providers. ## What the colocation side of the model usually omits **Rack space and power.** Space is billed monthly, and power is either metered separately or included up to a kilowatt threshold. The threshold matters more than the rack price, because the second cabinet is usually bought for power rather than for space. **Cross connects and transit.** Cross connects, IP transit, and a second carrier for real redundancy. One carrier in one facility is not redundancy, and the second link is a cost line, not a footnote. **Refresh amortisation.** Not purchase price divided by an accounting depreciation life, but purchase price divided by how long you actually intend to run the equipment, plus extended warranty for the years beyond the standard term. **Spares.** A shelf disk, a power supply, sometimes an entire node for a small cluster. Capital that produces nothing until the day it produces everything. **Remote hands.** Physical intervention is billed per incident or per hour, and site visits by your own staff cost time. **Hypervisor and backup licensing.** Hypervisor, backup software, monitoring, operating systems. A five-year model built on today's prices quietly assumes those prices hold, and recent years suggest otherwise. **Engineering time.** The line omitted most often. Someone plans, racks, patches, answers alerts, tests restores and drives to the facility. It is either salary or a contract. Without it, the model compares a service to a piece of equipment. ## Utilisation moves the answer more than pricing does Owned hardware is paid for whether or not it is used. Cloud is paid per unit consumed, at a rate that includes a premium, and that premium buys the right not to pay when you are not consuming. If you consume nearly all of it, nearly all of the time, you are paying a premium for an option you never exercise. So the useful output of the model is not a total. It is a breakeven: the utilisation level at which the two options cross. A breakeven can be checked against next quarter's metrics. A total cannot. ## A hypothetical illustration of the method The figures below are invented, rounded and expressed in arbitrary cost units. They are not market prices, they do not come from a client, and their only purpose is to show how the model behaves. Take an application platform with a fixed fleet, running at high utilisation, over five years. Owned in colocation: 100 units hardware, 50 facility and power, 30 licensing, 20 spares and remote hands, 100 engineering. Total 300. In cloud, with three-year commitments: 160 compute, 70 storage, 40 egress and cross-zone, 20 support, 50 remaining engineering. Total 340. The model now favours colocation by roughly twelve percent, which is inside the error bars of every input. Change one assumption. If the fleet only needs to run at roughly a third of that capacity for most of the year, the cloud compute and storage lines fall with it while the colocation lines barely move, because the hardware, the rack and the engineer are already paid for. The ranking flips. That flip is the finding, not the totals. The model has told you the decision depends on a utilisation number, which is measurable, rather than on a platform preference, which is not. ## Commitments trade away the thing you are paying for Reserved instances and savings plans reduce cloud cost substantially in exchange for a one or three year commitment. They are the right tool for steady-state workloads, with one caveat: a commitment consumes exactly the flexibility that the cloud premium was buying. If the business case for cloud rests on agility and the cost model prices it with three-year commitments, the model is evaluating something you are not purchasing. Run both: committed cloud against owned hardware, where two equally rigid decisions are compared fairly, and on-demand cloud against owned hardware, where you can see what optionality actually costs. The commitment risk is real and it sits with you. Architectures change, instance families are superseded, applications get replaced. The commitment does not care. ## Price optionality instead of asserting it Flexibility should be neither the trump card nor the thing dismissed as marketing. It should be a number. A workable method: define three demand scenarios for year three, below plan, on plan and above plan, then cost both options in each. With owned hardware, being under means an emergency purchase with a procurement lead time attached, and being over means stranded capital for the remaining term. In cloud, both errors resolve into a different invoice next month. The gap between the probability-weighted cost and the central-case cost is the price of the option. Sometimes that is small enough to ignore, and sometimes it exceeds every list-price saving in the comparison. ## Horizon, residual value and the cost of capital Three to five years, aligned to the refresh cycle, is the defensible horizon. A one-year window mechanically favours cloud because it loads the entire capital outlay into the period. A ten-year window mechanically favours hardware because it assumes the workload still exists in that form. Treat residual value conservatively. Equipment retains some value at the end of the term, but what is realisable is small and uncertain, so many organisations model it at zero and treat any recovery as upside. Apply a cost of capital explicitly: money spent up front is not equivalent to the same amount spread across five years, so discount the cash flows at a rate finance agrees to, and include interest if the purchase is financed. ## Residency, regions and procurement Three factors routinely override the arithmetic for international organisations, and each is cheaper to confront early than to discover during a review. Data residency and jurisdiction can rule out an option before cost is discussed, or force a specific region whose pricing differs from the one in the calculator. Genuine multi-region distribution is where owned hardware becomes expensive quickly, because a second facility means a second set of everything while a provider region is a configuration change. Procurement decides timing: an approved framework, an enterprise agreement with committed spend already on it, or hardware lead times in the market you buy in. ## Migration, and the cost of leaving again A comparison that excludes migration compares a current state to an ideal one. Include engineering effort, the period of running both environments in parallel, data transfer, rewritten operational procedures and training. Include the exit cost too: moving a large dataset out of a provider is billed egress, and the reverse case carries decommissioning. ## Where each answer is almost always right Cloud is close to always correct for unpredictable growth, short-lived development and test environments, global distribution, seasonal peaks, and managed data services you would otherwise hire someone to operate. Cloud is usually the wrong answer for large stable storage footprints, sustained heavy egress, and steady compute at high utilisation, which together describe most mature internal platforms. Most organisations land between the two: the stable base on owned hardware, the peaks, temporary environments and disaster recovery capacity in cloud. That split is sound when it is chosen and expensive when it is inherited, because two environments mean two sets of procedures and people who know both. ## What to do with this An honest model rarely produces a large gap, and when it does, one line is usually responsible: storage volume, egress, or utilisation. Find that line before the conversation turns into a debate about platforms. We build these comparisons against measured usage as part of [IT consulting](/services/it-consulting/), and implement whichever direction the numbers point through [cloud management](/services/cloud-management/) or [server management](/services/server-management/).