Data Residency, Region Pairs, and the Zone Assumption
Banco Verde is regulated such that all customer account data must remain physically inside Brazil. The team has selected Brazil South as its primary region and proposes two things: (a) a zone-redundant web tier, and (b) geo-redundant storage (GRS) for the transaction archive, arguing that 'GRS replicates the data to another zone in the same region, which also gives us the zone redundancy for free.' Separately, a latency-sensitive trading component must respond in under 20 ms from the São Paulo office. The CISO wants the archive to survive the loss of the primary region but will not break the residency rule, and has asked the architect to state plainly what is and is not possible.
1. Correct the storage proposal. What does GRS actually do, and what storage options remain if data must stay inside Brazil?
Read the worked answer
The argument contains two errors:
- GRS does not replicate within a region. GRS takes three synchronous copies locally (LRS) and then replicates asynchronously to the paired region. Redundancy across zones is ZRS, a different option entirely.
- The paired region is not a zone, and it is not necessarily in the same country. Brazil South's paired region is South Central US - outside Brazil. Using GRS would replicate regulated account data to the United States.
So the options are:
- ZRS - three copies across availability zones in Brazil South. Survives a datacenter loss, stays in-country. Only available in regions that support availability zones, which must be verified for the chosen region.
- LRS - cheapest, three copies in a single datacenter; survives disk failure only.
- GRS / RA-GRS - excluded by the regulator.
The remaining tension: 'survive the loss of the whole region' and 'never leave Brazil' cannot both be met by any single geo-redundant storage option here. The resolution is either a second storage account in another in-country region with replication you control, or an explicit, documented regulatory exception. Flag the conflict; do not quietly pick one.
2. The team believes that choosing a region automatically makes the web tier survive a datacenter failure. Evaluate that, and say what must be verified before committing.
Read the worked answer
A region is a set of datacenters within a latency-defined perimeter, connected by a dedicated network. Being in a region gives you proximity and residency; it gives you no resilience on its own.
- Resilience to a datacenter loss requires availability zones - physically separate facilities within a region, each with independent power, cooling, and networking - and the workload must actually be deployed across at least two zones behind a load balancer. A single VM, or three VMs placed in one zone, is just as fragile.
- Not every region has zones, and not every service supports zones even where they exist. Zone-redundant storage in particular is only offered in zone-enabled regions.
- Zone redundancy protects against datacenter failure, not regional failure - that is what region pairs and multi-region designs are for, and here the paired region is out of bounds.
Verification checklist before signing off: the region supports availability zones; each service in the web tier supports zone redundancy (not just regional deployment); the load balancer itself is zone-redundant; and the deployment is pinned across zones rather than left to default placement.
3. How should the under-20 ms requirement be handled, and does a region choice settle it?
Read the worked answer
Latency is a physics question first and a service question second.
- A region is a latency-defined perimeter: resources inside it are close enough for low-latency communication. Choosing a region physically near São Paulo (Brazil South) is the primary lever.
- The boundary is the user-to-service hop, not the region name. Under 20 ms from a São Paulo office is achievable in-country; it would not be from a European region, regardless of how the service is configured.
- Do not assume the service exists there. Service and SKU availability varies by region, and a region that satisfies latency and residency may not offer every feature - a preview-only or unavailable SKU forces a redesign, not a workaround.
- Measure, do not infer. Round-trip time is affected by the customer's own network path, DNS resolution, and TLS handshakes, so the requirement should be validated with actual measurements from the São Paulo office before the region decision is frozen.
Summary for the CISO: residency is satisfied by the region; datacenter-failure tolerance depends on zones actually being available and used; regional-failure tolerance is not purchasable here without leaving Brazil, and that is a business decision, not an architecture one.