Analysis · Published 29 Aug 2026

You Are Not Multi-Region Until You've Turned Off Your Primary Region

Bob Boole

AI editorial persona, Abyshire News Desk · About the desk

"We're multi-region" is a claim about a configuration almost nobody has tested by actually removing their primary region. Write the test into the contract as four pass/fail lines and the claim finally gets a price.

Listen7 min

Here is a clause worth putting in front of any supplier that calls its platform multi-region. On a named date, in daylight, with the primary region made genuinely unreachable, the service passes four tests written down before the run so nobody can argue the result afterwards. One: a brand-new user, with no warm cache anywhere, authenticates end to end while the primary is dark. Two: a write completes and is durably readable from the secondary inside the recovery-point objective you were sold, not the one they wish they had promised. Three: measured time to serve from the secondary meets the stated recovery-time objective, on the clock. Four: no step in the runbook needs a console, secret or credential that itself lives in the dead region. Four lines, pass or fail. Suddenly "we're multi-region" has a price and an audit trail.

Price both sides and the case makes itself. The drill costs a planned window, an engineer's afternoon and, at worst, a few minutes of deliberately degraded service you chose and announced. The failed test costs whatever your busiest hour is worth, at the moment you least control it. Take a retailer turning over £1m of online sales on an ordinary weekday: an unplanned regional outage that drops checkout for three hours at peak is not a rounding error, and it arrives with refunds, support load and a day of reputation to buy back. The drill is that same failure, bought in daylight for the price of an afternoon. You are not choosing whether to run the test. You are choosing whether you or your customers run it, and on whose clock.

One real example stands in for the pattern. Late on 19 October 2025 in US Pacific time, in the early hours of 20 October by UTC, a race condition in the automated DNS management for DynamoDB in AWS's us-east-1 left the regional endpoint pointing at an empty record, per AWS's post-event summary. The wider pattern that followed, that a long tail of "global" services which had never run the test discovered live that their redundancy stopped at compute, is the desk's reading rather than anything AWS stated.

What does "multi-region" actually guarantee?

On its own, almost nothing. Running compute in two regions guarantees you have compute in two regions, and says nothing about whether the second can serve a request end to end when the first is unreachable. A request carries more than compute. It carries authentication, a session token validated somewhere, a configuration lookup, a feature flag, a metadata read, a queue, a lock, a certificate check. Any one of those pinned to a single region turns your redundant fleet into expensive decoration. That is why the failure that hurts is rarely the server dying or the database failover you rehearsed. The outage arrives and the identity layer will not answer, or the control plane that hands out configuration has gone dark, or a metadata store that everything reads on startup, and that nobody listed as critical because it never troubled a latency dashboard, has left with the region. The redundant application cannot boot because the unglamorous state it depends on lives in one place. You were single-region the whole time; you just could not see the string until someone pulled it.

How would you actually prove a failover works?

Not with a diagram review. With a controlled amputation. Pick a real production workload, not a staging toy. In a planned daylight window, with rollback ready, make the primary region genuinely unreachable at the network edge. Do not simply scale it to zero, because that quietly leaves DNS, identity and certificate paths intact and hands you a false pass. Then hold the run against the four criteria from the top of this piece, and treat any single miss as your true single point of failure, whatever the box count claims. A miss found this way is the cheapest result you will ever buy, because you bought it in daylight instead of at 3am in front of your customers.

Whose fault is it when a "global" service fails to fail over?

Mostly the buyer's, and that is the part that stings. Every cloud outage invites the reflex of filing it under "the provider let us down". Sometimes that is fair. Often it is not, because graceful degradation is a deployment decision the customer owns. A well-built service, cut off from a backend it cannot reach, falls back to a usable baseline: it serves cached content, queues writes for later, drops a non-essential feature and keeps the checkout working. A badly built one goes inert, because nobody decided in advance what "working, but degraded" should look like. That absence is a configuration defect on your side. The provider supplied the raw materials for failover; whether you assembled them into something that survives is on you. This is exactly the continuity assumption a serious technical strategy should force into the open rather than leave as folklore.

So why does almost nobody run the test?

Because the incentives are backwards. A real failover drill has a visible blast radius and a named owner who carries the blame if it goes sideways. The risk of skipping it is diffuse, deferred and deniable, and it lands on whoever is on call the night the provider runs the test for you. Set a certain small embarrassment now against a possible large one later that someone else might absorb, and most organisations quietly choose later. The engineering fix is easy. The organisational fix is harder: make the person who signs off "we are resilient" also sign the runbook that proves it, and put the four-line clause where it belongs, in the contract.

So the question to put to any team that calls its stack resilient is short and awkward. When did you last turn off your primary region and watch what happened? If the answer is never, you do not have a multi-region system. You have a diagram, and a bill waiting to be presented at the worst possible hour. Force the question into the open before an engagement ships, because the worked examples that survive contact with production are the ones where someone pulled the string on purpose first.

Questions people ask

What caused the AWS us-east-1 outage in October 2025?

According to AWS's post-event summary, a race condition in the automated DNS management for DynamoDB in the us-east-1 region left the regional DynamoDB endpoint pointing at an empty DNS record, so clients could no longer resolve it. Because core EC2 subsystems depend on DynamoDB, its recovery left a backlog of network state to reconcile, which delayed new instance launches for hours. The failure began late on 19 October 2025 Pacific time (early 20 October UTC). It was regional, but many "global" services felt it because they anchor state in that one region, which is the desk's reading rather than a claim AWS made.

What usually causes a supposedly redundant system to go down in a regional outage?

Not compute. It is typically shared state that was never flagged as critical: an identity or authentication service, a control plane that distributes configuration, or a metadata store that everything reads on startup. These work invisibly every day, so they rarely appear on resilience reviews until the region hosting them becomes unreachable.

Is graceful degradation the cloud provider's responsibility?

No. The provider supplies the building blocks for failover, but deciding what a degraded-but-usable service looks like, and configuring the fallbacks that deliver it, is the customer's design choice. A service that goes fully inert when a backend is unreachable is exhibiting a configuration gap on the buyer's side, not just a provider outage.

Written by an AI editorial persona of Abyshire's proprietary editorial system and reviewed by our team.