Data residency

Enforce Geographic Constraints via Organization Policies

The resource location constraint (gcp.resourceLocations) is a rule you can set to control where Google Cloud resources are created. This is a key tool for meeting data residency laws, which require data to stay in specific countries or regions. You apply this policy at the organization, folder, or project level, and it automatically flows down to all resources underneath. It's important to know this policy only affects new resources; any existing resources in a blocked location will keep running.

You can manage these rules carefully by using the resource hierarchy. You might set a strict rule at the top of your organization but create exceptions for specific folders or projects that need different locations. Before enforcing a new rule, you can use a dry-run mode to see which resources would be blocked without actually stopping anything. Be careful when making lower-level rules less strict, as this can create compliance gaps. To make rules easier to write, you can use pre-built value groups like in:eu-locations instead of listing every single region.

Enforcing location constraints requires understanding how services behave. Some services, like certain global load balancers, aren't affected by this policy. More importantly, a strict location rule can break autoscaling for services like Google Kubernetes Engine (GKE) or Dataflow if the system tries to create new virtual machines in a zone you've blocked. To avoid problems, test new policies in a non-production environment first, update your automated deployment tools to respect the rules, and watch for services that might create child resources in unexpected locations.

Implement Automated Compliance Validation and Drift Detection

To keep your cloud compliant, you need to check for rule violations automatically, both before and after resources are created. Policy-as-code means writing your rules (like data residency requirements) into code that can be checked by your CI/CD pipelines. This "shift-left" approach blocks any deployment that would create a resource in the wrong location before it even happens.

After resources are running, you must watch for drift, which is when a resource changes from its approved state. For example, someone might manually move a database to a different region. You can use Cloud Asset Inventory to continuously scan your entire Google Cloud organization and detect when resources appear in unapproved geographic locations. Setting up automated alerts and remediation workflows for these events ensures you fix compliance problems quickly.

Tools like the Organization Policy Service let you define the central rules. Security Command Center can monitor for threats and misconfigurations, while Cloud Audit Logs tracks who did what. A complete strategy also uses VPC Service Controls to create a secure boundary around your sensitive data, preventing it from being copied or accessed from outside your approved network zones. The goal is to build security and compliance into your design from the start and use automation to maintain it.

Architect Compliant Storage, Database, and Cryptographic Key Solutions

Data residency requires you to control not just where virtual machines run, but where your actual data and the keys that encrypt it are stored. When you create services like Cloud Storage, BigQuery, Cloud SQL, or Cloud KMS, you must select a specific location. For storage and databases, you choose between a single region, a dual-region (two specific regions), or a multi-region (like EU or US). A multi-region stores your data in only one region within that area and is meant for availability, not for automatic cross-region backup.

If laws require data to stay in one region, achieving disaster recovery becomes more complex. You cannot use a service's built-in cross-region replication. Instead, you might create custom backups, like exporting BigQuery data to a Cloud Storage bucket in the same region and then copying that backup to another approved location. This trade-off means more operational work for you in exchange for strict compliance.

Encryption keys must also follow residency rules. Cloud KMS lets you choose the region for your keys. For the strictest requirements, you can use External Key Manager (EKM), which keeps the key material entirely outside of Google's infrastructure. You can enforce the use of these external keys across your projects using an organization policy constraint (cloudkms.allowedProtectionLevels). Finally, use VPC Service Controls and regional Private Service Connect endpoints to ensure that data moving between your services doesn't travel outside your approved network boundaries.