Most cloud-versus-dedicated comparisons are written by people selling one of the two. This one is written by a company that rents dedicated servers and will still tell you the honest cases where cloud wins: spiky or unpredictable load, heavy managed-service dependencies, and teams with no capacity planning discipline. For everything else, the arithmetic is not close, and it is worth walking through with real numbers so you can place your own workload on the right side of the line.
A mid-range dedicated server today, something like a modern 16-core CPU, 128 GB of RAM, dual NVMe drives in RAID and a 1 Gbps port, rents for roughly 150 to 250 GBP per month from a reputable UK or EU provider. To assemble comparable raw capacity from a hyperscale cloud you would need roughly 16 vCPUs and 128 GB of RAM across a few large instances. On published on-demand pricing that lands somewhere between 700 and 1,100 GBP per month before you have moved a single byte of traffic. Reserved pricing closes the gap to perhaps 400 to 600 GBP per month if you commit for one to three years, which is to say: even with a multi-year commitment, you are still paying roughly two to three times the dedicated price for the same compute.
The reason is structural, not promotional. A cloud provider runs your workload on the same physical hardware a dedicated provider would, then adds a multi-tenant virtualisation layer, a metering and billing stack, an API control plane, and the margin that pays for all of it plus the free tiers. You are not paying for the CPU. You are paying for the optionality of the CPU.
That optionality has real value, and pretending otherwise is how dedicated providers lose arguments. Cloud genuinely wins when your load is unpredictable: a retail site at five percent capacity for three weeks and thirty-five percent on launch day, a batch job that needs 200 cores for six hours, a startup that does not yet know its own traffic shape. Cloud also wins when you consume managed services heavily, because running your own database cluster, object storage and message queue on dedicated hardware is real engineering work with real on-call consequences. If your team is two developers, the cloud premium is partly a staffing bill, and it can be worth every penny.
The mistake is paying the optionality premium for workloads that never exercise the option. A database that runs at 60 percent utilisation every hour of every month, a mail platform, a game server, a company website, an internal analytics box: these have steady, known load. There is nothing to burst into. Buying elasticity for them is paying an insurance premium on an event that has already been ruled out.
Bandwidth pricing is where the comparison stops being arguable. Hyperscale egress is billed per gigabyte, historically in the range of 5 to 9 pence per GB after the first 100 GB or so, which works out to roughly 50 to 90 GBP per terabyte. Move 10 TB out of a cloud region in a month and the traffic alone can exceed the entire cost of a dedicated server including its bandwidth. Dedicated providers, by contrast, sell bandwidth by capacity: a committed rate on a port, as covered in our piece on 95th percentile versus metered transfer billing. Ten TB of monthly transfer on a 500 Mbps commit costs the same as two TB, which is to say it costs nothing incremental at all.
For anything media-heavy, backup-heavy, or API-heavy, egress alone moves the crossover point so far that no reserved-instance discount can recover it. We regularly onboard customers whose entire reason for leaving cloud is a monthly egress line bigger than their compute line.
Dedicated servers are not cloud with a discount sticker. You give up API-driven elasticity, so scaling means buying hardware with days of lead time rather than seconds. You give up the managed layer, so patching, RAID monitoring and failover are your job or your provider's managed-service job, and the quality varies enormously between providers. You also take on single-box risk unless you architect around it, which is why failover IP and BGP capabilities matter more with dedicated than cloud, a subject we cover in our article on BGP announcements and failover IPs. And when hardware does fail, the recovery contract is the product: our own recovery-time expectations are documented in what separates a 4-hour recovery from a 4-day one, and you should demand the same specificity from any provider you consider.
Take a concrete workload: an e-commerce backend, steady 30 percent CPU, 96 GB RAM, 8 TB monthly egress. On cloud, reserved, roughly 350 GBP compute plus 400 to 700 GBP egress, call it 750 to 1,050 GBP per month. On a dedicated box with a suitable port commit, roughly 200 to 300 GBP all in. Over three years the difference is 16,000 to 27,000 GBP, which for most businesses is a person's salary or a product line's budget. Run the same numbers for a workload doing 100 GB of egress with wildly spiky load and cloud wins outright. Neither answer is ideological; both are arithmetic.
Three questions decide it. First, is your load predictable month to month? If yes, the elasticity premium is dead money. Second, how much traffic leaves the box? Above a few terabytes a month, cloud egress makes the decision on its own. Third, do you have the engineering capacity to run the box, or a provider whose managed service you actually trust? If the third answer is no, stay on cloud until it is yes, and revisit every time your bill crosses the price of a junior ops hire. The crossover is not a belief system. It is a line on a graph, and your invoice tells you which side of it you are standing on.