Data Residency
Data residency refers to the geographic location where data is stored. Google Cloud’s architecture guidance gives the compact version: data residency describes where your data is stored at rest. A data residency requirement is an obligation — from regulation, contract, or internal policy — that certain data be kept in a particular country or region.
The definition is simple. Satisfying a requirement usually is not, because requirements rarely stop at where the bytes rest.
Residency and neighboring terms
Several terms are used around this idea, and they are not used consistently across vendors, regulators, and contracts. Google Cloud’s framework, for example, separates residency (where data is stored) from data sovereignty, which it describes as mechanisms that prevent the provider itself from accessing customer data, such as keeping encryption keys outside the cloud. Other sources use “sovereignty” to mean being subject to a jurisdiction’s laws, and “localization” for a legal mandate to keep data in-country. When a requirement uses any of these words, read what it actually restricts rather than relying on the label.
What a region setting does and does not settle
Storage location depends on the provider, product, and selected resource configuration. S3 buckets use a chosen AWS Region; Google Cloud Storage also offers dual-region and multi-region locations. Verify the location guarantees and replication settings for the resource in use rather than assuming all cloud storage has one regional default. Residency assessment extends beyond that stored copy:
| Question | Why the storage region does not answer it |
|---|---|
| Where is the data stored? | Answered by the resource’s documented location configuration — for the primary copy. Replicas, backups, and disaster recovery copies may be configured elsewhere. |
| Where is it processed? | A query engine, ML service, or support tool in another region may read the data and hold it in memory or temporary storage there. |
| From where can it be accessed? | A table that never leaves its region can still be read by a user in another jurisdiction unless identity and network controls prevent it — least privilege applied to location as well as to action. |
| Where can results go? | Query results, extracts, and reports are new data. Exporting them can move the protected information even though the source table stayed put. |
Google Cloud’s guidance reflects the same breadth: it recommends controlling not only where data is stored but how it is accessed and processed, and using location policies to restrict where resources can be created and where data can be replicated between regions.
Paths that are easy to miss
- Backups and replicas configured for resilience in a distant region.
- Logs and telemetry that capture query text, parameters, or sample values and are shipped to a central region — including the audit log kept to prove compliance.
- Caches near users in other regions.
- Metadata. A globally searchable catalog does not necessarily copy every entry into every region. Check where each metadata type is stored or replicated and where search is processed. Google Cloud’s catalog documentation distinguishes regional resources from global metadata types. Profiled samples, if collected, need a separate location and access assessment; the catalog’s global interface does not settle it.
- Shared data across regions. In-place sharing features often create a replica when the consumer is in another region.
Designing for it
Platforms that serve several jurisdictions tend toward regional data with consistent global definitions: each region holds its own data, while the catalog, access policies, and business definitions are the same everywhere. That keeps one description of what exists without moving the data itself. What it cannot do is make a cross-region join free. A workload that must combine data from two jurisdictions needs an explicit decision. Aggregating within each region, or masking before combining, can reduce what crosses, but it does not replace checking whether the transfer is permitted: an aggregate over one person’s salary is that person’s salary, and a pseudonymized value can still be linked. The summaries and masked values need the same assessment of sensitivity, re-identification risk, and applicable transfer restrictions as the rows they came from, and whatever transfer is permitted still has to be paid for. Which rows are subject to the constraint is itself a governance decision, and one that has to be recorded before the platform can enforce it.
Residency is a constraint to settle before the architecture, not a setting to optimize within it. Which regulations apply, and what they require, is a question for legal and compliance specialists; this entry explains the engineering side only. How residency interacts with sharing, copies, and cost on a shared platform is worked through in Enterprise Scale: One Platform, Workloads That Disagree.
References:
- Google Cloud Architecture Framework, Meet regulatory, compliance, and privacy needs
- Amazon S3 User Guide, What is Amazon S3?
- Google Cloud Storage, Bucket locations
- Google Cloud, Catalog locations and regional resources
- NIST SP 800-188, De-Identifying Government Datasets: Techniques and Governance
Discover more from Insightful Data Lab
Subscribe to get the latest posts sent to your email.