A payments dataset must stay in the EU. The team reads that as one EU region and pins all storage there across two availability zones. Six months later the business asks for a 15-minute recovery time objective against a regional failure. What did residency actually cost and when did the bill arrive?

What was gained

A defensible answer to a contract clause, and a genuinely smaller compliance footprint. One region means one set of audit evidence, one key hierarchy, one network boundary to describe. A platform in Grab's position, operating across several Southeast Asian jurisdictions with different localisation rules, would pay noticeably more for this than a single-jurisdiction business does, and the simplification is worth having.

What was paid

A single-region failure domain. Availability zones are independent for power, cooling and most hardware, and they share the region's control plane and its regional services. A multi-availability-zone deployment protects against losing a building. It does not protect against losing a region, because recovery needs capacity and a readable copy of the data somewhere else.

So the 15-minute objective is not reachable from this design at any amount of effort, and that is the cost arriving late. The honest options are a second EU region, which the clause almost certainly permits, or writing an objective measured in hours into the contract and saying so plainly.

When the cost becomes visible

Three moments, in this order. The first customer contract that specifies a recovery objective. The first regional event, which is rare enough that teams discount it and consequential enough that it ends the argument. And the key-management decision, which is the one that bites hardest: a key held in one region's key service is a dependency on that region. Restoring into a second region requires a multi-region key, and that choice has to be made before the data is written. Retrofitting it means re-encrypting everything, which for a payments dataset is a project with its own risk register.

How to keep the option to reverse

• Write under a multi-region key from day one, even while using one region. The cost is a slightly more complex key policy and it preserves the only expensive option.
• Express the requirement as a jurisdiction in configuration, not a region hard-coded in deployment manifests, so adding a second EU region is a configuration change rather than an archaeology exercise.
• Have the clause read by someone who can tell "in the EU" from "in Frankfurt". Residency constrains where, and almost never how many. Teams routinely implement the stricter reading because nobody checked, and then carry the availability cost for years.

When this is the wrong answer

Some clauses genuinely name a country, and some public-sector and health contracts mean it. If no second region exists in that country, a second region is not an option and the correct move is to negotiate the recovery objective down with the actual constraint on the table, rather than designing a two-region architecture that quietly breaks the clause. The decision rule: establish whether the requirement is jurisdictional or geographic before designing for either, because the two readings differ by a region and by an order of magnitude in recovery time.