When on-premise beats cloud, and the costs both sides leave out

We build and operate both cloud and on-premise infrastructure, and we do not sell hardware, so nothing rides on which way this comes out. For most workloads a public cloud is the right answer and we say so regularly. But cloud has quietly become a default rather than a decision, and there is a specific set of cases where owned hardware is straightforwardly better.

Utilisation decides it, not size

The most common mistake in this argument is comparing absolute scale. The variable that actually matters is utilisation. Cloud pricing is a premium for elasticity, and you only get value from that premium if your demand genuinely varies. If your fleet runs at 70% around the clock, you are paying for the option to burst and never exercising it.

As a rough guide, sustained utilisation above roughly 60% on always-on compute is where owned hardware tends to win over a three-year view. Below about 30%, cloud wins comfortably. In between it depends on the specifics, and it is worth modelling properly rather than arguing from priors.

Cloud pricing is a premium for elasticity. If your load never varies, you are buying an option you never exercise.

What cloud advocates leave out

• Data egress. Metered, and the line item that most often ambushes data-heavy workloads. Analytics pipelines, media, and backup restores are where it bites.
• Always-on compute at scale. Reserved instances and savings plans help, but committing to three years of capacity is itself a bet against elasticity — which was the reason for being there.
• Managed service premiums. Convenient and genuinely valuable, priced accordingly, and the main source of the lock-in that makes leaving expensive.
• GPU compute. The gap between cloud GPU pricing and owned hardware is currently the widest of any category, and if you train models continuously it dominates everything else.
• Inter-zone traffic. Charged, frequently invisible in architecture reviews, and easy to multiply accidentally with a chatty service mesh.

What on-premise advocates leave out

• Staff time. Someone owns capacity planning, firmware, disk replacement and physical security. That is a real salary, or a real retainer, and it does not appear on a hardware quote.
• Hardware refresh. Servers are a three-to-five-year cycle. A comparison that omits refresh is comparing a capital purchase against an operating cost and calling it a saving.
• Power, cooling and space. Modest in colocation, significant in your own facility, and consistently forgotten.
• Disaster recovery. A second site is real capital. In a cloud, multi-region is a configuration change — this is one of the largest genuine advantages cloud has.
• Time to first environment. Weeks of procurement and racking versus minutes. Early in a product's life that difference is worth more than the cost gap.

The reason that overrides the arithmetic

For a meaningful share of the clients who ask us about this, cost is not the driver at all. A regulator, a client contract or a sovereignty requirement states that data must sit on hardware they control. Pharmaceutical, defence, government and parts of financial services routinely land here.

Cloud regions answer the geography question but not the operator question. If the requirement is that no third party has custody, a region in the right country does not satisfy it. When that is the constraint, the cost model is irrelevant — and the useful conversation is about doing on-premise well rather than whether to do it.

On-premise done badly is the actual problem

Most bad experiences with on-premise are not about on-premise. They are about undisciplined infrastructure that happened to be on-premise: one server configured by hand years ago, no reproducible provisioning, no deployment pipeline, monitoring that consists of someone noticing it is slow, and a restore procedure nobody has ever run.

None of that is inherent. Ansible gives you hosts reproducible from bare metal. Kubernetes or Docker Swarm gives you orchestration — and Swarm is the right answer more often than the industry admits, because a handful of services on a handful of nodes does not justify Kubernetes' operational tax. Argo CD gives you the same GitOps deploy and one-step rollback you would have in a cloud. Prometheus, Grafana, Loki and a self-hosted Sentry give you observability that never leaves your network.

The reason cloud infrastructure is usually more disciplined is not the technology. It is that a billing dashboard forces you to look at it every month. On-premise lets you get away with neglect for longer, and that is the real difference in outcomes.

The decision that actually matters

It is not cloud or on-premise. It is portability. Stay on containers, keep to open components, and keep proprietary managed services off the critical path. Do that and moving between a cloud and your own hardware in either direction is ordinary engineering work.

Skip it and the choice you made in year one becomes permanent — which is how companies end up with a bill they cannot reduce, or hardware they cannot grow out of. Our usual advice: start in a cloud, keep it portable, and revisit when either the invoice or a regulator forces the question. Then have the argument with your actual numbers rather than someone's pricing page.