Renting compute capacity does not always pay off

Renting looks cheaper when the spreadsheet contains only a monthly bill, while buying looks cheaper when people, redundancy, and electricity are missing. An honest three-year calculation often gives an answer that neither camp enjoys: the decision depends on neither the server price nor the CPU percentage in a monitoring panel. It depends on the share of useful capacity the company actually pays for continuously. I evaluate projects like these through one threshold. Below it, rental preserves cash and room to change direction. Above it, an owned rack starts earning back its capital cost. You cannot borrow the threshold from someone else's case. You have to derive it from your quotes, workload profile, and redundancy rules.

The threshold uses billable utilization, not CPU

The variable you need is billable utilization: paid hours of equivalent capacity divided by the hours of all available capacity over the same period. If eight out of sixteen identical virtual machines run for the whole month, billable utilization is 50%, even when the guest systems report an average CPU load of 18%.

This distinction regularly ruins cost comparisons. A cloud resource can be shut down or released at night, while an owned server stays on and consumes power. The reverse also happens: a virtual machine may appear stopped but still incur charges. Microsoft's FinOps documentation distinguishes a stopped VM from a deallocated VM. In the first state, compute remains reserved and billable. In the second, it is released, although disks and related services still cost money. The invoice matters to the model, not the label in the console.

Collect an hourly series covering at least eight representative weeks. For every hour, determine how many standard units of capacity were required after acceptable consolidation. Do not average peaks over the month. An average load of 30% does not rescue a configuration that needs 100% every morning and cannot wait.

The billing export must reach the resource and hour level. Split its rows into compute, persistent storage, traffic, licensing, and support, then assign them to applications. A department-wide total hides powered-down development environments and forgotten test disks. If you cannot allocate part of the bill yet, mark it separately instead of presenting it as the variable cost of useful capacity.

Calculate two utilization measures. u_bill is the share of billable hours and belongs in the financial model. u_work is completed work relative to tested performance and helps expose technical headroom. A large gap between them is not an argument for rental or a rack. It signals poor capacity management. Remove obvious waste before making an investment decision.

Rental has two different modes. In the first, the company genuinely shuts down, releases, and scales resources, so expense moves with billable utilization. In the second, it keeps a constant fleet of virtual machines or purchases a one-year or three-year commitment. Most of the expense then becomes fixed, and the comparison with a rack is no longer linear in utilization. A commitment discount does not turn idle time into savings. Microsoft's rate optimization guidance explicitly warns about the risk of underusing reserved capacity.

Compare the same useful capacity

The comparison unit must describe completed work under equal memory, latency, and availability requirements. You cannot compare the vCPU total on an invoice with the number of physical cores in a specification. A provider may use a different oversubscription ratio, while your database may hit a memory or IOPS limit well before the processor.

I start with a reference bundle, such as "8 vCPU, 32 GB RAM, 500 GB of fast storage, a defined operations-per-second target, and recovery after one node fails." I then test it with the real workload in both environments. The result is not a count of advertised cores. It is the number of concurrent reference bundles that meet the same latency test.

The test must run long enough to expose cache warm-up, garbage collection, database checkpoints, and background backups. Record application versions, the dataset, request count, 95th and 99th percentile latency, memory use, and storage throughput. Average latency easily hides brief pauses that make users experience the system as slow.

Do not carry a ratio from one workload class into another. A node that consolidates web services efficiently may handle a database with a large working set or a model training job poorly. For GPUs, compare finished jobs, queue time, accelerator memory, and whether the device can be partitioned. An hourly rate says little if one option takes twice as long to finish the work.

You cannot count all installed capacity in a rack as useful. If four nodes have to survive one node failure, only the capacity of three belongs in the model. If the cluster needs 20% free for migration during maintenance, subtract that too. Networking, storage controllers, and licenses may impose a limit before CPU does.

Use the effective price of the reference bundle for rental:

q = compute + RAM + mandatory_license + local_storage

Keep object storage, backups, outbound traffic, public addresses, premium support, and taxes separate if q does not include them. Do not assign provider features a zero cost on the rack side. If the application needs a load balancer, firewall, remote console, recovery site, and protected backups, include the corresponding equipment or services.

Four formulas are enough for a three-year model

A complete model separates fixed, variable, and one-time costs. That reveals the threshold itself instead of producing one opaque total.

For rental where hourly resources are released:

Rent(u) = K * H * q * u + Rfixed + Rvariable(u)

Here, K is the number of reference bundles at full useful capacity, H is 26,280 hours over three non-leap years, q is the hourly bundle price, and u is billable utilization from 0 to 1. Rfixed includes disks, backups, and services billed even when compute is off.

For an owned rack:

Rack(u) = Capex + Colo + Staff + Service + Migration
          + H * PUE * Tariff * (Pidle + Pvariable * u)
          - Residual

Capex includes servers, networking, the rack or its allocated share, spare components, and initial licenses. Colo covers space, physical security, connectivity, and remote hands. If the equipment sits in a company facility, replace that single row with UPS capacity, cooling, fire suppression, a generator, floor space, inspections, and maintenance of that infrastructure. Do not call the facility free.

Normalize every row to the same tax and currency basis. If one proposal includes VAT and another excludes it, the threshold is already wrong before you use the formula. For foreign-currency payments, use a base exchange rate, a stress rate, and the price revision terms in the contract. Do not forecast the rate to the last decimal. Show the change at which the decision reverses.

Capacity growth rarely follows a smooth line. Rental can add one bundle, while a cluster may require a whole new node, switch, or license pack. Round capacity in the monthly model to the units you can actually buy and include the delivery date. Otherwise the spreadsheet grants the rack fractional servers that no vendor will sell.

Solve the threshold from Rent(u*) = Rack(u*):

u* = (Rack_fixed - Rent_fixed)
     / (Rent_variable_at_100% - Rack_variable_at_100%)

The formula works when the variable components are reasonably linear. With tiered rates, minimum rack orders, or cluster expansion, calculate month by month. The method is still simple: iterate from 0% to 100% utilization and find the first month or level where cumulative rack cost becomes lower.

A worked example puts the threshold near 29%

In this example, a company compares rental with a four-node cluster. One node is reserved, so useful capacity equals twelve reference virtual machines. Every amount below is a teaching assumption in tenge, not a market price list. The point is that you can repeat the calculation with your own proposals.

Model inputs:

• useful capacity K: 12 bundles;
• rental price q: 980 ₸ per bundle per hour;
• fixed rental services for 3 years: 12,000,000 ₸;
• servers, networking, spares, and licenses: 50,000,000 ₸;
• colocation and connectivity: 900,000 ₸ per month.

Administration consumes 0.25 of a position whose full annual cost is 18,000,000 ₸. Service and spare parts cost 6,000,000 ₸, commissioning, migration, and retirement add 2,000,000 ₸, and residual value is 5,000,000 ₸. Idle IT load is assumed to be 1.4 kW with another 2.2 kW at full utilization. PUE is 1.35 and the tariff is 45 ₸/kWh.

The rental compute portion at full utilization costs 12 × 26,280 × 980 = 309,052,800 ₸. With fixed services, the rental function is 12,000,000 + 309,052,800 × u.

The fixed rack portion before electricity is 50,000,000 + 32,400,000 + 13,500,000 + 6,000,000 + 2,000,000 - 5,000,000 = 98,900,000 ₸. Electricity adds 26,280 × 1.35 × 45 × (1.4 + 2.2u), or about 2,235,000 + 3,512,000u. This gives:

Rent(u) = 12 000 000 + 309 052 800u
Rack(u) = 101 135 000 + 3 512 000u
u* = 89 135 000 / 305 540 800 = 0.292

At 10% billable utilization, rental costs about 42.9 million ₸ and the rack 101.5 million ₸. At 25%, the figures are roughly 89.3 million ₸ and 102.0 million ₸. At 50%, rental rises to about 166.5 million ₸ while the rack reaches 102.9 million ₸. Above 29%, the rack is cheaper under these assumptions.

You can verify the values in a normal spreadsheet without a special calculator. Enter utilization in cell B1, then use the formulas below. At B1=0.292, the results should be close; the small difference comes from rounding the threshold.

B2 = 12000000 + 309052800 * B1
B3 = 101135000 + 3512000 * B1
B4 = B2 - B3

A negative B4 means rental is cheaper, while a positive value means the rack is cheaper. Add monthly columns if hardware payments are split into stages. A finance committee can audit this sheet more easily than a calculator with hidden logic.

The result does not mean every rack pays off at 29%. Double the colocation price, remove residual value, or add a second site and the threshold moves. Substitute a three-year provider commitment for the hourly rate and the rental curve becomes much flatter. The number has meaning only beside its input rows.

Electricity starts at idle

A server does not consume electricity in direct proportion to CPU starting from zero. Memory, fans, power supplies, drives, and network adapters create a base load. SPECpower_ssj2008 therefore measures a server at load levels from 100% down to Active Idle with zero throughput. I do not transfer a SPEC result to an unrelated configuration, but I do accept its methodological conclusion: a nameplate maximum alone cannot support a budget.

Measure each node at its input in three states: normal idle, typical production load, and a confirmed peak. Data from a managed power distribution unit over several weeks is best. A manufacturer calculator is suitable for an initial estimate, not an approved budget.

Check available power as well as consumed power. Two server power supplies do not always mean their ratings should be added, but an A/B feed may require either side to carry the whole load if the other fails. A colocation operator sells a kilowatt limit and a defined number of outlets. A dense configuration can occupy half a rack by height while exhausting its entire power allowance.

Account for degraded operating conditions. A clogged filter, missing blanking panels, high inlet temperature, and unbalanced phases can increase fan load or reduce usable capacity. These issues do not justify an arbitrary 30% buffer. They call for inlet temperature measurements, per-feed power data, and a layout review before purchase.

PUE needs careful handling too. The Green Grid defines it as total data center energy divided by ICT equipment energy. If the colocation operator bills measured kWh with cooling already included, multiplying by PUE again double counts the expense. If the company pays the entire facility bill, PUE or a direct measurement of auxiliary energy is necessary.

The tariff must match the contract. Energy, capacity, losses, taxes, and possible peak charges may appear on separate rows. Build three tariff and PUE scenarios instead of one forecast with two decimal places. Over three years, a wrong accounting boundary does more damage than a small power-meter error.

Depreciation does not replace cash flow

Depreciation answers an accounting allocation question, while TCO asks how much cash and labor a decision will consume. If one column contains the full payment for servers and then three years of depreciation, capital cost is counted twice. If it contains only depreciation, the table hides the vendor payment and the need for working capital.

I show two views for a management decision. Cash flow contains the actual dates of deposits, deliveries, taxes, rental, support renewals, and equipment sale. Economic cost allocates the depreciable amount over its useful life and makes periods comparable.

A third column covers staff time. An administrator's salary does not disappear because the person already works for the company. Estimate hours for design, acceptance, firmware, component replacement, on-call duty, audits, and retirement. Count only incremental work or work that can actually be released, but assign an owner to every operation. "The current team will do it" without hours hides a constraint rather than a saving.

IAS 16 requires an organization to estimate useful life and residual value according to the asset's expected utility to that organization, and to review the method and estimates at least at each financial year end. That is more useful than the mechanical claim that "a server lasts three years." Equipment may operate physically for longer but lose economic usefulness because memory needs rise, support ends, or the application changes.

Residual value belongs in a three-year comparison if the company will keep using or can sell the equipment after the horizon. Do not use the price of a new server in year three. Use a conservative repurchase proposal or zero, and show the sensitivity. Calculate present value separately when the cost of capital is material. Early Capex and even monthly payments cannot be compared honestly by a simple sum.

Choose the corporate discount rate with the finance team and apply it to monthly cash flows, not to the final total. Discount residual value as well. Do not use the financing rate to conceal project risk. Show workload uncertainty in separate scenarios so readers can see why the threshold moved.

Redundancy changes both sides

Equivalent availability often changes the result more than a processor discount. A rental design with one virtual machine is not equal to an N+1 rack cluster. One local cluster is not equal to a service that survives the loss of an entire site either.

Write down the failure the system must survive: a drive, node, switch, rack, link, or site. Then add the cost of that requirement to both sides. For the rack, this may mean a spare node, two switches, independent power feeds, off-site backups, and a parts stock. For rental, it may mean multiple zones, a load balancer, data replication, and inter-zone traffic.

Put recovery time and acceptable data loss beside the failure. A spare server without a tested startup procedure does not meet a recovery target, and a second copy in the same array does not protect against operator error or site damage. Drills, backup monitoring, and periodic restoration cost money in both options.

Do not dissolve downtime cost into an invented "risk" percentage. Choose a concrete business process, define its acceptable window, count affected staff or transactions, and record the direct effect of delay. Then compare the designs by the failures they actually address. If you cannot estimate loss, at least show unavailable hours separately from TCO.

There is also a time buffer. Companies buy owned hardware with room to last until the next purchasing cycle and cover delivery lead time. Rental can expand faster, but only when the required quota and configuration are available. Do not grant either option perfect elasticity.

Check license metrics before selecting hardware. Licensing by physical core, socket, or virtual core can reverse the result, especially with a standby node. Put the initial purchase, subscription, support, and transfer rights into the sheet. "We already own the licenses" is acceptable only after someone checks the agreement.

Sensitivity is more useful than a precise total

Management needs a threshold range and the reasons it moves. One number creates false confidence, particularly when rental is tied to a foreign currency, the tariff changes, and growth comes in steps.

Calculate at least three scenarios:

• low utilization: slow growth, hourly resource release, and high residual value;
• base: the most likely profile and signed commercial terms;
• high utilization: fast growth, lower residual value, and more expensive energy and service.

Then change one parameter by 10% and recalculate u*. If rental rate and Capex move the threshold most, obtain firm proposals for those rows first. If administrator time drives it, arguing over the price of a kilowatt-hour distracts from the main uncertainty.

I also calculate cumulative break-even by month. A rack may be cheaper over the full three-year horizon but lose for the first twenty months. That is a material risk for a project with uncertain funding. Add exit cost: a commitment penalty, data transfer, dismantling, secure media erasure, and team time.

Run two more boundary tests. In the first, halve the workload after twelve months as if the product were cancelled. In the second, double it and add the next minimum node. The first exposes the cost of irreversible Capex. The second exposes the expansion step and the date when the current rack stops being sufficient.

The most useful model check is blunt: can every large row be defended with an invoice, contract, measurement, or calculation another person can reproduce? If not, widen the range. Decimal precision does not repair an unsupported input price.

Rental buys reversibility

Rental remains more sensible below the threshold, with sharp seasonal peaks, a short project life, and high configuration uncertainty. It also helps when the team does not yet know the I/O profile or needs to test a new workload quickly. The premium over bare hardware buys an option to shrink the resource and stop spending without selling equipment.

That reversibility must exist in the engineering, however. If the application depends on proprietary managed services, data is expensive to extract, and a discount requires a three-year commitment, rental has become less flexible. The model needs an exit case with data volume, available bandwidth, traffic charges, and specialist hours.

Test the exit before signing: export a backup, restore it elsewhere, and measure the time. This does not mean you should reject managed services. Their operational benefit can exceed the transfer cost, but the decision now has a measurable switching cost.

Do not buy a rack merely because one peak month's bill looks alarming. Separate the temporary peak from the persistent base first. The base can run on owned capacity while rare peaks remain rented. A hybrid design needs compatible networking, identity, backup, and observability, so it has its own fixed cost.

Rental also wins when delay from a purchasing procedure costs more than the infrastructure. If new capacity is required next week, a hardware saving three months later does not help. Record delay cost separately instead of burying it in TCO.

An owned rack wins with a predictable base

A rack becomes a strong option when the workload stays above the calculated threshold, the configuration is stable, and the team can operate the cluster without heroics. It works particularly well for persistent databases, virtualization, internal analytics, and other workloads where memory and local traffic are paid for around the clock.

Before purchase, require four pieces of evidence: a load test of the reference bundle, an hourly billable capacity profile, two comparable rental proposals, and a complete N+1 rack calculation. That is enough to remove the most expensive fantasies from both columns.

Define the responsibility boundary in a contract appendix. Who replaces a drive, updates firmware, holds spares, responds to an alert at night, and restores service after an error? "Support included" means little without response times, access arrangements, a task list, and an escalation process. The same duties cannot appear in both a contractor's price and your team's hours.

Delivery lead time has a cost too. If equipment arrives in four months, interim rental belongs in the rack project, as does parallel operation during migration. After the move, the old resource must actually be released. Otherwise the finance model promises a saving while accounting receives both bills for another six months.

For projects in Kazakhstan, GSE.kz can select server and data center infrastructure and support it through local manufacturing, systems integration, and round-the-clock technical support. The proposal still has to pass through the same model: a vendor's name does not remove downtime cost, redundancy, or responsibility boundaries.

Review the decision quarterly using actual billable utilization. If the base remains above the threshold for three months and the forecast supports another two years of work, talks about owned capacity are already late. If utilization jumps around and the project can be shut down easily, a rack will be an expensive way to keep empty metal.