Multi-region is a cost decision before it is an architecture decision

The conversation usually starts after an incident. A region had a bad day, the service was down for three hours, and someone senior asks why the system is not multi-region. The engineering answer that follows is a diagram. The answer that should follow is a price and a recovery time, side by side, for three options.

Multi-region is not a capability you add. It is a tier you buy, and the tiers differ by roughly an order of magnitude in cost and by minutes versus hours in recovery. Most estates that ask for it should buy the tier below.

The tiers, and what each actually buys

Backup and restore. Data replicated to a second region, no compute standing. Recovery means provisioning everything and restoring, which is hours to a day depending on data volume. Cost is storage and transfer only. This is the right answer for internal systems and for anything where a day of downtime is survivable.

Cold standby. Infrastructure defined in code and deployable to the second region, data replicating continuously, nothing running. Recovery is the time to apply your infrastructure code, restore the most recent state and repoint traffic, realistically an hour or several. Cost is storage, transfer and the discipline of keeping the code genuinely deployable, which is the part that decays.

Warm standby. A scaled-down but running copy: database replica live, a minimum set of application instances up, everything wired. Recovery is promoting the database and scaling out, which is minutes. Cost is roughly the second region's minimum footprint plus replication, commonly a quarter to a half of primary cost.

Hot, active-active. Both regions serving traffic. Recovery is close to instantaneous and, more valuable, the failover path is exercised continuously rather than theoretically. Cost is more than double the primary, because you are also paying for cross-region data traffic, a data layer that can handle multi-region writes, and the engineering to build it.

The jump that surprises people is not cold to warm. It is warm to active-active, where the cost lands mostly in engineering and in the data layer rather than in instance hours.

Data is the part that decides everything

Compute is easy to duplicate. The database is the problem, and the shape of the problem is the recovery point objective.

Asynchronous replication is what nearly everyone runs. It is cheap and it has replication lag, which means a failover loses whatever had not replicated: usually seconds, sometimes minutes under load. If your recovery point objective is zero, asynchronous replication does not meet it, and you should say so out loud rather than let a diagram imply otherwise.

Synchronous replication across regions means every write waits for the round trip. Between European regions that is tens of milliseconds added to every transaction. Between continents it is not viable for an interactive workload. This is the physics that no architecture removes.

Multi-region writes need either a database built for it, accepting its consistency model and its price, or an application partitioned so each record has a home region. The second is usually the better engineering answer and it is a rewrite, not a configuration.

And there is a second copy problem: object storage, search indexes, caches, message queues and the secrets store all need a replication story, and each one is a place a failover discovers a gap.

The bills you did not plan for

• Cross-region data transfer, charged per gigabyte, continuously, in both directions if the application is chatty. On a replication-heavy estate this becomes one of the larger lines, as it does in Azure storage and data transfer.
• Duplicate licensing and per-node vendor pricing, which frequently doubles rather than scaling with usage.
• The second region's fixed costs. NAT gateways, load balancers, cluster control planes and private connectivity are per-region charges that exist whether or not traffic flows.
• Observability doubled. Twice the logs, metrics and traces, in a system priced per gigabyte.
• Reserved capacity that does not apply. A commitment scoped to one region leaves the second at on-demand rates. Check the scope before assuming your discount carries over.

DNS failover is slower than the TTL suggests

The failover mechanism is a second source of surprise. DNS-based failover depends on health check intervals plus TTL plus resolver behaviour, and resolvers ignore short TTLs more often than documentation admits. Budget minutes, not seconds, and test with real clients rather than dig.

A global anycast load balancer moves traffic faster because it does not depend on client caching, at the cost of tying you to one provider's edge. Client-side retry with a second endpoint is the fastest of all and requires control of the client.

Whichever you choose, the failover has to be triggerable by a human in one action, and that action has to be documented and practised. A failover that requires six people to agree takes longer than the outage.

Why multi-zone is the right answer more often than people admit

A multi-zone deployment in a single region survives the failure of a data centre, which is the most common infrastructure failure by a wide margin. It costs very little extra because zones are close enough for synchronous replication and, in most providers, intra-region traffic between zones is charged modestly or not at all.

Full-region failures are rare, and when they happen they are often accompanied by control plane degradation that also affects your ability to fail over. Meanwhile a great many outages that teams blame on the region were caused by a bad deploy, an expired certificate or an exhausted connection pool, and multi-region protects against none of those.

Work out what an hour of downtime costs, multiply by the hours the cheaper tier would have added, and compare that to the annual cost of the more expensive tier. In most businesses the honest answer is multi-zone plus a tested restore, which is the discipline described in RTO, RPO and the restore test.

The region that has never been tested does not work

Every failover we have observed for the first time has found something: an AMI or image that only exists in the primary region, a secret that was created by hand, a certificate scoped to one region's load balancer, a quota that is zero because nobody requested it, a DNS record with a hardcoded address, an IAM condition pinned to a region.

Test on a schedule and, where the architecture permits, run a real failover and stay on the secondary region for a period rather than failing back immediately. The estates that do this find their failover works. The ones that do not find out during the incident. A zone-loss experiment, as described in the first five chaos experiments, is the cheap rehearsal.

What to do this week

Write down three numbers: what an hour of full downtime costs the business, what your current recovery time actually is if you had to rebuild in another region today, and what the warm standby tier would cost per month. That table is the decision, and it usually makes it for you. We build exactly that comparison in the resilience phase of a cloud engagement.