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 detail | Source |
|---|---|
| Zone with the fault: europe-west2-b | The 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:00 | Northdoor |
| Revolut confirmed a multi-service disruption and said customer money and data were safe | The 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 feasible | The 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
| Check | Why it matters | Where to look |
|---|---|---|
| Which zones does each production workload use? | A single-zone service fails with its zone | EC2, load balancer and Auto Scaling settings |
| Is Multi-AZ switched on for databases? | Not automatic for RDS, Redshift or ElastiCache | RDS console, “Multi-AZ” setting |
| Are any dependencies single-zone? | One zonal component can take down a Multi-AZ service | Architecture diagram, EBS and network layout |
| Is there a Region-level recovery option, and has it been timed? | A plan nobody has timed is a guess | Last failover test report |
| Is your impact tolerance stated in customer terms? | “Payments unavailable for four hours” is testable | Your important business services list |
| Who tells customers, and how, if your own systems are down? | Your website or email may share the dependency | Incident 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.
| Design | Survives a zone failure? | Stays inside a 4-hour tolerance in a regional problem? | Illustrative extra monthly cost |
|---|---|---|---|
| Single zone | No | No | None |
| Multi-AZ | Yes | Not by design | 5-15% |
| Multi-AZ plus pilot light in a second Region | Yes | Yes, if the failover is tested | 15-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 announcement | Relevance to a UK SME |
|---|---|
| Amazon’s resilience testing for Prime Day: over 44,000 AWS Fault Injection Service experiments before the event | A 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 Region | Worth trialling if you hold client data in PostgreSQL |
| AWS Continuum for code vulnerabilities is generally available | At 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 December | We 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.