In a real system with dozens of services, how would you decide which specific ones actually need multi-region treatment versus which can safely stay single-region?

Multi-region treatment should be reserved for services where a full-region outage would cause unacceptable business impact — usually the small set of services directly on the critical path for core user-facing functionality (auth, checkout, the primary read path) — while internal tooling, batch/analytics pipelines, and anything with a generous recovery-time tolerance can stay single-region (with solid multi-AZ resilience) and simply accept a slower, more manual recovery if their region has a bad day. The decision should be made service-by-service against actual business impact, not applied uniformly to "the whole system."

The instinct to make everything multi-region usually comes from treating resilience as a single company-wide policy rather than a per-service, cost-versus-impact decision — but multi-region isn't free: it multiplies infrastructure cost, adds real engineering complexity (data replication strategy, conflict resolution or partitioning for active-active, or standby capacity and failover tooling for active-passive), and increases the surface area for subtle cross-region bugs. Applying that cost uniformly to services where it isn't justified is itself a bad trade-off, not a safety margin.

A practical framework is asking, per service: what's the actual business impact if this service's region goes down for the duration of a realistic regional outage (historically, hours, occasionally longer)? Services where the answer is "revenue stops, or users are fully locked out of core functionality" are strong multi-region candidates — authentication, the primary transaction/checkout path, and anything gating access to the product's core value. Services where the answer is "some internal team is inconvenienced" or "a report is late" or "a background job runs a few hours later than usual" are strong candidates to stay single-region, accepting a manual, slower recovery process (restore from backup in another region, redeploy, reconnect) rather than paying for always-on multi-region infrastructure and complexity they don't need.

There's also a middle tier worth naming explicitly: services that aren't on the critical path for availability but do hold data that would be genuinely bad to lose — these might reasonably get multi-region backup/replication (so data isn't lost in a regional disaster) without needing multi-region serving (so the service itself doesn't need active-active or hot-standby compute in a second region, just durable, cross-region data durability). Splitting "protect the data" from "keep the service actively serving" this way often captures most of the risk reduction at a fraction of full multi-region serving cost.

The other practical constraint worth stating plainly: dependencies matter. A multi-region "critical path" service that depends on a single-region service for something essential isn't actually multi-region resilient — the dependency graph needs to be traced, not just the individual service's own deployment footprint, or the investment in the critical-path service's multi-region setup gets undermined by an unexamined single-region dependency.

• Multi-region treatment should follow actual business impact per service, not be applied uniformly across the whole system.
• The strongest multi-region candidates are services directly on the critical path for core user-facing functionality; internal tooling and delay-tolerant batch work are strong candidates to stay single-region.
• A middle tier exists: cross-region data durability (backup/replication) without full multi-region active serving, capturing much of the risk reduction at lower cost.
• Multi-region resilience for one service can be undermined by an unexamined single-region dependency elsewhere in its call path — the dependency graph matters as much as the individual service's own footprint.

• AWS Well-Architected Framework: Reliability Pillar
• AWS: Disaster Recovery of Workloads on AWS