How would you choose between a dual-region and a multi-region Cloud Storage bucket for a workload needing regional resilience?

A dual-region bucket replicates data across exactly two specific regions you explicitly choose, giving you control over which two regions (useful for latency reasons, or regulatory data-residency requirements limiting data to specific geographies) and access to turbo replication (a faster, SLA-backed replication speed). A multi-region bucket replicates across a larger set of regions within a broader geographic area (like all of the US, or all of the EU) chosen by Google, without letting you specify exactly which regions, but with broader built-in resilience across more locations.

Dual-region gives explicit control over exactly which two regions hold your data: choosing, for instance, us-east1 and us-central1 specifically (rather than accepting whichever regions Google's multi-region location includes) matters when you have a specific latency requirement (keeping data close to two specific compute locations) or a data-residency/compliance requirement limiting exactly which geographic locations may hold the data.

Multi-region spreads data across more locations within a broader area, without letting you pick which ones specifically: choosing a multi-region location like US means your data is replicated across multiple regions within the United States, but Google determines the specific regions involved (and may include additional ones or shift over time) — this generally provides broader geographic resilience, at the cost of not being able to guarantee data stays out of a specific region you might want to exclude.

Turbo replication is specifically a dual-region capability, with an SLA-backed replication time: dual-region buckets can enable turbo replication, which provides a specific, contractually-backed guarantee (99.9% of objects replicated within 15 minutes) — multi-region buckets replicate across their broader region set too, but without this same explicit, SLA-backed speed guarantee, since it's built specifically for the dual-region use case.

The choice often comes down to whether you have a specific, named-region requirement: if a regulatory or architectural requirement specifies "data must stay within these exact two regions" or "data must be close to these two specific compute locations for latency reasons," dual-region is the only option that actually satisfies that precise requirement. If the requirement is more general ("survive a regional outage, broadly reside within this country/continent"), multi-region's broader, Google-managed resilience is often the simpler, equally-valid choice.

Both are meaningfully different from a single-region bucket's resilience profile: a single-region bucket, even with multiple storage classes, doesn't survive a full regional outage at all — both dual-region and multi-region exist specifically to provide that cross-region resilience, and the choice between them is about the specific control/guarantee trade-off, not about whether cross-region resilience exists at all.

• Dual-region lets you explicitly choose exactly which two regions hold your data, useful for specific latency or data-residency requirements.
• Multi-region spreads data across a broader, Google-determined set of regions within a larger geographic area, without letting you pick specific regions.
• Turbo replication (a 15-minute, SLA-backed replication guarantee) is specifically a dual-region capability.
• Choose dual-region when you have a specific, named-region requirement; choose multi-region for more general "survive a regional outage" resilience without needing to control exact regions.

• Google Cloud: Bucket locations
• Google Cloud: Turbo replication