Google Cloud Outage Hits European Banking: Revisiting Cloud Dependency Risk

Event Overview: One Cloud Outage, Half of Europe's Banking Services Affected

According to Neowin, a recent Google Cloud outage caused service disruptions at several major European financial institutions, including HSBC, Revolut, Bank of Scotland, Lloyds, and credit reporting agency Equifax. The original headline bluntly stated that the outage affected "almost all banking and other operations in Europe," though the body itself did not provide more detailed technical root causes. Based on the types of institutions named, however, the problem spans three layers: traditional banks, digital banks, and credit data service providers.

This news received 292 points and 149 comments on Hacker News. The discussion heat wasn't explosive, but comment density was high, indicating it struck a long-standing anxiety in the tech community: when critical infrastructure is highly concentrated in the hands of a few cloud providers, just how far can a single point of failure propagate?

Why One Cloud Provider's Outage Can Simultaneously Hit Multiple Banks

Traditional banks' IT architectures are typically considered "self-built primary, cloud secondary." But over the past decade, even strictly regulated financial institutions have been migrating more and more non-core and even core business to public clouds. Digital banks like Revolut were built on cloud-native architectures from day one, with virtually no buffer zone of self-built data centers.

This means the same outage can affect different institutions in completely different ways: for digital banks, it may mean the core transaction chain is directly unavailable; for traditional banks, it more commonly manifests as timeouts in some middle-layer service—identity verification, risk control queries, reconciliation interfaces—leading to partial degradation of counter and app functions. The involvement of data service providers like Equifax allows the failure to spread along the credit query chain to more downstream institutions.

This "shared dependency" structure is the source of cloud computing's efficiency and also a risk amplifier. When multiple banks share the same batch of managed services in the same region, their fault domains overlap physically and logically—independence is merely an assumption on paper.

Fault Domain is a key concept for understanding cloud failure propagation. It refers to the boundary of the scope that may be affected when a component in a system fails. In cloud environments, fault domains can be divided by physical hierarchy (e.g., a single server, a single rack, a single availability zone) or by logical hierarchy (e.g., a certain managed service, a certain identity authentication cluster). Cloud providers isolate fault domains through multi-availability-zone deployment, but if resources rented by different customers fall within the same fault domain, a "shared fault domain" is formed—once that domain fails, all tenants are affected simultaneously. In the article, multiple banks sharing the same batch of managed services in the same region essentially means overlapping fault domains, which causes their seemingly independent systems to lose isolation physically and logically.

SLA (Service Level Agreement) is an availability commitment between cloud providers and customers, typically expressed as a monthly uptime percentage (e.g., 99.9%). But SLAs commit to infrastructure-layer availability, not customer business continuity. SLA compensation mechanisms usually exist in the form of service credits, which are far from covering the actual losses caused by business interruption. More importantly, the statistical period and exemption clauses of SLAs (such as planned maintenance and force majeure) often make the actual level of protection lower than the literal commitment. Developers need to understand that SLAs are a floor, not a goal—business continuity must be guaranteed by your own architecture design.

Multi-Cloud and Disaster Recovery: Much Talk, Little Action

After every large-scale cloud outage, "multi-cloud strategy" gets brought up again. But judging from this incident, the industry is still quite far from true multi-cloud disaster recovery.

True multi-cloud isn't about putting different businesses on different clouds; it's about the same critical business being able to switch to another environment within minutes during a failure. This requires duplicating data synchronization, network configuration, security policies, and even compliance audits—costly and dramatically increasing operational complexity. For profit-sensitive banks, this is a hard account to get internally approved—until an outage actually happens.

A more realistic middle path is "de-clouding critical paths": keeping modules with the highest availability requirements, such as transaction clearing and core accounting, in self-built or proprietary environments, while placing businesses that can tolerate interruption, such as marketing, reporting, and data analytics, on public clouds. This hybrid architecture isn't new, but the intensity of implementation often depends on regulatory pressure and how long the memory of incidents lasts.

Multi-Cloud and Hybrid Cloud are often used interchangeably but have different meanings. Multi-cloud refers to using services from two or more public cloud providers simultaneously, while hybrid cloud refers to a combination of public cloud and private cloud/self-built data centers. The "de-clouding critical paths" mentioned in the article is closer to the hybrid cloud approach: keeping core modules with high availability requirements in proprietary environments and placing interruption-tolerant businesses on public clouds. True multi-cloud disaster recovery requires the same business to have hot-switching capability across multiple cloud environments, which involves multiple challenges such as real-time data synchronization, network interconnection, security policy consistency, and compliance auditing. In practice, most enterprises adopt "shallow multi-cloud"—multiple clouds coexisting but not backing each other up—meaning different businesses are scattered across different clouds but lack cross-cloud failover mechanisms, thus not truly eliminating shared fault domain risk.

Three Takeaways for Developers and Technical Decision-Makers

First, failure drills can't just test "our own system went down"; they must also test "the dependency went down." Cloud providers' SLAs promise infrastructure availability, not your business continuity—your architecture design stands between the two.

Second, map out shared fault domains clearly. The same region, the same managed service, the same identity provider—these implicit coupling points often only surface when failures occur. Drawing dependency relationships as a graph is more useful than reading SLA documents.

Third, this applies to industries beyond finance as well. Payments, e-commerce, logistics, and government systems are all concentrating toward a few cloud platforms. This banking outage was a public stress test—except the test subject was the entire industry's risk awareness, not any single institution's technical capability.

The discussion heat on Hacker News shows that the tech community is no stranger to such incidents. What's truly scarce isn't "knowing the risk exists," but the decision-making courage to pay the cost for redundancy.

One-line Summary

A single Google Cloud outage affected multiple European banks, exposing cloud concentration risk and disaster recovery gaps.

Paragraph Summary

A recent Google Cloud outage caused service disruptions at multiple European financial institutions including HSBC, Revolut, Bank of Scotland, Lloyds, and Equifax, spanning traditional banks, digital banks, and credit service providers. Digital banks, lacking buffers due to cloud-native architectures, experienced more direct failure propagation; traditional banks mostly showed middle-layer service degradation. The shared dependency structure caused overlapping fault domains across multiple institutions—business independence is merely an assumption on paper. The article points out that true multi-cloud disaster recovery is costly and difficult to implement, and the industry's more realistic choice is a hybrid architecture with de-clouded critical paths. The takeaway for developers: failure drills should cover dependency failures, systematically map shared fault domains, and bear the decision-making cost for redundancy.