When one zone fails, the first question isn’t how to fail over. It’s what was running there.
At 07:08 on Tuesday, one of Google Cloud’s three London zones lost power.
Within hours, UK banks, a parcel carrier and property sites were reporting problems, according to outage trackers. Google’s advice to customers was practical: “If feasible, the impacted customer may try to migrate their workload impacted to another available location (zone or region).”
It is good advice. It also assumes you know which of your workloads were impacted. For many organisations, that was the one question nobody could answer quickly.
One zone, many front doors
A cloud region is split into zones so that a failure in one stays contained. London has three. The power event hit one of them, europe-west2-b, and Google’s status page went on to list 38 affected services across the region.
The effect reached well beyond the zone itself. Services several layers removed went down too, because something they depended on ran there. Dr Amro Al-Said Ahmad of Keele University called it “the dependency effect of modern cloud ecosystems.”
Outages happen, and no provider avoids them entirely. The useful question isn’t whose fault it was. It’s what you could have known before 07:08.
The assumption that broke
“We’re in the cloud, so we’re resilient” is one of the most common assumptions in IT. It only holds if workloads are actually spread across zones.
Estates drift into a single zone without anyone deciding it. A database gets created without a standby. A Kubernetes cluster is set up as zonal rather than regional. A virtual machine that was meant to be temporary is still running three years later.
Every dashboard reports each resource as healthy. None of them tells you that everything important sits in one place. That only becomes visible when the place fails.
Why asking people is too slow
At 07:30 on a bad morning, the inventory lives in three places: a configuration database, last quarter’s architecture diagram and the memory of whoever built it. So the answer arrives the slow way, with messages to every team asking them to check their services.
One CTO told us log4j felt exactly the same. The patch was never the hard part. Finding where it ran was, and a zone outage asks that same question with the clock already running.
For UK financial services, that clock is formal. In-scope firms have had to stay within impact tolerances for important business services since 31 March 2025, and new FCA incident and third-party reporting rules take effect on 18 March 2027. Everyone else will hear the same question from their board in plainer words: what did we lose, and why?
Make “where is it?” a lookup
The alternative is to stop treating the inventory as a document and start treating it as a live record.
A system that discovers the estate continuously, read-only, can record which zone or region each resource runs in. It keeps dated snapshots, so you can show what ran where on the day. When a zone fails, the list of what lived there already exists.
It also shows risk before the outage rather than during it. A production database estate with Multi-AZ disabled can look perfectly healthy on a compliance report. On a map of what runs where, it stands out.
Knowing where something runs is also what makes acting on all of it possible. For a Nordic enterprise on AWS, one security rule was applied and verified across 21 security groups in 13 regions in 15 minutes. People set the boundaries and approve anything that matters, and every action is on the record.
Back online is not the same as fixed
After a zone fails there are two jobs, and they are easy to confuse.
The first is remediation: getting services back as fast as possible. That is what Google’s advice was for. Restart the workload in a healthy zone or region, restore from backup, send traffic somewhere that works. It is measured in minutes and hours, and it ends when customers can log in again.
The second is the remedy: changing the estate so the same failure can’t take the same services down next time. That means running production across zones by design. A database with a standby in a second zone, a regional cluster rather than a zonal one, instances spread across zones by a managed group rather than placed by hand. For the services that matter most, it can mean a second region too.
Most organisations stop after the first job. The incident closes when the service is back, and the work that would prevent a repeat becomes a ticket in someone’s backlog. And the remediation itself can rebuild the problem. A workload moved to another zone in a hurry is still in one zone. It has just changed address.
The remedy isn’t “make everything multi-region”. That adds cost and complexity to workloads that could happily be down for an afternoon. The right level of resilience follows the business: multi-zone as the default for production, multi-region where the impact tolerance demands it. For UK financial services, those tolerances are already set, service by service.
Both jobs start with the same map. Remediation needs to know what was in the zone this morning. The remedy needs to know what is still in only one zone next month, and the month after, because estates drift back. A new database is created without a standby. An emergency move becomes permanent. A record that refreshes continuously catches that drift while it is still a configuration setting, not an outage.
The questions leaders should ask
- If one zone in our main region failed at 7am, how long would it take to list everything that ran only there? Minutes, or a morning of messages?
- Which of our production databases and clusters have a standby in another zone, and when did someone last check?
- After our last incident, did we change the design or just restore the service? Is anything we moved in a hurry still sitting in one zone?
- Could we show a regulator or the board what ran where on the day? That means a dated record, not last year’s diagram.
Resilience starts with a map
Zones were designed to keep failures small. They only do that for organisations that know what is in them. The map tells you what to move this morning and what to rebuild this quarter.
The next outage will hit a different zone, in a different region, on a different morning. The organisations that recover fastest will be the ones for whom “what was running there?” is a lookup, not a hunt.
A read-only pilot on one cloud account shows what runs where, zone by zone, within days.
