Compute · total cost of ownership
Bare metal vs cloud TCO: the sticker is not the bill.
Cloud's per-hour sticker is a fraction of its true cost — egress, over-provisioning, managed-service premiums, support tiers, and the always-on penalty stack on top. Bare metal is a flat cost with far fewer hidden layers, but real trade-offs in elasticity and commitment. For steady, high-utilization workloads, bare metal's total cost of ownership usually wins; for variable or early-stage ones, cloud's does. We do the honest maths, and say which is you.
In short
- The sticker misleads. Cloud's instance rate is the first line of the bill, not the total — egress and add-on meters do the rest.
- Bare metal is flat. A predictable monthly cost with few hidden layers, close to its true total cost of ownership.
- Utilization decides. Steady, high-use workloads favour bare metal's TCO; variable or idle ones favour cloud's.
- Egress is the classic hidden cost. Moving data out of the cloud is billed per gigabyte and surprises data-heavy workloads.
- Cloud's TCO still wins sometimes. For early-stage, spiky, or genuinely elastic work, its flexibility is worth the premium — and we'll say so.
What total cost of ownership really counts
The reason cloud and bare metal are so often compared badly is that people compare the wrong numbers. A cloud instance's per-hour rate sits on the pricing page and looks concrete, so it becomes the figure everyone quotes — but it is only the first line of a bill with many more. Total cost of ownership means the whole cost of running your workload over time: not just the compute, but the data movement, the headroom, the managed services around it, the support, and the human time to operate it. Compare stickers and cloud can look cheap; compare total cost of ownership and the picture often changes.
For bare metal, the sticker and the total are close together. A flat monthly server cost, with bandwidth frequently included or flat, is most of what you pay — there are fewer meters ticking in the background, so the number you are quoted is close to the number you owe. For cloud, the sticker and the total can diverge sharply, because the model is built from many separately-billed components that add up as you actually use it. Neither is dishonest; they are different billing shapes, and understanding the shape is the whole of a fair comparison.
So this page is not an argument that cloud is expensive and bare metal is cheap — that would be as lazy as the sticker comparison it replaces. It is a method for counting the real total on both sides, and a guide to the one variable that decides which total is lower for you: how you use the capacity. A workload that runs steadily and moves data will usually find bare metal's total lower; one that is spiky, small, or elastic will usually find cloud's lower. The maths, done honestly, tends to place you clearly.
Cloud's real TCO, layer by layer
The gap between a cloud instance's sticker and its true cost is made of a handful of predictable layers. Egress bills you per gigabyte to move data out of the provider's network. Over-provisioning has you paying, around the clock, for the headroom that scaling friction makes you keep. Managed-service meters — load balancers, storage IOPS, snapshots, inter-zone transfer — each add their own line. And a support plan is often a percentage of the total. Stack them and the instance rate becomes a fraction of the bill.
# Cloud: the instance sticker is only the first line of the bill
instance/hour the number in the pricing page
+ data egress $ per GB out # moving data costs
+ over-provisioning headroom you pay for 24/7
+ managed premiums load balancers, storage IOPS, snapshots
+ support plan a % of spend
= true cloud TCO # commonly a large multiple of the sticker
# Bare metal: fewer layers, flat and predictable
flat monthly + bandwidth (often included) = TCO close to the stickerThis is why a cloud migration that was costed on instance rates so often overruns: the rates were real, but the bill was never only the rates. It is also why the savings from moving a steady workload off cloud can be large — you are shedding the compute premium and, with it, the whole stack of meters that rode on top of it. When you compare against bare metal, compare this full total, not the first line. A fair comparison puts the complete cloud number beside the flat bare-metal one, and for a steady workload that comparison rarely stays close.
Bare metal's honest costs
To keep the comparison fair, bare metal is not free of trade-offs — it simply has different ones, and they are easier to see. The first is fixed capacity: you provision a machine sized to your need and pay for it whether it is busy or idle, so a workload that sits idle much of the time wastes that flat cost. The second is elasticity, or the lack of it — you cannot conjure ten more servers for an hour and release them, so a genuinely spiky load is a poor fit. The third is commitment: bare metal is a monthly relationship rather than a per-second one, which suits stable needs and chafes against rapidly changing ones.
What bare metal does not carry is the stack of hidden meters. Its bandwidth is frequently flat or included, there is no per-gigabyte egress charge to move your own data, and there are no separate bills for the load balancer, the snapshot, or the inter-zone transfer — so the total cost of ownership stays close to the quoted price. And because our bare metal is operated for you, the old objection that owning hardware means running a data centre does not apply: the physical operation is handled, so the honest costs are the economic ones above, not an operational burden. Weighed plainly, bare metal trades elasticity and commitment for a total that is low and predictable.
Side by side
Bare metal and cloud TCO, dimension by dimension
Read the egress, over-provisioning, and utilization rows together — they are where the true totals diverge.
| Bare metal (with us) | Cloud | |
|---|---|---|
| Headline cost | Flat monthly, close to the true cost | Per-hour sticker — a fraction of the real bill |
| Data egress | Bandwidth often flat or included | Billed per GB out — a major hidden line |
| Utilization | You pay for capacity whether busy or idle | Pay only while running — good when idle |
| Over-provisioning | Sized once to your real need | Headroom you often pay for around the clock |
| Managed premiums | Fewer add-on meters | Balancers, IOPS, snapshots, transfer all billed |
| Support cost | Included operation (with us) | Often a percentage of total spend |
| Elasticity | Fixed capacity you provision | Scale up and down on demand |
| Commitment | Monthly term; you own the capacity | None — but you pay the on-demand premium for it |
| Best TCO for | Steady, predictable, high-utilization workloads | Variable, early-stage, or spiky workloads |
Cloud pricing components vary by provider and region; build the comparison on your own workload's real numbers.
When does cloud's TCO genuinely win?
When your workload is variable, early-stage, or truly needs elasticity — and we say so plainly, because we host bare metal and an honest TCO page cannot only argue one way. If your demand is spiky and unpredictable, cloud's pay-as-you-go model means you pay for peaks only when they happen and nothing for idle capacity between, which a flat cost cannot match. If you are a young product whose needs may change month to month, cloud's lack of commitment is worth real money in avoided mistakes. And the speed of standing infrastructure up in minutes has genuine value when you are moving fast and uncertain.
The deciding question is always utilization and predictability, not ideology. A steady, well-understood workload that runs most of the time and moves data will almost always find bare metal's total lower once the full cloud bill is counted. A variable, small, or fast-changing one will find cloud's lower, because it uses the elasticity it pays for. Most mature estates end up mixed — a stable baseline on bare metal for its total cost, and variable workloads in the cloud for its flexibility — and the right design puts each where its total is lowest rather than committing everything to one model.
Do reserved and spot pricing close the gap?
It is the fair counter-question, because cloud providers offer real discounts for commitment, and any honest TCO has to account for them. Reserved instances and savings plans cut the per-hour rate substantially in exchange for a one- or three-year commitment — which narrows the compute gap, but does so by giving up the very elasticity that was cloud's advantage in the first place. Once you have committed to a fixed amount of capacity for years, you are much closer to bare metal's economic shape already, and it is worth asking why you would accept commitment on cloud terms rather than owned ones.
The discounts also do not touch the other layers. A reserved instance still pays egress per gigabyte, still meters its managed services, and still carries a support plan — so the reservation lowers one line of the bill while the rest continue as before. Spot and pre-emptible instances go further on price, but they can be reclaimed with little notice, which makes them excellent for interruptible batch work and unsuitable for anything that must stay up. Neither mechanism is a trick; they are useful tools. But they narrow the compute gap by adding commitment or accepting interruption, not by removing the structural costs that make cloud's total higher for steady workloads.
So the honest way to use them in a comparison is to price the cloud side at its best realistic rate — reserved where the workload is steady enough to justify the commitment — and still add egress, meters, and support on top, then compare that to the flat bare-metal total. Done that way, reservations close part of the gap for steady workloads but rarely erase it, and the commitment they demand undercuts the flexibility argument for staying on cloud at all. If you are ready to commit for years, that is often the clearest signal the workload belongs on owned capacity.
The crossover
Which total is lower for your workload?
Predictability and utilization decide it: variable, idle, early-stage work favours cloud's TCO; steady, high-use, data-heavy work favours bare metal's.
We host the bare-metal side, so read that as disclosed bias. The honest rule: below the crossover, cloud's flexibility earns its premium; above it, bare metal's flat, meter-free total is lower — often by a wide margin once egress is counted.
Choosing
How to run the comparison — and how we help
A short, honest path from the full cloud bill to the true total-cost comparison for your workload — including the case where cloud wins.
- 01
Count the whole cloud bill, not the sticker
Add egress, over-provisioning, managed-service meters, and the support plan to the instance rate. That total, not the per-hour number, is what you compare.
- 02
Measure your real utilization
Steady, high-utilization workloads waste cloud's pay-as-you-go advantage. If your servers run most of the time, a flat cost almost always wins on TCO.
- 03
Price the elasticity you actually use
Cloud's premium buys elasticity. If your load is predictable and you rarely scale, you are paying for flexibility you don't use — count that honestly.
- 04
Include engineering and opportunity cost
TCO isn't only invoices. Factor the engineering time each option costs and the speed cloud can buy early on — sometimes worth the premium, sometimes not.
- 05
Let us model it on your numbers
We host bare metal, so treat that as disclosed bias — and we will show you the case where cloud's TCO genuinely wins for your workload.
Questions
Bare metal vs cloud TCO, answered plainly
The things compute buyers email us about most.
Is bare metal really cheaper than cloud?
For steady, predictable, high-utilization workloads, usually yes — once you count the whole bill rather than the sticker. Cloud's per-hour rate is only the first line; egress, over-provisioning, managed-service meters, and support plans stack on top, so the true cost of ownership commonly runs to a large multiple of the advertised instance price. Bare metal is a flat cost with far fewer hidden layers, so for a server that runs most of the time its TCO tends to be lower. The honest exception is variable or low-utilization work, where cloud's pay-as-you-go model wins — cheaper is a function of your usage pattern, not a universal truth.
What are the hidden costs of cloud?
The ones that do not appear on the pricing page you first read. Data egress — the per-gigabyte charge to move data out of the provider's network — is the classic one, and it surprises data-heavy workloads. Over-provisioning is another: because scaling has friction, teams run headroom they pay for around the clock. Then there are the managed-service meters — load balancers, storage IOPS, snapshots, inter-zone transfer — and a support plan often priced as a percentage of spend. None is hidden in a dishonest sense, but together they turn the instance sticker into a fraction of the real total-cost-of-ownership.
When does cloud have the better TCO?
When your workload is variable, early-stage, or genuinely needs elasticity. If demand is spiky and unpredictable, if you are a young product whose needs may change monthly, or if you regularly scale up and down, cloud's pay-as-you-go model means you pay for what you use and nothing for idle capacity — which a flat bare-metal cost cannot match for low or bursty utilization. Cloud also buys speed early on: standing up infrastructure in minutes has real value when you are moving fast and uncertain. For those shapes, cloud's higher unit cost buys flexibility that is worth more than the saving bare metal would offer.
Why are companies moving workloads back to bare metal?
Because at steady scale the cloud TCO math stops favouring cloud, and some well-publicized migrations back to owned or bare-metal infrastructure have reported large savings. The pattern is consistent: a workload that was variable and small when it started on cloud becomes large and predictable as the business matures, at which point the always-on premium and egress fees it pays every month exceed what flat, owned capacity would cost. This is not a rejection of cloud — it is a workload crossing the utilization threshold where its economics change. The same company often keeps variable workloads in the cloud and moves only the steady baseline.
Doesn't cloud save on staff and operations?
It can, and that belongs in an honest TCO — but it is easy to overstate. Cloud removes the physical operation of hardware, which is real, yet a serious cloud estate needs its own specialists to manage cost, security, and complexity, so the saving is smaller than 'no servers to run' implies. With managed bare metal, the physical operation is handled for you too, which narrows the gap further: you are not trading a managed cloud for a raw data centre, but comparing two operated options. The staffing question is real, but it rarely swings the TCO on its own the way vendors suggest.
How do I actually calculate the TCO comparison?
Build the whole cloud number first: instance cost at your real utilization, plus egress for the data you move, plus the managed-service meters you use, plus over-provisioning headroom, plus the support plan. Then compare it to the flat bare-metal cost plus its bandwidth, and add the honest bare-metal trade-offs — the capacity you pay for whether busy or idle, and the commitment term. Finally, weigh the non-invoice factors: engineering time and the value of elasticity or speed to your specific situation. The comparison is rarely close once the full cloud bill is on the table for a steady workload — but do the maths on your numbers, which is what we will help with.
Is bare metal harder to operate than cloud?
Raw, self-run bare metal asks more of you than a managed cloud console. But that is not the comparison with us: our bare metal is operated for you, so you get owned, single-tenant capacity without becoming a data-centre operator. The real trade-off against cloud is therefore about the economic model and elasticity — flat cost and fixed capacity versus per-hour billing and on-demand scale — not about managed versus unmanaged. If your utilization suits it, you get bare metal's TCO advantage without taking on the operational burden people imagine.
Want the honest total, not the sticker?
Tell us your workload, its utilization, and how much data it moves. We will build the full cloud TCO beside a flat bare-metal cost, run bare metal when it wins, and tell you plainly when cloud's total is lower.