For most UK businesses, the cloud-versus-colocation decision gets made once, by default, and rarely revisited. A team spins up on AWS or Azure because it’s the fastest way to get moving, and three years later nobody has stopped to ask whether that’s still the right economic and operational fit. It often isn’t. The workloads that suit hyperscale public cloud (bursty, unpredictable, short-lived) are a different shape to the workloads that suit colocation (steady-state, predictable, compliance-sensitive, data-heavy) — and most organisations run a mix of both without realising it.

This isn’t an argument against cloud. It’s an argument for matching infrastructure to workload rather than defaulting to whatever was easiest to provision first. Here’s how to think about it properly.

What colocation actually means

Colocation is simple in principle: you own (or lease) the physical servers, and you rent secure, powered, connected rack space in someone else’s purpose-built data centre to house them. You get enterprise-grade power redundancy, cooling, physical security and network connectivity without the capital cost of building a facility yourself. Compare that to public cloud, where you rent compute and storage as a metered service on infrastructure you never see or control, with the provider abstracting away the hardware entirely.

Both models solve “I don’t want to run my own data centre.” They solve it in very different ways, and the differences matter once you’re spending real money at scale.

Where cloud wins

• Elastic, unpredictable demand. If your traffic genuinely spikes 10x around seasonal events or marketing campaigns, paying for peak capacity you use 5% of the time is wasteful. Cloud autoscaling matches spend to demand in near real time.
• Rapid, disposable experimentation. Spinning up a test environment for an afternoon and tearing it down is trivial in cloud and awkward in colocation.
• Global reach with minimal lead time. Deploying close to users in a dozen regions overnight isn’t realistic with physical infrastructure.
• No hardware lifecycle to manage. No procurement, no refresh cycles, no disposal — someone else’s problem.

Where colocation wins

• Steady-state workloads. If your compute usage is flat and predictable — a core ERP system, a database tier that runs 24/7 at consistent load — you are paying a permanent premium for elasticity you never use. Owned hardware in a colocation facility is usually cheaper over a 3-5 year horizon for this profile.
• Data-heavy or I/O-intensive applications. Public cloud egress and high-IOPS storage charges add up fast. Bulk storage and data-heavy processing are often dramatically cheaper on owned hardware.
• Regulatory and data sovereignty requirements. Knowing precisely which building your data sits in, who can physically access it, and being able to demonstrate that to an auditor is far more straightforward with UK colocation than with a hyperscale provider’s shifting regional infrastructure.
• Hardware control. Specific GPU configurations, storage architectures or network interface cards that aren’t available (or are prohibitively marked up) as a cloud SKU.
• Cost predictability. A fixed monthly colocation and power bill is much easier to budget against than a cloud invoice that can swing with usage, data transfer and the occasional forgotten resource left running.

The real cost comparison: TCO, not sticker price

Comparing an EC2 instance’s hourly rate to a colocation invoice is comparing the wrong numbers. A proper Total Cost of Ownership (TCO) comparison for colocation needs to include hardware capex (amortised over its useful life, typically 4-5 years), rack space, power (both consumption and PUE overhead), bandwidth, remote hands support, and hardware refresh cycles. For cloud, the equivalent figure needs to include not just compute and storage, but data egress, load balancer and NAT gateway charges, snapshot storage, and the engineering time spent on cost optimisation — cloud bills are notoriously easy to underestimate.

Factor	Public Cloud	Colocation
Best suited to	Bursty, unpredictable, short-lived workloads	Steady-state, predictable, long-running workloads
Cost model	Metered, usage-based, variable	Fixed monthly rack + power, capex on hardware
Hardware control	Limited to provider SKUs	Full control over spec
Data egress cost	Often significant	Typically included or flat-rated
Scaling speed	Minutes	Days to weeks (procurement lead time)
Data sovereignty clarity	Region-based, less granular	Specific facility, fully auditable

The hybrid answer most UK businesses land on

In practice, the businesses getting the best value aren’t choosing one model exclusively — they’re running core, predictable infrastructure on colocated hardware and pushing genuinely elastic or geographically distributed workloads to public cloud. This is exactly the pattern we’ve seen accelerate over the past two years: organisations that lifted-and-shifted everything to AWS during the early cloud-adoption wave are now repatriating steady-state workloads back to owned infrastructure once the TCO numbers become impossible to ignore, while keeping cloud for what it’s genuinely good at.

Making this hybrid model work well depends heavily on connectivity between your colocated hardware and the public cloud regions you still use — low-latency, high-bandwidth links via direct connect or good network peering turn “hybrid” from a compromise into an architecture advantage.

Questions to ask before you decide

1. Is this workload’s resource demand flat or spiky over a typical month?
2. Will it still exist, largely unchanged, in three years?
3. Does it handle regulated data where you need to demonstrate exactly where it physically resides?
4. Have you calculated a genuine 3-5 year TCO for both options, including egress, support labour and hardware refresh?
5. Do you have (or can you get) reliable, low-latency connectivity between the two environments if you go hybrid?

If you’re weighing this up for your own infrastructure, our team can run the TCO numbers against your actual workload profile rather than a generic estimate — get in touch and we’ll give you a straight answer, including if that answer is “stay on cloud.”