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.

Agent Assist

Organization policy is enforced when you create a conversation profile or a knowledge base resource in Agent Assist. Both resources are regional.

For a list of available locations and limitations, see the Agent Assist regionalization and data residency page.

Apigee

Resource locations constraints are enforced when creating the following Apigee resources:

For list of available locations, see Apigee locations.

Learn more about how to set an organization policy with resource locations constraints in Restricting resource locations.

AI Platform

Resource locations constraints apply to the following AI Platform resources:

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.

AlloyDB for PostgreSQL

Organization policy is enforced when you create clusters, instances, and certain types of backups. The creation of on-demand backups is subject to the organization policy, while the creation of automated and continuous backups is exempted if enabled to prevent data loss.

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

For a list of available locations, see AlloyDB for PostgreSQL locations.

Anti Money Laundering AI

Resource locations constraints apply to all Anti Money Laundering AI resources and are enforced at the time of resource creation.

For a list of available locations, see AML AI locations.

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.

Application Integration API

The organization policy is enforced when you use the Application Integration API to create the following resources:

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

Application Integration is regional, which means that an integration created in a specific region can access the resources only within that region.

For a list of available locations, see Application Integration locations.

Limitations

The following Application Integration resources don't support the resource location constraints that you specify:

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.

Backup for GKE

Organizational policy is enforced when you create either of the top-two regional resources:

  • BackupPlan: the location of this resource determines the target region where all backup data is stored for backups created below this plan. There may be multiple BackupPlan resources in a project.

  • RestorePlan: the location of this resource controls the allowable region of the target cluster into which data from a backup is restored. There may be multiple RestorePlan resources in a project

For more information, see Backup for GKE locations.

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 doesn't 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 can't 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.

Bigtable

A 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 Bigtable Locations page.

Cloud Build

Organization policy is enforced when you create new regional Cloud Build resources. Although you can create resources in any region, Cloud Build ensures that you select a region approved by your organization. Organization policy is only enforced on newly created Cloud Build resources in a non-global region after you create the organization policy.

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

Cloud Composer

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.

Cloud Data Fusion

Organization policy is enforced when you create an instance. The instance is a regional resource that is created in the region that you specify.

When you create an instance with a customer-managed encryption key (CMEK), the key location must be the same as the instance location.

By default, Cloud Data Fusion creates ephemeral Dataproc clusters in the same region as the instance for each pipeline. The location for these ephemeral clusters can be changed and isn't enforced by the resource locations organization policy. For static Dataproc clusters, you can use any of the locations supported by Dataproc and these locations aren't enforced by the resource locations organization policy.

For a list of available locations, see Cloud Data Fusion supported regions.

Cloud Deploy

The following are the Cloud Deploy resource types:

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

All 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 Cloud Deploy resources in that region (delivery pipeline, target, release, or rollout).

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

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 Interconnect

A Cloud Interconnect attachment can be created in any region. However, you can't choose a zone. The organizational policy is enforced at the time that you create the Cloud Interconnect attachment.

For a list of available regions, see the Compute Engine Regions and zones page.

Cloud Intrusion Detection System

Organization policy is enforced when you create a Cloud IDS endpoint, which is a zonal resource. Organization policy compliance isn't enforced retroactively. Existing endpoints 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 Cloud IDS endpoint, delete the instance and then create it again with the organization policy applied.

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

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 NAT

A Cloud NAT gateway can be created in any regional location. However, you can't choose a zone for a Cloud NAT gateway. The organizational policy is enforced at the time that you create the Cloud NAT gateway.

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

Cloud Router

A Cloud Router can be created in any regional location. However, you can't choose a zone for a Cloud Router. The organizational policy is enforced at the time that you create the Cloud Router.

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

Cloud Load Balancing

Load balancers using the following products can be created in any regional location:

  • regional external Application Load Balancer
  • regional external proxy Network Load Balancer
  • regional internal Application Load Balancer
  • regional internal proxy Network Load Balancer
  • external passthrough Network Load Balancer
  • internal passthrough Network Load Balancer

However, you cannot choose a zone for these load balancers. The organizational policy is enforced at the time that you create the load balancing resource.

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

Google Cloud Armor

When you create a Google Cloud Armor security policy, the organization policy is enforced based on the region you specify in the creation request. The policy is not enforced on already existing resources. Global resources are not subject to the resource locations constraint.

For a list of available regional locations, see the Compute Engine Regions and zones 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.

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 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.

Cloud VPN

A Cloud VPN gateway can be created in any regional location. However, you can't choose a zone for a Cloud VPN gateway. The organization policy is enforced at the time that you create the Cloud VPN gateway.

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

Cloud Workstations

Organization policy is enforced when you create new regional resources such as workstation clusters, workstation configurations, and workstations. Creation of a workstation configuration might result in the creation of Compute Engine persistent disks and VMs, so you can create these resources only in zones that your organization policy allows.

For a list of available locations, see Cloud Workstations 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 pre-existing 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 pre-existing node group and later set a resource location constraint, you can't scale out the group to add new hosts (manually or through autoscaling) if the group's location violates the constraint.

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.

Contact Center AI Insights

The organization policy is enforced when you create a conversation in Contact Center AI Insights. conversation resources are regional.

For a list of available locations, see the Contact Center AI Insights 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 aren't in the list of allowed locations defined in the organization policy.

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

Dataform

Dataform resources are regional. When you create a Dataform repository, the repository and all its child resources are constrained to the region specified on repository creation.

For a list of available locations, see Dataform locations.

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 doesn't 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.

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.

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.

Generative AI on Vertex AI

Resource locations constraints apply to all Generative AI on Vertex AI resources. Organization policy compliance isn't retroactively enforced. This means that applying a resource locations constraint doesn't affect any pre-existing resources or updates to those resources.

For a list of available regions, see Generative AI on Vertex AI locations.

GKE Multi-Cloud

The organization policy is enforced when you use the GKE Multi-Cloud API to create the following clusters:

  • GKE on AWS
  • GKE on Azure
  • GKE attached clusters

For a list of available locations, see the following pages for each cluster platform.

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.

Infrastructure Manager

Infrastructure Manager uses these Google Cloud regions for creating Infra Manager Deployments.

Additionally, Infrastructure Manager uses HCL as the configuration language to actuate resources using Terraform.

Resource location constraints are enforced for both Infra Manager Deployment resources as well as the supported Google Cloud resources defined in HCL.

Integration Connectors API

The organization policy is enforced when you use the Integration Connectors API to create the following resources:

For a list of available locations, see Integration Connectors locations.

Looker (Google Cloud core)

Looker (Google Cloud core) resources can be created in regional locations. The organization policy will be enforced at the time you create that resource.

For a list of available regions, see the Create a Looker (Google Cloud core) instance 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.

Memorystore for Memcached

The organization policy is enforced when you create an instance. The instance is a regional resource that creates one or more zonal caches depending on the number of nodes selected. When you add nodes using a scale-up operation, you locate the new resources in the same region as the original instance. The location organization policy is enforced during scale-up.

For a list of available locations, see the Memorystore for Memcached Regions and Zones page.

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.

Network Connectivity Center

Network Connectivity Center Hub and VPC Spoke resources can be created in the global location. Network Connectivity Center Hybrid Spoke resources can be created in any regional location. The organization policy will be enforced at the time you create that resource.

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

Network Intelligence Center - Connectivity Tests

Connectivity Tests resources can be created in the global location. The organization policy will be enforced at the time you create that resource.

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.

Secure Source Manager

Organization policy is enforced when you create new Secure Source Manager instances. Secure Source Manager ensures that you select a region approved by your organization. Organization policy is only enforced on newly created Secure Source Manager instances in a region after you create the organization policy.

For more information, see the Secure Source Manager overview page.

Sensitive Data Protection

Resource location constraints apply to all Sensitive Data Protection resources.

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

Learn more about regions available for Sensitive Data Protection.

Speaker ID

The resource locations organization policy affects the locations in which a speaker resource can be created, which determines where enrollment phrases and voiceprints are stored.

The resource locations organization policy also affects the locations in which settings can be updated.

Learn more about Speaker ID available regions.

Speech-to-Text

The resource locations organization policy affects the locations in which any Speech-to-Text resource can be created. It also affects the locations in which the config resource can be updated.

Speech-to-Text v1 is available in the global, eu, and us regions. Learn more about Speech-to-Text v2 available regions.

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.

Resource locations constraints apply to all Vertex AI Search resources. Organization policy compliance isn't retroactively enforced. This means that applying a resource locations constraint doesn't affect any pre-existing resources or updates to those resources.

For a list of available regions, see Vertex AI Search locations.

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.