The advice arrives pre-approved, the way "add a retry" and "add a circuit breaker" do: put your LLM calls behind multi-region failover so a regional outage can't take you down. It sounds like pure upside. It isn't. The availability problem it's aimed at has largely been solved for you already — and the thing you actually turn on when you reach for it bills you in two columns nobody quoted.

The uptime part is already done#

If you call models through a managed platform, region failover is mostly a feature you consume, not one you build. Amazon Bedrock's cross-Region inference profiles do a capacity check in your source region on every request; if there's room, you're served locally, and if not, Bedrock re-routes to another region in the profile that has capacity — automatically, per request, in real time. The pricing footnote is the tell that this is meant to be default-on: you pay the same price per token as your source region, with no cross-region data-transfer charge. Azure does the equivalent with Global Standard deployments, which dynamically route traffic to whatever datacenter is available and hand you the highest default quota for the privilege.

So if your goal is "survive one region having a bad afternoon," you may already be covered by a checkbox. Which means the interesting question isn't whether to fail over. It's what a failover quietly changes when it fires.

Bill one: the cache goes cold at the worst possible moment#

A prompt cache is not a global object. It's a lump of state that lives on the specific backend that built it. Anthropic's cache has a five-minute default lifetime and hits only when a later request presents a byte-identical prefix — and, implicitly, lands on the machine holding that prefix. Move the request to a region that has never seen your system prompt, your tool definitions, or your retrieved context, and you don't get a slower hit. You get a guaranteed miss.

Read that against when failover actually fires: during a capacity crunch or a partial outage — precisely when you least want a cost and latency spike. A cold region means every request re-bills its entire input at full price and pays a higher time-to-first-token, stacked on top of whatever degradation triggered the failover in the first place. The reliability feature makes the bad moment more expensive — the opposite of what your work to cut agent token costs was buying.

Failover reroutes for availability at exactly the moment cache locality is worth the most — and reroutes it to the one place the cache doesn't exist.

You can tell how real this is by the fact that the platforms engineered around it. AWS didn't leave prompt caching to break under cross-region routing; it built caching that transparently follows the route so you keep the discount. Google's Vertex is blunter about the seam: on the global endpoint, subsequent requests may hit different backends, so to keep cache hits you must send an X-Vertex-Ai-Session-Id for session affinity — or just use a regional endpoint. Cache locality and free-for-all routing are in direct tension, and the vendors know it well enough to sell you the patch.

Bill two: your data crossed a border you were paid to hold#

Here's the column that turns an SRE decision into a legal one. Availability-first routing optimizes for capacity, not jurisdiction. Bedrock's Global cross-Region inference will route "beyond geographic boundaries" to any supported commercial region worldwide. Azure's Global Standard, in Microsoft's own words, offers no data-residency guarantee.

For a lot of workloads that's fine. For a workload under GDPR, a data-residency clause, or a sector regulation, it means your reliability feature is also a mechanism that can process EU user data in Virginia the instant your Frankfurt region gets busy. That's not an outage you'll see on a dashboard; it's a compliance finding you'll see in an audit. The mitigation exists — Bedrock's geographic profiles and Azure's Data Zone deployments keep processing inside a US or EU boundary — but you have to choose them, and they trade away exactly the borderless failover pool that made "global" attractive. You cannot have the widest possible failover surface and a hard residency guarantee at the same time. Pick one, on purpose.

And if you fail over to another provider#

The most robust failover — surviving an entire vendor's outage — is also the one that fails silently. It's also the one a gateway or router makes trivially easy to switch on, which is exactly the trap. A second provider brings a different tokenizer, different context limits, and a different output distribution. The fallback path therefore returns answers your evals never scored and your prompts were never tuned for. It'll look fine in a smoke test and drift in production. If you keep a cross-provider escape hatch, treat its prompts as a separately versioned, separately evaluated artifact, not a drop-in the router swaps in at 3 a.m.

What to actually decide#

The frame "add multi-region failover" hides the real question, which is which invariant you're willing to give up. There are only three, and you can't keep all of them:

Match the dial to the workload. A latency-sensitive, cache-heavy, residency-bound path — a customer-facing agent over EU data — wants a regional deployment with in-region redundancy, and should eat the smaller blast radius. A throughput-hungry, residency-agnostic batch job wants the global router and should let it spread. The failure mode is flipping "global" on everywhere because it read like a free upgrade, then discovering in an incident review — or a compliance one — that it was a trade you never priced. Reliability engineering for LLMs isn't adding failover. It's knowing, per call, which of the three you just spent to get the other two.