A Region Called Northern Virginia

At 9:37 in the morning, Pacific time, on 28 February 2017, an engineer on Amazon’s S3 storage team in the Northern Virginia region was investigating why the billing system was running slowly. Following an established procedure, the engineer typed a command meant to take a small number of servers out of service. One input was wrong, and far more servers were removed than intended, including some that supported two subsystems at the heart of S3, one that kept track of where every object was stored and one that decided where new ones would go. Both had to be restarted completely. They had not been fully restarted in years, and the region had grown enormously in the meantime, so the restart took hours. For about four hours, a large share of the websites and apps that stored their images, files and data in that region failed or slowed. Amazon’s own status page, which told customers whether its services were working, could not report the problem properly, because it too depended on S3 in Northern Virginia.¹

A single command, typed in one building complex in one American state, had reached into thousands of companies around the world that had never thought of themselves as depending on it. That is what the cloud is: the decision, made by millions of organisations one at a time, to rent computing from a few providers instead of owning it. The scale of that decision is now very large. Amazon Web Services alone reported revenue of $128.7 billion in 2025, and operating income of $45.6 billion.² In the third quarter of 2025, by Synergy Research Group’s estimate, companies spent $106.9 billion on cloud infrastructure services, and Amazon, Microsoft and Google together took 63 percent of it.³ The four largest technology companies spent about $410 billion on capital investment in 2025, much of it on data centres for artificial intelligence, and told investors to expect more than $700 billion in 2026.⁴

This essay follows how computing became a rented utility. It follows the decisions that shaped the cloud: Amazon’s choice to sell its plumbing, its rivals’ late entry, the companies and governments that moved onto it, and the discoveries that came after, that failures concentrate, that security remains the tenant’s job, that metered bills grow, that leaving costs money, that data has a nationality, and that the cloud is made of buildings, chips and electricity. Its deeper subject is dependence: what it means for organisations, and the people who rely on them, to build on machines they will never see, owned by companies whose decisions they cannot control.

Before the cloud: the computer utility

The idea is older than the machines that realised it. In April 1961, at a celebration of MIT’s centennial, the computer scientist John McCarthy predicted that “computing may someday be organized as a public utility just as the telephone system is a public utility,” with each subscriber paying only for the capacity they actually used.⁵ He was speaking at the start of time-sharing, when one large computer could serve many users at terminals, an arrangement described on this site in Machines Inside Machines. Through the 1960s, writers imagined a “computer utility” or “information utility”: central computing plants, connected to homes and offices by telephone lines, selling processing as power stations sold electricity. Service bureaus and time-sharing companies did sell computing time to businesses that could not afford a machine of their own.

The utility did not arrive, for practical reasons. Telephone lines were slow and expensive, central machines were costly to run, and from the late 1970s computers became cheap enough to own. The personal computer and then the company server room reversed the direction of the industry. For thirty years, computing meant buying machines, installing them in a building you controlled, and employing people to keep them running. The idea of a computer utility, as the encyclopaedias put it, was popular in the late 1960s and had faded by the mid-1990s.

Engineers, meanwhile, had a habit that would supply the name. When they drew diagrams of networks, they drew the parts they did not control, the telephone network and later the internet, as a cloud: a shape that meant “something happens in here, and we need not care how.” In late 1996 a group of executives at Compaq, the computer maker, wrote an internal strategy for selling servers to internet providers under the heading “cloud computing,” a phrase the MIT Technology Review traced in 2011 to a planner entry and a fifty-page document from November of that year.⁶ The term became common a decade later, after Eric Schmidt, Google’s chief executive, used it at an industry conference on 9 August 2006 to describe services and data that lived on the internet rather than on a user’s own machine. By then the thing it described had just begun to exist.

A bookshop’s plumbing

The cloud as it exists today was built by a company that sold books. By the early 2000s Amazon was a large online retailer whose engineers struggled with their own infrastructure. Teams that wanted to build something new spent much of their time arranging servers, databases and storage, and the company’s software had grown into a tangle in which teams reached directly into each other’s databases. According to a widely circulated account written years later by Steve Yegge, a former Amazon engineer, Jeff Bezos issued an instruction around 2002 that every team must expose its data and functions only through service interfaces, designed as if they might one day be offered to outsiders, and communicate with other teams only through them.⁷ Yegge’s account is a recollection, not a document, and is discussed on this site in Stevey’s Google Platforms Rant. Whatever its exact wording, Amazon spent those years turning its systems into services that other teams could call without talking to their owners.

In 2003 Chris Pinkham, who ran Amazon’s infrastructure engineering, and Benjamin Black wrote a short internal paper describing what a standardised, automated infrastructure might look like, built on web services. Near its end they suggested that Amazon might sell access to virtual servers to other companies. Around the same time, a team under Andy Jassy, who would later lead AWS and then Amazon itself, worked out what the first building blocks should be: storage, computing and databases.⁸ Pinkham, who wanted to return to his native South Africa, set up a small team in Cape Town that built the compute service, working, as one account puts it, in an office full of patio furniture. Brad Stone’s history of Amazon, The Everything Store (2013), describes how unusual the project looked inside a retailer and how many executives doubted it.

A popular story holds that Amazon was selling spare capacity left over from the holiday season. Accounts of the project’s origins reject that story. The point was not to rent idle machines but to build a separate business on purpose, with its own hardware, sold as simple, general building blocks that customers could combine. On 14 March 2006 Amazon launched Simple Storage Service, S3, which stored any amount of data and charged by the gigabyte per month. In August it opened Elastic Compute Cloud, EC2, which rented virtual servers by the hour.⁸ There was no contract and no salesperson. A developer with a credit card could start a server in minutes and switch it off when finished.

Three choices in that launch shaped everything that followed. The services were primitives, small and general, not a finished platform for a particular kind of application; customers had to assemble them, which made them harder to use and far more flexible. They were priced by use, so a start-up paid a few dollars to try an idea and a large company paid for exactly what it consumed. And they were offered to everyone on the same terms, so the smallest developer could use the same infrastructure as the largest. The trade-off was that customers had to take on the work of designing reliable systems from unreliable parts. Amazon did not promise that any individual server would stay up. It promised the means to build things that survived when servers failed.

The rivals arrive late

Google and Microsoft had the engineering to build clouds and were slow to sell them. Google’s first offering, App Engine, previewed on 7 April 2008, took the opposite approach to Amazon’s. Instead of renting raw machines, it ran a developer’s web application on Google’s infrastructure and handled scaling automatically, but only for programs written in Python and only for the first 10,000 developers to sign up.⁹ It was easier to use and much more restrictive, and it attracted far fewer large customers than Amazon’s primitives.

Microsoft’s position was more awkward. Its profits came from software licences: Windows, Office and server products installed on customers’ own machines. A utility that rented computing threatened to make those licences less necessary. On 27 October 2008, at its developer conference, Ray Ozzie, Microsoft’s chief software architect, announced Windows Azure, a cloud platform. One live blog of the event judged that Microsoft was well behind what Amazon and others already offered.¹⁰ Under Satya Nadella, who became chief executive in 2014, Microsoft reorganised around the cloud, and it had an advantage Amazon lacked: long relationships with the information technology departments of almost every large organisation, and the software they already ran. It sold Azure through those relationships, often alongside the licences.

That advantage later drew scrutiny. In its final decision on the cloud market in July 2025, Britain’s Competition and Markets Authority found that Microsoft’s licensing practices harmed competition, particularly for customers who wanted to run Microsoft software on rival clouds.¹¹ By then Azure was the second-largest cloud in the world, and Google Cloud the third.

Betting on a rival’s servers

The most consequential early customer was Netflix. In August 2008 a major database corruption in its own data centre stopped Netflix from shipping DVDs to its members for three days. The company concluded that it was not good at running data centres, that its new streaming service would grow faster and more unpredictably than any data centre it could build, and that it should move its computing onto AWS, owned by a company that also sold video. The migration took seven years. In early January 2016 Netflix announced that it had shut down the last data centre equipment used by its streaming service.¹²

The decision mattered for the rest of the industry because of how Netflix did it. It did not trust the cloud to be reliable. It assumed that any server, and eventually any data centre, could fail at any moment, and it wrote software that kept working when they did, testing this by deliberately switching off its own servers in production. Its engineers published their tools and methods, which spread across the industry. Netflix showed that a large consumer business could run on rented infrastructure, and that the price of doing so was to design for failure everywhere.

The government moves in

Governments followed the companies, with larger stakes. In 2013 the CIA awarded Amazon a contract to build a private cloud for the intelligence community, reported to be worth up to $600 million. IBM protested, and the Government Accountability Office upheld part of the protest before Amazon won in court.¹³ In October 2019 the Pentagon awarded its Joint Enterprise Defense Infrastructure contract, JEDI, worth up to $10 billion, to Microsoft rather than Amazon, which had been considered the favourite. Amazon challenged the award in court, and the Pentagon cancelled JEDI in 2021 and replaced it in December 2022 with the Joint Warfighting Cloud Capability, a $9 billion arrangement shared among Amazon, Google, Microsoft and Oracle.¹³ The shift from one provider to four reflected a lesson the commercial world was learning too: depending on a single cloud is a risk in itself.

Functions without servers

The cloud kept raising its level of abstraction. In November 2014 Amazon introduced Lambda, a service that ran a piece of code in response to an event, such as a file being uploaded, and charged only for the milliseconds it ran.¹⁴ The customer no longer chose, sized or even saw a server. The industry called this serverless computing, a misleading name for computing in which the servers had become someone else’s problem entirely. Containers, managed databases and later managed AI models followed the same direction. Each step removed work from customers and, with it, knowledge of how their systems actually ran, and each step tied them more closely to the provider whose services they used.

Shared responsibility

From the start, cloud providers drew a line between what they secured and what customers did. Amazon calls it the shared responsibility model: the provider secures the physical buildings, the hardware and the software that runs the cloud, and the customer secures what it puts in the cloud, including its data, its access rights and the configuration of every service it uses. The line was clear on paper. In practice, the customer’s side included hundreds of settings across dozens of services, many of them created by developers who were not security specialists, and a single wrong setting could make private data public.

The most expensive demonstration came at Capital One, one of the first large American banks to commit to the public cloud. In 2019 an intruder, a former AWS employee, exploited a misconfigured web application firewall in Capital One’s cloud environment, used it to obtain credentials, and copied data on about 106 million people in the United States and Canada, including some Social Security numbers. AWS’s infrastructure was not breached. In August 2020 the Office of the Comptroller of the Currency fined the bank $80 million, finding that it had failed to establish effective risk assessment before moving significant technology operations to the public cloud. The bank later agreed to pay $190 million to settle a class action, while it and AWS denied liability.¹⁵

Capital One was not alone. Researchers repeatedly found storage buckets left open to the internet, holding records of voters, patients and customers. The analyst firm Gartner predicted in 2019 that through 2025, 99 percent of cloud security failures would be the customer’s fault, a claim widely repeated though rarely tested.¹⁶ The model put responsibility exactly where control lay. It also spread that responsibility across so many people and settings that, in many organisations, no one held all of it.

When Northern Virginia sneezes

The 2017 outage was not the last. AWS’s oldest region, US-East-1 in Northern Virginia, remained its largest, and many global services depended on systems there. In the early hours of 20 October 2025, a latent fault in the automated system that managed the internet addresses for DynamoDB, Amazon’s database service, left the regional endpoint without valid addresses. The database became unreachable, then the failure spread to the systems that launched new servers and to network load balancers. AWS identified the cause within hours, but errors in launching servers continued until early afternoon, and some services took longer to clear their backlogs. Messaging apps, games and banking services failed around the world.¹⁷ Nine days later, on 29 October, a configuration change to Azure Front Door, Microsoft’s global system for routing web traffic, slipped past safety checks because of a software defect and disrupted Microsoft 365, Xbox and thousands of other services for about eight hours.¹⁸

Each provider published detailed accounts and described fixes: splitting systems into smaller, independent cells, adding checks to automated changes, removing hidden dependencies on a single region. The outages were rare, given the scale of the services. But they showed a property of the cloud that individual customers could not see from their own contracts. A company that chose AWS or Azure for reliability, and spread its systems across several data centres within a region, could still fail because a provider’s shared systems failed, along with its competitors, suppliers and customers, all at once.

The meter keeps running

The cloud’s pricing was its great attraction: no up-front cost, pay for what you use. It turned out that organisations used a great deal. Developers could start servers without asking anyone, forget to stop them, store data indefinitely and move it between services that each charged for traffic. The bills arrived monthly, long after the decisions that caused them, often aggregated across thousands of resources. In Flexera’s 2025 survey of more than 750 technology professionals and executives, 84 percent named managing cloud spending as their top cloud challenge, and respondents estimated that about 27 percent of their cloud spending was wasted; the 2026 edition put waste at 29 percent, the first increase in five years, which Flexera attributed to the costs of AI.¹⁹ A profession, called FinOps, grew up to watch the meter.

For some companies the arithmetic eventually favoured owning. In May 2021 Sarah Wang and Martin Casado of the venture capital firm Andreessen Horowitz published “The Cost of Cloud, a Trillion Dollar Paradox,” arguing that for large software companies, cloud costs had become a large share of the cost of their products, and that bringing steady workloads back in-house could cost a third to a half as much.²⁰ Dropbox had already done so. From 2015 it moved most of its file storage off S3 onto its own system, Magic Pocket, and its 2018 filing to go public credited the change with tens of millions of dollars of lower infrastructure costs.²¹ 37signals, the small company behind the Basecamp project-management software, later made the same choice; its co-founder David Heinemeier Hansson reported in 2024 that its annual cloud bill had fallen from about $3.2 million to $1.3 million, and in 2025 that it was deleting its AWS account after moving its last stored data onto hardware it owned.²² These are participants’ accounts, and the cases are not typical: both companies ran large, steady workloads with skilled engineers. For variable workloads and smaller firms, renting usually remained cheaper and much simpler.

The price of the door

Leaving a cloud is harder than joining one. Providers charged little or nothing to bring data in and charged by the gigabyte to take it out, fees known as egress charges. Customers who built on a provider’s own databases, queues, identity systems and AI services found that moving meant rewriting software and retraining staff, whatever the fees. Licensing terms could make the same software more expensive to run on a rival’s cloud.

Regulators moved against these barriers. The EU’s Data Act, which entered into force in January 2024 and applied from September 2025, requires cloud providers to make switching possible and to phase out charges for it; from 12 January 2027, switching charges, including data egress fees, must disappear entirely, though fees for ordinary data transfer between clouds used in parallel may continue at cost.²³ Major providers had already announced that they would waive egress fees for customers leaving. In Britain, the Competition and Markets Authority’s final decision of 31 July 2025 found that competition in cloud services was not working well, that AWS and Microsoft each held between 30 and 40 percent of British cloud spending, and that egress fees and Microsoft’s licensing practices harmed customers. It recommended investigating both firms under its new digital markets powers.¹¹ In March 2026 it instead accepted voluntary commitments from the two companies on cloud, and in May opened an investigation into Microsoft’s business software, which would also examine cloud licensing.²⁴

Whose law reaches the data

A cloud server sits in a particular country, and the data on it is subject to that country’s laws. It is also held by a company subject to the laws of its home country. In 2013 US prosecutors served Microsoft with a warrant for emails stored on a server in Ireland. Microsoft refused, arguing that a US warrant could not reach data abroad, and won in the federal appeals court. While the case was before the Supreme Court, Congress passed the Clarifying Lawful Overseas Use of Data Act, the CLOUD Act, signed on 23 March 2018, which requires US providers to disclose data within their “possession, custody, or control” wherever it is located, and allows agreements with other countries for reciprocal access. The Supreme Court dismissed the case as moot on 17 April.²⁵

For European customers, the law confirmed what they had feared. On 16 July 2020, in the case known as Schrems II, the EU’s Court of Justice struck down the Privacy Shield, the arrangement that let companies transfer personal data to the United States, finding that American surveillance law did not give Europeans adequate protection. A successor, the EU–US Data Privacy Framework, was adopted in 2023 and upheld by the EU’s General Court on 3 September 2025, though an appeal to the Court of Justice remained possible.²⁶ In June 2025 Anton Carniaux, the legal director of Microsoft France, told a French Senate inquiry under oath that he could not guarantee that French citizens’ data would never be handed to US authorities without French approval, while adding that such a demand had never occurred.²⁷ The same year, reports that the email account of the International Criminal Court’s chief prosecutor had been cut off after US sanctions against him, which Microsoft denied causing, led the court to begin moving its staff to openDesk, a European open-source suite.²⁸

The providers answered with “sovereign” clouds. On 15 January 2026 AWS opened its European Sovereign Cloud in Brandenburg, Germany, physically and logically separate from its other regions and run by staff in the EU, part of a €7.8 billion investment through 2040.²⁹ Whether a separately operated subsidiary of an American company can be placed beyond American legal reach is a question lawyers continue to debate.

The AI build-out

The arrival of large AI models changed the cloud’s economics. Training and running them requires vast numbers of specialised chips, mostly from Nvidia, in buildings with enormous power supplies, and only a few companies could build them fast enough. Microsoft’s partnership with OpenAI made Azure the main supplier of computing to the most prominent AI company; in January 2025 the arrangement was loosened to give Microsoft only a right of first refusal, and in October 2025, when OpenAI restructured, that right was removed in exchange for a commitment by OpenAI to buy a further $250 billion of Azure services. On 3 November 2025 OpenAI signed a seven-year, $38 billion agreement for computing from AWS.³⁰ AI firms became some of the largest cloud customers, and cloud providers became some of the largest investors in AI firms.

The investment showed in the providers’ accounts. The four largest technology companies spent about $410 billion on capital investment in 2025, and their guidance for 2026 rose above $700 billion.⁴ The International Energy Agency projected in April 2025 that electricity demand from data centres worldwide would more than double by 2030, to around 945 terawatt-hours, with data centres accounting for nearly half of the growth in electricity demand in the United States.³¹ The cloud, which had sold itself as weightless, was now among the largest buyers of land, chips, water and power in the world.

What cloud computing is today

Today the cloud is the default way to run software. Most new applications are built on rented infrastructure from three American providers, AWS, Microsoft Azure and Google Cloud, with Oracle, Alibaba and specialist providers of AI computing behind them. Customers rent raw servers and storage, managed databases, analytics, identity systems and AI models, paid by the second, the request or the token, from regions spread across dozens of countries. Large organisations use several providers at once and keep some workloads in their own data centres. Regulators in Europe and Britain are reshaping the terms on which customers can leave. Governments ask where data is stored and whose law reaches it. And the largest providers are spending more on physical construction than almost any companies in history, betting that demand for AI will keep growing.

How the cloud changed what it means to have a computer

From owning machines to renting capacity

Computing became an operating expense rather than an investment. A start-up could launch with no hardware at all, and a large company could add a thousand servers for an afternoon. The decision to buy computing became thousands of small, continuous decisions made by developers.

From knowing your systems to trusting a provider’s

Each layer of abstraction removed work and knowledge. Organisations that once understood every machine they ran now depend on systems whose internals they cannot see, documented by status pages and incident reports written by the provider.

From local failures to shared ones

When each company ran its own data centre, failures were independent. Now many companies fail together when a shared provider fails, and the risk that each customer judged acceptable adds up to a risk for whole economies.

From a fixed bill to a running meter

The cost of computing became a variable that rises with every decision anyone makes, which made experiments cheap and waste easy, and turned cost control into a permanent discipline.

From a machine in a building to data with a nationality

The question of where computing happens became a question of law and politics, as states asked which governments could reach the data of their citizens and their institutions.

What the history suggests

The history repeats patterns seen across this site. Abstraction won, as small, general building blocks sold by the hour beat complete platforms and private data centres for most uses. Distribution beat design, as Microsoft caught up with a rival that had a two-year lead by selling through relationships it already had. Making something cheap moved the cost elsewhere: the low entry price of the cloud moved costs into monthly bills, into the work of configuration and into the price of leaving. Compatibility became gravity, as data and code built on one provider’s services became difficult to move. Permissive defaults were borrowed time, as storage left open and configurations left loose exposed data at scale. And the pendulum swung between central and personal machines, back toward central computing plants of the kind McCarthy imagined, now owned by a handful of companies.

The cloud also shows something more particular. It succeeded because it let each organisation stop worrying about something it had never wanted to worry about, and it concentrated that worry in a few companies that could handle it better than anyone else. That concentration is the source of the cloud’s efficiency and of its fragility, its security and its new risks, its abundance and its dependence. What it means to rely on infrastructure that one cannot see, cannot inspect and cannot easily leave is where the philosophy begins.

Understanding the philosophy

The rest of this essay examines eight ideas beneath cloud computing, one at a time. Each is explained in plain terms, placed in the tradition of thought that has examined it, traced in the history above, tested against its strongest objection and related to how people and organisations decide today. Two of them are psychological. The connections to philosophers, sociologists, economists, psychologists, lawyers and engineers are interpretations offered to make the ideas clearer. The people who built and regulated the cloud were solving practical problems, and did not, as a rule, set out to answer these thinkers.

1. Infrastructure is what you notice when it breaks

The idea in plain terms

The best infrastructure disappears. Nobody thinks about the water main while drinking from a tap, or about the power grid while switching on a light. The cloud was designed to disappear in the same way: developers call a service and never think about the building it runs in. That disappearance is what makes infrastructure useful, and it is also what makes dependence on it hard to see until the moment it fails.

The tradition

In 1996 the sociologists Susan Leigh Star and Karen Ruhleder published “Steps Toward an Ecology of Infrastructure,” a study of the networked software that a community of biologists used to share research. They argued that infrastructure is not a thing but a relation: something becomes infrastructure for a particular person doing a particular task, when it sinks into the background of their work. They listed its properties. Infrastructure is embedded in other structures and social arrangements. It is transparent in use, supporting tasks without having to be reinvented each time. It is learned as part of belonging to a community, so that newcomers find it strange and members do not see it at all. It is built on an installed base and inherits that base’s limits. And it becomes visible upon breakdown: the server is down, the bridge washes out, the power fails, and suddenly everyone sees what they had been standing on. In a later essay, “The Ethnography of Infrastructure” (1999), Star urged researchers to study the boring things, the standards, cables and forms, because so much of social life is organised through them.

Star drew on an older philosophical observation. In Being and Time (1927), Martin Heidegger distinguished between a tool in use, which withdraws from attention as the user concentrates on the work, and a tool that has broken, which suddenly presents itself as an object to be examined. A hammer is invisible while it drives nails and conspicuous when its head flies off. Star’s point was that the same is true of whole systems shared by millions, and that the invisibility is not a natural fact but an achievement, maintained by people whose work is also invisible.

Where it shows up

Amazon’s first services were designed to be invisible: a developer stored an object or started a server without knowing which building, rack or disk was involved. Lambda went further, hiding the server altogether. The breakdowns made the infrastructure visible in Star’s exact sense. On 28 February 2017, companies that had never thought about Northern Virginia discovered that their images, files and apps lived there, and Amazon’s status page, itself built on the invisible service, could not report its own failure. In October 2025 people trying to use banking apps and games learned the name of a database service they had never heard of. Each outage produced a burst of public attention to the cloud’s concentration, which faded as the services returned.

The strongest objection

It can be argued that invisibility is the whole point, and that it is good. People are better off not thinking about the grid or the water main, and organisations are better off not thinking about servers. Infrastructure that demanded constant attention would have failed at its job. Breakdowns are rare, and attention after a breakdown leads to fixes. This is correct as far as it goes. The difficulty is that invisibility also hides dependence from the people who should be managing it: the board that does not know which provider its business rests on, or the regulator that discovers after an outage that half the banks share one region. What should be invisible to users need not be invisible to those responsible for them.

What it means today

Organisations should make their infrastructure visible to themselves before it breaks. That means mapping which services, regions and suppliers each product depends on, including the dependencies of suppliers, and testing what happens when they fail, as Netflix did by deliberately switching off its own servers. Leaders should treat a provider’s outage report as a description of their own system. And anyone who builds infrastructure for others should remember that the people who keep it running are part of it, and that their work is invisible for the same reason the infrastructure is.

2. Robust yet fragile

The idea in plain terms

The cloud is far more reliable than most companies’ own data centres. It survives failed disks, failed servers and even failed buildings every day without anyone noticing. Yet when it does fail, it fails for many people at once. These two facts are connected. The same design choices that make a system resistant to the failures its designers expected can make it vulnerable to the rare ones they did not.

The tradition

In the late 1990s the physicist Jean Carlson and the engineer John Doyle proposed a theory they called highly optimised tolerance. Complex systems built or evolved to perform well, they argued, become highly structured and specialised to cope with the disturbances they commonly face. That makes them robust to those disturbances and fragile to unexpected ones, and their failures follow heavy-tailed patterns: many small failures, and occasionally a very large one. In “Complexity and Robustness” (2002) they described such systems as “robust yet fragile,” and later work by Doyle and David Alderson argued that complexity itself, added to create robustness, becomes a source of new fragility.

Herbert Simon had made a related point in “The Architecture of Complexity” (1962). He argued that complex systems that last tend to be nearly decomposable: built from parts whose internal connections are much stronger than the connections between them, so that a disturbance in one part stays mostly inside it. Andrew Haldane, then at the Bank of England, applied similar ideas to finance in a 2009 speech, “Rethinking the Financial Network.” The global banking system, he argued, had become more connected and more concentrated, which made it more resilient to small shocks, because losses were shared, and more fragile to large ones, because connections spread them everywhere. Regulators, he suggested, should look at the network, not just at each bank.

Where it shows up

Cloud providers designed for the failures they expected. Data was copied across several data centres within a region, and customers were told to spread their systems across them, so a fire or power cut in one building would not be noticed. That design worked. The large outages came from a different kind of failure, in shared control systems that sat above the separated buildings: the S3 index subsystem in 2017, the automated system managing DynamoDB’s addresses in 2025, the global routing layer of Azure Front Door. Each was a point where the structure was not decomposable, where a fault crossed boundaries because many things depended on the same thing. The providers’ responses, splitting systems into smaller cells and isolating regions, were Simon’s prescription applied after the fact. On the customers’ side, the concentration of the market made the network fragile in Haldane’s sense: the more companies shared one provider and one region, the more a single fault became a common shock.

The strongest objection

A harder point is that the comparison flatters the alternative. Before the cloud, companies suffered outages all the time, and they rarely made the news because each affected only one firm. Averaged across customers, cloud availability is much higher than what most organisations achieved alone, and Netflix showed that customers who design well can survive even regional failures. Concentrated failures are visible, while dispersed ones are not, so the cloud’s fragility is overstated. This is a strong point, and for most individual firms the cloud is the more reliable choice. The concern is systemic. When banks, hospitals, airlines and payment systems fail together, the cost is larger than the sum of their separate outages, because they cannot cover for one another. That is why European financial regulators, under rules applying from January 2025, began bringing the largest technology suppliers to banks under direct oversight.

What it means today

For individual organisations, the lesson is to look for shared dependencies as well as redundant copies. Spreading systems across data centres in one region protects against a fire, not against a fault in the region’s control systems; critical services need a plan for losing a region or a provider. For providers, the lesson is Simon’s: keep the connections between parts weaker than the connections within them, and find the hidden links before a failure does. For regulators, it is Haldane’s: the risk lies in the network, and it should be measured there.

3. The meter and the mind

The idea in plain terms

The cloud charges for exactly what is used, which seems the fairest and most efficient way to pay. But people do not experience costs as an economist would. How a bill is presented, when it arrives and who sees it change how much is spent. Metered computing, paid monthly by an organisation for resources started by its developers, separates the decision to spend from the experience of paying, and that separation has predictable consequences.

The tradition

Richard Thaler, the economist who later won the Nobel prize for work in behavioural economics, introduced the idea of mental accounting in 1985. People do not treat money as interchangeable. They sort it into mental accounts, judge spending against the account it comes from, and feel costs differently depending on how they are grouped and timed. Drazen Prelec and George Loewenstein, in “The Red and the Black” (1998), showed that the pain of paying depends on how closely payment is tied to consumption. When payment is “decoupled” from use, as with a prepaid holiday or a credit card, people consume more freely, because they no longer feel each unit as a cost. This site’s essay Paying a Stranger discusses the pain of paying in another context.

Anja Lambrecht and Bernd Skiera, studying customers of an internet provider in 2006, found a related bias pointing the other way. Many customers chose flat-rate plans even when paying by use would have been cheaper, a flat-rate bias that persisted over time. Among the causes they identified was what they called the taximeter effect: people dislike watching a meter run, because every moment of use then feels like a cost, and they will pay extra not to see it.

Where it shows up

The cloud combined both effects in a way no one designed. For the developer starting a server, storing data or calling an AI model, consumption was entirely decoupled from payment: there was no price at the moment of use, and the bill went to someone else weeks later. Thaler and Prelec’s work predicts generous consumption, and that is what Flexera’s surveys report: most organisations naming cloud spending as their top challenge, and around a quarter or more of spending judged to be waste. For the finance department receiving the bill, the meter ran visibly and unpredictably, which is exactly what Lambrecht and Skiera’s customers would pay to avoid. Organisations responded by buying commitments, reserved capacity and savings plans, paying in advance for a fixed amount of use, turning the metered utility back into something close to a flat rate. The a16z argument and the departures of Dropbox and 37signals were, in part, decisions to stop watching the meter.

The strongest objection

Others point out that this is a story about poor management, not psychology. Organisations that tag their resources, show developers what they cost and review bills regularly control their spending well; the waste figures come from self-reported surveys by a firm that sells cost-management software; and some waste is simply the price of speed, since a developer who waits for budget approval before starting a test server is slower and no cheaper. All of this is fair, and FinOps exists because good management works. But the need for an entire profession to restore the link between spending and the people who spend is itself evidence of the effect. The design of the pricing, not the carelessness of the customers, created the gap that management has to close.

What it means today

Put prices where decisions are made. Show developers the cost of what they start, at the moment they start it, and give teams budgets they can see. Distinguish experiments, where spending freely is the point, from steady workloads, where the meter should be watched or replaced by a commitment. And when designing pricing for one’s own customers, remember that metering is not neutral: it shapes how much people use, how they feel about the bill, and whether they stay.

4. Everyone’s responsibility, and no one’s

The idea in plain terms

The shared responsibility model divides security between provider and customer. On the customer’s side, responsibility is divided again, among developers, operations staff, security teams and suppliers, each of whom can change settings that expose data. When responsibility is spread across many people, each feels less of it. That is not carelessness. It is one of the most studied effects in social psychology.

The tradition

In 1968 the psychologists John Darley and Bibb Latané published a study in the Journal of Personality and Social Psychology prompted by the murder of Kitty Genovese in New York, which newspapers had reported, inaccurately as later research showed, as witnessed by dozens of neighbours who did nothing. In their experiment, students talking over an intercom heard another participant apparently having a seizure. Those who believed they were the only listener almost always went for help, and quickly. Those who believed several others could also hear were much slower and less likely to act. Darley and Latané called the mechanism diffusion of responsibility: when others are present, each person’s share of the obligation feels smaller, and each assumes someone else will act.

The effect has a mixed but substantial record. A 2011 meta-analysis by Peter Fischer and colleagues, in Psychological Bulletin, confirmed it across many studies, while finding that it weakened when the emergency was clearly dangerous, perhaps because danger made the need for action unmistakable. The psychologist Albert Bandura later described diffusion of responsibility as one of the ways people disengage from the moral consequences of what they do within organisations: when a task is divided, no one feels they did the harmful thing.

Where it shows up

Capital One’s breach began with a single misconfigured firewall, in an organisation with large security and technology teams, operating under a model that clearly assigned the configuration to the customer. The regulator’s finding was about process: the bank had moved quickly without effective risk assessment, which is the organisational form of everyone assuming someone else has checked. The open storage buckets found by researchers year after year followed the same pattern. A developer created a bucket for a short project, made it public to share a file, and moved on; the security team assumed developers followed policy; the provider assumed the customer’s settings were intentional. Gartner’s prediction that almost all cloud security failures would be the customer’s fault was, read this way, a statement about diffusion more than about competence. The danger in a cloud configuration is rarely obvious, which is the condition in which Fischer’s meta-analysis found the effect strongest.

The strongest objection

Then again, the model is not ambiguous at all, and blaming psychology excuses negligence. Providers publish exactly what customers must secure, offer tools that scan for exposed resources, and in recent years have made new storage private by default. Organisations that assign clear owners and enforce policies with automated checks do not suffer these breaches. That is true, and it shows the remedy. But the remedy works precisely because it counteracts diffusion: it names one owner, removes the need for anyone to notice, and makes the safe setting the default. The objection describes what works without explaining why the failures were so common.

What it means today

Assign every resource and every setting a named owner, and make ownership visible. Make the safe configuration the default and the exception require deliberate effort, as the choice architecture discussed on this site in The Architecture of Choice suggests. Use automated checks so that safety does not depend on anyone noticing. And be wary of any arrangement, internal or contractual, in which responsibility is described as shared without saying exactly who will act when something goes wrong.

5. Whose law reaches the data

The idea in plain terms

The modern state claims authority over a territory: what happens within its borders is subject to its laws. Data in the cloud has a location, in a particular building in a particular country, and it is also controlled by a company that answers to the laws of its home country, and can be copied anywhere in an instant. When the place of the server, the nationality of the company and the citizenship of the person the data describes all differ, the old idea of territorial sovereignty no longer gives a clear answer.

The tradition

The idea of sovereignty was set out by the French jurist Jean Bodin in Six Books of the Commonwealth (1576), who defined it as the absolute and perpetual power of a commonwealth, and it became the organising principle of European states after the Peace of Westphalia in 1648, which is associated with the principle that each state governs its own territory without outside interference. The political scientist Stephen Krasner, in Sovereignty: Organized Hypocrisy (1999), argued that this principle has always been violated in practice. He distinguished four meanings of sovereignty: a state’s control within its borders, its control over what crosses them, its recognition by other states, and the exclusion of outside authority from its internal affairs. Powerful states, he showed, routinely intrude on weaker ones while affirming the principle.

The legal scholar Jennifer Daskal argued in “The Un-Territoriality of Data” (2015), in the Yale Law Journal, that data breaks the link between location and authority on which territorial law depends. Data moves constantly, is often divided across countries, and is stored wherever a company’s engineers find it efficient, so its location says little about whose interests it touches. Tying legal authority to the place a server sits, she argued, produces arbitrary results.

Where it shows up

The Microsoft Ireland case put Daskal’s problem before the Supreme Court: whether an American warrant could reach emails that happened to be stored in Dublin. Congress answered with the CLOUD Act, which replaced the location of the server with the control of the company, a choice that solved the arbitrariness Daskal described by asserting American authority over everything American companies held. Europe answered from the other side. The Schrems II judgment held that personal data could not simply flow to a country whose surveillance law lacked adequate protections, and the testimony of Microsoft France’s legal director confirmed that a European location did not place data beyond American reach. The International Criminal Court’s move to European software, after disputed reports about its prosecutor’s email, showed sovereignty in Krasner’s fourth sense, the fear of outside authority inside an institution’s own operations. Sovereign clouds were the industry’s attempt to rebuild territory inside a global network.

The strongest objection

Some argue that “data sovereignty” often serves other purposes. It can protect national providers from foreign competition, justify governments’ own surveillance of data kept within reach, and fragment a global network in ways that make services slower and more expensive for everyone. Law enforcement also has a legitimate need to reach evidence of crimes, wherever a company happens to store it, and the CLOUD Act’s provision for agreements between countries tries to meet that need. These points are strong, and European governments are not neutral defenders of privacy. But the objection does not remove the asymmetry: a few countries’ companies hold most of the world’s data, so a few countries’ laws reach it, and others have little say.

What it means today

Organisations should know which governments can compel access to their data, through the location of the servers and the nationality of every provider and subprovider. Sensitive data may need encryption with keys the provider does not hold, or providers outside the reach of a particular jurisdiction. Governments should be honest about which aim they are pursuing, privacy, security or industrial policy, because the measures differ. And anyone building global services should expect the question of whose law applies to become harder, not easier.

6. The price of the door

The idea in plain terms

It is easy to start using a cloud and hard to stop. Every database, queue and AI service a company builds on, every script its engineers write for one provider’s tools, and every certification its staff earn makes leaving more expensive. Economists call these switching costs, and they describe a market in which competition is fierce for new customers and weak for existing ones.

The tradition

In Information Rules (1998), the economists Carl Shapiro and Hal Varian described what they called the lock-in cycle. A customer chooses a product, invests in using it, becomes entrenched as the investment grows, and faces switching costs when a rival appears. Sellers, they explained, compete to win customers at the start of the cycle, often at a loss, expecting to recover the cost from locked-in customers later. They advised buyers to anticipate lock-in before choosing, by bargaining for terms that would make leaving possible.

The economist Oliver Williamson explained why such investments create power. When one party makes investments that are valuable only within a particular relationship, which he called asset-specific investments, the other party can exploit them by renegotiating terms once the investment is made, a problem known as hold-up. This site discusses his work on why firms make some things and buy others in Why Firms Exist, and the broader dynamics of lock-in in Path Dependence and Lock-In.

Where it shows up

The cloud’s pricing followed Shapiro and Varian’s cycle closely. Bringing data in cost little or nothing; taking it out was charged by the gigabyte. Free credits brought start-ups in at the beginning, when they chose a provider without thinking about leaving. Over time, customers adopted each provider’s own managed services because they were convenient and well integrated, and every adoption was an asset-specific investment in Williamson’s sense. Britain’s competition authority found that egress fees and Microsoft’s licensing terms raised the cost of switching and of using several clouds. The EU’s Data Act attacks the most visible part of the cost, the fees, by abolishing switching charges from 2027. The customers who left, Dropbox and 37signals, did so by rebuilding systems on their own hardware, which shows what leaving actually requires.

The strongest objection

There is a reply: lock-in is the price of using good services, and customers accept it knowingly. A managed database is valuable precisely because it is integrated with the rest of a provider’s tools; a perfectly portable cloud would offer only the lowest common denominator. Competition for new workloads is intense, prices for basic computing and storage have fallen over the years, and the providers’ willingness to waive egress fees for departing customers suggests that switching costs were not their main defence. These points have force. But Williamson’s insight applies regardless of intent: once a customer has built around a provider, that provider’s prices and terms matter more than any competitor’s, and the customer’s bargaining power has gone.

What it means today

Price the exit at the entrance. Before adopting a provider’s distinctive service, ask what it would cost to move away from it and whether the convenience is worth that cost. Keep the most valuable data in formats and systems that can be moved. Use the provider-specific services where they add the most value and portable ones elsewhere. And negotiate the terms of leaving while the provider still wants your business, because that is when Shapiro and Varian’s cycle gives the buyer power.

7. A cloud made of buildings

The idea in plain terms

“The cloud” suggests something light, distant and everywhere, data floating free of the ground. In reality it is a set of buildings: warehouses full of computers in specific places, drawing electricity from specific grids and water from specific rivers, connected by cables under streets and seas. The name hides what it names, and what a technology is called shapes what people think about when they decide how to use it.

The tradition

In Metaphors We Live By (1980), the linguist George Lakoff and the philosopher Mark Johnson argued that metaphor is not decoration but a basic structure of thought. People understand abstract things through concrete ones: argument as war, time as money, ideas as objects. Each metaphor highlights some features of what it describes and hides others, and people reason within the metaphor without noticing it. A metaphor that is never questioned becomes a set of assumptions.

The media scholar Tung-Hui Hu, in A Prehistory of the Cloud (2015), applied this to computing. He traced how the cloud grew out of older networks and older institutions, and argued that its imagery of weightlessness obscured both its physical form and the forms of power, security and control built into it. To call computing a cloud, on his account, is to invite people not to ask where it is or who owns it.

Where it shows up

The name came from engineers’ diagrams, where a cloud meant the part of the network that was someone else’s concern. It spread as a marketing term because it suggested ease and abundance. For years the metaphor fitted the experience of customers, who saw an online console and never a building. The AI build-out made the material cloud visible again. Its owners’ spending on construction, chips and power rose into the hundreds of billions of dollars a year, the International Energy Agency projected that data centres’ electricity demand would more than double by 2030, and debates over data centres moved into local planning meetings about land, grid connections and water. Even the region at the centre of this essay has a name that is a place.

The strongest objection

A sceptic would say that metaphors are shorthand and everyone knows what they abbreviate. No engineer thinks data floats; businesses sign contracts that name regions and countries; and calling something a cloud no more hides its buildings than calling a company a “firm” hides its offices. Abstraction is the cloud’s purpose, and a term that captures the experience of using it is a good term. This is fair for professionals. But decisions about computing are also made by managers, policymakers and the public, and Lakoff and Johnson’s point was that metaphors shape the reasoning of experts too. A decision about where to run a workload is also a decision about which grid it draws on and which law it falls under, and the word “cloud” makes neither question come to mind.

What it means today

Organisations should account for the physical footprint of their computing, the energy and water their workloads use and where, alongside the cost. Product leaders deciding to add AI features should know that each request runs on physical machines with real resource costs. And everyone discussing the cloud should, from time to time, replace the word with “someone else’s buildings” and see whether the decision still looks the same.

8. Building blocks and the value of modularity

The idea in plain terms

Amazon did not sell a finished product. It sold building blocks, each doing one thing through a defined interface, and let customers combine them. That choice explains much of the cloud’s success, and its costs. Modular systems let many people innovate independently, but every interface hides something, and what it hides can matter.

The tradition

In 1972 the computer scientist David Parnas published “On the Criteria To Be Used in Decomposing Systems into Modules.” He argued that a system should be divided not by the steps of its processing but by the decisions most likely to change, with each module hiding one such decision behind an interface, so that it could change without disturbing the rest. He called this information hiding. In Design Rules: The Power of Modularity (2000), the Harvard economists Carliss Baldwin and Kim Clark extended the argument to industries. Modularity, they argued, creates options: when a system is divided into modules with stable interfaces, many firms can experiment with improving each module independently, and the value of the whole grows with the number of experiments. They used the history of the computer industry after IBM’s System/360 to show how modular design turned one company’s product into an industry of thousands.

The idea has a known limit. In 2002 the software developer Joel Spolsky formulated what he called the law of leaky abstractions: all non-trivial abstractions leak to some degree. The details an interface hides, its performance, its failure modes, its costs, eventually show through, and the people using it must understand them anyway.

Where it shows up

Amazon’s internal mandate, as Yegge recalled it, was Parnas’s principle imposed on a company: every team behind an interface, no team reaching into another’s data. AWS’s first services followed Baldwin and Clark’s logic: small, general modules that customers combined in ways Amazon had not planned, creating the option value that turned a retailer’s infrastructure into an industry. Google’s App Engine, a more complete and more restrictive platform, attracted fewer large customers, as modular theory would predict. Lambda raised the abstraction further. And the leaks appeared where Spolsky said they would. Customers who believed a service’s interface discovered in outages that it depended on systems they had never heard of, discovered in bills that it consumed resources they had not imagined, and discovered in breaches that a configuration buried in its settings made their data public.

The strongest objection

Defenders reply that modularity has costs that its advocates understate. Systems assembled from many services from one provider are complex, difficult to reason about and expensive to operate, and the freedom to combine modules also produced the tangled architectures that FinOps teams and security teams struggle to understand. A simpler integrated system, such as a single well-run server, can be easier to secure, cheaper and more reliable for many organisations, which is the argument 37signals made for leaving. This is a strong objection for small and steady workloads. For the industry as a whole, the record of innovation on top of the cloud’s modules is hard to dispute. The question for any particular organisation is how many modules it can understand.

What it means today

Use the modules that save real work, and learn enough about what each hides to know how it fails and what it costs. Design one’s own systems Parnas’s way, with the decisions most likely to change hidden behind interfaces, including the decision of which cloud provider to use. And when offering a platform to others, remember Baldwin and Clark: the value lies in what others can build on it, which depends on keeping interfaces stable and honest about what leaks through them.

Bringing the threads together

The cloud is infrastructure that works by disappearing, and it becomes visible only when it breaks. It is robust to the failures its designers expected and fragile to the rare shared ones, which concentration turns into common shocks. Its metered pricing separates the choice to use from the pain of paying, and its shared model of security spreads responsibility until no one feels it. Its data has a location and a nationality that may not match, so whose law applies is contested. Its convenience creates investments that make leaving costly. Its name hides its buildings, which the AI boom has made impossible to ignore. And its building blocks gave the world a platform for innovation whose abstractions leak. Each thread comes back to the same exchange: organisations gained flexibility, scale and freedom from managing machines, and gave up knowledge of, and control over, the systems they depend on.

A region called Northern Virginia

When the S3 engineer mistyped a command in 2017, the failure travelled through a world that had quietly organised itself around one place. McCarthy’s computer utility had arrived, not as a public service but as a few private companies, and it had delivered on most of what he imagined: computing available to anyone, paid for by use, at almost any scale. The engineers who built Amazon’s primitives, the companies such as Netflix that learned to build on them, and the providers who published honest accounts of their failures made something that has done a great deal of good. Others, by moving faster than their controls or by making leaving deliberately costly, added risks their customers did not see.

The history suggests some working principles. Know where your systems actually run, and what they share with everyone else’s. Design for the failure of the provider as well as of its machines. Put the price of computing in front of the people who spend it. Name an owner for every setting that could expose data. Find out whose law can reach your data before someone else invokes it. Price the exit before you walk in. Remember that every abstraction hides a building and a decision. The cloud lets organisations stop thinking about computers, which was its gift. The organisations that use it well are the ones that keep thinking about what they stopped thinking about.

Selected bibliography

• Bodin, Jean. Les Six Livres de la République. Paris, 1576.
• Heidegger, Martin. Being and Time. 1927; English translation by John Macquarrie and Edward Robinson, Harper & Row, 1962.
• Simon, Herbert A. “The Architecture of Complexity.” Proceedings of the American Philosophical Society 106, no. 6 (1962): 467–482.
• Darley, John M., and Bibb Latané. “Bystander Intervention in Emergencies: Diffusion of Responsibility.” Journal of Personality and Social Psychology 8, no. 4 (1968): 377–383.
• Parnas, David L. “On the Criteria To Be Used in Decomposing Systems into Modules.” Communications of the ACM 15, no. 12 (1972): 1053–1058.
• Lakoff, George, and Mark Johnson. Metaphors We Live By. University of Chicago Press, 1980.
• Thaler, Richard. “Mental Accounting and Consumer Choice.” Marketing Science 4, no. 3 (1985): 199–214.
• Williamson, Oliver E. The Economic Institutions of Capitalism. Free Press, 1985.
• Star, Susan Leigh, and Karen Ruhleder. “Steps Toward an Ecology of Infrastructure: Design and Access for Large Information Spaces.” Information Systems Research 7, no. 1 (1996): 111–134.
• Prelec, Drazen, and George Loewenstein. “The Red and the Black: Mental Accounting of Savings and Debt.” Marketing Science 17, no. 1 (1998): 4–28.
• Shapiro, Carl, and Hal R. Varian. Information Rules: A Strategic Guide to the Network Economy. Harvard Business School Press, 1998.
• Bandura, Albert. “Moral Disengagement in the Perpetration of Inhumanities.” Personality and Social Psychology Review 3, no. 3 (1999): 193–209.
• Krasner, Stephen D. Sovereignty: Organized Hypocrisy. Princeton University Press, 1999.
• Star, Susan Leigh. “The Ethnography of Infrastructure.” American Behavioral Scientist 43, no. 3 (1999): 377–391.
• Baldwin, Carliss Y., and Kim B. Clark. Design Rules, Volume 1: The Power of Modularity. MIT Press, 2000.
• Carlson, J. M., and John Doyle. “Complexity and Robustness.” Proceedings of the National Academy of Sciences 99, supplement 1 (2002): 2538–2545.
• Spolsky, Joel. “The Law of Leaky Abstractions.” Joel on Software, 11 November 2002.
• Lambrecht, Anja, and Bernd Skiera. “Paying Too Much and Being Happy About It: Existence, Causes, and Consequences of Tariff-Choice Biases.” Journal of Marketing Research 43, no. 2 (2006): 212–223.
• Haldane, Andrew G. “Rethinking the Financial Network.” Speech at the Financial Student Association, Amsterdam, 28 April 2009.
• Fischer, Peter, and others. “The Bystander-Effect: A Meta-Analytic Review on Bystander Intervention in Dangerous and Non-Dangerous Emergencies.” Psychological Bulletin 137, no. 4 (2011): 517–537.
• Stone, Brad. The Everything Store: Jeff Bezos and the Age of Amazon. Little, Brown, 2013.
• Daskal, Jennifer. “The Un-Territoriality of Data.” Yale Law Journal 125, no. 2 (2015): 326–398.
• Hu, Tung-Hui. A Prehistory of the Cloud. MIT Press, 2015.
• United States v. Microsoft Corp., No. 17-2, Supreme Court of the United States, 17 April 2018 (per curiam).
• Clarifying Lawful Overseas Use of Data Act, Pub. L. 115-141, div. V (2018).
• Data Protection Commissioner v. Facebook Ireland Ltd and Maximillian Schrems, Case C-311/18, Court of Justice of the European Union, 16 July 2020.
• Wang, Sarah, and Martin Casado. “The Cost of Cloud, a Trillion Dollar Paradox.” Andreessen Horowitz, May 2021.
• Regulation (EU) 2023/2854 on harmonised rules on fair access to and use of data (Data Act), 2023.
• International Energy Agency. Energy and AI. April 2025.
• Competition and Markets Authority. Cloud Services Market Investigation: Final Decision. 31 July 2025.

Research limitations

The origins of AWS rest largely on participants’ and journalists’ accounts written years later; the instruction to expose all work through service interfaces is known from Steve Yegge’s recollection rather than a document, and accounts of the 2003 paper and the Cape Town team come from secondary sources. The date on which EC2 opened in August 2006 differs between sources. The origin of the term “cloud computing” is disputed; this essay follows the MIT Technology Review’s 2011 investigation. Details of the 2017 and 2025 outages are taken from the providers’ own post-event summaries as reported by the press, and the causes they describe are the providers’ accounts. The Capital One breach is described from regulators’ orders and press reports; the bank and AWS denied liability in the class action. Gartner’s prediction about customer fault is widely quoted, but its original document was not consulted. Survey figures on wasted cloud spending are self-reported estimates from a vendor of cost-management software. Savings reported by Dropbox and 37signals come from the companies themselves, and Dropbox’s figures are drawn from its public filing as summarised by the press. Market shares come from Synergy Research Group’s estimates, and capital spending totals from company guidance as aggregated by secondary sources, which differ on definitions. The account of Microsoft France’s testimony and of the International Criminal Court’s email rests on press reports; Microsoft denied cutting off the prosecutor’s email. The CMA’s later steps and the EU–US Data Privacy Framework were subject to further decisions and possible appeals at the time of writing. The IEA’s projections are scenarios, not forecasts. The connections to Star, Ruhleder, Heidegger, Carlson, Doyle, Simon, Haldane, Thaler, Prelec, Loewenstein, Lambrecht, Skiera, Darley, Latané, Fischer, Bandura, Bodin, Krasner, Daskal, Shapiro, Varian, Williamson, Lakoff, Johnson, Hu, Parnas, Baldwin, Clark and Spolsky are the author’s interpretation; their works are paraphrased apart from short, attributed phrases. The decisions in the decisions box are judged by the author, separating what could be known at the time (process) from what happened (call).

Footnotes

1. Amazon Web Services, “Summary of the Amazon S3 Service Disruption in the Northern Virginia (US-EAST-1) Region”, March 2017; “AWS claims human error to blame for US cloud storage outage,” Computer Weekly, March 2017. ↩

2. Amazon, “Amazon.com Announces Fourth Quarter Results,” 5 February 2026. ↩

3. Synergy Research Group, “Cloud Market Share Trends: Big Three Together Hold 63% While Oracle and the Neoclouds Inch Higher”, 2025. ↩

4. “Hyperscaler capex trends: 2026 guidance passes $700 billion,” Datacentres.com; “Hyperscaler capex 2026: guidance by company,” Yield Theory, 2026. ↩ ↩²

5. Simson L. Garfinkel, “The Cloud Imperative,” Technology Review, 2011, quoting McCarthy’s 1961 remarks; Wikipedia, “John McCarthy (computer scientist)”. ↩

6. Antonio Regalado, “Who Coined ‘Cloud Computing’?” MIT Technology Review, 31 October 2011. ↩

7. Steve Yegge, “Stevey’s Google Platforms Rant,” October 2011, archived for University of Washington CSE 452. ↩

8. Wikipedia, “Timeline of Amazon Web Services”; “From Cape Town to the cloud: the South African roots of Amazon Web Services,” BizNews; Brad Stone, The Everything Store (Little, Brown, 2013). ↩ ↩²

9. “Google to challenge Amazon by hosting web apps,” eWeek, April 2008. ↩

10. S. Somasegar, “Announcements from PDC 2008,” Microsoft, October 2008; “Microsoft PDC live blog,” InformationWeek, 27 October 2008. ↩

11. Competition and Markets Authority, Cloud services market investigation; “Brit watchdog pushes to rein in Microsoft and AWS with ‘strategic market status’,” The Register, 31 July 2025. ↩ ↩²

12. Netflix, “Completing the Netflix Cloud Migration,” February 2016. ↩

13. “IBM battles Amazon over $600M CIA cloud deal,” Washington Technology, May 2013; “Top government contracts won by Amazon Web Services,” ExecutiveBiz, August 2023. ↩ ↩²

14. “Our 2014 re:Invent experience and 3 AWS cloud announcements for developers,” Redis, November 2014. ↩

15. “Capital One to pay $80M penalty over 2019 data breach,” Banking Dive, August 2020; “Capital One OCC consent order,” Banking Dive. ↩

16. Gartner’s prediction as quoted in a SecureWorks announcement, Business Wire, 26 February 2020. ↩

17. “AWS DynamoDB outage postmortem,” InfoQ, November 2025; Amazon, “Update on AWS service disruptions,” October 2025. ↩

18. “Azure network outage,” The Stack, October 2025. ↩

19. Flexera, “New Flexera report finds that 84% of organizations struggle to manage cloud spend,” 2025; “29% of cloud spend is wasted and the number just went up,” iTWire, August 2026. ↩

20. Sarah Wang and Martin Casado, “The Cost of Cloud, a Trillion Dollar Paradox,” Andreessen Horowitz, May 2021; summary at Cloudian. ↩

21. Dropbox, Inc., Form S-1, February 2018; “Dropbox saved almost $75 million over two years by building its own tech infrastructure,” GeekWire, February 2018. ↩

22. David Heinemeier Hansson, “Our cloud-exit savings will now top ten million over five years,” October 2024; “37signals is completing its on-prem move, deleting its AWS account,” The Register, 9 May 2025. ↩

23. “EU Data Act: switching cloud provider,” McCann FitzGerald; “Cloud switching under the EU Data Act,” Deloitte Legal. ↩

24. “CMA to launch strategic market status investigation into Microsoft; Amazon Web Services off the hook,” Computer Weekly, 2026; “UK regulator probes Microsoft while backing voluntary cloud rules,” Tech Policy Press, 2026. ↩

25. “Supreme Court dismisses warrant case against Microsoft after CLOUD Act renders it moot,” TechCrunch, 17 April 2018; Amy Howe, “Justices officially declare Microsoft email case moot,” 17 April 2018. ↩

26. “EU court upholds the validity of the EU–U.S. Data Privacy Framework,” Wilson Sonsini, September 2025; “The General Court upholds the EU–US Data Privacy Framework,” Mondaq. ↩

27. “Microsoft tells French lawmakers it can’t protect user data from US demands,” SDxCentral, July 2025. ↩

28. “The International Criminal Court is ditching Microsoft software for an open source alternative,” TechRadar, October 2025; “Microsoft denies mail blockade at the International Criminal Court,” heise, 2025. ↩

29. Amazon, “AWS launches AWS European Sovereign Cloud and announces expansion across Europe,” 15 January 2026. ↩

30. “Microsoft is no longer OpenAI’s exclusive cloud provider,” TechCrunch, 21 January 2025; “OpenAI and Microsoft sign agreement to restructure OpenAI,” Tom’s Hardware, October 2025; “AWS, OpenAI strike $38B computing deal,” YourStory, November 2025. ↩

31. International Energy Agency, “AI is set to drive surging electricity demand from data centres,” 10 April 2025. ↩