Servicios compatibles de ubicaciones de recursos

Los recursos que utiliza cada servicio se ven afectados por la ubicación de diferentes formas. Antes de añadir una restricción de ubicaciones de recursos a tu política de organización, consulta la sección correspondiente a continuación para ver cómo se comportarán los recursos a los que apliques la política.

Agent Assist

La política de organización se aplica cuando creas un recurso conversation profile o knowledge base en Agent Assist. Ambos recursos son regionales.

Las restricciones de ubicación de los recursos no se aplican a la ubicación global, por lo que siempre se permite la creación de recursos.

Para ver una lista de las ubicaciones disponibles y las limitaciones, consulta la página Regionalización y residencia de datos de Asistente.

AlloyDB for PostgreSQL

La política de organización se aplica cuando creas clústeres, instancias y determinados tipos de copias de seguridad. La creación de copias de seguridad bajo demanda está sujeta a la política de la organización, mientras que la creación de copias de seguridad automáticas y continuas está exenta si se habilita para evitar la pérdida de datos.

AlloyDB para PostgreSQL solo admite ubicaciones de regiones. Las restricciones en las ubicaciones multirregionales y de zona no tienen ningún efecto. Sin embargo, las restricciones de los grupos de valores que contienen regiones sí tienen efecto. Por ejemplo, el valor asia de una política de la organización no tiene ningún efecto, pero el valor in:asia-locations sí.

Para ver una lista de las ubicaciones disponibles, consulta Ubicaciones de AlloyDB para PostgreSQL.

Anti Money Laundering AI

Las restricciones de ubicación de los recursos se aplican a todos los recursos de IA contra el blanqueo de capitales y se aplican en el momento de crear los recursos.

Para ver una lista de las ubicaciones disponibles, consulta Ubicaciones de AML AI.

API Gateway

Las restricciones de ubicación de los recursos se aplican al crear pasarelas, que son recursos regionales. Otros recursos de API Gateway, como las APIs y las configuraciones de API, son recursos globales y no están sujetos a restricciones de ubicación de recursos.

Para ver la lista de ubicaciones admitidas de API Gateway, consulta Elegir una región Google Cloud .

Consulta más información sobre cómo definir una política de organización con restricciones de ubicaciones de recursos en el artículo Restringir ubicaciones de recursos.

Apigee

Las restricciones de ubicación de recursos se aplican al crear los siguientes recursos de Apigee:

Para ver una lista de las ubicaciones disponibles, consulta Ubicaciones de Apigee.

Consulta más información sobre cómo definir una política de organización con restricciones de ubicaciones de recursos en el artículo Restringir ubicaciones de recursos.

Hub de APIs de Apigee

Las restricciones de ubicación de recursos se aplican a todos los recursos del hub de APIs de Apigee. El cumplimiento de las políticas de la organización no se aplica de forma retroactiva. Esto significa que, si aplicas una restricción de ubicación de recursos, no se verán afectados los recursos que ya existan ni las actualizaciones de esos recursos.

Para ver una lista de las ubicaciones disponibles, consulta Ubicaciones del hub de APIs de Apigee.

API de integración de Apigee

La política de la organización se aplica cuando usas la API Apigee Integrations para crear los siguientes recursos:

  • Integración
  • Configuración de autorización (AuthConfig)
  • Certificado de AuthConfig
  • Versión de integración
  • Canal de SFDC (Salesforce)
  • Instancia de SFDC (Salesforce)

La política de la organización también se aplica cuando ejecutas, programas o pruebas una integración.

Las integraciones de Apigee son específicas de cada región. Esto significa que una integración creada en una región específica solo puede acceder a los recursos de esa región.

Para ver una lista de las ubicaciones disponibles en las que puedes crear tus integraciones, consulta Regiones admitidas.

App Engine

App Engine es una propiedad del recurso application. La propiedad de ubicación se aplica a todos los entornos cuando creas un application. Solo puedes crear un application de App Engine en cada proyecto. Se crea automáticamente un segmento de Cloud Storage en la misma ubicación que el application. Si creas un application con una ubicación amplia que no cumple la política de la organización, tendrás que crear un proyecto y un application de App Engine.

Cuando inhabilitas un application, no se servirá en el futuro, pero el código y los datos replicados permanecerán en las ubicaciones en las que se almacenó el application. Para eliminar estos datos por completo, elimina el proyecto principal.

El entorno flexible de App Engine se basa en Compute Engine. Las instancias de escalado automático pueden fallar si alguna de las ubicaciones en las que se produce el escalado no está en la lista de ubicaciones permitidas definidas en la política de la organización.

Para ver una lista de las ubicaciones disponibles, consulta Ubicaciones de App Engine.

App Hub

La política de la organización se aplica cuando creas una aplicación en App Hub. Una aplicación regional solo puede contener recursos de esa región, mientras que una aplicación global puede contener recursos globales y recursos de cualquier región. Para obtener más información, consulta Aplicaciones globales y regionales de App Hub.

Para ver una lista de las ubicaciones disponibles, consulta Ubicaciones de App Hub.

API Application Integration

La política de organización se aplica cuando usas la API Application Integration para crear los siguientes recursos:

La política de la organización también se aplica cuando ejecutas, programas o pruebas una integración.

La integración de aplicaciones es regional, lo que significa que una integración creada en una región específica solo puede acceder a los recursos de esa región.

Para ver una lista de las ubicaciones disponibles, consulta Ubicaciones de integración de aplicaciones.

Limitaciones

Los siguientes recursos de integración de aplicaciones no admiten las restricciones de ubicación de recursos que especifiques:

Artifact Registry

Puedes crear repositorios en una multirregión o en una región. Artifact Registry aplica la política de la organización cuando creas un repositorio.

El cumplimiento de las políticas de la organización no se aplica de forma retroactiva. Los artefactos se pueden añadir a cualquier repositorio, aunque la política de ubicaciones de recursos de la organización deniegue la ubicación del repositorio. Para aplicar una nueva política de organización de ubicaciones de recursos a los repositorios, cree repositorios después de aplicar la política de organización y, a continuación, migre los artefactos de los repositorios antiguos a los nuevos. Puedes usar la herramienta gcrane para copiar imágenes entre repositorios.

Para ver una lista de las ubicaciones disponibles, consulta la documentación de Artifact Registry.

Audit Manager

Cuando ejecutas una nueva auditoría, la política de organización se aplica en función de la región que hayas especificado al crear la solicitud de auditoría. Si se selecciona la ubicación de la auditoría como global, no se aplicará la restricción de ubicaciones de recursos.

Para ver una lista de las ubicaciones regionales disponibles, consulta Ubicaciones de Gestor de auditorías.

Servicio de copia de seguridad y DR

La política de organización se aplica cuando creas el siguiente recurso regional:

  • BackupPlan: la ubicación de este recurso determina la región de destino en la que se almacenan todos los datos de la copia de seguridad.

Para obtener más información, consulta las ubicaciones del servicio de copia de seguridad y recuperación tras desastres.

Copia de seguridad de GKE

La política de organización se aplica cuando creas uno de los dos recursos regionales principales:

  • BackupPlan: la ubicación de este recurso determina la región de destino en la que se almacenan todos los datos de las copias de seguridad creadas con este plan. Puede haber varios recursos BackupPlan en un proyecto.

  • RestorePlan: la ubicación de este recurso controla la región permitida del clúster de destino en el que se restauran los datos de una copia de seguridad. Puede haber varios recursos RestorePlan en un proyecto

Para obtener más información, consulta Copia de seguridad de ubicaciones de GKE.

BigQuery

Los recursos de BigQuery dataset pueden ser regionales y multirregionales. El cumplimiento de las políticas de la organización no se aplica de forma retroactiva. Para aplicar una nueva restricción de ubicaciones de recursos a un dataset, elimina el recurso dataset y vuelve a crearlo con la política de organización aplicada al recurso superior.

Puedes crear recursos Database en un recurso dataset con una ubicación que se deniegue en la política de ubicaciones de recursos de la organización. La ubicación del recurso dataset no determina la ubicación del recurso database. Para aplicar una nueva restricción de ubicaciones de recursos a un database, elimina el recurso database y vuelve a crearlo con la política de organización aplicada al recurso superior.

Para ver una lista de las ubicaciones disponibles, consulta la página Ubicaciones de conjuntos de datos de BigQuery.

BigQuery Data Transfer Service

El recurso TransferConfig puede ser regional y multirregional. El cumplimiento de las políticas de la organización no se aplica de forma retroactiva. La política de la organización solo se comprueba al crear un TransferConfig. Para aplicar una nueva restricción de ubicaciones de recursos a un TransferConfig, elimina el recurso TransferConfig y vuelve a crearlo con la política de organización aplicada al recurso superior.

Para ver una lista de las ubicaciones disponibles, consulta las ubicaciones de BigQuery Data Transfer Service.

Servicio de migración de BigQuery

El recurso MigrationWorkflow describe las tareas y subtareas que componen el flujo de trabajo de migración. Se pueden crear mediante la Google Cloud consola o la API al ejecutar la evaluación de la migración o la traducción de SQL. El flujo de trabajo de migración debe crearse en la misma ubicación que los recursos que utiliza. Por ejemplo, si tu conjunto de datos de BigQuery y el segmento de Cloud Storage están en la multirregión US, el flujo de trabajo de migración se puede crear en la multirregión US o en la región us-west1.

La política de la organización solo se comprueba al crear un flujo de trabajo de migración, ya que es un recurso inmutable.

Para ver una lista de las ubicaciones disponibles, consulta las ubicaciones de BigQuery Migration Service.

Bigtable

Un recurso de instancia de Bigtable es un contenedor lógico de clústeres. Cada uno de estos clústeres se encuentra en una zona. Todos los datos de una instancia se replican de forma uniforme en todos los clústeres que contiene esa instancia. La política de organización se aplica cuando se crea un clúster. No puedes crear contenedores de almacenamiento en una ubicación que se deniegue en la política de la organización. Las instancias y los clústeres ya creados seguirán funcionando aunque se encuentren en ubicaciones que se denieguen en un cambio posterior de la política de la organización.

Puedes corregir manualmente los recursos que infrinjan una nueva política de organización. Para ello, elimínalos y vuelve a crearlos una vez que se haya implementado la política de organización. Por ejemplo, si tienes una instancia multiclúster en la que un clúster infringe una nueva política de la organización, puedes eliminarlo y, a continuación, añadir un nuevo clúster en una zona permitida.

Para ver una lista de las ubicaciones disponibles, consulta la página Ubicaciones de Bigtable.

Servicio de Autoridades de Certificación

Los recursos del servicio de CA, como las plantillas de certificados, los grupos de autoridades de certificación (CA) y las CAs, se pueden crear en cualquier ubicación disponible. Estos recursos no se pueden mover una vez creados.

Las plantillas de certificados se pueden replicar mediante comandos de la CLI de Google Cloud. Puedes usar comandos de la CLI de gcloud para crear recursos con el mismo nombre en otra ubicación admitida. Para obtener más información, consulta el artículo Crear plantillas de certificados.

Las autoridades de certificación se pueden clonar a partir de autoridades de certificación que ya estén en el mismo grupo de autoridades de certificación. Estas nuevas ACs se crean en la misma ubicación que la AC de la que se han clonado. Para obtener más información, consulta el artículo sobre cómo crear autoridades de certificación.

Para ver la lista de ubicaciones disponibles, consulta Ubicaciones de servicio de CA.

Certificate Manager

A excepción de CertificateMaps y CertificateMapEntries, que solo pueden ser globales, los recursos de Certificate Manager se pueden crear en cualquier ubicación regional o global. Sin embargo, no puedes elegir una zona para un recurso. La política de organización se aplica cuando creas el recurso de Certificate Manager.

Para ver una lista de las ubicaciones disponibles, consulta Productos disponibles por ubicación.

Inventario de Recursos de Cloud

Los recursos de feed de Cloud Asset Inventory son recursos globales y no están sujetos a restricciones de ubicación de recursos.

Cloud Build

La política de la organización se aplica cuando creas recursos de Cloud Build regionales. Aunque puedes crear recursos en cualquier región, Cloud Build se asegura de que selecciones una región aprobada por tu organización. La política de organización solo se aplica a los recursos de Cloud Build recién creados en una región no global después de crear la política de organización.

Para ver una lista de las regiones disponibles, consulta la página de ubicaciones de Cloud Build.

Cloud Composer

Un entorno de Cloud Composer es un contenedor lógico de los recursos que se indican a continuación. Durante el proceso de creación del entorno, elige una ubicación (región o zona) para el entorno y los recursos subyacentes se crearán en función de la ubicación seleccionada.

  • Clúster de Google Kubernetes Engine

  • Instancia de Cloud SQL

  • Máquinas virtuales de App Engine que ejecutan el servidor web de Airflow

  • Discos persistentes: los usan el servidor web de Airflow y el clúster de GKE.

  • Temas de Pub/Sub

  • Cloud Storage

  • Crear y almacenar imágenes de Airflow con dependencias de Python personalizadas

    • Si no se especifican restricciones de ubicación, en función de la configuración, Composer puede compilar imágenes de Airflow en el clúster de GKE o mediante Cloud Build. Consulta más información en Instalar una dependencia de Python en un entorno de IP privada. En función de la versión de Composer, las imágenes de Airflow se pueden almacenar en la región seleccionada (con Artifact Registry) o en la multirregión a la que pertenece la región seleccionada (con Container Registry).

    • Si se especifican restricciones de ubicación, Cloud Composer crea imágenes de Airflow en el clúster de GKE del entorno y las almacena en el repositorio de Artifact Registry de la región seleccionada.

  • Cloud Monitoring: almacena métricas de los entornos y los DAGs de Airflow ejecutados en la región que especifiques.

    • Algunas etiquetas de métricas pueden contener nombres de DAGs y entornos de Cloud Composer.

  • Cloud Logging: de forma predeterminada, Cloud Composer almacena los registros en Cloud Logging, que es un servicio global. Google Cloud Si quieres almacenar los registros de Cloud Composer en una ubicación específica, debes redirigirlos a un segmento de Cloud Storage en esa ubicación.

Para ver una lista de las ubicaciones disponibles, consulta Regiones de Cloud Composer.

En la documentación de Cloud Composer se ofrece más información sobre los detalles de la arquitectura de los entornos de Cloud Composer.

Cloud Data Fusion

La política de organización se aplica cuando creas una instancia. La instancia es un recurso regional que se crea en la región que especifiques.

Cuando creas una instancia con una clave de cifrado gestionada por el cliente (CMEK), la ubicación de la clave debe ser la misma que la de la instancia.

De forma predeterminada, Cloud Data Fusion crea clústeres de Dataproc efímeros en la misma región que la instancia para cada flujo de procesamiento. La ubicación de estos clústeres efímeros se puede cambiar y no se aplica de forma obligatoria mediante la política de organización de ubicaciones de recursos. En el caso de los clústeres de Dataproc estáticos, puedes usar cualquiera de las ubicaciones admitidas por Dataproc. Estas ubicaciones no están sujetas a la política de la organización sobre ubicaciones de recursos.

Para ver una lista de las ubicaciones disponibles, consulta Regiones admitidas de Cloud Data Fusion.

Cloud Deploy

Estos son los tipos de recursos de Cloud Deploy:

  • Flujo de procesamiento de entrega
  • Objetivo
  • Lanzar
  • Lanzamiento
  • Ejecución de la tarea

Todos los recursos de Cloud Deploy se crean en la misma región en la que se creó el flujo de procesamiento de entrega.

Si tienes una política de organización que prohíbe usar determinadas ubicaciones, no puedes crear ningún recurso de Cloud Deploy en esa región (canalización de entrega, destino, versión o lanzamiento).

Para ver una lista de las ubicaciones disponibles para el servicio Cloud Deploy y sus recursos, consulta Acerca de las regiones de Cloud Deploy.

Cloud Domains

Los recursos de registro de Cloud Domains son recursos globales y no están sujetos a restricciones de ubicación de recursos.

API de Cloud Healthcare

La política de organización se aplica cuando creas un recurso dataset. Los recursos de dataset son regionales o multirregionales. Los recursos de almacén de datos, como los almacenes FHIR u otros recursos de nivel inferior, como los mensajes HL7v2, se pueden añadir a cualquier dataset, aunque el recurso dataset esté en una ubicación que no permita la política de la organización. Para asegurarse de que sus recursos cumplen la restricción de ubicación de recursos, cree recursos dataset nuevos después de que se aplique la política de la organización y, a continuación, migre los datos de los recursos dataset antiguos a los nuevos.

Para ver una lista de las ubicaciones disponibles, consulta Regiones de la API Cloud Healthcare.

Cloud Interconnect

Una vinculación de Cloud Interconnect se puede crear en cualquier región. Sin embargo, no puedes elegir una zona. La política de organización se aplica en el momento en que creas la vinculación de Cloud Interconnect.

Para ver una lista de las regiones disponibles, consulta la página Regiones y zonas de Compute Engine.

Sistema de Detección de Intrusos de Cloud

La política de organización se aplica cuando creas un endpoint de Cloud IDS, que es un recurso zonal. El cumplimiento de las políticas de la organización no se aplica de forma retroactiva. Los endpoints actuales seguirán funcionando aunque se encuentren en ubicaciones que no se permitan en la política de la organización. Para aplicar una nueva restricción de ubicación de recursos a un endpoint de Cloud IDS, elimina la instancia y vuelve a crearla con la política de organización aplicada.

Para ver una lista de las ubicaciones disponibles, consulta Productos disponibles por ubicación.

Cloud Key Management Service

Los recursos de Cloud KMS se pueden crear en ubicaciones regionales, birregionales, multirregionales o globales. La política de organización se aplicará cuando crees ese recurso.

Para obtener más información, consulta la página de ubicaciones de Cloud KMS.

Cloud Load Balancing

Los balanceadores de carga que usan los siguientes productos se pueden crear en cualquier ubicación regional:

  • Balanceador de carga de aplicación externo regional
  • Balanceador de carga de red con proxy externo regional
  • Balanceador de carga de aplicación interno regional
  • Balanceador de carga de red con proxy interno regional
  • Balanceador de carga de red de paso a través externo
  • Balanceador de carga de red de paso a través interno

Sin embargo, no puedes elegir una zona para estos balanceadores de carga. La política de organización se aplica en el momento en que creas el recurso de balanceo de carga.

Para ver una lista de las ubicaciones regionales disponibles, consulta la página Regiones y zonas de Compute Engine.

Cloud Logging

La política de la organización se aplica cuando creas contenedores de registro. Aunque puedes crear un nuevo contenedor en cualquier región o definir su ubicación en global, Logging se asegura de que selecciones una región aprobada por tu organización. La política de organización solo se aplica a los segmentos de registro recién creados después de que crees la política de organización.

Para ver una lista de las regiones disponibles, consulta la sección Regionalización de la página Información general sobre el almacenamiento de Cloud Logging.

Cloud NAT

Una pasarela de Cloud NAT se puede crear en cualquier ubicación regional. Sin embargo, no puedes elegir una zona para una pasarela Cloud NAT. La política de organización se aplica en el momento en que creas la pasarela Cloud NAT.

Para ver una lista de las ubicaciones regionales disponibles, consulta la página Regiones y zonas de Compute Engine.

Cloud Next Generation Firewall Enterprise

La política de organización se aplica cuando creas un endpoint de Cloud NGFW Enterprise, que es un recurso zonal. El cumplimiento de las políticas de la organización no se aplica de forma retroactiva. Los endpoints actuales seguirán funcionando aunque se encuentren en ubicaciones que no se permitan en la política de la organización. Para aplicar una nueva restricción de ubicación de recursos a un endpoint de Cloud NGFW Enterprise, elimina la instancia y vuelve a crearla con la política de organización aplicada.

Para ver una lista de las ubicaciones disponibles, consulta Productos disponibles por ubicación.

Cloud Next Generation Firewall Standard

Las políticas de cortafuegos de red regionales de Cloud NGFW Standard se pueden crear en cualquier ubicación regional. Sin embargo, no puedes elegir una zona para una política de cortafuegos de red regional estándar de Cloud NGFW. La política de organización se aplica cuando creas la política de cortafuegos de red regional Estándar de Cloud NGFW.

Para ver una lista de las ubicaciones regionales disponibles, consulta la página Regiones y zonas de Compute Engine.

Cloud Router

Un router de Cloud Router se puede crear en cualquier ubicación regional. Sin embargo, no puedes elegir una zona para un Cloud Router. La política de organización se aplica en el momento en que creas el Cloud Router.

Para ver una lista de las ubicaciones regionales disponibles, consulta la página Regiones y zonas de Compute Engine.

Cloud Run

La política de organización se aplica cuando creas un recurso de nivel superior, como un Service. No se aplica a los recursos que ya existen ni a las actualizaciones de recursos, aunque esas actualizaciones conlleven la creación de un recurso de nivel inferior, como un Revision.

Para ver una lista de las regiones disponibles, consulta la página de ubicaciones de Cloud Run.

Cloud Run Functions

La política de la organización se aplica cuando creas o actualizas un recurso de función de Cloud Run. No se aplica a los recursos que ya existan.

Para ver una lista de las regiones disponibles, consulta Ubicaciones de Cloud Functions.

Cloud Service Mesh

La política de organización se aplica cuando intentas aprovisionar Cloud Service Mesh o crear cargas de trabajo para la malla. Cloud Service Mesh no aplica las políticas de la organización cuando las cargas de trabajo se registran en la malla.

Consulta la documentación pertinente de las cargas de trabajo de tu servicio específico:

Consulta la lista de regiones disponibles para tu infraestructura informática de Cloud Service Mesh:

Cloud SQL

La política de organización se aplica cuando creas una instancia. La instancia es un recurso regional que creará una base de datos zonal, para la que no se aplica la ubicación del recurso. Cuando creas réplicas de lectura o clones de bases de datos, los colocas en la misma región que el original, por lo que no se aplica la política de organización de ubicaciones de recursos.

Para ver una lista de las ubicaciones disponibles, consulta la página Ubicaciones de instancias de Cloud SQL.

Cloud Storage

La política de organización se aplica cuando creas un recurso bucket. Los recursos de Bucket son regionales o multirregionales. Los recursos de Object se pueden añadir a cualquier bucket, aunque el object esté en una ubicación que se deniegue en la política de ubicaciones de recursos de la organización. Para asegurarse de que sus recursos cumplen la política de la organización sobre ubicaciones de recursos, cree recursos de bucket después de aplicar la política y, a continuación, migre los datos de los recursos de bucket antiguos a los nuevos.

Para ver una lista de las ubicaciones disponibles, consulta la página Ubicaciones de los segmentos de Cloud Storage.

Cloud Tasks

La política de organización se aplica cuando creas una cola. No se aplica a las colas que se crearon antes de que se definiera la política de la organización ni a las actualizaciones de dichas colas.

Para ver una lista de las ubicaciones disponibles, consulta Productos disponibles por ubicación.

Limitaciones

Se aplican limitaciones en las siguientes regiones:

  • us-central1
  • us-central2 (región Google Cloud privada)

Si tienes alguna de las regiones mencionadas anteriormente en tu política de la organización, debes incluir tanto us-central1 como us-central2, aunque no crees recursos de Cloud Tasks en esas regiones. Puedes incluir la región us-central2 en la política de tu organización aunque esta no use regiones privadas.

TPU de Cloud

Los recursos de TPU de Cloud (nodos de TPU y VMs de TPU) son recursos zonales. Esto significa que debes seleccionar una zona específica dentro de una Google Cloud región al crear un recurso de Cloud TPU.

La disponibilidad de tipos de aceleradores de TPU de Cloud específicos (como v3, v4, v5e o v5p) varía según la zona. No todas las zonas ofrecen todos los tipos de TPUs. Las políticas de organización que aplican restricciones de ubicación de recursos se comprueban durante la creación de recursos de TPU de Cloud. Si una política de la organización restringe el despliegue en la zona elegida, se bloqueará la creación del recurso de TPU.

Para ver una lista de las regiones y zonas disponibles en las que se admite Cloud TPU, consulta Ubicaciones y zonas de Cloud TPU.

API Cloud Translation - Advanced (v3)

Para asegurarte de que tus recursos de Cloud Translation cumplen la restricción de ubicación de recursos, especifica un endpoint regional al crear el recurso. La restricción de ubicación de recursos se aplica cuando creas un recurso de Cloud Translation.

Para obtener información sobre cómo usar los endpoints regionales, consulta Especificar un endpoint regional.

Cloud VPN

Se puede crear una pasarela de Cloud VPN en cualquier ubicación regional. Sin embargo, no puedes elegir una zona para una pasarela VPN de Cloud. La política de organización se aplica en el momento en que creas la pasarela VPN de Cloud.

Para ver una lista de las ubicaciones regionales disponibles, consulta la página Regiones y zonas de Compute Engine.

Cloud Workstations

La política de la organización se aplica cuando creas recursos regionales, como clústeres, configuraciones y estaciones de trabajo. La creación de una configuración de estación de trabajo puede dar lugar a la creación de discos persistentes y máquinas virtuales de Compute Engine, por lo que solo puedes crear estos recursos en las zonas que permita tu política de organización.

Para ver una lista de las ubicaciones disponibles, consulta Ubicaciones de Cloud Workstations.

Compute Engine

Compute Engine ofrece una gran variedad de recursos, que pueden ser globales, regionales o zonales. Los recursos regionales y de zona están sujetos a las restricciones de ubicación de recursos. Los recursos globales no están sujetos a la restricción de ubicaciones de recursos, pero algunos recursos globales usan recursos regionales y de zona, que sí están sujetos a la restricción de ubicaciones de recursos.

Por ejemplo, una plantilla de instancia es un recurso global, pero puedes especificar discos regionales o zonales en una plantilla de instancia. Estos discos están sujetos a las restricciones de ubicación de recursos, por lo que, en tu plantilla de instancia, debes especificar discos en regiones y zonas que permita tu política de organización.

Limitaciones

Todos los recursos de Compute Engine admiten las restricciones de ubicación de recursos que especifiques, con las siguientes excepciones.

  • Capturas e imágenes

  • Grupos de instancias administradas

    • Algunas operaciones de grupos de instancias gestionados (MIGs) dependen de la creación o recreación de VMs en zonas permitidas. Estas operaciones incluyen el escalado horizontal (manualmente o mediante el autoescalado), la reparación automática, la actualización automática y la redistribución proactiva de instancias. Para que estas operaciones se realicen correctamente, tus MIGs deben estar en ubicaciones permitidas por la restricción de ubicación de recursos de tu organización.

    • Crea MIGs en las ubicaciones permitidas. En el caso de los MIGs regionales, selecciona zonas que no tengan restricciones de ubicación.

    • Si tienes un MIG zonal o regional y, más adelante, defines una restricción de ubicación de recursos, las operaciones del MIG fallarán si infringen la restricción. Debes volver a crear el MIG en una ubicación permitida.

  • Nodos de único cliente

    • Si tienes un grupo de nodos y más adelante defines una restricción de ubicación de recursos, no podrás ampliar el grupo para añadir nuevos hosts (manualmente o mediante el escalado automático) si la ubicación del grupo infringe la restricción.

Para ver una lista de las ubicaciones disponibles, consulta la página Regiones y zonas de Compute Engine.

Config Controller

Config Controller usa regiones y zonas de Compute Engine. La aplicación de las ubicaciones de los recursos se gestiona a nivel del recurso de Compute Engine cuando creas el clúster. Para escalar un clúster añadiendo más instancias, estas nuevas incorporaciones también deben estar en una ubicación permitida.

Para crear clústeres con suficiente redundancia, usa grupos de valores para controlar las ubicaciones que están restringidas. Si defines las ubicaciones manualmente, todas las zonas de esa región deben estar en la lista permitida para tener el mismo nivel de redundancia. Los clústeres con escalado automático pueden dejar de funcionar si alguna de las ubicaciones en las que se produce el escalado no está en la lista de ubicaciones permitidas definida en la política de la organización.

Conversational Insights

La política de la organización se aplica cuando creas un conversation en Estadísticas de conversaciones. Los recursos conversation son regionales.

Para ver una lista de las ubicaciones disponibles, consulta la página de ubicaciones de Estadísticas de conversaciones.

Database Migration Service

La política de organización se aplica cuando creas cualquiera de los siguientes recursos del servicio de migración de bases de datos:

La política se aplica cuando se crea el recurso. Aplicar una restricción de ubicación de recursos no afecta a los recursos que ya existen ni a las actualizaciones de esos recursos.

API Data Lineage

La política de la organización se aplica cuando creas o actualizas un Process mediante los métodos CreateProcess, UpdateProcess o ProcessOpenLineageRunEvent.

Los recursos secundarios (Runs o Events) se pueden actualizar o añadir a cualquier Process, aunque este se encuentre en una ubicación que no permita la política de ubicaciones de recursos de la organización.Process Para asegurarse de que todos sus recursos cumplen la política de organización de la ubicación de los recursos, cree nuevos Process después de aplicar la política de organización.

Dataflow

La política de organización se aplica cuando creas un job. Un job es un recurso regional que usa tanto Cloud Storage como Compute Engine. Puedes configurar los trabajadores de Compute Engine para que se ejecuten en una zona que no esté en la región del trabajo. Para ello, especifica el parámetro de zona. En este caso, el plano de control de Dataflow se ejecutará en la región especificada, mientras que los trabajadores de procesamiento de datos se ejecutarán en la zona especificada. Si no especificas la zona de los trabajadores, estos se crearán en la región en la que se haya configurado la job para que se ejecute.

Si no especificas la zona del job, los trabajadores se ubicarán en una de las zonas de la región en la que se haya configurado el job para que se ejecute. Dataflow seleccionará la zona en función de la capacidad disponible en ella. Todas las zonas de la región de job deben definirse como valores permitidos en la política de la organización sobre ubicaciones de recursos.

Los clústeres de escalado automático pueden dejar de funcionar si alguna de las ubicaciones en las que se produce el escalado no está en la lista de ubicaciones permitidas definida en la política de la organización.

Para ver una lista de las ubicaciones disponibles, consulta la página Puntos de conexión regionales de Dataflow.

Dataform

Los recursos de Dataform son regionales. Cuando creas un repositorio de Dataform, el repositorio y todos sus recursos secundarios se limitan a la región especificada al crear el repositorio.

Para ver una lista de las ubicaciones disponibles, consulta Ubicaciones de Dataform.

Dataplex Universal Catalog

La política de la organización se aplica cuando creas cualquiera de los siguientes recursos de Dataplex Universal Catalog:

La política se aplica cuando se crea el recurso. Aplicar una restricción de ubicación de recursos no afecta a los recursos que ya existen ni a las actualizaciones de esos recursos.

Dataproc

Cuando creas una cluster, la política de organización se aplica en función de la región que especifiques en la solicitud de creación. La ubicación de un job está limitada por la ubicación del cluster que es su elemento superior cuando se llama al método submit.

Para ver una lista de las ubicaciones disponibles, consulta la página Endpoints regionales de Dataproc.

Dataproc Metastore

Cuando creas una service, la política de organización se aplica en función de la región que especifiques en la solicitud de creación. La ubicación de backups y metadataImports está vinculada a la ubicación de service, que es su elemento superior, cuando se llaman los métodos importMetadata y backupService.

Para ver una lista de las ubicaciones disponibles, consulta la página Ubicaciones de Dataproc Metastore.

Datastore

Los recursos de database Datastore dependen directamente de la aplicación de App Engine del proyecto principal y de su ubicación definida. Si inhabilitas la aplicación de App Engine, se bloqueará el acceso a la API de la base de datos asociada. Para eliminar los datos replicados de las ubicaciones físicas, elimina el proyecto tal como se describe en la sección App Engine.

Para ver una lista de las ubicaciones disponibles, consulta la página Ubicaciones de Datastore.

Datastream

La política de la organización se aplica cuando creas cualquiera de los siguientes recursos de Datastream:

La política se aplica cuando se crea el recurso. Aplicar una restricción de ubicación de recursos no afecta a los recursos que ya existen ni a las actualizaciones de esos recursos.

Dialogflow

La política de la organización se aplica cuando creas un recurso agent o location setting en Dialogflow CX (Dialogflow ES aún no aplica la política de la organización). Tanto los recursos agent como los location setting son regionales o multirregionales. Otros recursos de Dialogflow, como intents o flows, se pueden añadir a cualquier agent, aunque el recurso agent se encuentre en una ubicación que la política de la organización deniegue. Para asegurarte de que tus recursos cumplan la restricción de ubicación de recursos, crea recursos agent nuevos después de aplicar la política de la organización y, a continuación, migra los datos de los recursos agent antiguos a los nuevos.

Las restricciones de ubicación de los recursos no se aplican a la ubicación global, por lo que siempre se permite la creación de recursos.

Para ver una lista de las ubicaciones disponibles, consulta la página Ubicaciones de Dialogflow.

Document AI

Los recursos de Document AI son regionales. Cuando creas un recurso Processor o LabelerPool, se aplica la política de organización de ubicación de recursos, que restringe las regiones en las que se pueden crear o almacenar recursos nuevos.

El cumplimiento de las políticas de la organización no se aplica de forma retroactiva. Se pueden crear recursos de Document AI en recursos superiores que ya existan, aunque la política de la organización de ubicaciones de recursos no permita la ubicación de recursos del elemento superior. Para aplicar una nueva restricción de ubicación de recursos a un recurso que ya existe, elimínelo y vuelva a crearlo con la política de organización aplicada.

Para ver una lista de las ubicaciones disponibles, consulta la página Compatibilidad multirregional de Document AI.

Eventarc

La política de organización se aplica cuando crea un activador de Eventarc. La política no se aplica a los recursos que ya existen ni a las actualizaciones de los recursos. Los activadores pueden ser recursos globales o regionales. Los recursos globales no están sujetos a la restricción de ubicaciones de recursos.

Si se aplica la restricción de ubicaciones de recursos, solo se podrán crear activadores regionales cuyas regiones coincidan exactamente con las que se apliquen en la restricción de ubicaciones de recursos o que se incluyan en el grupo de valores. Por ejemplo, si us-central1 o us-locations están en la lista de ubicaciones permitidas definida en la política de la organización, puedes crear un activador us-central1.

Para ver una lista de las ubicaciones disponibles, consulta Ubicaciones de Eventarc.

Filestore

La política de organización se aplica cuando creas una instancia de Filestore, que puede ser un recurso zonal o regional. El cumplimiento de las políticas de organización no se aplica de forma retroactiva. Las instancias que ya existan seguirán funcionando aunque se encuentren en ubicaciones que se denieguen en la política de la organización. Para aplicar una nueva restricción de ubicación de recursos a una instancia de Filestore, elimina la instancia y vuelve a crearla con la política de la organización aplicada.

Para ver una lista de las ubicaciones disponibles, consulta la página Regiones y zonas de Filestore.

Firebase Data Connect

Cuando creas una base de datos regional, se aplican políticas de la organización que generan una base de datos de Firebase Data Connect que contiene información sobre el servicio, el esquema y el conector. Además, esta información se asigna a una base de datos de Cloud SQL correspondiente que se encuentra en la misma región. La base de datos de Cloud SQL tiene su propia política de la organización.

Para ver una lista de las ubicaciones disponibles, consulta la página Ubicaciones de Firebase Data Connect.

Firestore

Los recursos de Firestore database dependen directamente de la aplicación de App Engine del proyecto principal y de su ubicación definida. Si inhabilitas la aplicación de App Engine, se bloqueará el acceso a la API de la base de datos asociada. Para eliminar los datos replicados de las ubicaciones físicas, elimina el proyecto tal como se describe en la sección App Engine.

Para ver una lista de las ubicaciones disponibles, consulta la página Ubicaciones de Firestore.

Fleet

El recurso de Cloud Fleet membership solo admite ubicaciones de regiones en regiones y zonas de Compute Engine. La aplicación de las ubicaciones de los recursos se gestiona a nivel del recurso membership cuando registras un clúster. Las membresías de flotas se admiten en ubicaciones globales y regionales.

Para crear suscripciones con suficiente redundancia, usa grupos de valores para controlar las regiones restringidas. Las restricciones de las ubicaciones multirregión y de las ubicaciones de zona no afectan a Fleet membership. Sin embargo, las restricciones de los grupos de valores que contienen regiones sí tienen efecto. Por ejemplo, el valor asia de una política de la organización no afecta a la pertenencia a la flota, pero el valor in:asia-locations sí.

IA generativa en Vertex AI

Las restricciones de ubicación de los recursos se aplican a todos los recursos de IA generativa en Vertex AI. El cumplimiento de las políticas de la organización no se aplica de forma retroactiva. Esto significa que, si aplicas una restricción de ubicación de recursos, no se verán afectados los recursos que ya existan ni las actualizaciones de esos recursos. Los modelos de editores de Model Garden no son recursos y no se les aplican las restricciones de ubicación de recursos. Google Cloud

Para ver una lista de las regiones disponibles, consulta las ubicaciones de la IA generativa en Vertex AI.

Limitaciones

Las restricciones de ubicación de los recursos se aplican en las siguientes interfaces de la IA generativa en Vertex AI:

  • Vertex AI Studio (UI)

Las restricciones de ubicación de recursos no se aplican en las siguientes interfaces:

  • Gen AI SDK for Python
  • Gen AI SDK for Go
  • Gen AI SDK for Node.js
  • Gen AI SDK for Java
  • Gen AI SDK for C#
  • REST API

Sigue esta herramienta de seguimiento de incidencias para estar al tanto de los últimos avances sobre esta limitación.

GKE Multi-cloud

La política de la organización se aplica cuando usas la API Multi-Cloud de GKE para crear los siguientes clústeres:

  • GKE en AWS
  • GKE en Azure
  • Clústeres de GKE adjuntos

Para ver una lista de las ubicaciones disponibles, consulta las siguientes páginas de cada plataforma de clúster.

Google Cloud Armor

Cuando creas una política de seguridad de Cloud Armor, la política de organización se aplica en función de la región que especifiques en la solicitud de creación. La política no se aplica a los recursos que ya existen. Los recursos globales no están sujetos a la restricción de ubicaciones de recursos.

Para ver una lista de las ubicaciones regionales disponibles, consulta la página Regiones y zonas de Compute Engine.

Centro de contacto como servicio de Google Cloud

El recurso ContactCenter es regional. El cumplimiento de las políticas de la organización no se aplica de forma retroactiva. La política de la organización se comprueba al crear un ContactCenter.

Para ver una lista de las ubicaciones disponibles, consulta las ubicaciones de Centro de contacto como servicio de Google Cloud.

Google Cloud Managed Lustre

La política de la organización se aplica cuando creas una instancia en Managed Lustre.

Las instancias de Managed Lustre son recursos regionales. Esto significa que la ubicación del recurso determina la región de destino en la que se tratan y almacenan todos los datos.

Para ver una lista de las ubicaciones disponibles en las que puedes crear tus instancias, consulta Regiones admitidas.

Google Cloud Managed Service para Apache Kafka

La política de la organización se aplica cuando creas un clúster en Managed Service para Apache Kafka.

Los clústeres de Managed Service para Apache Kafka son recursos regionales. Esto significa que la ubicación del recurso determina la región de destino en la que se tratan y almacenan todos los datos.

Para ver una lista de las ubicaciones disponibles en las que puedes crear tus clústeres, consulta Regiones admitidas.

Google Cloud NetApp Volumes

La política de organización se aplica cuando creas un volumen o un pool de almacenamiento de NetApp Volumes, que puede ser un recurso regional. El cumplimiento de las políticas de organización no se aplica de forma retroactiva. Los grupos de almacenamiento seguirán funcionando aunque se encuentren en ubicaciones que no cumplan la política de la organización. Para aplicar una nueva restricción de ubicación de recursos a un volumen o un grupo de almacenamiento de NetApp Volumes, elimina el recurso y, a continuación, vuelve a crearlo con la política de organización aplicada.

Para ver una lista de las ubicaciones disponibles, consulta la página Ubicaciones de NetApp Volumes.

Google Kubernetes Engine

Google Kubernetes Engine usa regiones y zonas de Compute Engine. La aplicación de las ubicaciones de los recursos se gestiona a nivel del recurso de Compute Engine cuando creas la VM de un clúster. Si quieres escalar un clúster añadiendo más instancias o añadiendo otra zona, estas nuevas incorporaciones también deben estar en una ubicación permitida.

Para crear clústeres con suficiente redundancia, usa grupos de valores para controlar las ubicaciones que están restringidas. Si defines las ubicaciones manualmente, todas las zonas de esa región deben estar en la lista permitida para tener el mismo nivel de redundancia. Los clústeres con escalado automático pueden dejar de funcionar si alguna de las ubicaciones en las que se produce el escalado no está en la lista de ubicaciones permitidas definida en la política de la organización.

Infrastructure Manager

Infrastructure Manager usa estas Google Cloud regiones para crear despliegues de Infra Manager.

Además, Infrastructure Manager usa HCL como lenguaje de configuración para activar recursos con Terraform.

Las restricciones de ubicación de recursos se aplican tanto a los recursos de Deployment (Implementación) de Infra Manager como a los recursos de Google Cloud admitidos definidos en HCL.

API Integration Connectors

La política de la organización se aplica cuando usas la API Integration Connectors para crear los siguientes recursos:

Para ver una lista de las ubicaciones disponibles, consulta Ubicaciones de Integration Connectors.

Looker (servicio principal de Google Cloud)

Los recursos de Looker (Google Cloud core) se pueden crear en ubicaciones regionales. La política de organización se aplicará en el momento en que crees ese recurso.

Para ver una lista de las regiones disponibles, consulta la página Crear una instancia de Looker (Google Cloud Core).

Servicio gestionado de Microsoft Active Directory

La política de la organización se aplica cuando creas dominios de Microsoft AD gestionados o actualizas recursos de AD. Para usar Microsoft AD gestionado, debes permitir la ubicación de global. Si no se permite la ubicación global, no se podrán crear dominios ni actualizar recursos.

Consulta cómo ver y actualizar la restricción de ubicación de recursos a global.

Memorystore para Memcached

La política de organización se aplica cuando creas una instancia. La instancia es un recurso regional que crea una o varias cachés zonales en función del número de nodos seleccionados. Cuando añades nodos mediante una operación de escalado vertical, los nuevos recursos se ubican en la misma región que la instancia original. La política de organización de la ubicación se aplica durante el escalado vertical.

Para ver una lista de las ubicaciones disponibles, consulta la página Regiones y zonas de Memorystore para Memcached.

Memorystore para Redis

La política de organización se aplica cuando creas una instancia. La instancia es un recurso regional que creará una o varias cachés zonales en función del nivel de instancia seleccionado. Las instancias de nivel básico despliegan una sola caché en una región y una zona especificadas. Las instancias de nivel Estándar implementan una caché zonal y una o varias réplicas de caché zonales que se encuentran en la región de la instancia. Cuando creas réplicas adicionales, colocas los nuevos recursos en la misma región que la caché zonal original. La política de organización de la ubicación se aplica al crear réplicas adicionales.

Para ver una lista de las ubicaciones disponibles, consulta la página Regiones y zonas de Memorystore para Redis.

Memorystore for Redis Cluster

La política de organización se aplica cuando creas una instancia. La instancia es un recurso regional que creará una o varias cachés zonales en función del modo de distribución zonal seleccionado. Cuando creas réplicas o particiones adicionales, colocas los nuevos recursos en la misma región que la caché zonal original. La política de organización de la ubicación se aplica al crear réplicas adicionales.

Para ver una lista de las ubicaciones disponibles, consulta la página Ubicaciones de Memorystore for Redis Cluster.

Memorystore para Valkey

La política de organización se aplica cuando creas una instancia. La instancia es un recurso regional que creará una o varias cachés zonales en función del modo de distribución zonal seleccionado. Cuando creas réplicas o particiones adicionales, colocas los nuevos recursos en la misma región que la caché zonal original. La política de organización de la ubicación se aplica al crear réplicas adicionales.

Para ver una lista de las ubicaciones disponibles, consulta la página Ubicaciones de Memorystore for Valkey.

Migrate to Virtual Machines

La política de organización se aplica cuando creas un recurso de Migrate to VMs. Los recursos de migración y de imagen de las VMs son recursos regionales. El recurso TargetProject, que contiene el ID del proyecto que se usa como proyecto de destino de los trabajos de migración e importación, es un recurso global.

Network Connectivity Center

Los recursos de hub de Network Connectivity Center y de VPC de radio se pueden crear en la ubicación global. Los recursos de Spoke híbrido de Network Connectivity Center se pueden crear en cualquier ubicación regional. La política de organización se aplicará en el momento en que crees ese recurso.

Para ver una lista de las ubicaciones regionales disponibles, consulta la página Regiones y zonas de Compute Engine.

Network Intelligence Center: pruebas de conectividad

Los recursos de pruebas de conectividad se pueden crear en la ubicación global. La política de organización se aplicará en el momento en que crees ese recurso.

Parallelstore

La política de organización se aplica cuando creas una instancia en Parallelstore.

Las instancias de Parallelstore son recursos regionales. Esto significa que la ubicación del recurso determina la región de destino en la que se tratan y almacenan todos los datos.

Para ver una lista de las ubicaciones disponibles en las que puedes crear tus instancias, consulta Regiones admitidas.

Gestor de parámetros

Las restricciones de ubicación de recursos se aplican a todos los recursos de Parameter Manager.

Las políticas de organización se aplican al crear un parámetro. Los parámetros que ya existían no se mueven automáticamente si cambian las restricciones de ubicación.

Para ver una lista de las ubicaciones disponibles en las que puede crear parámetros, consulte Ubicaciones de los recursos de Gestor de Parámetros.

Persistent Disk

La política de organización se aplica cuando creas un recurso de disk, que se puede asociar a máquinas virtuales:

  • Después de crear un recurso disk zonal, puede asociarlo a instancias de máquina virtual de la misma zona.
  • Una vez que hayas creado un recurso disk regional, podrás asociarlo a instancias de máquina virtual de una de las dos zonas en las que se encuentre el recurso disk.

El cumplimiento de las políticas de la organización no se aplica de forma retroactiva. Para aplicar una nueva política de organización de ubicaciones de recursos a los recursos disk, debes eliminar los recursos disk y volver a crearlos con la política de organización aplicada al recurso principal.

Para ver una lista de las ubicaciones disponibles, consulta la página Regiones y zonas de Compute Engine.

Pub/Sub

La política de organización de ubicaciones de recursos afecta a las ubicaciones en las que se pueden conservar los mensajes publicados en un topic en reposo. La política de organización se aplica cuando publicas mensajes en un topic. Ten en cuenta que un topic sigue siendo un recurso global al que pueden acceder clientes autorizados desde cualquier parte del mundo.

Los cambios en la política de la organización no son retroactivos y no se aplicarán a los topics actuales. Si una nueva restricción de ubicaciones de recursos deniega una ubicación en la que ya se almacenan mensajes publicados en un topic, esos mensajes no se moverán automáticamente.

Para obtener más información, consulta la página Restringir las ubicaciones de los recursos de Pub/Sub.

Pub/Sub Lite

La política de organización de ubicaciones de recursos afecta a las ubicaciones en las que se puede crear un topic, lo que determina dónde se conservarán los mensajes. Un topic es un recurso zonal, pero los mensajes se pueden solicitar desde cualquier ubicación, incluso fuera de Google Cloud.

Los cambios en la política de la organización no son retroactivos y no se aplicarán a los topics actuales. Si una nueva restricción de ubicaciones de recursos deniega una ubicación en la que ya se almacenan mensajes publicados en un topic, esos mensajes no se moverán automáticamente.

Secret Manager

Los secretos pueden tener una política de réplica automática o una política de réplica gestionada por el usuario.

Cuando se usa una política de replicación automática, los datos de la carga útil se replican sin restricciones. Secret Manager requiere que se permita la ubicación global al crear un secreto con una política de replicación automática. Si no se permite la ubicación global, no se podrá crear el secreto.

Cuando se usa una política de replicación gestionada por el usuario, los datos de la carga útil se replican en un conjunto de ubicaciones admitidas definido por el usuario. Secret Manager requiere que se permitan todas las ubicaciones de la política de replicación al crear un secreto con una política de replicación gestionada por el usuario. Si no se permite ninguna de las ubicaciones de la política de réplica de un secreto, no se podrá crear el secreto.

La política de la organización se aplicará cuando crees ese secreto.

Para obtener más información, consulta la página de ubicaciones de Secret Manager.

Secure Source Manager

La política de organización se aplica cuando creas instancias de Secure Source Manager. Secure Source Manager se asegura de que selecciones una región aprobada por tu organización. La política de la organización solo se aplica a las instancias de Secure Source Manager creadas recientemente en una región después de crear la política de la organización.

Para obtener más información, consulta la página Información general de Secure Source Manager.

Secure Web Proxy

Se puede crear un proxy web seguro en cualquier ubicación regional. Sin embargo, no puedes elegir una zona para un proxy web seguro. La política de organización se aplica cuando creas el proxy web seguro.

Para ver una lista de las ubicaciones disponibles, consulta Productos disponibles por ubicación.

Protección de datos sensibles

Las restricciones de ubicación de recursos se aplican a todos los recursos de Protección de Datos Sensibles.

Los cambios en la política de la organización no son retroactivos y no se aplicarán a los recursos que ya tengas.

Consulta más información sobre las regiones disponibles para la protección de datos sensibles.

Acceso a VPC sin servidor

La política de organización se aplica cuando creas instancias de conectores de acceso a VPC sin servidor. La política de organización solo se aplica a las instancias del conector de acceso a VPC sin servidor que se creen en una región después de crear la política de organización.

Para obtener más información, consulta las regiones admitidas de Acceso a VPC sin servidor.

Spanner

La política de organización se aplica cuando creas una instancia. Las instancias son recursos regionales o multirregionales. Si una instancia está bloqueada por la política de la organización sobre ubicaciones de recursos, la única forma de que el recurso cumpla la política es eliminar la instancia. Las instancias bloqueadas por la política de organización de ubicaciones de recursos seguirán permitiendo lecturas, escrituras y la creación de recursos de base de datos.

Para ver una lista de las ubicaciones disponibles, consulta la página Instancias de Spanner.

Speaker ID

La política de organización de ubicaciones de recursos afecta a las ubicaciones en las que se puede crear un recurso speaker, lo que determina dónde se almacenan las frases de registro y las huellas de voz.

La política de organización de ubicaciones de recursos también afecta a las ubicaciones en las que se puede actualizar settings.

Más información sobre las regiones en las que está disponible el ID de voz

Speech‑to‑Text

La política de organización de ubicaciones de recursos afecta a las ubicaciones en las que se puede crear cualquier recurso de Speech-to-Text. También afecta a las ubicaciones en las que se puede actualizar el recurso config.

La versión 1 de Speech-to-Text está disponible en las regiones global, eu y us. Más información sobre las regiones en las que está disponible Speech-to-Text v2

Servicio de transferencia de Storage

La política de organización se aplica cuando creas un trabajo del Servicio de transferencia de Storage. La política de organización asegura el cumplimiento al permitir que los trabajos del Servicio de transferencia de Storage se creen solo en las regiones permitidas. Si la región de la tarea de Storage Transfer Service no cumple las restricciones de la política de la organización, la tarea no se creará correctamente.

Para saber cómo elige el Servicio de transferencia de Storage la región en la que se ejecutará una tarea del Servicio de transferencia de Storage, consulta Ubicación de las tareas del Servicio de transferencia de Storage.

API de Timeseries Insights

Las restricciones de ubicación de recursos se aplican a todos los recursos de la API Timeseries Insights.

La API Timeseries Insights solo admite ubicaciones de regiones. Una integración creada en una región específica solo puede acceder a los recursos de esa región. Las restricciones de las ubicaciones multirregión y de las ubicaciones de zona no afectan a la API Timeseries Insights. Sin embargo, las restricciones de los grupos de valores que contienen regiones sí tienen efecto. Por ejemplo, el valor asia de una política de organización no tiene ningún efecto en la API Timeseries Insights, pero el valor in:asia-locations sí.

Para ver una lista de las ubicaciones disponibles en las que puedes crear tus integraciones, consulta Regiones admitidas.

API Transcoder

Los recursos job y jobTemplate son regionales. Puede especificar una ubicación al crear el recurso. La política de organización se aplica cuando creas el recurso.

Para ver una lista de las regiones disponibles, consulta Ubicaciones de la API Transcoder.

Vertex AI

Las restricciones de ubicación de recursos se aplican a todos los recursos de Vertex AI, excepto a los DataLabelingJobrecursos.

Vertex AI solo admite ubicaciones de regiones. Las restricciones de las ubicaciones multirregionales y de las zonas no afectan a Vertex AI. Sin embargo, las restricciones de los grupos de valores que contienen regiones sí tienen efecto. Por ejemplo, el valor asia de una política de organización no tiene ningún efecto en Vertex AI, pero el valor in:asia-locations sí.

Más información sobre las regiones disponibles para AI Platform Training

Las restricciones de ubicación de los recursos se aplican a todos los recursos de Vertex AI Search. El cumplimiento de las políticas de la organización no se aplica de forma retroactiva. Esto significa que, si aplicas una restricción de ubicación de recursos, no se verán afectados los recursos que ya existan ni las actualizaciones de esos recursos.

Para ver una lista de las regiones disponibles, consulta las ubicaciones de Vertex AI Search.

Nube privada virtual

Las redes de nube privada virtual (VPC) son redes virtuales globales que contienen subredes virtuales regionales (subredes). Las restricciones de ubicación de los recursos no se aplican a las redes de VPC, ya que son recursos globales. Las restricciones de ubicación de los recursos se aplican a las subredes en el momento de crearlas. Si creas una red de VPC en modo automático, las subredes solo se crearán en las regiones que permita la restricción de ubicación de recursos.

Para ver una lista de las regiones disponibles, consulta la página Regiones y zonas de Compute Engine.

Flujos de trabajo

La política de organización se aplica cuando crea un flujo de trabajo de Workflows. La política no se aplica a los recursos que ya existen ni a las actualizaciones de los recursos. Los flujos de trabajo son recursos regionales y están sujetos a la restricción de ubicaciones de recursos.

Si se aplica la restricción de ubicaciones de recursos, solo se pueden crear flujos de trabajo cuyas regiones coincidan exactamente con las que se aplican en la restricción de ubicaciones de recursos o que se incluyan en el grupo de valores. Por ejemplo, si us-central1 o us-locations están en la lista de ubicaciones permitidas definida en la política de la organización, puedes crear un flujo de trabajo us-central1.

Para ver una lista de las ubicaciones disponibles, consulta Ubicaciones de Workflows.

Workload Manager

La política de la organización se aplica cuando creas un recurso de evaluación o despliegue de Workload Manager. Las evaluaciones y las implementaciones son recursos regionales y están sujetas a la restricción de ubicaciones de recursos.

Para ver una lista de las ubicaciones disponibles, consulta las ubicaciones admitidas.