Explainer

Three Landlords of the Internet: How the Cloud Got Consolidated

The word 'cloud' was a marketing triumph: it made a landlord sound like weather. In practice a small number of firms own the ground almost every app, service and government system now stands on — and set the rent for standing there.

The cloud monopoly is not really a monopoly, and that is the first thing worth being honest about. It is an oligopoly of three — Amazon Web Services, Microsoft Azure and Google Cloud — which by most recent industry estimates together take somewhere around two-thirds of global spending on cloud infrastructure services. Those numbers move every quarter and every analyst house counts slightly differently, so treat them as a shape rather than a measurement. But the shape has been stable for a decade, and it is the shape of a market where three firms own the ground everyone else builds on and set the terms on which the rest of us are allowed to stand there.

What I find remarkable is the word itself. “Cloud” is the single most successful piece of branding in the history of computing. It made a landlord sound like weather. Something atmospheric, ambient, free at the point of use, belonging to nobody in particular — when in fact what you are renting is a very specific machine, in a very specific building, owned by a very specific company, on terms that company writes and can revise. Every other industry would call this what it is: infrastructure with a small number of owners. We called it the sky.

How three companies came to own the ground

Concentration here was not a conspiracy. It was arithmetic, and understanding the arithmetic matters more than finding a villain.

Start with capital intensity. Building global cloud infrastructure means spending tens of billions a year, indefinitely, before you know whether the demand will show up. That is not a startup expense. It is closer to building a national grid, and it eliminates almost every possible competitor at the door. Only firms with enormous existing cash flows from something else — retail, enterprise software licences, advertising — could fund a decade of that. The cloud was not won by the best engineers. It was won by the companies that could afford to lose money on it longest.

Then economies of scale do their work. Once you operate at that size, your cost per unit of compute falls below anyone else's, your utilisation improves, your purchasing power over chips and power and land improves, and you can undercut smaller rivals while still earning a fat margin. Scale begets cheapness begets scale. A regional provider running honest, competent infrastructure simply cannot match the price, and the price is what most buyers look at.

And finally bundling, which is the least discussed and possibly the most decisive. The cloud is rarely sold as raw servers. It arrives attached to the identity system your company already uses, the office software your staff already open, the enterprise licence you already negotiated, the discount that applies only if you also buy this. When one vendor controls the software your organisation runs on, the cloud underneath it becomes the default rather than a decision. Regulators in the UK and Europe have spent the last couple of years circling exactly this — licensing practices that make a rival's cloud more expensive to choose — and it is telling that the software bundle, not the servers, is where the scrutiny has landed.

This is the same sequence I keep tracing whenever I look at how technology gets captured. Something genuinely liberating arrives — and the cloud genuinely was liberating; I could not have started anything without it — it lowers costs for everyone, it democratises access for a real and glorious period, and then the layer underneath consolidates and starts charging rent on the liberation.

What lock-in is actually made of

People talk about lock-in as if it were a contract clause you could negotiate away. It is not. It is structural, and it accumulates quietly over years of ordinary good decisions. Here is what it is actually made of.

  • Proprietary managed services. You did not just rent a machine. You built on the provider's database, its queue, its function runtime, its identity layer, its monitoring. Each of those is genuinely excellent and none of them exists anywhere else. The convenience is real, and the convenience is the trap.
  • Rewritten architectures. Leaving does not mean copying files across. It means redesigning how your system works, because your system was shaped around one vendor's primitives. That is a multi-year engineering programme with no new features at the end of it — the hardest project any executive will ever be asked to fund.
  • Retrained people. Your engineers hold certifications in one provider's tooling. Your hiring pipeline assumes it. Your runbooks, your deployment pipeline, your on-call culture all encode it. Skills are a switching cost that sits in human beings, and human beings cannot be migrated over a weekend.
  • Data gravity. The more data you store in one place, the more everything else wants to live next to it, because moving it is slow and computing on it remotely is worse. Data does not just sit still. It pulls.
  • Egress fees. Historically, providers charged you to read your own data out of their systems, while charging nothing to put it in. A one-way valve, priced. For a company with petabytes, the bill for leaving could exceed the savings from leaving, which is a neat definition of a market that does not clear.

Competition requires the ability to leave. When leaving costs more than staying, what looks like a market is really a tenancy with extra steps.

On that last point, honesty is required, because it has changed. Under sustained regulatory pressure — the EU's Data Act and the UK competition authority's cloud work being the sharpest edges — the major providers have all announced policies waiving data transfer charges for customers moving off their platforms, with further restrictions on switching charges scheduled to bite in the EU. The detail matters and deserves checking rather than assuming: several of these waivers apply specifically to one-way exits, sometimes requiring you to close the account, sometimes within a fixed window, and routine day-to-day egress for a customer who stays is a different question from exit egress for a customer who goes. The fee was the most visible obstacle and it has been substantially dismantled. The architectural lock-in underneath it has not been touched at all, and no regulator can waive that.

A chokepoint has a failure mode

Concentration does not only affect prices. It affects whether things work.

When a single region of a single provider failed in October 2025 — a DNS fault in one Amazon service that cascaded for most of a day — the consequences were not confined to that provider's customers. Payment apps, games, social networks, retail sites and workplace tools went down together, generating millions of outage reports, because they all turned out to be standing on the same slab. Most of those companies believed they were independent businesses. For a day they discovered they were one business with many logos.

This is the part that should worry us most, and it is not really a technology problem. In a diverse ecosystem, failures are frequent and small. In a concentrated one, failures are rare and enormous, and correlated across sectors that have no commercial relationship whatsoever. Your bank, your hospital's records system and your child's school portal can fail at the same instant for the same reason. We optimised for efficiency and bought fragility with the savings, and because the outages are infrequent we keep concluding that the arrangement is fine.

Governments are tenants too

The awkward fact is that the state is not outside this. Tax systems, welfare payments, health records, defence workloads and police databases increasingly run on the same three platforms — in the UK, reporting suggests the overwhelming majority of public sector bodies use them. A government that runs its core functions on infrastructure it does not own, operated under another country's legal jurisdiction, has quietly outsourced a piece of its sovereignty and mostly filed it as a procurement decision.

You can see the discomfort setting in. Europe has been building sovereignty requirements, jurisdictional risk tests for sensitive public contracts, and national “sovereign cloud” arrangements. The providers, to their credit, have responded with local operating models and European staffing. Whether that resolves the underlying issue is a genuinely open question, because the licences, the roadmap and the ability to withdraw access still sit with the owner. Data residency is not the same thing as control. Where your data physically rests is a question about the cloud is physical — land, power, water, buildings. Who can switch it off is a question about ownership, and they are not the same question.

The rent, and who collects it

Strip away the abstraction and this is a landlord economy. Three firms own the ground. Everyone else — startups, banks, hospitals, newspapers, governments, and now every AI company on earth — builds on rented land, pays monthly, and cannot easily move. The rent is collected in cash, but also in terms: the pricing you accept, the roadmap you depend on, the features you cannot have, the competitor you become the day your landlord enters your market.

That last one is worth sitting with. The AI boom has made the position stronger, not weaker, because the compute that trains and serves every model is rented from the same three landlords, who are frequently also investors in their tenants. I have written separately about the AI monopoly, and the honest summary is that it is largely the cloud oligopoly wearing a newer, more exciting hat.

Infrastructure that everything depends on and only three companies own is not a market. It is a toll gate with good uptime.

What would actually change it? Not much that is comfortable. Removing exit fees helps and was worth doing. Interoperability requirements — real ones, covering the managed services and not just the bytes — would help more, because they attack the architectural lock-in rather than its cheapest symptom. Procurement rules that require public bodies to keep genuine exit options, and to demonstrate them rather than describe them, would help enormously, because the state is the one customer large enough to move the market by choosing differently. Beyond that lie the structural questions I have explored in breaking up Big Tech, which are harder, slower, and increasingly difficult to avoid.

But the first step is smaller and costs nothing: stop calling it the cloud in our own heads. It is somebody's computers, in somebody's building, under somebody's terms, and the terms can change. Once you see the landlord instead of the weather, every other question about concentration, resilience and rent becomes a great deal easier to ask.

Kenney Jacob is the author of Captured, a history of who takes, who pays, and who fights back.

Frequently asked questions

Who controls the cloud?

The market is dominated by a small group — principally Amazon Web Services, Microsoft Azure and Google Cloud — which together have been reported to hold roughly two-thirds of global cloud infrastructure spending, with the rest split among many smaller providers. Exact shares move each quarter, so treat any figure as a recent estimate.

What is cloud vendor lock-in?

The difficulty of leaving a cloud provider once you are on it: proprietary managed services, rewritten architectures, retrained staff, and historically fees charged to move your own data out ('egress'). The result is a customer who can technically leave but practically cannot — which is what lets terms be adjusted in the provider's favour over time.

Why is cloud concentration a risk?

Because it turns competitive infrastructure into a chokepoint. Concentration creates systemic fragility — a single provider's outage can take down large parts of the economy at once — and it hands enormous pricing and governance power to a few firms, including over who gets served, at what price, and under what conditions.

← All articles