What's the actual difference between designing for high availability across Availability Zones versus across Regions, and when do you actually need multi-region instead of just multi-AZ?

Availability Zones are physically separate data centers within one region connected by low-latency private links, so multi-AZ protects against a single data center failing (power, cooling, hardware) with minimal added latency and complexity; regions are fully independent geographic areas with no shared infrastructure at all, so multi-region protects against a much larger blast radius (a regional service outage, a natural disaster, a compliance requirement to keep data in a specific geography) at the cost of significantly more complexity — data replication latency, consistency trade-offs, and often multiplied cost. Most systems need multi-AZ as a baseline; multi-region is justified specifically when the business impact of a full-region outage, or a data-residency/latency requirement tied to user geography, outweighs that added complexity.

An Availability Zone is one or more discrete, physically separate data centers within a region, each with independent power, cooling, and networking, but connected to other AZs in the same region by high-bandwidth, low-latency private links (typically sub-millisecond to low-single-digit milliseconds). This proximity is what makes multi-AZ practical for almost any workload: a database can run synchronous replication across AZs without meaningfully impacting write latency, and application servers can fail over between AZs with negligible added round-trip time. Multi-AZ protects against the failure domain of "one data center goes down" — power loss, cooling failure, a hardware fault affecting one facility — which is a meaningfully common failure mode that doesn't require any specialized architecture beyond spreading resources across zones and letting the provider's managed services (load balancers, managed databases with multi-AZ options) handle most of the mechanics.

A Region is a fully independent geographic area — different physical location entirely, with no shared power grid, no shared networking backbone, and often hundreds to thousands of miles of separation from other regions. Cross-region latency is an order of magnitude higher (tens to hundreds of milliseconds), which rules out synchronous replication for most workloads and forces a choice between asynchronous replication (accepting some data loss window on failover) or an active-active architecture with its own consistency trade-offs (conflict resolution, eventual consistency). Multi-region protects against the failure domain of "an entire region becomes unavailable" — a genuinely rare but real category of event (major cloud provider regional outages have happened), and also serves non-availability goals: data residency/compliance requirements that mandate certain data stay within a specific country's borders, or reducing latency for geographically distributed users by serving them from the nearest region.

The decision in practice is a cost/complexity trade-off against actual business requirement, not a default "more redundancy is always better": multi-AZ is close to a no-brainer baseline for any production workload on a modern cloud provider, since the cost and complexity overhead is low relative to the protection gained. Multi-region is a much bigger commitment — replication architecture, failover automation, data consistency model, often roughly doubled infrastructure cost — and is justified specifically when regional-outage business impact, regulatory data-residency requirements, or genuine global-latency requirements make that cost worth it, not merely because "multi-region" sounds more resilient on a slide.

• How would you design the data layer differently for an active-active multi-region architecture versus an active-passive (failover) one?
• What's the difference between RPO and RTO, and how does each differ between a multi-AZ and multi-region failover strategy?
• How would you decide which specific services in a system need multi-region treatment versus which can safely remain single-region?

• AZs are physically separate data centers within one region with low-latency links; regions are fully independent geographic areas with high latency between them.
• Multi-AZ protects against single-data-center failure at low complexity/latency cost and is a reasonable baseline for most production workloads.
• Multi-region protects against a much larger blast radius (full regional outage, compliance/data-residency needs, global user latency) at significantly higher complexity and cost.
• The decision should be driven by actual business impact and requirements, not a default assumption that more geographic redundancy is always the right call.

• AWS: Regions and Availability Zones
• AWS Well-Architected Framework: Reliability Pillar
• Google Cloud: Geography and regions