ExtraSysWork out the decision first. The vocabulary follows.
How a Hyperscaler's Datacentre Differs from Yours

FORK 01/Move it at all?/How a Hyperscaler's Datacentre Differs from Yours

How a Hyperscaler's Datacentre Differs from Yours

By the ExtraSys desk · Move it at all? · 3 min read

The differences are real and large. What they imply for your workload is a separate question.

The Physical Gap

A hyperscaler's datacentre is a different class of object from what most organisations operate, and pretending otherwise obscures an honest decision. The differences sit across four dimensions: power, cooling, network topology, and hardware refresh.

On power, a large hyperscaler facility draws hundreds of megawatts — some campuses exceed a gigawatt. More importantly, the redundancy architecture is deep. Multiple independent utility feeds, on-site generation with fuel reserves measured in days, uninterruptible power systems that can carry full load while generators start: the investment required to build and maintain this is, for most organisations, simply not available. A typical enterprise datacentre achieves Uptime Institute Tier III — concurrent maintainability, N+1 redundancy — and that is genuinely adequate for most workloads. Tier IV, fault-tolerant 2N redundancy, is rare and expensive to own. Hyperscalers design their own redundancy models and operate at a scale where they test failure modes that most enterprise facilities will never see.

Cooling follows a similar pattern. The hyperscalers have moved aggressively toward direct liquid cooling, rear-door heat exchangers, and — in newer facilities — immersion cooling for the densest compute. Power Usage Effectiveness figures at large hyperscaler facilities have improved steadily over the past decade. Most corporate datacentres are still running raised-floor air cooling designed around the assumptions of equipment from fifteen years ago.

Network topology is where the gap widens further. Inside a hyperscaler facility, the spine-and-leaf fabric connecting compute to storage to the wider backbone is built to eliminate the bandwidth bottlenecks that plague traditional three-tier switching architectures. They design their own switching silicon, run their own backbone, and interconnect their facilities with private fibre at scales that dwarf anything an enterprise network team manages. The available bandwidth between a virtual machine and attached storage, or between two instances in the same availability zone, is a product of that investment. You are tenanting a fraction of something enormous.

Hardware refresh cycles are the least-discussed advantage. A major provider replaces server generations on a cadence measured in years, not decades. Your datacentre probably has equipment that is seven to twelve years old because capital budget is scarce and migrations are painful. Newer silicon delivers better performance per watt, better memory bandwidth, and hardware mitigations for the vulnerability classes that have accumulated since Spectre and Meltdown in 2018. The hyperscaler absorbs that refresh continuously; the enterprise absorbs it episodically, and sometimes not at all.

A whiteboard covered in an architecture diagram mid-session — boxes, arrows, crossing-out, a dry-erase marker resting in the tray

What This Does and Does Not Mean for a Tenant

None of the above is an argument to move. It is context.

The physical capabilities are real, but they do not transfer uniformly to a tenant. When you rent a virtual machine, you are sharing physical hosts with other tenants, connected through a virtualised network that introduces its own latency and throughput ceiling. The hyperscaler's raw internal bandwidth does not fully materialise as your available bandwidth. The power redundancy protects the facility; it does not protect you from a control-plane failure, a botched deployment in the provider's management layer, or a software bug that takes down an entire availability zone while the power stays on. Understanding what an availability zone actually is matters here — the physical isolation is real, but its limits are not always where engineers assume.

If your on-premises estate runs old silicon, the performance-per-dollar comparison tilts toward cloud more than headline instance prices suggest.

The hardware refresh advantage is genuine and often underweighted. If your on-premises estate runs old silicon, the performance-per-dollar comparison tilts toward cloud more than headline instance prices suggest. But if your workloads are steady, well-understood, and sized correctly, the hyperscaler's refresh cycle benefits you less — because you could refresh your own hardware on a planned cycle and capture similar gains, at a cost that becomes competitive at sustained utilisation.

The honest summary: a hyperscaler's facility is better-engineered in almost every physical dimension than what most organisations can afford to build and operate. That engineering advantage is real at the facility level and partially real at the tenant level. It is not evenly distributed across all failure modes, and it does not answer the questions of cost, data sovereignty, latency, or operational fit. It is one input to the decision — a significant one — not the decision itself.