The question this answers
When is renting infrastructure the right answer, and when is owning it — and what actually differs between the two?
A company must decide where a workload runs for the next five years. The workload is known: a steady, predictable, storage-heavy service with a compliance obligation and a five-person operations team.
A comparison on dimensions that can be checked against your own workload, rather than a conclusion. The output is a defensible placement decision, which may well be "both", and may well be "neither has an advantage that matters here".
Seven dimensions, none of which is universally won by cloud
Cloud material almost always argues one direction, so it is worth stating plainly: cloud is not automatically better. It is a different set of trades, and there are ordinary, unglamorous workloads for which owned hardware is cheaper, faster and no harder to run. A steady, predictable, storage-heavy workload with no burst and a long horizon is close to the worst case for usage-based pricing, and close to the best case for capital equipment that depreciates over five years.
What cloud genuinely wins is *time* and *variance*. A capacity decision that takes twelve weeks on-premises — quote, purchase order, delivery, rack, cable, provision — takes ninety seconds. A workload whose peak is twenty times its mean pays for peak all year on owned hardware and pays for what it uses in the cloud. Those two properties are worth an enormous amount to a business that does not know its own load, which describes most businesses building something new.
What on-premises genuinely wins is *unit economics at steady state*, *control*, and *predictability of the bill*. Nobody changes your pricing model with ninety days' notice. Nobody deprecates the API you built against. And for storage-heavy or egress-heavy workloads the difference is not marginal: a service pushing large volumes of data to the internet can find that transfer alone costs more per month than the entire hardware amortization would.
| Dimension | On-premises | Cloud | Which workload cares |
|---|---|---|---|
| Capital structure | CapEx: buy up front, depreciate over ~3–5 years, cost is sunk and predictable | OpEx: pay monthly, no commitment required, cost tracks usage | A startup with no capital and unknown load wants OpEx; a mature service with a five-year horizon may prefer CapEx |
| Provisioning speed | Weeks to months: quote, order, deliver, rack, cable, image | Seconds to minutes, via an API | Anything with unpredictable growth, and every experiment |
| Control | Total: hardware choice, kernel, hypervisor, network topology, physical access | Bounded by what the provider exposes; you cannot fix what you cannot see | Specialised hardware, custom kernels, deterministic latency, forensic requirements |
| Operational burden | You own power, cooling, hardware failure, firmware, capacity planning, physical security | The provider owns the facility and the hardware; you still own everything above it — see Shared Responsibility | Small teams: the burden is measured in people, and people are the scarce resource |
| Elasticity | Fixed: peak capacity is purchased and idle the rest of the time | Elastic within minutes, and genuinely down as well as up | Bursty and seasonal workloads. A steady workload gains nothing from elasticity |
| Geographic reach | One or two sites, expanding is a construction project | Dozens of regions, a new one is a configuration change | Global user bases and data-residency obligations |
| Vendor dependence | Hardware vendors are interchangeable; the software stack is yours | Managed services and provider APIs are sticky; data egress is the exit toll | Anything with a long horizon and a regulator who asks about exit plans — see Multi-Cloud, Taught Cautiously |
The comparison teams get wrong: instance price against server price
The most common analysis error is comparing a monthly instance price against the purchase price of a comparable server, concluding cloud is expensive, and stopping. That comparison omits most of what owning hardware costs, and it omits the largest cloud line items too.
On the owned side, the honest total includes: hardware, spares held against failure, rack space, power and cooling, network transit and cross-connects, the hypervisor and management stack, the staff time to rack, patch, replace and monitor, and the capacity you bought for peak and never used. On the rented side, the honest total includes instance-hours, storage, backups, load balancers, NAT, and — the line that surprises people — egress, which is charged per gigabyte and scales with users rather than with servers.
The result of doing this properly is usually not a landslide either way. It is a crossover: below some steady, predictable utilization, renting wins on total cost of ownership; above it, owning wins, provided you actually have the operations staff. And that proviso is not a footnote. A worksheet that omits the cost of the people is the same error in a different column.
OWNED (per year, amortized) RENTED (per year) ---------------------------------- ---------------------------------- hardware / depreciation instance-hours spare capacity for failures block storage GB-months peak headroom, idle most of year snapshot / backup retention GB rack space + power + cooling load balancer hours + GB processed network transit + cross-connect NAT hours + GB processed hypervisor / management licences managed database premium firmware + hardware lifecycle work EGRESS GB <-- scales with users staff: racking, replacement, on-call support plan capacity planning cycle time staff: still needed, fewer of them MISSING FROM BOTH COLUMNS IF YOU ARE NOT CAREFUL: - the cost of a 12-week provisioning delay on the owned side - the cost of an unplanned 3x traffic month on the rented side - the cost of the exit, in either direction (data has gravity and a per-GB toll) COST-VARIES: no rates here. Every figure is yours, and the crossover point moves by an order of magnitude between a bursty API and a steady archive.
Hybrid is the common real answer, and it has its own cost
In practice most organizations past a certain size run both, and not as a transitional state. A steady, licence-heavy database on owned hardware next to elastic web tiers in a provider region is an entirely coherent design. So is keeping regulated data in a controlled facility while everything stateless runs rented.
The cost of hybrid is that you now operate two control planes, two identity systems, two network models and two sets of failure modes, and you have added a link between them that is the single most fragile thing in the topology. The dedicated interconnect between a facility and a provider region is a genuine single point of failure with a lead time measured in weeks, and teams routinely discover during an incident that their "hybrid" design assumed that link never goes down.
This is why the placement decision should be made per workload with a stated reason, and why the number of distinct placements should be small. Two is a strategy. Five is an accident — see Hybrid Cloud and Scoring Operational Complexity.
Bars are relative weights, not currency. Real rates depend on provider, region, commitment and volume.
Key points
- Cloud wins decisively on provisioning speed, elasticity and geographic reach; on-premises wins on steady-state unit economics, control and bill predictability.
- Steady, storage-heavy or egress-heavy workloads with a long horizon are the strongest remaining case for owned hardware.
- Comparing an instance price to a server price is the standard error: it omits power, spares, staff and idle peak headroom on one side, and egress, backups and managed premiums on the other.
- Operational burden is measured in people. A five-person team that cannot staff a hardware lifecycle should not own hardware, whatever the spreadsheet says.
- Hybrid is a legitimate steady state, and its real cost is two control planes plus one fragile, long-lead-time link between them.
The loop, answered
Every field is required, which is why no lesson here can recommend something without saying what it costs and what simpler thing to consider first.
- • On-premises: you buy or lease hardware, place it in a facility you control or rent space in, and run everything from the hypervisor upward.
- • Cloud: the provider owns the facility, hardware, power and network fabric, and exposes capacity through an API with a metered price.
- • The boundary between the two models is not fixed — colocation, dedicated hosts and bare-metal-as-a-service sit between them and inherit properties from both.
- • A hybrid design joins them with a dedicated interconnect or a VPN, and every subsequent design decision has to answer which side a component lives on and how often it crosses.
- • On-premises: hardware failure, firmware, capacity forecasting, physical access control, power and cooling, and a purchasing cycle measured in months.
- • Cloud: everything above the hypervisor, plus the parts people assume are free — backups you must configure, patching you must schedule, and the capacity choice nobody makes for you.
- • Both: the application, the data model, the access control, the deployment pipeline and the bill. Placement changes almost nothing about these.
- • Hybrid: the interconnect, its redundancy, and the identity mapping between two directories that were never designed to agree.
- • On-premises: a disk fails and the spare is three weeks out because procurement was optimised; capacity runs out mid-quarter with no way to add any.
- • Cloud: a provider service degrades in one region and your design assumed the region was an atom; you discover the dependency during the incident, not before.
- • Cloud: a pricing or deprecation change lands with notice you cannot act on inside your release cycle.
- • Hybrid: the interconnect drops and the "cloud side" cannot reach the identity provider on the "owned side", so everything fails authentication simultaneously.
- • On-premises scales in steps the size of a purchase order; the practical consequence is that you are either over-provisioned or you are blocked.
- • Cloud scales continuously within quota limits — and quotas are the real ceiling that teams meet first, usually during exactly the traffic event that made them scale.
- • Neither model scales the parts that matter most: a database that cannot shard does not shard because you moved it, and staff capacity is unchanged by placement.
- • On-premises gives you physical control and the full burden that comes with it: your facility, your access logs, your key management, your patching.
- • Cloud shifts physical security and hardware lifecycle to the provider and leaves you the entire configuration surface — which is where essentially all publicly reported cloud incidents originate. See Shared Responsibility.
- • Compliance rarely mandates one model. It mandates evidence: where data sits, who touched it, and how that is proven. Both models can produce that evidence, with different effort.
- • Hybrid doubles the identity surface and creates a link whose failure mode is a simultaneous authentication outage on both sides.
- • CapEx against OpEx is a financial structure difference before it is an amount difference: sunk and predictable versus variable and immediate.
- • The cloud line items that dominate long-run cost are rarely compute: storage growth, backup retention and egress are the ones that compound.
- • The on-premises line items that get omitted are power, cooling, spares, idle peak headroom and staff time — and staff time is usually the largest of them.
- • Commitment discounts move the crossover substantially: a workload you can commit to for years is priced very differently from one you cannot.
- • Utilization against purchased capacity on the owned side — sustained low utilization is the signal that the CapEx case has weakened.
- • Cost per unit of business work on the rented side (per request, per tenant, per GB stored) — an absolute bill tells you nothing about whether it is reasonable.
- • Provisioning lead time as an engineering metric: weeks of waiting is a real cost that never appears in a cost comparison.
- • The signal that lies: a falling monthly cloud bill during a traffic decline. Usage-shaped spend flatters you in a downturn and does not mean the design got more efficient.
- • Colocation or rented dedicated servers: you get owned-hardware economics and control without operating a facility, and provisioning drops from months to days. For steady workloads this is frequently the best of both and is routinely overlooked.
- • Staying entirely on one provider and buying commitment discounts, if the workload is steady — most of the CapEx advantage is available as a multi-year commitment without owning anything.
- • Managed hosting or a PaaS for teams whose real constraint is people rather than money; the highest-leverage move for a five-person team is usually to reduce the number of things they operate, in either model.
- • Deferring the decision. A workload that has run for six months tells you its shape; deciding placement before that is deciding with the least information you will ever have.
- • Cloud buys speed and elasticity and charges variance in the bill plus dependence on a provider's roadmap and pricing.
- • On-premises buys control and steady-state economics and charges lead time, capital, and a staffing obligation that does not shrink when the workload does.
- • Hybrid buys the right placement per workload and charges two of everything plus a link that is the most fragile component in the design.
What people believe, and what is true
Cloud is cheaper.
Cloud is cheaper for variable, unpredictable and small workloads, and frequently more expensive for large steady ones — especially storage-heavy and egress-heavy ones. It is reliably cheaper in *time*, which is often the decisive resource.
Moving to cloud reduces operational work.
It removes the hardware layer and leaves everything above it, which is most of the work. Teams that expected fewer operations people generally need the same number doing different things — see Shared Responsibility.
On-premises means you cannot scale.
It means you scale in purchase-order-sized steps with a lead time. For a workload whose growth is forecastable a quarter ahead, that is entirely workable.