Bare Metal Is Back, and It's Different This Time
For most of the last decade, the answer to "where do we run this?" was the same answer for almost every team: a hyperscaler. AWS, GCP, or Azure, with the specific service depending on what was being run. The exceptions were notable enough that they got case-studied — Dropbox famously moving off S3, Basecamp's leaving the cloud — but they were exceptions.
That has changed. Not loudly, and not all at once, but consistently. In the last twelve months we have onboarded more teams migrating workloads from hyperscalers onto dedicated hardware than in the previous three years combined. The teams making the move are not all-or-nothing — most still keep some workloads in the cloud — but the gravity has shifted.
It is worth understanding why, because the reasons are different from the reasons bare metal lost the first time around.
What bare metal lost on, the first time
The cloud won on three things, roughly in this order: elasticity, operational burden, and capital efficiency.
Elasticity meant you could go from one server to a hundred in minutes when you needed to. For startups whose load was unpredictable and whose growth was hopeful, that was transformative. You did not have to guess your peak load eighteen months in advance and write a cheque for the hardware.
Operational burden meant somebody else handled the boring parts. Power, cooling, network upstream, hardware failures, compliance certifications, the physical security of the building. For a small team, the staff cost of doing this in-house was often more than the entire AWS bill, and it competed for headcount with people who could be writing product code.
Capital efficiency meant you could pay monthly for what you used instead of writing six-figure cheques for hardware that depreciated. For venture-backed companies optimising for runway and growth rate, opex was structurally preferable to capex.
All three of those were real. None of them have gone away. But the math on each has changed in ways that, when you add them up, produce a different answer.
What changed, briefly
Three things shifted, and each one independently would have moved the needle a little. Together they have moved it a lot.
1. The cloud got expensive in ways that compound
The headline list price of EC2 is one number. The actual bill includes egress, NAT gateway hours, EBS provisioned IOPS, RDS multi-AZ replicas, ELB capacity units, CloudWatch logs, KMS request charges, S3 PUT charges, inter-AZ traffic, and a few dozen other line items that did not exist or did not matter ten years ago.
For workloads with predictable load and meaningful data movement, the all-in cost has crept up to where dedicated hardware — even when you include the human cost of someone managing it — is straightforwardly cheaper. We see customers reduce their monthly infrastructure spend by 60–75% on the migration, and that is before you count the engineer time they spent optimising AWS that they no longer have to spend.
2. Operational tooling caught up
Ten years ago, running your own Kubernetes cluster on bare metal was a serious undertaking. The control plane, etcd, networking (CNI), storage (CSI), ingress, certificate management, observability — every layer of the stack required deliberate engineering, and most of the open source options were rough enough that you needed real expertise to operate them.
That is no longer true. Talos, k3s, and the maturity of upstream Kubernetes have collapsed the operational complexity dramatically. Cilium and Calico have made networking on bare metal not just workable but better than what most cloud providers ship by default. Ceph and Longhorn have made distributed storage tractable. The tooling is still complex, but the complexity is now in the same range as the operational complexity of running things well in EKS or GKE — which, anyone who has done it knows, is not zero.
3. The workloads themselves got heavier
This is the one nobody talks about enough.
The workloads of 2015 — stateless web servers, modest databases, some background jobs — fit the cloud's pricing model well. Nothing was hammering the disk. Nothing was saturating the network. Most of the cost was CPU and RAM, which the cloud sells competitively.
The workloads of 2026 are different. Vector databases hold tens of gigabytes in RAM and are sensitive to memory bandwidth. AI inference saturates GPU and PCIe in ways that get billed cruelly when run on cloud GPU instances. Real-time data pipelines push terabytes a day through Kafka topics whose intra-region replication traffic alone costs more than the compute. Customer-facing video and audio workloads have egress profiles that make the AWS bill look like a typo.
For these workloads, the cloud's pricing model is not just expensive — it is structurally hostile.
Egress is no longer rounding error
This deserves its own section because of how badly it gets misunderstood.
For a typical web application — small payloads, modest traffic, most data staying inside the VPC — egress is genuinely a rounding error. It does not appear on cost reviews because it does not need to.
For a video streaming workload, an AI API serving large embedding responses, a backup-as-a-service product moving terabytes a week, or any workload that pushes meaningful data out to the internet or to a different region, egress can be the single largest line item on the bill. We have onboarded customers whose AWS bill was 60% egress. After migration to a colocation provider with flat-rate bandwidth, that line item went to roughly $300 a month.
Hyperscalers have been adjusting their egress pricing recently — not because they suddenly found generosity, but because regulation and competitive pressure forced them to. The adjustments are real but small. The structural advantage of paying per-gigabyte instead of per-port has not changed.
AI inference economics break the cloud model
The cleanest example of where the cloud's pricing model fails for modern workloads is GPU inference.
An A100 instance from a hyperscaler is meaningfully more expensive per hour than the same A100 in a colocation rack. That gap was always there for CPU instances too, but the absolute numbers were small enough that the operational simplicity of the cloud paid for itself. With GPUs, the absolute numbers are large enough that the math flips. A single A100 running 24×7 for a year costs roughly $60K on AWS list price. The same hardware in a colo, including power, bandwidth, and amortised hardware cost, comes in around $15–20K.
For teams running production inference at any volume, this is not a small optimisation. It is the difference between unit economics that work and unit economics that do not.
And inference is not the only AI workload with this profile. Fine-tuning runs, embedding generation pipelines, batch processing of historical data — anything that needs sustained GPU utilisation for a non-trivial fraction of the month — has the same pricing structure pushing toward the same answer.
What "bare metal" actually means in 2026
The phrase is doing a lot of work and it is worth being precise.
"Bare metal" in 2026 does not mean a single server in your office closet. For the teams making this move successfully, it means dedicated physical hardware in a tier-3 or tier-4 colocation facility, with redundant power and network, running an upstream Kubernetes distribution with full operational tooling — observability, ingress, certificate management, secrets, backups, deployment pipelines, on-call rotation. Operationally it looks very similar to a managed Kubernetes service. The difference is what is underneath.
The operational story we hear from teams that have done this is consistent: the day-to-day developer experience is unchanged. They still ship via the same CI/CD. They still get the same monitoring dashboards. The application layer has no idea it is not on AWS. What changed is the bill, the performance ceiling, and the answer to "what does our hardware actually do?".
The honest tradeoffs
This is not a one-way migration story. There are real things you give up.
You give up the ability to spin up an arbitrary new region in five minutes. If your business genuinely needs to be in São Paulo next month, the cloud is faster. We are happy to set up a Brazilian colocation deployment for you, but it is a six-week process, not a six-minute one.
You give up the ability to scale capacity instantly. Adding nodes to a bare metal cluster is fast — minutes, not days — but you have to have the hardware in the rack. Spike capacity that you did not provision is not on tap the way it is in EC2. For workloads with truly unpredictable load, this matters.
You give up the breadth of the managed services catalog. SageMaker, Aurora, MSK, EventBridge, Step Functions — these have open source equivalents, but the equivalents need to be operated, and the operational cost is real. For some workloads it is worth it. For others, the managed service is the better answer.
And you take on the failure modes of physical hardware. Disks fail. Power supplies fail. Network cards develop weird intermittent issues that take a day to diagnose. A good colocation provider and a good operational team handle this invisibly, but it is not free.
How we think about it
The pattern that works for most of the teams we talk to is not all-or-nothing. It is putting the workloads that benefit from dedicated hardware on dedicated hardware, and leaving the workloads that benefit from cloud elasticity in the cloud.
The workloads that benefit most from bare metal in 2026: production databases, AI inference, real-time data pipelines, anything with high-bandwidth egress, anything with predictable sustained load. These are also the workloads that hurt the most on a hyperscaler bill, which is not a coincidence.
The workloads that still belong in the cloud: spiky front-ends that need to scale to absorb traffic events, batch jobs that run for an hour a week, things that genuinely need a managed service nobody else provides as well, and anything where the customer's contractual requirements include "must run on AWS".
The decade-long bet on the cloud being the answer for everything is over. The decade ahead is going to be more pluralistic, with workloads landing where they belong based on their actual characteristics rather than on a default. That is healthier for everyone — including, in the long run, the hyperscalers.
If you are running a workload that has the smell of being in the wrong place — a database on a too-expensive RDS instance, an AI service whose inference bill scales linearly with users, a data pipeline whose biggest cost line is egress — we would like to talk. We will tell you honestly when the cloud is the right answer for what you are doing. When it is not, we can help you do something about it.