On the morning of 20 October 2026, Google Cloud’s London region had hours of errors after trouble in one zone, and UK banking and payments apps were disrupted. It was not an AWS incident, but the question it raises applies to every UK firm on AWS: if one Availability Zone fails, does your service stay up, and if the problem spreads wider, can you recover inside your impact tolerance? Here is what was reported, and six checks to run this week.

What happened in London

According to The Register’s report, Google Cloud services in europe-west2 (London) showed “elevated errors and intermittent network failures” from 06:08 UTC on 20 October. The trouble was in one of the region’s three zones, europe-west2-b, yet products across the region were affected, including Google Kubernetes Engine and Cloud Run.

Reported detailSource
Zone with the fault: europe-west2-bThe Register
Cause: a power event in that zone (verify against Google’s incident report when published)Northdoor
Google reported the power event mitigated at 12:12 UK time, with existing workloads expected back by about 14:00Northdoor
Revolut confirmed a multi-service disruption and said customer money and data were safeThe Register
Lloyds, HSBC, Royal Mail, Rightmove, DPD and BT appeared in outage-tracker reports (user reports, not confirmations)The Register
Google first said there was no workaround, then suggested moving workloads to another location where feasibleThe Register

Two points matter for anyone designing on a different cloud. A fault in one zone produced problems wider than the zone. And “move to another location” is only an option if that location was prepared in advance.

What AWS says about zones and Regions

AWS’s Well-Architected guidance is to run production in at least two Availability Zones, which have “independent physical infrastructure, including utility power connections, backup power sources”. It recommends multiple Regions only when requirements call for extreme resilience, and otherwise “as part of your disaster recovery (DR) strategy”, for example warm standby or pilot light. Services differ in what they do by default: S3, Aurora and DynamoDB replicate across zones; for RDS, Redshift and ElastiCache you must enable Multi-AZ yourself.

Multi-AZ answers “one zone fails”. It does not answer “the whole Region has a problem”. AWS reported in September that it could not restore resources held only in its Bahrain Region and one UAE zone after war damage, as Techzine reported (verify against AWS’s own notice). Most affected customers recovered by restoring backups or copying data held elsewhere. It is an extreme case, but it shows what a copy outside the Region is for.

Six checks to run this week

CheckWhy it mattersWhere to look
Which zones does each production workload use?A single-zone service fails with its zoneEC2, load balancer and Auto Scaling settings
Is Multi-AZ switched on for databases?Not automatic for RDS, Redshift or ElastiCacheRDS console, “Multi-AZ” setting
Are any dependencies single-zone?One zonal component can take down a Multi-AZ serviceArchitecture diagram, EBS and network layout
Is there a Region-level recovery option, and has it been timed?A plan nobody has timed is a guessLast failover test report
Is your impact tolerance stated in customer terms?“Payments unavailable for four hours” is testableYour important business services list
Who tells customers, and how, if your own systems are down?Your website or email may share the dependencyIncident communications plan

A worked example

(Illustrative.) A small payments firm has set a four-hour impact tolerance for “send a payment”. Using the reported timings, a regional problem of about five hours from first errors to mitigation would breach it.

DesignSurvives a zone failure?Stays inside a 4-hour tolerance in a regional problem?Illustrative extra monthly cost
Single zoneNoNoNone
Multi-AZYesNot by design5-15%
Multi-AZ plus pilot light in a second RegionYesYes, if the failover is tested15-35%

Percentages are planning assumptions as a share of the production bill, not AWS prices. On a £10,000-a-month bill, the second Region adds roughly £1,000 to £2,000 on top of Multi-AZ. Whether that is worth it depends on what an hour of downtime costs the firm, which is a sum worth doing before an outage rather than after. The RTO vs RPO and AWS disaster recovery strategies posts show how to set the targets and match the pattern.

The UK regulatory backdrop

Google Cloud EMEA is one of the four providers designated as critical third parties to the UK financial sector on 10 July 2026, alongside AWS, Microsoft and Oracle, per the Bank of England. Designation brings regulatory oversight of the provider, but AWS notes that the regime does not change firms’ own obligations. Under the FCA’s operational resilience rules, regulated firms must be able to stay within impact tolerances, whichever cloud they use. New FCA, PRA and Bank of England incident and third-party reporting rules take effect on 18 March 2027 (verify the final rules before relying on the date). For the wider picture, see The FCA’s Frontier AI Warning.

Also this fortnight

AWS announcementRelevance to a UK SME
Amazon’s resilience testing for Prime Day: over 44,000 AWS Fault Injection Service experiments before the eventA reminder that resilience is tested, not assumed
GuardDuty RDS Protection for data activity: detects exfiltration and destruction on Aurora and RDS for PostgreSQL; 30-day free trial per account per RegionWorth trialling if you hold client data in PostgreSQL
AWS Continuum for code vulnerabilities is generally availableAt launch it was listed for US East (N. Virginia) and US West (Oregon), not London, so not yet an option for UK-resident data
re:Invent runs 30 November to 4 DecemberWe will cover the announcements that matter

What to do next

Pick your most important service, find the zone and Region it depends on, and ask whether you could recover it inside your tolerance if both were gone for five hours. If you cannot answer in a sentence, that is the gap.

A Yemberzal Disaster Recovery Assessment maps each important service to its AWS dependencies, sets recovery targets per system, and proves them with a timed failover drill.