Restricting Resource Locations in GCP

Simple explanation

Imagine your company’s compliance rule says all customer data must stay in the EU. Without any restrictions in GCP, any developer on any project can create a Cloud Storage bucket in the US or Asia-Pacific with no friction. The platform will not stop them.

The constraint is preventive, not corrective. It stops new violations from happening. It does not move or delete resources that already exist in non-approved locations. You need to audit and migrate those separately — more on that below.

How it works

gcp.resourceLocations is a list constraint in the Organisation Policy Service. List constraints work by checking whether a value — in this case a resource’s target location — appears in an approved list before resource creation proceeds.

When you enforce this constraint, here is the sequence:

1. A developer runs an API call (or gcloud command) that specifies a location for a new resource

2. The Organisation Policy Service checks the location against the allowedValues list in the effective policy

3. If the location is on the list, the resource is created normally

4. If it is not on the list, the request is rejected immediately with a policy violation error before anything is created

A few behaviours that matter in practice:

• If an API call omits a location and the service would default to a non-approved region, the call still fails

• The check happens at creation time only. It has no effect on resources that already exist

• The constraint evaluates the location declared in the API call, not where data flows internally within GCP systems

• The policy is inherited. A constraint set at the organisation level automatically applies to every folder and project below it

What values you can allow

Three types of values work in the allowedValues list:

Individual regions

Exact region names like europe-west2 (London), europe-west4 (Netherlands), or us-central1 (Iowa). These give precise control. If a region is not in your list, it is blocked. Individual region names do not use the in: prefix. They are listed directly.

Multi-regions

Values like eu (Cloud Storage European multi-region) or us (US multi-region). Used alongside individual regions when you want to allow Cloud Storage’s multi-region storage tier. These are also listed directly without a prefix.

Location groups with the in: prefix

Pre-defined collections maintained by GCP, such as in:eu-locations, in:europe-locations, and in:us-locations. The in: prefix tells the policy engine you are referencing a named group, not a literal region string. Groups automatically include new regions as GCP launches them, so your policy does not need updating when a new region opens within the group.

EU vs Europe: which location group to use

The single most common configuration mistake with this constraint is confusing in:eu-locations and in:europe-locations. They sound similar but cover different territory.

If your compliance obligation is GDPR data residency and your approved territory includes the UK (which has its own UK GDPR regime), use in:europe-locations. If your regulatory requirement specifies EU member state regions only, use in:eu-locations.

Getting this wrong causes real problems in either direction. Too narrow and you block UK workloads that were approved. Too broad and you allow UK storage when the requirement is EU-only. Confirm with your legal or compliance team before enforcing.

Other useful location groups:

• in:us-locations — all GCP regions in the United States

• in:northamerica-locations — all North American regions including Canada

• in:asia-locations — all Asia-Pacific regions

When to use this

• Enforcing data residency obligations. GDPR, sector-specific regulations, or contractual requirements that say customer data must remain in a specific region or country.

• Government and public sector requirements. Rules that restrict data to a particular national territory, such as UK-only or Germany-only hosting.

• Reducing accidental deployments. Developers who do not know the approved regions get a hard stop instead of a soft reminder. The policy removes the human error vector entirely.

• Governance and audit readiness. Regional compliance becomes structurally enforced rather than process-dependent, which simplifies audit evidence collection.

• Organisation-wide baseline. Set once at the organisation or folder level and all current and future projects inherit it automatically, including ones created next year.

• Reducing unexpected costs. Prevents resource deployments in regions that attract higher charges or egress fees.

When this is not enough

Location restriction answers one question: where can resources be created? It does not cover encryption, access control, or network isolation. For most compliance frameworks, you need additional controls alongside it.

Encryption key ownership

Even if your data is stored in an EU region, GCP holds the encryption key by default. For full control over who can decrypt your data, use Customer-Managed Encryption Keys (CMEK). CMEK lets you generate, hold, and rotate keys in Cloud KMS so GCP cannot access plaintext without your key. CMEK is commonly required alongside location restrictions in strict compliance frameworks.

Data access visibility

Location control does not tell you who read or modified your data. Cloud Audit Logs record data access events. Enable Data Access audit logs on every service holding regulated data so you have a full record of who accessed what and when. Without this, a location-compliant bucket with unrestricted read access is still a compliance gap.

Network-level access

Location restricts where resources live, not which networks or identities can reach them across API boundaries. VPC Service Controls let you define a perimeter restricting which projects and identities can call your APIs, reducing the risk of data exfiltration even if a credential is compromised.

Contextual access control

IAM Conditions let you restrict role bindings by request context: time windows, resource names, or resource tags. They do not add location enforcement, but they complement it by limiting who can access resources that are already location-controlled.

Configuring and applying the constraint

Policies are written in YAML and applied with gcloud org-policies set-policy. The name field in the YAML determines where in the resource hierarchy the policy is set.

# Allow only two specific regions: London and Netherlands
name: organizations/ORG_ID/policies/gcp.resourceLocations
spec:
  rules:
    - values:
        allowedValues:
          - europe-west2
          - europe-west4

# Allow all EU member state regions (excludes UK)
name: organizations/ORG_ID/policies/gcp.resourceLocations
spec:
  rules:
    - values:
        allowedValues:
          - in:eu-locations

# Allow all European regions including UK, plus the EU multi-region storage tier
name: organizations/ORG_ID/policies/gcp.resourceLocations
spec:
  rules:
    - values:
        allowedValues:
          - in:europe-locations
          - eu

# Apply at folder level instead of org — change the name prefix
name: folders/FOLDER_ID/policies/gcp.resourceLocations
spec:
  rules:
    - values:
        allowedValues:
          - in:europe-locations

# Apply the policy from a YAML file
gcloud org-policies set-policy location-policy.yaml

# Verify the effective constraint on a specific project
gcloud org-policies describe gcp.resourceLocations \
  --project=my-app-prod

# List all org policies effective on a project, including inherited ones
gcloud org-policies list \
  --project=my-app-prod

# Test the constraint: try creating a resource in a blocked region
# A correctly enforced policy returns an error naming constraints/gcp.resourceLocations
gcloud storage buckets create gs://test-bucket \
  --location=us-central1 \
  --project=my-app-prod

After applying, test by attempting to create a resource in a disallowed location. A correctly enforced policy returns an error naming constraints/gcp.resourceLocations as the blocking constraint. If no error appears, verify the policy is set at the right level in the hierarchy and that no child override is allowing the location.

Where to set the constraint in the hierarchy

Apply location constraints at the organisation or folder level, not the project level. A project-level constraint only covers that one project. Any new project created later inherits nothing from it.

A practical structure for an organisation with strict EU data residency:

• Set in:eu-locations at the organisation level as the baseline. All projects inherit it automatically.

• For workloads that legitimately need non-EU infrastructure (CDN edge nodes, global load balancers), create a separate folder with a broader location policy and a documented business justification.

• Document any project-level exceptions with the owning team, the reason, and a review date so they do not persist indefinitely.

Auditing for existing out-of-compliance resources

Location policy only prevents future violations. To find resources already outside your approved locations, Cloud Asset Inventory is the most practical tool:

# Find all Cloud Storage buckets and their locations across the org
gcloud asset search-all-resources \
  --scope=organizations/ORG_ID \
  --asset-types=storage.googleapis.com/Bucket \
  --format="table(name,location)"

# Find Compute Engine instances running in US zones
gcloud compute instances list \
  --project=my-app-prod \
  --filter="zone:us-*" \
  --format="table(name,zone,status)"

# Find BigQuery datasets and their locations
bq ls --format=prettyjson --project=my-app-prod | \
  python3 -c "import json,sys; [print(d['datasetReference']['datasetId'], d.get('location','unknown')) for d in json.load(sys.stdin)]"

Once you have the inventory, prioritise migration based on data sensitivity. Resources holding customer data or regulated information should be addressed before infrastructure-only resources.