A Dependency Investigation (#09) – September, 2026
About This Series
The Magician’s Hands is a series of dependency investigations. Each report examines a single case in which a structural dependency, between a state and an infrastructure owner, a farmer and a seed company, a continent and an energy supplier, was created, normalised, leveraged, and converted into power. The cases span domains and decades. The grammar beneath them does not change.
The series takes its name from a simple observation: the most consequential things happening in the world are rarely the things that take centre stage. While we watch the visible hands, something else is being built in the structural layer underneath. These reports are an attempt to make that layer legible.
The founding article, “”, sets out the full grammar. Each investigation that follows applies it to a specific case.
Scene-setter
Open a laptop, tap a banking app, stream a film, file a tax return, or call up a hospital record, and somewhere behind that action a request is very likely landing on a server owned by Amazon, Microsoft, or Google. The visible story is one of convenience and progress: businesses that once maintained their own data centres, with all the capital cost, staffing, and physical risk that entailed, now rent computing power the way a household rents electricity, paying only for what they use, scaling instantly when demand spikes, and outsourcing the burden of keeping the lights on to companies that do it better than almost anyone could alone. Told this way, the shift from owned infrastructure to rented cloud infrastructure across the 2006 to 2015 period reads as one of the clearest efficiency gains in the history of computing, and largely, at the level of the individual decision, it was.
This investigation looks beneath that story, at the structural layer the efficiency narrative does not name. It examines what happened when an entire civilisation’s software, and by extension the businesses, institutions, and eventually the people who depend on that software, came to run on infrastructure controlled by three American companies, Amazon Web Services, Microsoft Azure, and Google Cloud, with a regional fourth in Alibaba Cloud inside China. It is not a story about any one of these companies behaving badly. It is a story about what happens when a genuine technical creation, the on-demand, elastic, pay-as-you-go compute utility, becomes so foundational, and so concentrated, that the businesses and institutions built on top of it, and the people who depend on those businesses and institutions, lose the ability to meaningfully exit even when they can clearly see the risk of staying.
The thesis this investigation sets out to demonstrate is this: cloud computing did not create dependency by capturing something that already existed, nor by inserting itself covertly into an existing standard. It created something genuinely new and useful, and it was the very success and elegance of that creation that allowed dependency to accumulate almost invisibly, one rational adoption decision at a time, until an outage in a single American data centre region could be felt as a structural tremor across the unrelated corners of the global economy.
Move 1: Creating the Dependency
The entry point here is creation, not capture or insertion, and the distinction matters. Amazon Web Services launched Simple Storage Service in March 2006 and Elastic Compute Cloud in beta that August, offering something that did not meaningfully exist before at that scale: computing capacity available on demand, billed by the hour, requiring no procurement cycle, no data centre lease, no hardware refresh plan. Microsoft and Google followed with Azure and Google Cloud Platform in the years after, and by the middle of the 2010s a full market had formed around the same basic proposition.
The hook was genuine utility, not a lure. For a startup, renting compute meant not needing to raise capital for servers before writing a line of revenue-generating code. For an enterprise, it meant converting a fixed capital cost into a variable operating cost, and shedding the specialist staff needed to run a data centre. For a public-sector body, it meant access to computing capacity and security tooling that an in-house department could rarely match. Every one of these adoption decisions, taken individually, was rational, often obviously so. Nobody signing a cloud contract in 2010 or 2014 was making a mistake by the standards available to them at the time.
The structural consequence that no individual adopter could see was aggregation. Each decision to move a workload to AWS, Azure, or Google Cloud was a decision made in isolation, weighed against the alternative of running that one workload in-house. What none of those decisions weighed, because no single actor was positioned to weigh it, was the cumulative effect of millions of similar decisions landing on the same three infrastructures. The key decision point was not any single migration but the compounding of the pattern itself: by the time cloud-first became the default architectural assumption rather than one option among several, roughly the mid-2010s onward, reversing course for any given organisation had become a multi-year, high-risk undertaking, not a procurement choice. The dependency creators, AWS, Azure, and Google Cloud, did not need to force this outcome. They needed only to keep building a product good enough that opting in kept being the obviously rational choice, year after year, until the world’s software ran substantially on three balance sheets.
Move 2: Normalising the Dependency
Two distinct mechanisms did the work of normalisation here, and they reinforced each other.
The narrative supplied by the industry, and largely accepted without much scrutiny by the trade press and by client-side leadership for most of the 2010s, foregrounded elasticity, cost efficiency, security, and innovation velocity, and backgrounded concentration. “Cloud-first” and later “cloud-native” became boardroom shorthand for competence and modernity; resisting the migration, or asking pointed questions about what it meant for three companies to hold this much of the world’s computing capacity, was more often read as technical conservatism or a failure to keep up than as a legitimate structural concern. The few voices raising concentration risk, typically security researchers, some competition regulators, and a scattering of infrastructure engineers who had lived through early outages, were operating well outside the mainstream of a conversation dominated by migration case studies and cost-savings testimonials.
Operational normalisation ran alongside the narrative and arguably did more of the actual work. Software architecture itself changed to assume the cloud was simply there: development teams built directly against AWS-specific or Azure-specific services rather than portable abstractions, because doing so was faster and the tooling rewarded it. Continuous-deployment pipelines, identity and access management, monitoring, and disaster-recovery planning all came to assume a specific cloud provider’s primitives rather than a generic computing environment. Egress fees, the cost providers charge to move data out of their platform, and the sheer engineering effort required to re-architect an application away from a provider’s proprietary services, quietly raised the switching cost of leaving without any single dramatic event announcing that the cost had risen. By the point at which an organisation’s engineers, contracts, monitoring, and institutional knowledge were all built around one provider’s specific way of doing things, the cloud had stopped being a vendor relationship and had become, simply, how the system worked. The reader should recognise, by this point in the story, that exit had already become extraordinarily expensive for the vast majority of organisations well before anyone tried to use the dependency as leverage, and largely without anyone deciding that this should be so.
Move 3: Leveraging the Dependency
Leverage in this case is visible mainly in its structural and option-space forms; direct, overt leverage of the kind seen in commodity supply cuts is comparatively rare, precisely because the dependency creators have little incentive to make their power visible.
Direct leverage does exist and is worth naming honestly. Pricing changes, changes to service terms, and the deprecation of specific services on a provider’s own schedule all place real costs on dependent businesses with limited recourse; a company that built its product on a cloud service that is later discontinued or repriced has few options beyond absorbing the cost or undertaking a difficult migration. Regulatory scrutiny of exactly this dynamic has intensified: the UK Competition and Markets Authority’s cloud services market investigation, concluded in July 2025, found that the market position of AWS and Microsoft restricts effective competition in the UK cloud market and recommended both be designated with strategic market status, a finding that is itself an institutional acknowledgment of the leverage this investigation describes.
Structural leverage is more consequential and less visible. The three providers set the terms on which nearly the entire downstream layer of internet businesses, internet service providers, application developers, hosting companies, software-as-a-service vendors, and streaming platforms, operate: pricing structures, data-transfer costs, default security and compliance postures, and even which artificial-intelligence models and tools are conveniently available all flow from decisions made inside three companies. A hosting company or SaaS vendor can see the resulting bill or the resulting architecture, but has no direct way to trace the terms it is operating under back to a negotiation it was never part of, because there was no negotiation; the terms are the platform.
Option-space leverage is the most durable form and the hardest to see, because it produces no event at all. A startup choosing its technical architecture today does not meaningfully consider running its own data centre; that option has been narrowed out of existence before the founders sit down to plan, not because anyone forbade it but because doing otherwise would be so far outside industry norms as to be nearly unfundable. A government agency planning a new digital service, likewise, now frames its options as a choice between the three or four major cloud providers cleared for its jurisdiction’s compliance requirements, not as a choice between cloud and self-hosting. The dependent parties here, the intermediary layer of service providers and the institutions above them, are not being pressured into anything at the moment of decision. Their option space narrowed years before the decision arrived, and by the time they are choosing, they are choosing among variations on dependency, not choosing whether to be dependent at all.
Move 4: Obscuring the Mechanism
The temporal displacement in this case is unusually stark, because the decisions that created the dependency were technical procurement choices made by engineering and IT leadership across thousands of separate organisations over roughly two decades, while the consequences of that concentration surface as sudden, dramatic, and highly visible events, most clearly a cloud outage, that land on a different set of people entirely: end users, customers, and the public, who had no part in and often no awareness of the original architectural decisions. The engineer who chose a specific AWS region for a database in 2016 is rarely the person answering for a multi-hour outage of unrelated consumer services years later; the gap between decision and consequence runs through career changes, company acquisitions, and shifts in technical leadership that make accountability nearly impossible to locate even when the underlying cause, concentration in a single region of a single provider, is well understood in the abstract.
Narrative capture operated by keeping a specific question unaskable for most of the period in question: not “is this cloud service reliable” but “what does it mean that an unrelated range of the world’s digital services shares a single point of failure.” Reliability, uptime percentages, and service-level agreements were the terms in which the industry discussed risk, and each of those terms individually made sense and was individually true; providers do deliver very high uptime most of the time. What that framing successfully kept out of view was the aggregation question, the fact that even a small probability of failure, multiplied across the sheer number of unrelated services now sharing the same underlying infrastructure, guarantees that failures will eventually be felt simultaneously across sectors that have no institutional reason to coordinate with each other or even to know they share a dependency.
Structural opacity compounds this. No single regulator, company, or industry body has a complete view of which services, in which sectors, ultimately depend on which specific cloud region or service. The information that a given hospital system’s patient portal, a given country’s tax-filing service, and a given streaming platform’s login system all route through the same underlying regional infrastructure is technically discoverable but institutionally invisible, distributed across the private architecture decisions of thousands of separate technical teams that have no shared registry and, in most cases, no mutual awareness. The picture only assembles itself after the fact, in the hours following a major outage, when incident reports and outage trackers retroactively reveal a map of interdependency that existed all along but that no institution had the mandate or the tooling to see in advance.
Move 5: Converting the Value
What is converted here is not, in the first instance, money in the direct sense of extraction; it is control over the operating conditions of the modern economy, converted into standard-setting authority and structural leverage that the dependency creators did not need to seek aggressively, because the position itself confers it. Commercial infrastructure ownership converts into normative power: AWS, Azure, and Google Cloud increasingly set the default assumptions, the reference architectures, the security baselines, and now the default terms of access to frontier artificial-intelligence capability, for a global economy that has no comparably positioned alternative to consult instead.
Financial value is converted too, and substantially, through the durable, high-margin revenue that comes from a customer base with genuinely limited exit options; this is a normal and legitimate outcome of building a valuable product, but it is also a direct consequence of the switching costs Move 2 describes, and it should be named as such rather than treated purely as a reward for quality. Political value is converted through the leverage these companies now carry in shaping how governments, including governments explicitly concerned about sovereignty over their own citizens’ data, ultimately negotiate access, compliance, and localisation terms; a government can set rules, but it sets them knowing that the practical alternative to compliance from these three companies is, for most public functions, no cloud infrastructure at all.
The parties who paid, and continue to pay, are not evenly distributed with the parties who benefited. The intermediary layer, the application developers, hosting companies, SaaS businesses, and streaming platforms who built their products atop this infrastructure, absorb the switching costs, the pricing terms, and the outage risk directly, often without the market power to negotiate meaningfully different terms. The consumer and prosumer layer above them absorbs the consequence one step further removed, most visibly during outages, when services that appear entirely unrelated to each other fail at the same moment for a reason the affected user will likely never learn. The long-term consequence still unfolding is a civilisational infrastructure layer whose resilience characteristics are now set primarily by the commercial and engineering priorities of three companies, rather than by any public body accountable for critical-infrastructure resilience as such.
Analytical Notes
Two dependency architectures operate simultaneously in this case and collide in a way that is arguably more consequential than either considered alone.
The first architecture is commercial cloud dependency itself: the concentration of global computing infrastructure inside AWS, Azure, and Google Cloud. As of the third quarter of 2025, Synergy Research Group placed AWS’s share of global cloud infrastructure services at 29 percent, Microsoft Azure’s at 20 percent, and Google Cloud’s at 13 percent, with the three together accounting for 63 percent of a market now worth well over 100 billion dollars a quarter. That concentration is reinforced by the switching costs described in Move 2. The second architecture is the sovereign and regulatory response to that same concentration, most visibly the European Union’s data-protection regime under the General Data Protection Regulation and the digital-sovereignty initiatives that followed it, of which Gaia-X, the Franco-German-led federated data infrastructure initiative launched in 2019, is the clearest institutional expression.
The collision point is structural rather than incidental. Organisations operating inside the EU, and public bodies especially, are required by one architecture, the regulatory one, to demonstrate sovereign control over where and how their data is processed, while operating, in practice, almost entirely inside infrastructure controlled by companies incorporated in a jurisdiction, the United States, whose own legal framework asserts a degree of extraterritorial reach over data held by companies under its jurisdiction regardless of where the servers physically sit. An organisation attempting to comply fully with both architectures at once finds that genuine compliance with the sovereignty architecture would require exiting the commercial architecture almost entirely, an option that, per Move 3, has in most cases already been narrowed out of existence.
Gaia-X itself is best read as evidence of acknowledgment rather than evidence of resolution. Conceived as a European framework for a sovereign, federated data infrastructure, it has since moved past its initial concept phase into building interoperable data spaces and digital ecosystems across sectors such as health, mobility, and finance, a phase its own organisers describe as its “second season” as of its 2025 summit. What it has not done, and does not currently appear positioned to do, is produce an alternative to the big three at anything like the scale, cost, or capability the market has come to expect. Its existence confirms that European policymakers and industry consortia recognise the dependency as a genuine sovereignty risk; its limited practical traction against the hyperscalers so far confirms how difficult that dependency has become to exit once the option space has already narrowed as far as it has here.
The October 2025 outage in AWS’s us-east-1 region belongs in this same frame, not as an isolated incident but as a demonstration of exactly the fragility that concentration produces. In the early hours of October 20, 2025, a latent race condition in the automated DNS management system behind DynamoDB, one of AWS’s core database services, caused the DNS records for DynamoDB’s regional endpoint to be deleted, an initial fault that took roughly fifteen hours to resolve and whose cascading downstream effects continued into October 21. Because so many other AWS services, and so many companies built on top of them, depend on DynamoDB even for resources deployed in other regions, the outage rippled outward to more than seventy AWS services and, according to widely reported estimates, well over a thousand companies, disrupting Slack, Snapchat, Reddit, Robinhood, Coinbase, Venmo, Fortnite, Roblox, Ring and Alexa smart-home devices, Amazon’s own retail and delivery operations, and a long list of otherwise unrelated banking, gaming, streaming, and government services worldwide. This is precisely the structural argument this investigation makes: the risk here is not that any one company will fail badly, but that so much of the world’s unrelated digital activity now shares so few points of failure that when one of those points does fail, the consequences are guaranteed to be felt far outside any sector that chose, or even knew, that it depended on that specific infrastructure.
Closing
What this case reveals about the grammar of hidden dependency is that creation is not the innocent entry point it can appear to be. Capture and insertion carry an obvious villain, an actor doing something to an unwitting party. Creation carries no such actor, because every individual decision inside it was genuinely reasonable, and this is precisely what makes creation-based dependency so difficult to see and so difficult to resist while it is forming: there is no single moment, no single decision, and often no single company to point to, only an accumulation of good decisions that collectively produced a structural vulnerability that none of the decision-makers intended and most could not have perceived from where they were standing.
This case also demonstrates that dependency architectures do not resolve simply because a competing architecture, in this instance regulatory sovereignty, recognises the problem and responds to it. Two structures can occupy the same institutional space indefinitely, each fully coherent on its own terms, each pulling the dependent party in a different direction, without either one displacing the other. That collision, rather than either architecture individually, may be the more durable condition; European institutions may continue asserting sovereignty requirements for years while continuing, in practice, to run on infrastructure that those same requirements cannot fully be reconciled with.
The question worth carrying forward is this: when a dependency was created rather than captured or inserted, when every step toward it was locally rational and no single actor holds the leverage or the villainy of the classic case, what does resistance even look like, and who, precisely, is positioned to attempt it.
Comments are closed