Business Challenge
A team creates a bucket for a reporting pipeline. The location dropdown offers a region, a dual-region and a multi-region; multi-region sounds the most robust, so they pick it and move on. Eighteen months later that choice is examined by three different people for three different reasons.
A multi-region is a large geographic area containing two or more geographic regions. It answers availability well and answers "where exactly" badly, because you never named the constituent regions.
Correct approachWhere residency has to be stated, choose a dual-region — a specific pair such as Tokyo and Osaka — so the two places holding the data are ones you named.
Cross-region redundancy is asynchronous. Default replication targets 99.9% of newly written objects within one hour and 100% within twelve hours, so a failover can legitimately lose recent writes.
Correct approachWrite the RPO down as twelve hours unless you have paid to change it, and design the pipeline to be able to reproduce the trailing window rather than assuming it survived.
Turbo replication targets 100% of newly written objects within a 15-minute recovery point, and it is only available for buckets in dual-regions. The multi-region bucket could not have it at any price.
Correct approachIf a tight recovery point might ever be required, the location type has to be dual-region from the start. It is the only one the lever attaches to.
A bucket can be relocated after creation, but relocation is available only if Storage Intelligence has been configured. The escape hatch exists and is not switched on by default.
Correct approachTreat location as a creation-time decision. Relocation is a real option and a project in its own right, not an undo.
Every one of those follows from a dropdown chosen in a few seconds, by someone reasonably assuming that the widest-sounding option was the safest.
Not "how fast" and not "how much", but two things at once: what do you need to survive, and how far behind may the surviving copy be. The second half is invisible at creation time and is the one that shows up during an incident.
Architecture
Cloud Storage offers three location types, and they differ in what they survive and in whether you know where the data is.
Region: synchronous, and a single point of regional failure
A region is a specific geographic place, such as Iowa (US-CENTRAL1), and data stored in regions is redundant across multiple zones within that region. That redundancy is synchronous, which is why there is no replication lag to reason about.
It survives a zone and not a region. For a great many workloads that is the correct answer, and it has the useful property of being the only option with no staleness question attached.
Dual-region: two places you named, asynchronously
A dual-region is a specific pair of regions — Tokyo and Osaka is ASIA1. Redundancy across those regions is asynchronous.
The defining property is not the redundancy, which multi-region also has. It is that you know which two places hold the data, because you picked the pair. That is what makes it the answer whenever somebody has to state where data resides.
Multi-region: widest footprint, least specificity
A multi-region is a large geographic area that contains two or more geographic regions, such as the United States (US). It gives cross-region redundancy without you choosing the constituent regions.
That is a genuine convenience and a genuine limitation, and which one it is depends entirely on whether anyone will ever ask the residency question.
The number that actually differs: RPO, not RTO
RTO is 0 for both dual-regions and multi-regions, with automated failover and failback. So the recovery time is not the variable — the platform handles it.
The recovery point is the variable, and it is large by default. Default replication is designed to provide redundancy across regions for 99.9% of newly written objects within one hour, and 100% within twelve hours.
Turbo replication changes that, and only on dual-regions: 100% of newly written objects within a 15-minute recovery point, regardless of object size. That last clause matters, because it means a large object does not get a longer grace period than a small one.
Fifteen minutes against twelve hours is a 48-fold difference in the worst-case recovery point. That is the whole reason the feature exists, and it is reachable only from a location type chosen at creation.
Why This Architecture Holds Up
The interesting number is not the twelve hours. It is the 99.9%.
Default replication targets 99.9% of newly written objects within an hour. Read as a service level that sounds excellent. Read as a recovery plan it says something sharper: one object in a thousand may take longer, and the outer bound on that tail is twelve hours.
For a bucket taking a hundred thousand objects a day, the tail is not an abstraction — it is on the order of a hundred objects that could be missing from the surviving copy at any moment. Whether that matters depends entirely on whether the pipeline reading them can tell that they are absent, which is a different design question from whether the bucket is redundant.
Durability is whether the data still exists. Availability is whether you can reach it. Recovery point is how much of the most recent data came across when you failed over. The location dropdown decides all three, and only the first two are what people think they are choosing.
When each type is the right answer
Region for anything whose loss in a regional outage is acceptable or recoverable from elsewhere — including, frequently, derived data that can simply be regenerated. It is cheaper, simpler and has no staleness to reason about.
Dual-region when either the residency question will be asked, or the recovery point needs to be tight. Those two motivations are unrelated to each other and both lead here, which is why it is more often the right answer than its reputation suggests.
Multi-region when broad availability and reach matter and nobody needs to state where the data is. Content served widely fits this well.
The creation-time trap, stated plainly
A bucket can be relocated after creation, but only if Storage Intelligence has been configured. So the escape hatch is real, has a prerequisite, and is a piece of work rather than a setting.
Practically, that means location joins the project ID from post #5 on the short list of choices made in seconds and lived with for years. The difference is that this one has an exit — it just is not the exit people assume they have when they pick from the dropdown.
Key Architecture Decisions
| Decision | Choose this | Because |
|---|---|---|
| Data whose location must be stated | Dual-region | It is a specific pair of regions that you name. A multi-region gives redundancy without telling you which regions hold the data. |
| Data needing a tight recovery point | Dual-region, with turbo replication | Turbo is only available on dual-regions. Choosing any other location type at creation puts the 15-minute RPO permanently out of reach. |
| Derived or reproducible data | Region | Cheaper, synchronously redundant across zones, and with no replication lag to reason about. Regenerating beats replicating when regenerating is possible. |
| Broadly served content | Multi-region | Widest footprint and cross-region redundancy, and the residency question genuinely does not arise. |
| What to write in the recovery plan | Twelve hours, unless turbo is enabled | That is the documented target for 100% of newly written objects. One hour covers 99.9%, and the remaining tenth of a percent is what a plan has to survive. |
| Arguing about RTO for storage failover | Do not | RTO is 0 for both cross-region types, with automated failover and failback. The recovery point is the variable worth the meeting. |
| Treating location as changeable | No — decide at creation | Relocation exists but requires Storage Intelligence to be configured first. It is a project, not an undo. |
| Large objects in a replication plan | No special handling under turbo | Turbo targets its 15-minute RPO regardless of object size, so size stops being a variable in the recovery point. |
It is the widest, which is not the same thing. It cannot tell you where your data is, and it cannot be given turbo replication. A dual-region with turbo enabled survives exactly the same class of failure with a recovery point 48 times tighter and an answer to the residency question. The instinct picks the option that sounds biggest rather than the one with the better properties.
Closing Thought
Location types look like a geography question and behave like a durability contract. All three keep your data safe in the ordinary sense; they differ in what they survive, whether you can say where the bytes are, and how far behind the second copy is allowed to fall.
The single most useful habit is to say the recovery point out loud when the bucket is created. Twelve hours is the default answer and it is rarely the one anybody would have chosen deliberately — but it is the one they get, because the dropdown never mentions it.
#10 covers Google's network and the Premium versus Standard network tiers: where traffic enters and leaves Google's backbone, what the two tiers actually change about the path a packet takes, and the cost and latency consequences of a setting most estates never revisit.
Comments