Restrict resource locations

Overview

This guide describes how to set an organization policy that includes the resource locations constraint.

You can limit the physical location of a new resource with the Organization Policy Service resource locations constraint. You can use the location property of a resource to identify where it is deployed and maintained by the service. For data-containing resources of some Google Cloud services, this property also reflects the location where data is stored. This constraint lets you define the allowed Google Cloud locations where the resources for supported services in your hierarchy can be created.

After you define resource locations, this limitation will apply only to newly-created resources. Resources you created before setting the resource locations constraint will continue to exist and perform their function.

A policy that includes this constraint won't be enforced on sub-resource creation for certain services, such as Cloud Storage and Managed Service for Apache Spark.

Limitations

The resource locations Organization Policy Service constraint controls the ability to create resources for which a location can be selected. This constraint does not affect where global resources, such as Compute Engine global addresses, or resources that don't support selecting a location are created.

To avoid breaking existing serving infrastructure, you should test any new policy on non-production projects and folders, then apply the policy gradually within your organization.

For data storage commitments, see the Google Cloud Terms of Service and the Service Specific Terms. Organization policies that contain the resource locations constraint aren't data storage commitments.

This constraint applies to a specific subset of products and resource types. For a list of supported services and details on the behavior of each service, see the Services that support restricting resource locations page.

Location types

You can deploy Google Cloud resources in location types that represent different size categories. The largest location type is the multi-region, which includes more than one region. Each region is further subdivided into zones. For more information about regions and zones, see the Regions and Zones overview.

Multi-region locations are backed by physical resources in more than one region and are typically only used by storage-based resources. Some examples include us, asia, europe, and global.
Region locations are geographically isolated from each other. Some examples include us-west1 (Oregon), asia-northeast1 (Tokyo), and europe-west1 (Belgium).
Zone locations are the most granular and isolated location type used for deploying resources. A zone is an independent failure domain within a region. Some examples are us-east1-b, us-west1-b, and asia-northeast1-a. Google Cloud also offers specialized AI zones that are tailored for AI and ML workloads—for example, us-central1-ai1a.

When setting up locations, you should use the in: prefix and a Value Group. Using a Value Group curated by Google Cloud lets you choose geographic location(s), without having to specify current or future Cloud locations.

The in: prefix to a Value Group specifies that all values that exist within the value group are considered to be part of the policy. If you enter a group value or a Google Cloud region without the prefix, the in: prefix will be automatically added, per these rules:

If you enter a location that uses the in: prefix, and it contains any invalid group, the policy change will fail.
If you enter a location that is a region, such as us-east1, it will have the in: prefix prepended, to in:us-east1-locations in this example.
If you enter a region or multi-region value group such as us-locations, it will have the in: prefix prepended, to in:us-locations in this example.
If you enter a zone or multi-region such as us-east1-b or us, the values won't be changed.

Setting the organization policy

The resource locations constraint is a type of legacy managed constraint with list rules. You can add and remove locations from the allowed_values or denied_values lists of a resource locations constraint. To prevent organization policies from unexpectedly restricting service behavior as new locations are added to the available list, use a value group, or a list of allowed_values that represents the entire geographic boundary you want to define.

To set an organization policy including a resource locations constraint:

Console

In the Google Cloud console, go to the Organization policies page.

Go to Organization policies
From the project picker, select the organization, folder, or project for which you want to set the organization policy.
Select the Google Cloud Platform - Resource Location Restriction constraint to open its Policy details page.
Click Manage policy.
On the Edit policy page, select Override parent's policy.
Under Policy enforcement, select Replace.
Click Add rule.
Under Policy values, select Custom.
Under Policy type, select Allow to create a list of allowed locations, or select Deny to create a list of denied locations.
In the Policy value box, enter the in prefix and a value group location string, then press Enter.

For example, in:us-locations or in:us-west1-locations. You can enter multiple location strings by clicking Add value.

You can also enter specific zone, region, or multi-region locations as location strings. For a list of available locations, see the Services that support restricting resource locations page.
To enforce the policy, click Set policy.

gcloud

To create an organization policy that enforces the resource locations constraint, create a policy YAML file that references the constraint:

name: organizations/ORGANIZATION_ID/policies/gcp.resourceLocations
spec:
  rules:
  - values:
      deniedValues:
      - in:us-east1-locations
      - in:northamerica-northeast1-locations

To enforce the organization policy containing the constraint, run the following command:

gcloud org-policies set-policy POLICY_PATH

Replace the following: