Data Residency Controls Across Google Cloud

Enforcing geographic constraints via organization policies means allowing new Google Cloud resources to be created only in approved locations. The control is the Organization Policy Service (opens in a new tab) constraint constraints/gcp.resourceLocations, which is set on an organization, folder, or project. The policy checks the location property of each creation request for supported services and blocks requests outside the allowed values. Because the location property identifies where a service deploys a resource, and for some data-containing resources where data is stored, the constraint creates a compliant footprint for future deployments.

1.1How the Resource Locations Constraint Controls Creation

The resource locations constraint controls creation by defining the allowed Google Cloud locations for supported services under the policy node. When a user or service account requests a new resource, the Organization Policy Service compares the requested location to the allowed values and denies the request if it does not match. The check applies only to newly created resources, while resources created before the policy was enforced continue to run unchanged. This order is fixed: first the allowed locations are declared in policy, then every new request is evaluated, and only passing requests are provisioned.

1.2What the Constraint Does Not Cover

The resource locations constraint does not cover global resources, resources without a selectable location, or every product and resource type. It does not apply to global resources such as Compute Engine global addresses, and it applies only to a specific subset of products and resource types. A policy with this constraint is not enforced on sub-resource creation for certain services, such as Cloud Storage and Managed Service for Apache Spark, and some services interact with the constraint differently. The constraint also controls where a resource is created, not where data is stored or processed, because some services may store or process data elsewhere, and the policy is not a data storage commitment under the Google Cloud Terms of Service.

1.3Location Types and Value Groups

Google Cloud location types form a hierarchy from large multi-regions down to single zones, and the policy uses these values plus curated groups. A multi-region spans more than one region, a region is a geographically isolated deployment area, and a zone is an isolated failure domain inside a region. Google Cloud also offers specialized AI zones tailored for AI and machine learning workloads.

Value groups let administrators express geography without listing every current or future location. Using the in: prefix with a Google Cloud-curated Value Group includes all values in that group in the policy, and the prefix is added automatically when a group or region is entered without it. If an entered in: value contains any invalid group, the policy change fails, so group names must be validated before enforcement.

1.4Inheritance Across Organization, Folder, and Project

Inheritance across the resource hierarchy (opens in a new tab) means a policy set at a higher node flows down to all resources below it. The Organization resource sits at the apex, an organization can contain one or more folders, each folder can contain one or more projects, and projects contain service resources such as virtual machines, Pub/Sub topics, storage buckets, and VPN endpoints. A resource locations policy set at the organization therefore restricts creation across all child folders and projects, while a policy set on a folder or project narrows enforcement to that branch for testing or for a jurisdictional boundary.

Hierarchical exception handling must align child policies with the workloads they contain, because a higher-level geographic rule can block lower-level provisioning. Apigee (opens in a new tab) provisioning shows this dependency because the constraint applies to Apigee control plane, consumer data, runtime, endpoints attachment, and analytics resources created during provisioning. If an Apigee organization is provisioned without data residency, the effective constraint must allow global because the Apigee control plane is a global entity by default and provisioning fails otherwise. If Apigee is provisioned with data residency, the effective constraint must not exclude the selected control plane region, otherwise provisioning fails at the project level.

1.5Safe Rollout and Compliant Boundary Design

Safe rollout and compliant boundary design prevent the location policy from breaking services that depend on resources in another location. New policies should first be tested on non-production projects and folders and then applied gradually within the organization, with review of service-specific behavior for supported services. Assured Workloads (opens in a new tab) control packages illustrate strict boundary design by presetting gcp.resourceLocations allowed values at the folder level, where loosening the list would allow data creation outside the compliant data boundary with effects that can be difficult or impossible to reverse.

Compliant boundaries are expressed as explicit allowed-values lists that block all other regions, multi-regions, and locations for in-scope resources. A United States data boundary uses us plus us-central1, us-central2, us-east1, us-east4, us-east5, us-south1, us-west1, us-west2, us-west3, and us-west4. A Canada boundary (opens in a new tab) uses ca, northamerica-northeast1, and northamerica-northeast2. Changing either list to be less restrictive undermines data residency by permitting creation outside the boundary, so automated policy management must prevent unintentional changes.

Architecting compliant storage, database, and cryptographic key solutions means keeping regulated data in an approved physical location while meeting performance, disaster recovery, and access rules. Data residency is the physical location of data plus the local laws that govern how that data is stored, encrypted, and accessed. In Google Cloud, residency is enforced through three linked controls: configuring where data rests, controlling where encryption keys live, and controlling where data can be reached from.

2.1Cloud SQL Localized Storage and Governance

Cloud SQL (opens in a new tab) localized storage pins managed relational data at rest to a chosen Google Cloud region. The region is selected when the instance is created and can be changed by editing an existing instance, and Google stores data at rest only in those configured regions under the Service Specific Terms. This regional pinning covers MySQL, SQL Server (opens in a new tab), and PostgreSQL (opens in a new tab) instances, while backups are part of the same boundary so custom backup locations must also stay inside the approved region.

Cloud SQL residency also depends on replication and perimeter controls that determine where copies and access paths can go. A cross-region read replica creates a readable copy in a second region, which can sustain reads during a regional outage and serve users in a designated region, but the replica region becomes an additional residency location that must be allowed. The resource locations constraint defines where location-based resources can be created by allowing or denying multi-regions, regions, or zones, and VPC Service Controls creates a context-based service perimeter around Cloud SQL APIs, including import and export paths that use the Cloud SQL Admin API or the Cloud Storage API.

2.2Cloud Storage Regional, Dual-Regional, and Multi-Regional Trade-Offs

Cloud Storage is the object storage service where the bucket location type determines both the compliance footprint and survival during a large-scale disruption. A single-region bucket stores objects in one region, a dual-region bucket stores objects in an administrator-chosen pair of regions, and a multi-region bucket stores objects across data centers in a broad area such as the EU or US. Objects in dual-regions and multi-regions are stored in at least two geographically separate areas regardless of storage class, and replication between those areas occurs asynchronously.

When strict recovery time objective (RTO) and recovery point objective (RPO) proof is required, the stronger pattern is to use two single-region buckets with either dual-write to both buckets or write-to-one plus an explicit object copy to the second bucket. When a workload is restricted to a single region, geographic redundancy must come from outside that single Google Cloud location or from cryptographic separation. A multi-cloud or hybrid strategy keeps a second copy with another provider or on-premises in the same geographic area, using interoperability with Amazon S3, open-source stores such as minIO and Ceph, Managed Service for Apache Airflow with the gcloud storage utility, or the Transfer service for on-premises data.

2.3BigQuery Dataset Locality and Backup Resilience

BigQuery is the managed analytics warehouse where residency is set by the dataset location, which can be regional or multi-regional. Locality restrictions dictate where datasets are stored and backed up, so a regulated dataset must be created in the approved region or multi-region and its backups must not drift outside that boundary. To survive a regional disaster, data must be backed up to another geographic location, and for multi-region datasets the backup must avoid regions inside the scope of that multi-region.

Regional BigQuery contains the data footprint to one jurisdiction but concentrates recovery risk, while multi-regional BigQuery spreads storage across zones and regions for availability and durability at the cost of a wider footprint. Firestore follows the same principle: a regional location confines data to one region, while a multi-region location runs in a multi-zone and multi-region replicated configuration that maintains availability without data loss even if entire regions are lost. Bigtable production instances illustrate in-region resilience: at least two clusters must run in unique zones of the same region, Google automatically replicates and synchronizes an independent copy in each zone, and traffic can fail over to another cluster in the same instance. Choose regional when the contract requires one jurisdiction and design cross-region backup and failover explicitly; choose multi-region only when locality rules permit it and maximum availability is the priority.

2.4Cryptographic Key Residency with Cloud KMS, Cloud EKM, and CSEK

Cloud Key Management Service (KMS) controls residency from the encryption side by determining where keys live and who can use them to decrypt data. If keys are held outside Google Cloud, a multi-region storage architecture can still satisfy locality intent because data moved outside the approved area remains unreadable without those keys. Cloud External Key Manager (Cloud EKM) encrypts BigQuery and Compute Engine data with keys stored and managed in a third-party key management system deployed outside Google infrastructure. Customer-supplied encryption keys (CSEK) protect Cloud Storage objects and Compute Engine disks by wrapping Google-generated data-encryption keys with a customer-supplied key for each operation, and Google does not permanently store the CSEK but purges it after the operation completes.

External key control creates a hard dependency between the data plane and the key manager that shapes disaster recovery for locality-restricted workloads (opens in a new tab). The external key manager must be designed for high availability with its own recovery processes because latency to the key service affects every encrypt and decrypt path. Recovery point objective is not the critical concern because no data can be safely written without the keys, so there is no diverged data to lose. Recovery time objective is the critical concern because without available keys data cannot be decrypted or safely written, and an outage of the key manager halts access even when storage itself is healthy.

2.5Enforcing Residency Across the Resource Hierarchy

The Organization Policy Service is the centralized control that enforces residency across the organization, folder, and project hierarchy before resources are created. The location-restricted resources constraint limits where location-based resources can be created, with policies that allow or deny multi-regions, regions, or zones for supported services. The domain-restricted sharing constraint complements location control by limiting which Cloud Identity or Google Workspace customer identities can be added to identity and access management (IAM) policies, so only approved organizational identities gain access to resident data.

Application access locality is enforced at the network and perimeter layers that sit around the data. Google Cloud Armor implements IP-based and geography-based constraints that restrict where an application can be reached from. VPC Service Controls provides context-based perimeter security that restricts which networks, identities, and APIs can move data, including Cloud SQL import and export flows. Before selecting regions, validate granularity by confirming whether multi-regional services are permitted, whether data at rest must stay in a specific region, which regions each product supports, and what mitigating features exist when a product has no regional restriction.

Automated compliance validation and drift detection is a two-layer system that blocks data-residency violations before resources exist and finds violations after deployment. The preventive layer uses Organization Policy and policy-as-code checks in delivery pipelines to deny provisioning in unapproved locations. The detective layer uses Cloud Asset Inventory and continuous monitoring to report resources that have drifted outside allowed geographies and trigger remediation.

3.1Prevent Noncompliant Provisioning with Policy-as-Code

Preventive validation for data residency centers on the constraints/gcp.resourceLocations organization policy constraint, which defines where location-based resources can be created. The constraint can be attached at the organization, folder, or project level of the resource hierarchy (opens in a new tab), so an Assured Workloads (opens in a new tab) folder created with a control package automatically restricts the regions selectable for new in-scope resources inside that folder. Because some resources are out of scope and unrestrictable, prevention must be paired with service selection based on regionality and with an understanding that Customer Data at rest commitments do not cover resource identifiers, attributes, or other data labels.

Prevention is enforced before provisioning by defining infrastructure as code with tools like Terraform and validating every change in the CI/CD pipeline. A pipeline built with Cloud Build can run Static Application Security Testing (SAST) and automated security gates that reject noncompliant code or Terraform plans before apply, which keeps configuration consistent and auditable. This shift-left order matters: first the allowed regions are declared in policy, then the pipeline evaluates the planned deployment against that policy, and only after the check passes does provisioning proceed to Google Cloud.

Effective policies start from explicit locality requirements for the workload:

• Where the data is at rest, which dictates usable services and high-availability and disaster-recovery options
• Whether encryption with Cloud Key Management Service or Cloud External Key Manager can mitigate locality needs
• Whether data can be processed outside where it rests, or must be processed in place
• Whether more than one region can be used for redundancy
• Whether access must be restricted to predefined locations or identities

3.2Detect Geographic Drift with Continuous Inventory and Monitoring

Geographic drift detection is the continuous process of comparing the actual location of deployed resources against the allowed-region policy. Cloud Asset Inventory maintains the up-to-date inventory of deployed assets, software, services, or the code that defines them, and feeds detective controls that evaluate organization, folder, and project scopes. Security Command Center with posture management provides the unified interface for those findings, enables continuous monitoring for misconfigurations, and maps results to standards such as ISO 27001 and NIST 800-53, while audit logging and automated log analysis preserve evidence for audit requirements.

Two high-severity detectors illustrate how location drift (opens in a new tab) is reported for a Europe-only boundary:

Both detectors operate in Detective and Audit enforcement modes with HIGH severity and apply to organization, folder, and project targets. The first detector validates that the constraints/gcp.resourceLocations policy itself permits only the approved EU regions, while the second detector flags existing resources whose runtime location violates that boundary. Apigee (opens in a new tab) shows why both views matter: an organization provisioned without data residency (opens in a new tab) requires the constraint set to global because its control plane is global by default, while an organization provisioned with data residency fails if the constraint excludes its selected control-plane region.

3.3Remediate Drift and Sustain Auditability

Remediation for geographic drift returns the environment to the approved location set and then hardens prevention so the same drift cannot recur. A resource flagged as RESOURCE_LOCATION_OUTSIDE_EUROPE must be migrated or redeployed into an allowed region such as europe-west3, europe-west4, europe-west6, or europe-west8, or deleted if it is not needed. The policy dependency flows from remediation back to prevention: the organization policy is configured to deny future creation outside allowed locations, so the detective finding drives a preventive fix at the organization, folder, or project node.

Sustained compliance depends on isolation, inventory, and audit events that prove controls work over time. Resource isolation combines VPC networks for logical separation, firewall rules for traffic control, Identity and Access Management (IAM) allow policies for access control, and Google Kubernetes Engine (GKE) scheduling, with the CI/CD pipeline providing version-controlled change. Auditability requires enabled audit logging, IAM control over who can read or administer logs, defined retention, and regular review of log entries and alerting policies with automated analysis in Cloud Monitoring.

Key Facts

• The constraints/gcp.resourceLocations organization policy blocks creation of new resources outside allowed Google Cloud locations but does not move, delete, or remediate existing violating resources.
• An Apigee organization provisioned without data residency requires the effective resource locations constraint to allow global, while an Apigee organization provisioned with data residency fails if the constraint excludes its selected control plane region.
• A Cloud Storage single-region bucket confines data to one region, a dual-region bucket stores data in an administrator-chosen pair of regions, and a multi-region bucket stores data across data centers in a broad area.
• Cloud External Key Manager (Cloud EKM) keeps keys persistently in an external manager outside Google infrastructure, while customer-supplied encryption keys (CSEK) are supplied per operation and purged afterward.
• Geographic drift detectors report RESOURCE_LOCATION_NOT_ALLOWED when the location policy permits unapproved regions and RESOURCE_LOCATION_OUTSIDE_EUROPE when deployed resources run outside europe-west3, europe-west4, europe-west6, and europe-west8.