Originally published at rajesh.medampudi.com/blog/bare-metal-vs-cloud
Most teams asking whether they should leave the cloud for bare metal Kubernetes should stay on the cloud. I say this as someone who left.
I run six Hetzner dedicated nodes with a multi-tenant Kubernetes cluster on top of them. The price-per-spec gap between that and an equivalent setup on AWS is not a rounding error — it is a multiple. And still, my honest advice to most people who ask me about it is: don't. The reason both halves of that sentence are true is the whole point of this post.
The cloud-vs-bare-metal argument is usually run by zealots on both sides. One camp says the cloud is a tax and anyone paying it is being fleeced. The other says touching a physical server in 2026 is madness and you should pay AWS to never think about hardware again. Both are selling you their own comfort as a universal law. The truth is a tradeoff, and the tradeoff has a fairly clean dividing line. Here it is, and here is how to find which side of it you are on.
The price gap is real, and it's large
Start with the part the bare-metal camp gets right: at the hardware level, the gap is not subtle.
A Hetzner AX102 dedicated server — AMD Ryzen 9 7950X3D, 16 cores / 32 threads, 128 GB DDR5 ECC, 2× 1.92 TB NVMe — lists at €119/month in Finland, €124 in Germany, plus a one-off setup fee (Hetzner AX102, Jun 2026). That is a whole physical machine you don't share with anyone.
The closest-on-paper AWS on-demand instance by core count, an m7a.4xlarge (16 vCPU, 64 GB RAM — half the AX102's RAM, and vCPUs are hyperthreads, not full cores), runs about $0.927/hour, which is roughly $677/month in us-east-1 (Vantage m7a.4xlarge, Jun 2026). And that is just the compute. You haven't paid for the disk, you haven't paid for the data leaving the box, and you haven't paid for the managed Kubernetes control plane yet.
So compute alone is roughly €119 versus ~$677 for a weaker spec. Call it a 5x order-of-magnitude difference before you add the two line items that actually catch people out.
Egress is where the cloud bill quietly explodes
The second thing the bare-metal camp gets right is egress — the cost of data leaving the cloud.
AWS charges roughly $0.09/GB for the first 10 TB/month of internet egress, after a 100 GB free tier, sliding down to about $0.07/GB at very high volume (AWS Data Transfer pricing 2026, Jun 2026). That sounds small until you multiply. Ship 20 TB of traffic out in a month — not a lot for anything media-heavy or API-heavy — and you are looking at roughly $1,800 in egress alone, on top of compute and storage.
Hetzner's dedicated boxes ship with effectively unlimited traffic on the standard 1 Gbit/s port, and their cloud line includes 20 TB/month with overage at about €1/TB (Hetzner AX102, Jun 2026; Hetzner traffic docs, Jun 2026). The same 20 TB that costs ~$1,800 on AWS costs nothing extra here.
This is the line item that turns a "the cloud is a bit pricey" conversation into a "the cloud is structurally the wrong shape for this workload" conversation. Egress is not a discount you can negotiate your way out of with reserved instances, and it is not the only network charge that hides in plain sight — I , which catches teams the same way. If your product moves a lot of bytes to users, egress alone can justify the move.
Managed Kubernetes adds a per-cluster tax
Then there's the control plane. AWS EKS charges $0.10/hour per cluster — about $73/month — just for the managed control plane, before a single worker node (AWS EKS pricing, Jun 2026). And if you fall behind on Kubernetes version upgrades into extended support, that jumps to $0.60/hour — roughly $438/month per cluster (Cloud Burn EKS pricing, Jun 2026).
$73/month per cluster is not what breaks the bank. But it changes how you think. On managed K8s, every cluster has a standing tax, so you are pushed toward fewer, bigger, multi-tenant clusters whether or not that's the right architecture. On my own bare metal, a cluster costs me nothing but the nodes and my own time — so the architecture decision is made on its merits, not on a per-cluster meter. That freedom is real, and it is also exactly where the hidden cost lives, which is the next section.
Now the part the bare-metal zealots leave out
Everything above is true and it is why I run what I run. But if I stopped here I'd be selling you the same one-sided story I'm warning you about. The cloud's price is not a scam. You are paying for something, and the something is real.
You are paying AWS to be your on-call hardware team. When a disk dies in my Hetzner rack, that is my problem. I notice it, I open a ticket, I fail the workload over, I wait for the swap. On AWS, a failed host is invisible — the instance reschedules and you never knew. Physical machines also don't last forever; the honest TCO models put a full hardware refresh every 3–5 years and note that surprise infrastructure expenses hit a large share of teams every year (Hivelocity Cloud vs Dedicated TCO 2026, Jun 2026).
You are paying for elasticity you might actually need. Bare metal is fixed capacity. If your traffic is spiky — launch days, seasonal peaks, unpredictable virality — you either over-provision bare metal for the peak (and waste it the rest of the time) or you eat the outage. The cloud's "expensive" per-hour price is the price of paying only for the peak when the peak happens. For a steady, predictable workload that runs hot most of the time, you are paying that premium for nothing. For a spiky one, you are buying insurance.
You are paying to not become an infrastructure team. This is the big one and it is the one that does not show up on any pricing page. Running my own Kubernetes on my own nodes means I own the control plane upgrades, the etcd backups, the networking, the storage layer, the monitoring, the security patching, the certificate rotation. That is a real, recurring draw on the scarcest resource any small team has: senior engineering attention. The general TCO research is blunt about it — the tipping point where dedicated infrastructure wins on cost is usually somewhere around $2,000–$5,000/month of cloud spend and workloads running above ~50% utilisation (Hivelocity TCO, Jun 2026). Below that line, the money you save on bare metal is smaller than the salary-hours you spend operating it.
The bare metal Kubernetes decision framework
So strip out the ideology. Here is the actual question, in order. The first "yes" that points you back to the cloud should usually win.
- Is your cloud bill under ~$2,000/month? If yes, stay. The savings won't cover the operational time. Spend that time on your product, not your infrastructure.
- Is your traffic spiky and unpredictable? If yes, lean cloud. You are buying elasticity, and bare metal can't give it to you without over-provisioning for the peak.
- Do you have someone who actually wants to own infrastructure? Not "can tolerate it" — wants it, and has the hours. If no, stay on managed services. Self-hosted Kubernetes without a committed owner is how you get a 2 a.m. outage with no one who understands the stack.
- Is egress or steady high-utilisation compute your biggest line item? If yes, now bare metal starts to win hard. This is the workload shape — predictable, heavy, bandwidth-hungry — where the 5x compute gap and the unlimited-traffic gap actually land in your pocket.
- Can you tolerate a hardware failure as a known, planned event rather than an invisible one? If yes, and you've reached this step, go. If a single disk death is an existential outage for you, pay someone else to make it invisible.
If you answered in a way that keeps pointing you back to the cloud — good. That is the honest answer for most teams, and it is not a failure of nerve. The cloud earns its price for variable, small-to-mid, attention-constrained workloads. That is most workloads.
I run bare metal because my workload sits on the far side of every one of those questions: predictable, multi-tenant, bandwidth-aware, and I am the person who wants to own the stack. I documented how I set those nodes up in . My all-in bill for the six nodes is a couple hundred dollars a month, and the same workload on AWS — managed control plane, NAT gateways, egress, observability, secrets — would cost me five to ten times more. I have done the math, the same way I , and I keep doing it; it keeps coming out the same. That is what made the call obvious for me. It will not be obvious for you unless your workload looks like mine. Run the five questions honestly before you run the migration.
The skill is not "use bare metal" or "use the cloud." The skill is knowing which question you are actually answering — and refusing to let either camp answer it for you.
If you want a second pair of eyes on which side of those five questions your workload actually sits — or you just want your cloud bill read line by line before you decide anything — book a free 15-minute bill review. I will tell you honestly whether the move is worth it for you, including when it isn't.