The Guardian reports that a power fault in one Google Cloud zone in London disrupted courts and left bank customers unable to pay. A fault that small should not reach that far, and the fact that it did points to concentration risk.
Key takeaways
- The Guardian reports that a “power event” at Google’s London cloud operations disrupted UK courts and left customers of Lloyds, HSBC and Revolut unable to send or access money.
- Google said the failure affected a single zone, europe-west2-b. Cloud zones are built to fail on their own without taking whole services down with them.
- When one zone failure disrupts several banks and the courts at the same moment, many critical services are probably sharing a small number of infrastructure dependencies.
- The detailed technical cause, how long each service was affected and how each organisation had set up its systems are not yet publicly known, so any conclusion is provisional.
The argument: a small fault should not cause a broad outage
The Guardian reports that Google blamed a “power event” for an outage at its London cloud computing operations. Google said the event affected its “europe-west2-b zone”. The publication says the disruption reached courts, where hearings stalled, and banks including Lloyds, HSBC and Revolut, where millions of customers could not access or send money. It also says services were restored for most users.
The argument here is that the most telling part of this incident is not that hardware failed. Hardware fails all the time, and every large computing operation expects it. The telling part is how far a failure in one zone appears to have spread. Cloud platforms are sold and designed on the idea that a fault in one part of the system stays in that part. If a single zone losing power can hold up court hearings and stop people paying for things at several major banks, then the way essential UK services depend on a few cloud providers carries more correlated risk than the design principles suggest it should.
This does not mean anyone acted recklessly, and the incident does not show that cloud computing is unsafe. It does suggest that the UK’s critical digital infrastructure is more concentrated, and more tightly coupled, than public reassurances about resilience imply. The evidence below supports that view. It is not yet conclusive.
Evidence one: cloud zones are designed as separate failure domains
Large cloud providers, Google among them, split their infrastructure into regions and zones. A region is a geographic area, such as London. A zone is a separate section inside a region, usually with its own power, cooling and networking. The point of zones is to create failure domains: a fault in one should leave the others running.
Providers generally tell customers that anything important should run across more than one zone, so that losing a zone causes a brief slowdown at worst rather than an outage. In industry language, a system that loses one zone and keeps serving users is “zonally redundant”.
That is why the reported scope of this incident matters. Google says one zone was affected, yet customers at several banks and court users reportedly lost service. There are a few possible explanations. Some workloads may have run in that zone alone. Some systems may have been spread across zones but still relied on one component, such as a database, a queue or a network appliance, that was located in the affected zone. Or recovery mechanisms such as automatic failover may not have worked as intended. From public information it is not possible to say which of these applied to any particular organisation.
Each of these explanations is a gap in the separation that cloud design is supposed to provide. A single-zone fault that spreads widely suggests that, at least in some places, the protection existed in theory but not in practice.
Evidence two: unrelated institutions failed at the same time
The second piece of evidence is the range of organisations reportedly affected. A high-street bank, a digital bank and the court system are very different organisations. They have different technology histories, suppliers and engineering teams. In a less concentrated market, a fault at one data centre operator would be unlikely to reach all of them at once.
When unrelated services fail together, the usual cause is a shared dependency. Sometimes that dependency is direct, with each organisation running its own systems on the same cloud. Often it is indirect. Banks and public bodies rely on many outside suppliers for identity checks, payment processing, messaging, fraud detection, customer support software and case management. Each of those suppliers chooses its own infrastructure. A bank may have spread its own systems carefully and still be exposed because a supplier it depends on was not.
These indirect dependencies are hard to see from outside, and sometimes from inside as well. An organisation can list its own cloud contracts. Mapping every supplier of every supplier down to the data centre zone is much harder. When several services fail at once, those hidden links become visible.
It is not publicly known which of the reported disruptions came from direct dependence on Google Cloud and which came through suppliers. Either way, the pattern points the same direction: many essential services rest on a narrow base.
Evidence three: regulators already treat cloud concentration as a systemic risk
The third piece of evidence is that financial regulators already treat this risk as real enough to need specific rules. In the UK, legislation has given the Treasury powers to designate certain outside technology suppliers as “critical third parties” to the financial sector. Designated suppliers fall under direct oversight by the Bank of England, the Prudential Regulation Authority and the Financial Conduct Authority. Large cloud providers are the obvious candidates for that status. The European Union has taken a similar approach through its Digital Operational Resilience Act, which covers how financial firms manage information and communications technology risk, including risk from outside providers.
These regimes exist because policymakers concluded that a failure at one big technology supplier could disrupt many financial firms at once, and that regulating each bank separately would not capture that risk. This incident, as reported, looks like the scenario those rules were written for.
The regimes have limits. They supervise providers and set expectations for firms. They cannot remove concentration in a market where a few providers have the scale that most large customers want. Courts and other public services also sit largely outside financial regulation, so their exposure is governed by different frameworks.
The strongest case against: cloud may still be the more resilient option
There is a serious counter-argument and it should be stated fully.
First, the alternative to the cloud is not perfect reliability. Before cloud adoption, banks and public bodies ran their own data centres, and those failed as well, sometimes for long periods. In-house systems often have fewer engineers, older equipment and less investment in redundancy than a hyperscale provider can afford. A brief disruption that is mostly fixed within the day, which is consistent with the Guardian’s report that most users had service back, may compare well with the outages that self-managed systems have historically had. Judging the cloud against an ideal of zero downtime, rather than against the realistic alternatives, overstates the case against concentration.
Second, the details are not yet known. The power event may have hit something that zone redundancy could not fully cover, such as network or control systems shared across the region. If so, it would say less about how customers designed their systems and more about a rare failure mode. Without a detailed post-incident report it is not clear whether the wide impact came from customer design choices, provider design choices or bad luck.
Third, the main fix usually suggested, spreading critical systems across several cloud providers, has real costs. Running the same service on two different platforms adds engineering complexity, and complexity causes failures of its own. Data has to stay consistent across providers, staff need skills in more than one platform, and failover between providers is harder to test than failover between zones. Some engineers argue that a well-built deployment across several zones and regions on one provider is more reliable in practice than a poorly maintained multi-cloud setup.
Fourth, the economics of concentration can benefit users. Large providers spend heavily on security, physical resilience and engineering, and smaller organisations get access to that investment. A market split among many smaller providers might lower correlated risk while raising the chance of failure at each individual provider.
Taken together, these points support a narrower conclusion: the incident shows that some organisations’ resilience designs were incomplete, not that dependence on hyperscalers is too high.
Evidence that would change the conclusion
Several kinds of information would strengthen or weaken the argument made here.
A detailed technical account from Google would matter most. If it showed that the power event reached systems serving the whole London region, the incident would say more about provider design than customer concentration. If it confirmed that only one zone lost capacity, attention would move to why so many services could not run without it.
Disclosures from the affected banks and court services would also help. If most of them turn out to have depended on one or two shared suppliers rather than on Google directly, the problem is supply-chain visibility more than cloud concentration in itself, and the right response would be different.
Data on how long the disruption lasted for each service would test the counter-argument. Short, contained interruptions would support the view that cloud resilience is working mostly as intended. Long or repeated failures would support the concentration argument.
Finally, supervisory findings would carry weight, whether from the UK financial regulators under the critical third parties regime or from any review of court technology. A conclusion from those bodies that firms met their resilience obligations and the incident sat within tolerable limits would weaken the case made here. Findings that firms had not mapped or tested their dependencies on single zones would strengthen it.
Until that information is available, the reasonable conclusion is provisional: a fault designed to stay local appears to have had wide effects, and that pattern needs explaining.
Sources and further reading
- The Guardian: business coverage reporting the outage, Google’s explanation and the services affected.
- Google Cloud: public documentation on how regions and zones work and on recommended practice for resilient deployments.
- Bank of England, Prudential Regulation Authority and Financial Conduct Authority: published material on the UK critical third parties regime and operational resilience expectations.
- European Union: the Digital Operational Resilience Act and related guidance on technology risk at financial institutions.
Surfaced from the rss:guardian_tech signal “UK cloud outage disruption”. AI-assisted draft, editorially reviewed.
