Resource locations supported services

The resources used by each service are impacted by location in different ways. Before adding a resource locations constraint to your organization policy, review the appropriate section below to see how the resources you are applying the policy to will behave.

Note: Organization policies, including those with the resource locations constraint, are not retroactive. Adding the resource locations constraint to existing resources will not restrict their location, but might restrict automatic child resource creation or other functionality.

AI Platform

Resource locations constraints apply to the following AI Platform resources:

• AI Platform Training's job resource
• AI Platform Prediction's job resource
• AI Platform Prediction's model resource

AI Platform Training and AI Platform Prediction resources only support region locations. Constraints on multi-region locations and zone locations have no effect on AI Platform. However, constraints on value groups that contain regions do have an effect. For example, the value asia in an organization policy has no effect on AI Platform, but the value in:asia-locations does have an effect.

Learn more about regions available for AI Platform Training and regions available for AI Platform Prediction.

AI Platform (Unified)

Resource locations constraints apply to all AI Platform (Unified) resources except for DataLabelingJob resources.

AI Platform (Unified) only supports region locations. Constraints on multi-region locations and zone locations have no effect on AI Platform (Unified). However, constraints on value groups that contain regions do have an effect. For example, the value asia in an organization policy has no effect on AI Platform (Unified), but the value in:asia-locations does have an effect.

Learn more about regions available for AI Platform Training

App Engine

App Engine is a property of the application resource. The location property is enforced for all environments when you create an application. You can create only one App Engine application in each project. A Cloud Storage bucket is automatically created in the same location as the application. If you create an application with a broad location that doesn't comply with the organization policy, you will have to create a new project and App Engine application.

When you disable an application, it won't be served in future, but replicated code and data will remain in locations the application was stored in. To completely erase this data, delete the parent project.

The App Engine flexible environment is built on top of Compute Engine. Auto-scaling instances can fail if any locations where scaling happens aren't in the list of allowed locations that are defined in the organization policy.

For a list of available locations, see App Engine Locations.

Compute Engine

Compute Engine offers a variety of resources, and these can be global, regional, or zonal. Regional and zonal resources are subject to the resource location constraints. Global resources are not subject to the resource locations constraint, but some global resources use regional and zonal resources; those regional and zonal resources are subject to the resource locations constraint.

For example, an instance template is a global resource, but you might specify regional or zonal disks in an instance template. Those disks are subject to the resource locations constraints, so, in your instance template, you must specify disks in regions and zones that your org policy permits.

Limitations

All Compute Engine resources support the resource location constraints that you specify, with the following exceptions.

• Snapshots and images

  • When you create a snapshot or image, you must specify a storage location in a permitted location, otherwise the creation of the snapshot or image might fail.

• Managed instance groups

  • Some managed instance group (MIG) operations rely on the creation or recreation of VMs in permitted zones. These operations include: scaling out (manually or through autoscaling), autohealing, autoupdating, and proactive instance redistribution. For those operations to succeed, your MIGs must exist in locations that are allowed by your org's resource location constraint.

  • Create MIGs in permitted locations. For regional MIGs, select zones that are not location restricted.

  • If you have a preexisting zonal or regional MIG, and later set a resource location constraint, MIG operations will fail if they violate the constraint. You must recreate the MIG in a permitted location.

• Sole-tenant nodes

  • If you have a preexisting node group and later set a resource location constraint, you cannot scale out the group to add new hosts (manually or through autoscaling) if the group's location violates the constraint.

• HA VPN gateway

  • You can create an HA VPN gateway in any location. HA VPN gateways are not restricted by resource location constraints.

For a list of available locations, see the Compute Engine Regions and Zones page.

Google Kubernetes Engine

Google Kubernetes Engine uses Compute Engine regions and zones. Enforcement of the resource locations is handled at the level of the Compute Engine resource when you create the VM for a cluster. If you want to scale a cluster by adding more instances or adding another zone, these new additions must also be in an allowed location.

To create clusters with sufficient redundancy, use value groups to control the locations that are restricted. If you set the locations manually, all zones in that region must be in the allowed list to have the same level of redundancy. Auto-scaling clusters can break if any of the locations in which scaling happens aren't in the list of allowed locations defined in the organization policy.

Cloud Bigtable

A Cloud Bigtable instance resource is a logical container of clusters. Each of these clusters is located in a zone. All data in an instance is replicated uniformly to all clusters that are contained in that instance. Organization policy is enforced when a cluster is created. You can't create new storage containers in a location that is denied by the organization policy. Existing instances and clusters will continue to operate even if they are in locations that are denied by a subsequent change to the organization policy.

You can manually remediate resources that violate a new organization policy, by deleting them and recreating them once the organization policy is put into place. For example, if you had a multi-cluster instance in which one cluster violated a new organization policy, you could delete it and then add a new cluster in a permitted zone.

For a list of available locations, see the Cloud Bigtable Locations page.

Datastore

The Datastore database resources are directly dependent on the App Engine application in the parent project and its defined location. Disabling the App Engine application will block API access for the associated database. To delete replicated data from the physical locations, delete the project as described in the App Engine section.

For a list of available locations, see the Datastore Locations page.

Cloud Spanner

Organization policy is enforced when you create an instance. Instances are either regional or multi-regional resources. If an instance is blocked by the resource locations organization policy, the only way to bring the resource into compliance is by deleting the instance. Instances that are blocked by the resource locations organization policy will still allow for reads, writes, and the creation of database resources.

For a list of available locations, see the Cloud Spanner Instances page.

Cloud SQL

Organization policy is enforced when you create an instance. The instance is a regional resource that will create a zonal database, for which the resource location is not enforced. When you create read replicas or database clones, you locate the new resources in the same region as the original, so the resource locations organization policy isn't enforced.

For a list of available locations, see the Cloud SQL Instance Locations page.

Filestore

Organization policy is enforced when you create a Filestore instance, which is a zonal resource. Organization policy compliance isn't enforced retroactively. Existing instances will continue to operate even if they are in locations that are denied by the organization policy. To enforce a new resource location constraint on an existing Filestore instance, delete the instance and then create it again with the organization policy applied.

For a list of available locations, see the Filestore Regions and Zones page.

Cloud Storage

Organization policy is enforced when you create a bucket resource. Bucket resources are regional or multi-regional. Object resources can be added to any existing bucket even if the object is in a location that is denied by the resource locations organization policy. To ensure that your resources are in compliance with the resource locations organization policy, create new bucket resources after the organization policy is applied, and then migrate data from old bucket resources to the new ones.

For a list of available locations, see the Cloud Storage Bucket Locations page.

Persistent Disk

The organization policy is enforced when you create a disk resource, which can then be attached to virtual machines:

• After you create a zonal disk resource, you can attach it to virtual machine instances in the same zone.
• After you create a regional disk resource, you can attach it to virtual machine instances in one of the two zones the disk resides in.

Organization policy compliance isn't enforced retroactively. To enforce a new resource locations organization policy on existing disk resources, you need to delete the disk resources and then create them again with the organization policy applied to the parent resource.

For a list of available locations, see the Compute Engine Regions and Zones page.

BigQuery

BigQuery dataset resources can be both regional and multi-regional. Organization policy compliance isn't enforced retroactively. To enforce a new resource locations constraint on an existing dataset, delete the dataset resource and create it again with the organization policy applied to the parent resource.

You can create Database resources within a dataset resource with a location that is denied by the resource locations organization policy. The location of the dataset resource does not dictate the location of the database resource. To enforce a new resource locations constraint on an existing disk, delete the disk resource and create it again with the organization policy applied to the parent resource.

For a list of available locations, see the BigQuery Dataset Locations page.

Dataflow

The organization policy is enforced when you create a job. A job is a regional resource that uses both Cloud Storage and Compute Engine. You can configure Compute Engine workers to execute in a zone outside the region of the job by specifying the zone parameter. In this case, the Dataflow control plane will execute in the specified region, while data processing workers will execute in the specified zone. If you don't specify the zone of workers, the workers will be created within the region in which the job is configured to run.

If you don't specify the zone of the job, the location of the workers will be in one of the zones within the region in which the job is configured to run. Dataflow will select the zone based on the available capacity in the zone. All zones within the region of the job should be set as allowed values in the resource locations organization policy.

Auto-scaling clusters can break if any of the locations in which scaling happens isn't in the list of allowed locations defined in the organization policy.

For a list of available locations, see the Dataflow Regional endpoints page.

Dataproc

When you create a cluster, the organization policy is enforced based on the region you specify in the creation request. The location of a job is bound by the location of the cluster that is its parent when the submit method is called.

For a list of available locations, see the Dataproc Regional endpoints page.

Pub/Sub

The resource locations organization policy affects the locations in which messsages published to a topic can be persisted at rest. The organization policy is enforced when you publish messages to a topic. Note that a topic is still a global resource that is accessible from anywhere in the world to authorized clients.

Changes to the organization policy are not retroactive, and will not be applied to existing topics. If a new resource locations constraint denies a location where messages published to a topic are already stored, those messages will not be automatically moved.

For more information, see the Pub/Sub Restricting Pub/Sub resource locations page.

Pub/Sub Lite

The resource locations organization policy affects the locations in which a topic can be created, which determines where messages will be persisted. A topic is a zonal resource, but messages can be requested from any location, including outside of Google Cloud.

Changes to the organization policy are not retroactive, and will not be applied to existing topics. If a new resource locations constraint denies a location where messages published to a topic are already stored, those messages will not be automatically moved.

Cloud Healthcare API

The organization policy is enforced when you create a dataset resource. dataset resources are either regional or multi-regional resources. Data store resources, such as FHIR store, or other lower-level resources, such as HL7v2 messages, can be added to any existing dataset, even if the dataset resource is in a location that is denied by the organization policy. To ensure that your resources are in compliance with the resource location constraint, create new dataset resources after the organization policy is applied, and then migrate data from old dataset resources to the new ones.

For a list of available locations, see Cloud Healthcare API Regions.

Cloud Key Management Service

Cloud KMS resources can be created in regional, dual-regional, multi-regional, or global locations. The organization policy will be enforced at the time you create that resource.

For more information, see the Cloud KMS locations page.

Managed Service for Microsoft Active Directory

Organization policy is enforced when you create Managed Microsoft AD domains or update existing AD resources. Managed Microsoft AD requires the global location to be allowed. If the global location is not allowed, domain creation and resource updates will fail.

Learn how to view and update the resource location constraint to global.

Secret Manager

Secrets can have either an automatic replication policy or a user managed replication policy.

When using an automatic replication policy, payload data is replicated without restriction. Secret Manager requires the global location to be allowed when creating a secret with an automatic replication policy. If the global location is not allowed, secret creation will fail.

When using a user managed replication policy, payload data is replicated to a user defined set of supported locations. Secret Manager requires all locations in the replication policy to be allowed when creating a secret with a user managed replication policy. If any of the locations in a secret's replication policy are not allowed, secret creation will fail.

The organization policy will be enforced at the time you create that secret.

For more information, see the Secret Manager locations page.

Cloud Composer

Note: Cloud Composer supports location constraints on the region level. Location constraints on the zone level are not supported.

A Cloud Composer environment is a logical container for the resources listed below. During the environment creation process, you choose a location (region/zone) for the environment and the underlying resources are created based on the location selected.

• Google Kubernetes Engine cluster

• Cloud SQL instance

• App Engine VM(s) running Airflow web server

• Persistent Disks: Used by the Airflow Webserver and GKE cluster

• Pub/Sub topics

• Cloud Storage

• Building and Storing Airflow images with custom Python dependencies

  • When location restrictions are not specified then depending on the configuration Composer might build Airflow images either within GKE cluster or using Cloud Build. Please, read more about it here. Depending on Composer version Airflow images might be stored in the selected region (using Artifact Registry) or multi-region to which the selected region belongs to (using Container Registry).

  • If location restrictions are specified, Cloud Composer builds Airflow images within the environment's GKE cluster and stores them in Artifact Registry repository in the selected region.

• Cloud Monitoring: Stores metrics for environments and executed Airflow DAGs in the region you specify

  • Some metric labels may contain names of DAGs and Cloud Composer environments.

• Cloud Logging: By default, Cloud Composer stores in Cloud Logging which is a global Google Cloud service. If you want to store Cloud Composer logs in a specific location, you must redirect logs to a Cloud Storage bucket in this location.

For a list of available locations, see Cloud Composer Regions.

The Cloud Composer documentation provides more information on the architectural details of Cloud Composer environments.

Cloud Run

Organization policy is enforced when you create a top-level resource, such as a Service. It is not enforced on any already existing resources or on updates to existing resources, even if those updates lead to the creation of a lower level resource, such as a Revision.

For a list of available regions, see the Cloud Run locations page.