# One Google zone took down UK banks: your Azure zone audit

A power event in one Google Cloud zone, europe-west2-b in London, left Revolut, HSBC, Lloyds and the UK courts' video platform degraded for most of 20 October 2026, and regulators were asking questions within hours. Azure has the same three-zone model in Sweden Central and the same failure mode when resources are left nonzonal, so here is the service-by-service audit, the Sweden Central price of fixing it, and what DORA Articles 11 and 12 already demand.

- Published: 2026-10-21 · Category: Azure & Cloud · Tags: Azure Availability Zones, Resilience, Google Cloud Outage, DORA, Sweden Central, Azure SQL Database, App Service, Azure Storage, Finansinspektionen, Business Continuity
- Author: Technspire AB, Stockholm (https://technspire.com)
- Canonical: https://technspire.com/en/blog/one-google-zone-took-down-uk-banks-your-azure-zone-audit

At 08:08 Swedish time on Tuesday 20 October 2026, a power event in a single Google Cloud zone, europe-west2-b in London, started an outage that Google's own status page did not close until 16:00. In between, Revolut customers could not pay by card or withdraw cash, HSBC, Lloyds and Halifax reported service problems, and the Cloud Video Platform that HM Courts and Tribunals Service uses for remote hearings was down across large parts of England and Wales. One zone. Eight hours. Banks and courts offline. If you run production on Azure in Sweden Central, this is the cheapest resilience lesson you will get this year, because someone else paid for it.

## What actually happened

Google's incident record is unusually precise about scope. The incident opened at 23:08 Pacific time on 19 October (08:08 CEST on the 20th) and was marked resolved at 07:00 Pacific (16:00 CEST). The stated cause was short: "a power event caused an outage within europe-west2-b zone." The incident page lists more than 30 affected products, from Compute Engine, Kubernetes Engine and Cloud Run through Cloud SQL, Spanner, Pub/Sub, Memorystore and Cloud Storage. Google has promised a full analysis "once we have completed our internal investigation."

The customer-side timeline, pieced together from the Guardian, ABC and the UK status updates, ran like this:

| Time (CEST) | What was visible |
| --- | --- |
| 08:08 | Google opens the incident: elevated errors and network failures in europe-west2-b. |
| Morning | Revolut confirms disruption to card payments and ATM withdrawals. HSBC, Lloyds and Halifax acknowledge problems. DPD, Royal Mail and Rightmove report website issues. |
| 11:00 | The Criminal Bar Association says the courts' Cloud Video Platform has been down across large parts of England and Wales since 10:00 UK time. Some hearings cannot proceed. |
| 14:00 | Services begin returning. Google says the issue "has been mitigated for most of the customers." |
| 16:00 | Google closes the incident. Revolut still reports problems two hours later. |

The regulatory response was immediate. The Financial Conduct Authority said it expected firms to fix issues quickly because "people need to be able to access their money and make payments." The Prudential Regulation Authority was in contact with Google. The chair of the Treasury Committee asked Google for details by 4 November. Under DORA, a Swedish bank in the same position would be filing a major incident report with Finansinspektionen rather than answering a parliamentary committee, but the questions would be the same: why did one datacenter's power take out a critical function, and why did recovery take hours?

## The uncomfortable part: zones existed and it still happened

europe-west2 has three zones. That is the whole design point of zones: separate power, separate cooling, separate networking, so that a power event in zone b leaves a and c standing. Nobody outside the affected firms knows yet whether their workloads were pinned to a single zone, or were nominally multi-zone with a single-zone dependency buried somewhere in the stack. Two things are already clear from the public record, though.

First, a zone-level fault produced customer-facing outages measured in hours, not seconds. Whatever the architecture diagrams said, the effective blast radius was the zone, and the effective recovery time was Google's recovery time. Second, the incident title itself was "Multiple services are experiencing issues in the europe-west2 region," and the per-product durations on the status page show regional services such as Cloud Storage degraded for over three and a half hours. A zone power event can ripple into regional control planes. Zone redundancy is necessary. It is not sufficient on its own, and anyone selling it as a complete answer has not read the status page.

Both lessons transfer directly to Azure, because Azure's zone model is built on the same assumptions and has the same failure modes when customers skip the configuration.

## How Azure zones work, and the three words that decide your outcome

Sweden Central, in Gävle, has three availability zones. So do Norway East, Denmark East, North Europe and West Europe. Microsoft's reliability documentation describes each zone as a logical grouping of one or more datacenters with "independent power, cooling, and networking infrastructure," typically several kilometres apart and usually within 100 kilometres, with a round-trip latency target under roughly 2 milliseconds between zones. Data transfer between zones in the same region is free. So far, so Google.

The decision that matters is not whether your region has zones. It is which of three deployment types each resource uses:

- **Zone-redundant.** The service spreads instances or replicas across two or more zones and manages failover itself. Some services do this automatically in zoned regions; many require you to turn it on. This is what survives a europe-west2-b.
- **Zonal.** You pin the resource to one zone you choose. Microsoft's own wording: zonal deployments "don't automatically provide resiliency to availability zone outages." You get isolation from other zones' faults and low intra-zone latency, and you own the failover.
- **Nonzonal, also called regional.** You did not configure zones at all. Azure places the resource in any zone it likes, you cannot see which, and "if any availability zone in the region experiences an outage, nonzonal resources might be in the affected zone and could experience downtime."

That third category is where most Azure estates built before 2023 still sit. A virtual machine created without a zone parameter, an App Service plan on a Standard tier, a General Purpose SQL database with zone redundancy left at its default of off, a storage account on LRS: each one is a europe-west2-b waiting for its power event. The Google outage did not expose a flaw in zones. It exposed how many production systems never opted into them.

## The audit: service by service

Work through the Azure reliability guides for each service in your critical path. The table summarises what Microsoft's current documentation says for the services that appear in most Swedish enterprise estates. Confirm against the live guide before you change anything; the requirements move.

| Service | Zone support | What to check | Cost of fixing it |
| --- | --- | --- | --- |
| Virtual Machines | Zonal only. A single VM is never zone-redundant. | Is the zone property set? Is there a second VM in another zone behind a zone-redundant load balancer? Microsoft's guidance for a zonal VM in a dead zone is blunt: "VMs remain down until the availability zone recovers." | No price difference between zonal and nonzonal. The cost is the second VM and the ZRS disks. |
| App Service | Zone-redundant on Premium v2, v3 and v4 plans only. | Plan tier, the zoneRedundant flag, and whether the plan's scale unit supports zones at all (if not, you must redeploy to a new plan). | No separate meter. The platform enforces a minimum of two instances and bills for both. |
| Azure SQL Database | Zone-redundant on General Purpose, Business Critical, Hyperscale and Premium. Not on Basic or Standard. | The zone-redundant property per database and per elastic pool. Enabling it on GP, BC and Premium is an online operation; Hyperscale requires a redeploy. | Extra charge on General Purpose. No extra charge on Business Critical or Premium, because the replicas you already pay for are simply spread across zones. |
| Storage accounts | ZRS, GZRS and RA-GZRS are zone-redundant. LRS is not. | Redundancy SKU on every account in the critical path, including the boring ones holding Functions code, App Service content or diagnostic logs. | See the Sweden Central numbers below. |
| AKS | Both zonal and zone-redundant node pools. | Zones on each node pool, plus the storage class of every persistent volume. A cluster across three zones with a zonal managed disk is still a single-zone application. | Node pool spread is free; ZRS disks cost more than LRS. |
| Microsoft Foundry Agent Service | Microsoft-hosted components are zone-redundant. | Your own dependencies. The guide says to "verify that your customer-managed dependencies (Cosmos DB, AI Search, Storage) are also configured for zone redundancy," and states that Foundry "doesn't provide automatic failover or disaster recovery." | Cosmos DB and AI Search zone redundancy carry their own pricing; check each. |

Two details from the documentation deserve emphasis because they bite in exactly the way Tuesday bit Google's customers. For App Service, Microsoft warns that during a zone outage "Azure doesn't guarantee that requests for more instances succeed," and recommends over-provisioning if you need guaranteed capacity with a zone down. In other words, a two-instance zone-redundant plan may survive the outage at half capacity. For SQL Database, zone failover is automatic and "typically less than 30 seconds" with no data loss, but "Microsoft doesn't automatically notify you when a zone is down." You find out from Service Health alerts you configured, or from your customers.

## The cost math in Sweden Central

The objection to zone redundancy is always cost, so here are the actual list prices, pulled from the Azure retail prices API for the swedencentral region on 21 October 2026. Hot block blob storage, first tier, per GB per month:

| Redundancy | Survives | USD per GB-month | 10 TB per month |
| --- | --- | --- | --- |
| LRS | Disk and rack failure | 0.0184 | about 188 |
| ZRS | Loss of one zone | 0.0230 | about 236 |
| GRS | Loss of the region (async copy in Sweden South) | 0.0392 | about 401 |
| GZRS | Loss of one zone and loss of the region | 0.0460 | about 471 |

Moving 10 TB of hot data from LRS to ZRS costs roughly 48 dollars a month at list price. That is the entire premium for making the storage layer survive the Azure equivalent of europe-west2-b. Set it against what a single hour of card payments being declined costs a bank, or what a day of adjourned hearings costs a court system, and the argument ends.

Compute is where the real money sits, and the pattern is the same across services: zone redundancy itself is free, the second instance is not. A zone-redundant App Service plan is two Premium instances instead of one. A pair of VMs across zones behind a Standard load balancer is two VMs instead of one. For SQL Database the premium only applies to General Purpose; if you are already paying for Business Critical you are paying for the replicas and simply not spreading them. Check that flag today. It costs nothing.

The one Azure-specific trap in the cost model is the App Service scale unit. If your existing plan landed on a scale unit without zone support, you cannot flip the flag. You redeploy to a new plan, which means a new outbound IP set, new deployment slots and a cutover. Budget engineering time, not just the second instance.

## Three commands before you touch anything

Start by learning which physical zone your logical zones map to. Azure assigns the mapping per subscription, so "zone 1" in your production subscription may be a different building from "zone 1" in your shared-services subscription. If a workload spans subscriptions, two resources both in logical zone 1 may or may not share a power feed.

```
az account list-locations \
  --query "[?name=='swedencentral'].availabilityZoneMappings" -o table
```

Then inventory what is actually zonal, zone-redundant or nothing. Resource Graph is the fastest way across subscriptions. The two queries below find VMs with no zone set and App Service plans with zone redundancy off.

```
az graph query -q "
Resources
| where type =~ 'microsoft.compute/virtualmachines'
| where location =~ 'swedencentral'
| where isnull(zones) or array_length(zones) == 0
| project name, resourceGroup, subscriptionId"

az graph query -q "
Resources
| where type =~ 'microsoft.web/serverfarms'
| where location =~ 'swedencentral'
| where properties.zoneRedundant != true
| project name, resourceGroup, sku.tier, properties.numberOfWorkers"
```

Finally, prove it. Azure Chaos Studio has a Compute Zone Down scenario that shuts down VMs and scale set instances in a target zone. Run it in a staging environment that mirrors production topology, and watch whether the application stays up or whether a forgotten zonal dependency (a Redis cache, a file share, a managed disk) takes it down. Google's customers ran this experiment on Tuesday without choosing to. A controlled run on a Thursday afternoon is cheaper.

## The Swedish and EU angle: DORA already requires this

The UK response on Tuesday, with the FCA and PRA contacting Google within hours and a parliamentary committee demanding answers, is a preview of what any EU financial entity faces under the Digital Operational Resilience Act, Regulation (EU) 2022/2554, in force since 17 January 2025. Three of its provisions map straight onto a single-zone outage.

- **Article 11** requires an ICT business continuity policy with plans that are periodically tested, paying particular attention to critical or important functions that rely on third-party providers. A hyperscaler zone is a third-party dependency, and "we assumed the cloud handled it" is not a tested plan.
- **Article 12(4)** requires financial entities to "maintain redundant ICT capacities equipped with resources, capabilities and functions that are adequate to ensure business needs." A zonal VM with LRS disks is, by Microsoft's own description, a resource that stays down until the zone recovers. It is hard to describe that as redundant capacity.
- **Article 12(6)** requires recovery time and recovery point objectives per function. On Tuesday the effective RTO for affected firms was Google's RTO. If your RTO for a critical function is shorter than the time it takes a cloud provider to restore power to a building, zone redundancy is not optional; it is how you meet the number you wrote down.

Finansinspektionen is the competent authority for Swedish entities and has made clear it is paying attention. In July 2026 it published its first annual report on major ICT incidents reported under DORA, finding that failures in systems and processes together with external events account for the vast majority of incidents, with third-party dependencies prominent in the Swedish data, and concluding that resilience work "needs to continue to be strengthened." FI has also selected around 50 Swedish financial firms for an in-depth review of how they implemented DORA. A Swedish bank whose card payments went down because of one Azure zone would be explaining itself to FI with that report on the table.

Outside finance, the logic carries into NIS2 scope for Swedish essential and important entities, and into every public-sector contract that specifies availability targets. The question a procurement officer or auditor will now ask, with Tuesday's headlines in hand, is simple: which of your systems would have survived a europe-west2-b? For Azure estates the honest inventory is the Resource Graph output above, and most organisations will not like what it shows.

One more EU-specific note. Sweden Central's paired region, Sweden South, is access-restricted, so for many organisations the only redundancy that keeps data inside Sweden is in-region zone redundancy. Microsoft's guidance for exactly this case is that "deploying across multiple availability zones is the primary recommended way to maximize availability without moving data outside the region." Data residency and zone redundancy are not in tension. The former makes the latter mandatory.

## The checklist

1. Run the Resource Graph queries across every production subscription. List every nonzonal VM, every non-Premium App Service plan and every LRS storage account in the critical path.
2. Flip the free switches first: zone redundancy on Business Critical and Premium SQL databases, zone spread on AKS node pools, ZRS on the storage accounts that hold application content and Functions code.
3. Price the paid switches: second App Service instance, second VM plus zone-redundant load balancer, ZRS disks, General Purpose SQL zone redundancy. Put the numbers next to your RTO per function.
4. Check whether each App Service plan's scale unit supports zones. If not, plan the redeploy as a project, not a toggle.
5. Configure Service Health and Resource Health alerts. Azure will not tell you a zone is down otherwise.
6. Run the Chaos Studio Compute Zone Down scenario against staging. Fix whatever it finds.
7. For Foundry workloads, confirm Cosmos DB, AI Search and Storage dependencies are zone-redundant, and decide separately how you handle a regional failure, because Foundry will not do it for you.
8. If you are in DORA scope, write the result into the Article 11 continuity plan and the Article 12 RTO/RPO register, and schedule the test.

Google will publish its post-incident analysis in due course. Do not wait for it. The customer-side flaw it will describe is already visible in your own subscription, and the query to find it takes four seconds.

## Sources

- [Google Cloud Service Health: Multiple services are experiencing issues in the europe-west2 region (20 October 2026)](https://status.cloud.google.com/incidents/Xs2XTHzAVC9YnafnPyzj)
- [The Guardian (syndicated via AOL): Google cloud failure hits millions as UK courts and banks knocked offline (Makortoff and Kollewe, 20 October 2026)](https://www.aol.co.uk/articles/millions-unable-revolut-app-cards-094539000.html)
- [ABC News: European banks, websites hit as Google Cloud data centre goes offline for hours](https://www.abc.net.au/news/2026-10-20/google-cloud-failure-europe-banks/107290238)
- [Microsoft Learn: What are Azure availability zones?](https://learn.microsoft.com/en-us/azure/reliability/availability-zones-overview)
- [Microsoft Learn: List of Azure regions (zone counts and paired regions)](https://learn.microsoft.com/en-us/azure/reliability/regions-list)
- [Microsoft Learn: Azure services that support availability zones](https://learn.microsoft.com/en-us/azure/reliability/availability-zones-service-support)
- [Microsoft Learn: Reliability in Azure Virtual Machines](https://learn.microsoft.com/en-us/azure/reliability/reliability-virtual-machines)
- [Microsoft Learn: Reliability in Azure App Service](https://learn.microsoft.com/en-us/azure/reliability/reliability-app-service)
- [Microsoft Learn: Reliability in Azure SQL Database](https://learn.microsoft.com/en-us/azure/reliability/reliability-sql-database)
- [Microsoft Learn: High availability and resiliency for Microsoft Foundry projects and Agent Service](https://learn.microsoft.com/en-us/azure/foundry/how-to/high-availability-resiliency)
- [Azure Retail Prices API (swedencentral, Storage, General Block Blob v2, queried 21 October 2026)](https://prices.azure.com/api/retail/prices)
- [Regulation (EU) 2022/2554 (DORA), Articles 11 and 12](https://eur-lex.europa.eu/eli/reg/2022/2554/oj/eng)
- [Finansinspektionen: Rapport om allvarliga IKT-relaterade incidenter enligt Dora-förordningen (3 July 2026)](https://www.fi.se/sv/publicerat/nyheter/2026/rapport-om-allvarliga-ikt-relaterade-incidenter-enligt-dora-forordningen)
- [Finansinspektionen: Om Dora](https://www.fi.se/sv/bank/it-risker-dora/om-dora/)

---

Technspire AB builds AI agents, Azure OpenAI solutions, and production web platforms for Swedish and EU enterprises. Book a call: https://calendly.com/technspire · hello@technspire.com · More articles: https://technspire.com/en/blog · Site overview for agents: https://technspire.com/llms.txt