Dedicated vs. public cloud: understanding the real cost drivers
Quick answer
The compute rate on a public cloud invoice rarely tells the whole story. Data egress, the fee for moving data out of a cloud provider's network, is usually the cost driver that grows fastest and least predictably. Workloads with a steady, predictable baseline and heavy data movement are the ones where owning dedicated infrastructure instead tends to make sense; workloads that are spiky or lean heavily on managed cloud services usually don't. Moving specific workloads back onto infrastructure you control is a recognised pattern called cloud repatriation, and it's normally selective, not a full exit from the cloud.
Why the sticker price isn't the real comparison
Comparing a dedicated server's monthly rate against a cloud instance's hourly rate looks simple, but it misses where cloud spend actually accumulates once a workload is live. The two figures that decide whether cloud or dedicated infrastructure works out better for a given workload are how predictable that workload's usage is, and how much data it moves. Both point back to the same underlying mechanism: public cloud pricing is built around elasticity, and elasticity is expensive to keep paying for once a workload no longer needs it.
The egress fee mechanism
Egress fees are charges for data leaving a cloud provider's network, commonly labelled "data transfer out," whether that's to the public internet or to another location entirely. The mechanism that makes them significant is simple: egress cost scales directly with how much data you ship. Downloads, video, datasets, backups, AI model outputs, all of it counts, and the fee rises even when your compute usage stays flat. For a data-heavy product, egress can end up as the largest single line on the bill, precisely because it's tied to your product's success rather than to a fixed resource you provisioned in advance.
Dedicated and private infrastructure generally isn't billed this way. Because you're not paying a public cloud provider per gigabyte to move your own data off their network, a workload that moves a lot of data is one of the clearest cases where the cost profile of dedicated infrastructure looks structurally different from a cloud one, independent of any specific price comparison.
Predictable workloads vs. variable workloads
The other half of the comparison is how steady the workload's resource usage is over time:
| Predictable, steady-state | Variable, bursty | |
|---|---|---|
| Usage pattern | Runs continuously at a fairly constant, high utilisation | Spikes, idles, or scales unpredictably |
| What you're paying for on cloud | Elasticity you aren't actually using | Elasticity that's doing real work absorbing the spikes |
| Better structural fit | Dedicated or private infrastructure, sized once for the steady baseline | Public cloud, scaling resources up and down as demand changes |
Cloud's core value is elasticity, paying for extra capacity only when you need it. That's a real advantage for a workload that genuinely fluctuates. It stops being an advantage once a workload settles into a constant, predictable baseline, because you're then paying an ongoing premium for flexibility the workload no longer uses.
Cloud repatriation: moving workloads back onto infrastructure you control
Cloud repatriation is the term for moving specific workloads out of a public cloud, such as AWS, Azure or Google Cloud, back onto infrastructure you control: dedicated servers, private cloud, or on-premises hardware. It's usually driven by wanting to reduce steady-state costs, get more predictable performance, or meet data control and jurisdiction requirements. Repatriation is typically selective: a business moves the workloads where the economics or compliance case is clearest, and keeps everything else running in the cloud. It's rarely a full exit.
Is your workload a good repatriation candidate?
Four characteristics make a workload a strong candidate for moving off public cloud:
- Predictable baseline usage: it runs continuously at a fairly constant, high level of utilisation, rather than idling most of the time.
- High outbound data traffic: it regularly ships significant volumes of data out, the kind of usage pattern where egress fees accumulate fastest.
- Large persistent datasets: the data itself has settled in place, sometimes described as "data gravity," which makes moving it, or the cost of leaving it where it is, a bigger factor over time.
- Strong control requirements: auditability, tenancy isolation, or a specific jurisdiction the data needs to stay within.
Workloads that don't fit this profile are usually better left where they are. Spiky or experimental workloads, and anything that leans heavily on managed cloud services, such as serverless functions or auto-scaling managed databases, tend to belong in the cloud for longer: rebuilding that managed functionality yourself on dedicated infrastructure is its own project, and often isn't worth it unless the workload has already matured into something stable.
A hybrid approach: dedicated for the baseline, cloud for the burst
Repatriation doesn't have to mean choosing one platform for everything. A common pattern keeps cloud services for what they're genuinely best at, automation, managed control planes, rapid scaling, while routing steady-state and bandwidth-heavy traffic through dedicated infrastructure instead. In practice that can look like serving high-egress traffic from a dedicated environment, offloading large files to dedicated object storage, or running the baseline workload on dedicated infrastructure and bursting to cloud only when demand actually spikes. The aim is to keep cloud's agility where it earns its keep, while removing the costs that scale against you as your product grows.