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.

Apigee Integration API

The organization policy is enforced when you use the Apigee Integrations API to create the following resources:

• Integration
• Authorization configuration (AuthConfig)
• Certificate for AuthConfig
• Integration version
• SFDC (Salesforce) channel
• SFDC (Salesforce) instance

The organization policy is also enforced when you run, schedule, or test an integration.

Apigee integrations are region specific. It means that an integration created in a specific region, can access the resources only within that region.

For a list of available locations where you can create your integrations, see Supported Regions.

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.

Artifact Registry

You can create repositories in a multi-region or region. Artifact Registry enforces organization policy when you create a repository.

Organization policy compliance isn't enforced retroactively. Artifacts can be added to any existing repository, even if the repository location is denied by the resource locations organization policy. To enforce a new resource locations organization policy on existing repositories, create new repositories after the organization policy is applied, and then migrate artifacts from old repositories to the new ones. You can use the gcrane tool to copy images between repositories.

For a list of available locations, see the Artifact Registry documentation.

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 database, delete the database 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.

BigQuery Migration Service

The MigrationWorkflow resource describes the tasks and subtasks that constitutes the migration workflow. They can be created by using the Google Cloud console or the API when running the migration assessment or SQL translation. The migration workflow must be created in the same location as the resources that it uses. For example, if your BigQuery dataset and the Cloud Storage bucket are in the US multi-region then the migration workflow can be created in the US multi-region or the us-west1 region.

Organization policy is checked only when creating a migration workflow, because it is an immutable resource.

For a list of available locations, see BigQuery Migration Service locations.

Certificate Authority Service

CA Service resources such as certificate templates, certificate authority (CA) pools, and CAs can be created in any available location. These resources cannot be moved after creation.

Certificate templates can be replicated using Google Cloud CLI commands. You can use gcloud CLI commands to create resources with the same name in another supported location. For more information, see Creating certificate templates.

CAs can be cloned from existing CAs in the same CA pool. These new CAs are created in the same location as the CA from which they were cloned. For more information, see Creating certificate authorities.

For the list of available locations, see CA Service locations.

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.

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. Read more about it in Installing a Python dependency to a private IP environment. 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.

Fleet

Cloud Fleet membership resource only supports region locations in Compute Engine regions and zones. Enforcement of the resource locations is handled at the level of the membership resource when you register a cluster. Fleet memberships are supported in global and regional locations.

To create memberships with sufficient redundancy, use value groups to control the regions that are restricted. Constraints on multi-region locations and zone locations have no effect on Fleet membership. 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 Fleet membership, but the value in:asia-locations does have an effect.

Cloud Functions

Organization policy is enforced when you create or update a Cloud Function resource. It is not enforced on any already existing resources.

For a list of available regions, see Cloud Functions locations.

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.

Cloud Logging

Organization policy is enforced when you create new log buckets. While you can create a new bucket in any region or set its location to global, Logging ensures that you select a region approved by your organization. Organization policy is only enforced on newly created log buckets after you create your organization policy.

For a list of available regions, see the Regionalization section of the Cloud Logging storage overview page.

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.

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.

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.

Cloud Tasks

Organization policy is enforced when you create a queue. It is not enforced on queues that were created before the organization policy was set, or on updates to such queues.

For a list of available locations, see Products available by location.

Limitations

Limitations apply to the following regions:

• us-central1
• us-central2 (private Google Cloud region)

To allow the creation of queues in either of these regions, you must include both us-central1 and us-central2 in your organization policy. You can include the region us-central2 in your organization policy even if your organization doesn't use private regions.

Cloud Translation - Advanced API (v3)

To ensure that your Cloud Translation resources are in compliance with the resource location constraint, specify a regional endpoint when creating the resource. The resource location constraint is enforced when you create a Cloud Translation resource.

For information about how to use regional endpoints, see Specify a regional endpoint.

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.

Config Controller

Config Controller 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 cluster. To scale a cluster by adding more instances 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.

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.

Dataproc Metastore

When you create a service, the organization policy is enforced based on the region you specify in the creation request. The location of backups and metadataImports are bound by the location of the service that is its parent when the importMetadata and backupService methods are called.

For a list of available locations, see the Dataproc Metastore 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.

Dialogflow

Organization policy is enforced when you create an agent or a location setting resource in Dialogflow CX (Dialogflow ES does not enforce organization policy yet). Both agent resources and location setting resources are regional or multi-regional. Other Dialogflow resources, such as intents or flows, can be added to any existing agent, even if the agent 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 agent resources after the organization policy is applied, and then migrate data from the old agent resources to the new ones.

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

Cloud Data Loss Prevention

Resource location constraints apply to all Cloud DLP resources.

Changes to the organization policy are not retroactive and will not be applied to existing resources.

Learn more about regions available for Cloud DLP.

Document AI

Document AI resources are regional. When you create a Processor or LabelerPool resource, the resource location organization policy is enforced and restricts the regions in which new resources can be created or stored.

Organization policy compliance isn't enforced retroactively. New Document AI resources can be created under existing parent resources, even if the parent's resource location is denied by the resource locations organization policy. To enforce a new resource location constraint on an existing resource, delete the resource and create it again with the organization policy applied.

For a list of available locations, see the Document AI Multi-regional support page.

Eventarc

Organization policy is enforced when you create an Eventarc trigger. The policy is not enforced on already existing resources or on updates to existing resources. Triggers can be either a global or regional resource. Global resources are not subject to the resource locations constraint.

If the resource locations constraint is enforced, only regional triggers whose regions exactly match those applied in the resource locations constraint or are included in the value group can be created. For example, if either us-central1 or us-locations are in the list of allowed locations defined in the organization policy, you can create a us-central1 trigger.

For a list of available locations, see Eventarc locations.

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.

Firestore

The Firestore 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 Firestore Locations page.

Google Cloud Deploy

The following are the Google Cloud Deploy resource types:

• Delivery pipeline
• Target
• Release
• Rollout
• Job run

All Google Cloud Deploy resources are created in the same region where the delivery pipeline was created.

If you have an organization policy against using certain locations, you can't create any Google Cloud Deploy resources in that region (delivery pipeline, target, release, or rollout).

For a list of available locations for the Google Cloud Deploy service and its resources, see About Google Cloud Deploy regions.

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.

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.

Memorystore for Redis

Organization policy is enforced when you create an instance. The instance is a regional resource that will create one or more zonal caches depending on the selected instance tier. Basic tier instances deploy a single cache within a specified region and zone. Standard tier instances deploy a zonal cache and one or more zonal cache replicas which are located within the instance's region. When you create additional replicas, you locate the new resources in the same region as the original zonal cache. The location organization policy is enforced when creating additional replicas.

For a list of available locations, see the Memorystore for Redis Regions and Zones 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.

Pub/Sub

The resource locations organization policy affects the locations in which messages 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.

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.

Timeseries Insights API

Resource locations constraints apply to all Timeseries Insights API resources.

Timeseries Insights API only supports region locations. An integration created in a specific region can only access the resources within that region. Constraints on multi-region locations and zone locations have no effect on Timeseries Insights API. 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 Timeseries Insights API, but the value in:asia-locations does have an effect.

For a list of available locations where you can create your integrations, see Supported Regions.

Transcoder API

job and jobTemplate resources are regional. You can specify a location when creating the resource. The organization policy is enforced at the time you create the resource.

For a list of available regions, see Transcoder API locations.

Vertex AI

Resource locations constraints apply to all Vertex AI resources except for DataLabelingJob resources.

Vertex AI only supports region locations. Constraints on multi-region locations and zone locations have no effect on Vertex AI. 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 Vertex AI, but the value in:asia-locations does have an effect.

Learn more about regions available for AI Platform Training

Workflows

Organization policy is enforced when you create a Workflows workflow. The policy is not enforced on already existing resources or on updates to existing resources. Workflows are regional resources and are subject to the resource locations constraint.

If the resource locations constraint is enforced, only workflows whose regions exactly match those applied in the resource locations constraint or are included in the value group can be created. For example, if either us-central1 or us-locations are in the list of allowed locations defined in the organization policy, you can create a us-central1 workflow.

For a list of available locations, see Workflows locations.