No Second Region: What the Google Cloud London Outage Teaches Every Single-Cloud Business

On 20 October, a chunk of UK business ground to a halt because of a problem in a single building's worth of computers. Google Cloud's London region — the one labelled europe-west2 in dashboards across the country — ran into trouble, and firms that had quietly built everything on top of it discovered they had no plan B. Websites went dark. Internal tools stopped responding. Support queues filled with the same question from every direction: when will this be back?

Here is the uncomfortable part. For most of the businesses affected, this was not really Google's failure. It was theirs.

That sounds harsh, so let me explain. Cloud providers publish their uptime numbers, their regional architecture and their recommended patterns in open documentation. They tell you, repeatedly, that a single region can and will fail. The outage exposed a decision that thousands of companies made without ever deciding anything at all: they accepted the default, which was to run in one place, and assumed that place would always be there.

Why 'the London region' is a trap

Google Cloud has exactly one region in the United Kingdom. That is europe-west2. If your workloads run there and only there, and that region has a bad day, you have nowhere to fail over without leaving the country.

For a lot of UK firms, leaving the country is not a casual choice. Data residency rules, customer contracts, and plain nervousness about where personal data physically sits all push companies towards keeping everything on home soil. So the logic goes: UK data must stay in the UK, Google has one UK region, therefore we run in that one region. Each step feels reasonable. The destination is a single point of failure with a Union Jack on it.

This is the bit that makes the London outage more instructive than a generic 'cloud goes down' story. It is not simply that a region failed. It is that the single-region default collided with a data-residency assumption, and the two together removed every escape route. You could not spin up in Belgium or Frankfurt at short notice without a conversation involving your compliance team, your lawyers, and possibly your biggest customer.

Contrast that with how a resilient design handles the same event. Multiple availability zones within the region catch a lot of smaller faults automatically. A warm standby in a second region — even one outside the UK, pre-cleared for exactly this scenario — turns a day-long outage into a fifteen-minute wobble. The businesses that stayed online on 20 October were not luckier. They had made different decisions earlier.

The resilience you can actually build

Resilience is not a product you buy. It is a set of choices, each with a cost, that you make on purpose. Here is a practical checklist you can work through this quarter, roughly in order of effort.

1. Know what 'down' actually costs you. Before you spend a penny on redundancy, put a number on an hour of downtime for each system. Your public website, your order-processing pipeline, and your internal HR tool do not deserve the same investment. Most firms discover that two or three systems carry almost all the risk, and the rest can sit on a single region quite happily.

2. Use multiple availability zones first. This is the cheapest meaningful step. Within europe-west2 there are separate zones with independent power and networking. Spreading your compute and databases across zones protects you from a surprising share of failures and usually costs little beyond some configuration time. If you are running in a single zone today, fix that before anything else.

3. Decide your second region in advance. For the systems that genuinely cannot be offline, pick a secondary region now, while nothing is on fire. Clear the data-residency question with your compliance people in calm conditions. Document exactly what data may leave the UK, under what legal basis, and for how long. Write it down. On the day of an outage you want to execute a plan, not start a debate.

4. Keep your backups somewhere else entirely. A backup that lives in the same region as the thing it protects is not really a backup. Store copies in a second region or, ideally, a second provider. Test a restore at least twice a year. An untested backup is a hope, not a safeguard.

5. Automate the failover, then rehearse it. Infrastructure defined as code — so you can rebuild an environment from a repository rather than from memory — is what separates a smooth recovery from a frantic one. Run a game day where you deliberately 'lose' the London region and time how long it takes to come back. The first attempt will be embarrassing. That is the point of doing it when the stakes are low.

This is also a negotiation, not just an engineering problem

There is a commercial angle people skip. When you sign with a cloud provider, you are accepting their service level agreement, and most SLAs are far weaker than customers assume. Service credits typically refund a slice of your bill for the month. They do not compensate you for the revenue you lost, the customers who left, or the overtime your team worked to recover.

So read the SLA properly. Understand what counts as downtime, how it is measured, and what you are actually owed. Then ask the harder question: given that the provider's own contract will not make you whole, how much resilience do you need to build yourself? The answer, almost always, is 'more than the default gives you'. The provider is responsible for the reliability of their region. You are responsible for what happens to your business when that region fails anyway.

The regulatory edge for financial firms

If you are a regulated financial firm, this stops being a matter of good practice and becomes a matter of compliance. Under the FCA and PRA operational resilience rules, firms must identify their important business services and set impact tolerances — the maximum disruption they can withstand before causing intolerable harm to customers or market integrity. Crucially, you must stay within those tolerances even when a third party fails. 'Our cloud provider had an outage' is not a defence. The regulator expects you to have planned for exactly that.

That means mapping your dependencies down to the region level, testing severe-but-plausible scenarios — such as losing europe-west2 for a working day — and demonstrating that your important services keep running or recover inside tolerance. The London outage was, for many regulated firms, an unplanned fire drill. Some passed. Some have awkward conversations ahead.

The lesson in one line

The cloud did not let these businesses down. The single-region default did, and they signed up for it without noticing. Pick your second region, test your failover, read your SLA, and — if you are regulated — prove you stay inside tolerance when your provider does not.

If you are not sure where your single points of failure sit, that is the first thing worth finding out. We help UK firms map exactly this, and we would rather do it on a quiet Tuesday than during the next outage. Get in touch with Cloudworks and let's look at where your architecture would break.