Google Cloud outage affects almost all banking and other operations in Europe

A power failure in Google Cloud’s europe-west2 (London) region knocked out services for multiple European banks and fintechs, leaving customers unable to access accounts, make payments, or even unlock shared bikes. Commenters use the incident to probe why critical financial infrastructure depends on a single cloud zone, debating the realities of multi-region design, the tradeoffs of public cloud versus self-hosting, and the added risks from data sovereignty rules and US-based providers. Many see it as a test case for regulatory frameworks like the EU’s Digital Operational Resilience Act and a reminder that “the cloud” does not remove the need for rigorous redundancy planning.

User impact and neobank reliability

  • Many commenters report outages at neobanks and fintechs (e.g., Revolut), with card payments, ATM withdrawals, and app access failing.
  • Some users highlight the lack of phone support or human contact during incidents as a major downside of app‑only banks.
  • Others contrast this with neobanks that invested in separate, simplified “stand‑in” systems on different providers, which preserved core banking functions during past outages.
  • A few users avoided or left certain neobanks over concerns about regulation, account freezes, or poor incident handling, preferring traditional banks with reliable phone support.

Cause and scope of the outage

  • Google’s status page attributes the issue to a “power event” in the europe‑west2‑b zone, with partial restoration within about 30 minutes and further mitigation after.
  • Commenters are surprised that large banks and financial services appear to have concentrated critical workloads in a single zone/region, rather than multi‑zone or multi‑region architectures.
  • Some report that services in other zones or regions also had issues, but the extent and root cause of cross‑zone impact are unclear.

Cloud architecture, resilience, and testing

  • Several comments stress that multi‑AZ or multi‑region setups only matter if they are regularly tested; many organizations never simulate full AZ loss.
  • Practitioners note that multi‑cloud and true geographic redundancy are hard and expensive, especially with strict consistency and legacy dependencies.
  • There is criticism that hyperscalers can have inter‑zone/region dependencies and capacity limits, causing “thundering herd” problems when one zone fails.
  • Others argue that outages would also occur if everyone colocated their own hardware in the same data center; the real issue is lack of properly implemented redundancy.

Sovereignty, regulation, and DORA

  • Discussion around “AI sovereignty” versus “compute/data sovereignty”: some say relying on a single hyperscaler region contradicts sovereignty goals.
  • Others distinguish sovereignty (where data resides) from redundancy (how many locations), arguing regulators and firms must consider both.
  • Questions are raised about EU/UK regulatory implications (e.g., DORA), with a view that institutions may face reviews and improvement plans, but large fines are unlikely if this is a first major issue.
  • Legal/geographic residency rules and Brexit are cited as reasons some banks keep UK workloads strictly in UK regions, limiting redundancy options.

Cloud provider comparisons and broader sentiment

  • Mixed views on providers: some rank AWS and Azure above “everything else,” others claim GCP usually has fewer outages and strong security.
  • Azure is described as nicely designed at the control‑plane level but clumsy in implementation and documentation.
  • Skepticism about “cloud will be cheaper and more resilient” is common; many see cloud as shifting where failures happen rather than eliminating them.