Leadership asks for multi-region "for resilience". What do you establish before designing anything?

First: is multi-region the right answer to the actual problem?

Multi-region defends against a region-wide failure. Most outages are not that — they are bad deployments, expired certificates, exhausted connection pools, configuration pushes and dependency failures, none of which a second region helps with. A second region doubles the surface for exactly those.

So the first question is what has actually gone wrong historically, and whether the money would buy more availability spent on deployment safety, testing and observability.

Then: the numbers that determine everything

RTO and RPO, per workload rather than globally. The cost is steeply non-linear:

Which data must be consistent across regions. This single answer decides whether the project is difficult or merely expensive, because synchronous cross-region replication puts inter-region latency on every write, and asynchronous means RPO greater than zero and possible conflicts.

Whether there is a residency or regulatory driver, which changes the problem from availability to compliance and often dictates the design.

What I would likely recommend

Multi-AZ first, which handles the physical failures cheaply and which many organisations asking for multi-region have not fully done.

Then partitioned active-active if the workload permits it: every region serves traffic, but each record has a home region owning its writes. That gives latency, utilisation and a continuously exercised failover path without global write conflicts — and it is what most large multi-region systems actually run.

Active-passive with a genuinely tested failover where partitioning is not possible. The word doing the work is tested: an untested standby has an unknown RTO, and organisations discover this at the worst moment.

What a strong answer adds

Insisting on regional evacuation as a routine drill rather than an emergency procedure. Capacity headroom in the surviving regions must be verified — it is the constraint that most often fails — and a failover exercised monthly is one an on-call engineer can invoke without senior sign-off, which is worth more than the architecture on its own.