La ubicación afecta los recursos que usa cada servicio de distintas maneras. Antes de agregar una restricción de las ubicaciones de un recurso a tu política de la organización, revisa la sección respectiva a continuación para ver cómo se comportarán los recursos en los que aplicas la política.
Agent Assist
La política de la organización se aplica de forma forzosa cuando creas un conversation profile
o un
Recurso knowledge base
en Agent Assist. Ambos recursos son regionales.
Para obtener una lista de las ubicaciones y limitaciones disponibles, consulta el Regionalización de Agent Assist y residencia de datos .
Apigee
Las restricciones de las ubicaciones de recursos se aplican cuando se crea lo siguiente: Recursos de Apigee:
Para obtener una lista de las ubicaciones disponibles, consulta Ubicaciones de Apigee.
Más información para configurar una política de la organización con ubicaciones de recursos limitaciones en Restringe las ubicaciones de los recursos.
AI Platform
Las restricciones de ubicaciones de recursos se aplican a los siguientes recursos de AI Platform:
- Recurso
job
de AI Platform Training - Recurso
job
AI Platform Prediction - Recurso
model
AI Platform Prediction
Los recursos de AI Platform Training y AI Platform Prediction solo admiten ubicaciones regionales. Las restricciones de ubicaciones de varias regiones y ubicaciones de zonas no tienen efecto en AI Platform. Sin embargo, las restricciones sobre grupos de valores que contienen regiones sí tienen un efecto. Por ejemplo, el valor asia
en una política de la organización no tiene efecto en AI Platform, pero el valor in:asia-locations
sí tiene un efecto.
Obtén más información sobre las regiones disponibles para AI Platform Training y regiones disponibles para AI Platform Prediction.
AlloyDB para PostgreSQL
La política de la organización se aplica de forma forzosa cuando creas clústeres, instancias y ciertos tipos de copias de seguridad. La creación de copias de seguridad a pedido 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 región. Las restricciones de las ubicaciones multirregionales y de zona no tienen efecto. Sin embargo, las restricciones en los grupos de valores que contienen regiones sí tienen efecto. Por ejemplo, el valor asia
en una política de la organización no tiene efecto, pero el valor in:asia-locations
sí lo tiene.
Para obtener una lista de las ubicaciones disponibles, consulta Ubicaciones de AlloyDB para PostgreSQL.
IA para prevención del lavado de dinero
Las restricciones de ubicaciones de recursos se aplican a todos los recursos de IA para la prevención del lavado de dinero y se se aplican en el momento de la creación del recurso.
Para obtener una lista de las ubicaciones disponibles, consulta Ubicaciones de IA de AML.
API de Apigee Integration
La política de la organización se aplica de forma forzosa cuando usas el API de Apigee Integrations para crear los siguientes recursos:
- Integración
- Configuración de autorización (AuthConfig)
- Certificado de AuthConfig
- Versión de la integración
- Canal de SFDC (Salesforce)
- Instancia de SFDC (Salesforce)
También se aplica la política de la organización cuando ejecutas, programas o pruebas una integración.
Las integraciones de Apigee son específicas de cada región. Significa que una integración creados en una región específica, pueden acceder a los recursos solo dentro de esa región.
Para obtener una lista de las ubicaciones disponibles en las que puedes crear tus integraciones, consulta Regiones compatibles.
App Engine
App Engine es una propiedad del recurso application
.
La propiedad de la ubicación se aplica de forma forzosa en todos los entornos cuando creas una application
. Puedes crear solo una application
de App Engine en cada proyecto. Se crea un depósito de Cloud Storage de forma automática en la misma ubicación que la application
. Si creas una application
con una ubicación amplia que no cumple con la política de la organización, deberás crear un proyecto y una application
de App Engine nuevos.
Cuando inhabilitas una application
, no se entregará en el futuro, pero el código y los datos replicados permanecerán en las ubicaciones en las que se almacenó la application
. Para borrar por completo estos datos, borra el proyecto superior.
El entorno flexible de App Engine se compiló sobre Compute Engine. Las instancias de ajuste de escala automático pueden fallar si alguna de las ubicaciones en las que se escala no está en la lista de ubicaciones admitidas que se definen en la política de la organización.
Para obtener una lista de las ubicaciones disponibles, consulta Ubicaciones de App Engine.
API de Application Integration
La política de la organización se aplica de forma forzosa cuando usas el API de Application Integration para crear los siguientes recursos:
- Integración
- Versión de la integración
- Ejecución
- Suspensión
- Configuración de autorización (AuthConfig)
- Instancia de SFDC (Salesforce)
- Canal de SFDC (Salesforce)
También se aplica la política de la organización cuando ejecutas, programas o pruebas una integración.
Application Integration es regional, lo que significa que una integración creados en una región específica pueden acceder a los recursos solo dentro de esa región.
Para obtener una lista de las ubicaciones disponibles, consulta Ubicaciones de Application Integration.
Limitaciones
Los siguientes recursos de Application Integration no admiten las restricciones de ubicación de recursos que especificas:
- Asunto y cuerpo del correo electrónico de la tarea Enviar correo electrónico
- Certificado para AuthConfig
- Compila integraciones con Gemini
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 forzosamente de forma retroactiva.Los artefactos pueden ser a cualquier repositorio existente, incluso si la ubicación del repositorio en la política de la organización de las ubicaciones del recurso.Para aplicar de manera forzosa las nuevas ubicaciones de un recurso política de la organización sobre los repositorios existentes, crea repositorios nuevos después del se aplica la política de la organización y, luego, se migran los artefactos a los nuevos. Puedes usar gcrane para copiar imágenes entre repositorios.
Para obtener una lista de las ubicaciones disponibles, consulta la documentación de Artifact Registry.
Administrador de auditorías
Cuando ejecutas una nueva auditoría, la política de la organización se aplica según la región que especificaste cuando creaste la solicitud de auditoría. Cuando la ubicación se selecciona la auditoría como global, no está sujeta a las ubicaciones de los recursos “compute.vmExternalIpAccess”.
Para obtener una lista de las ubicaciones regionales disponibles, consulta Ubicaciones del Administrador de auditorías.
Copia de seguridad para GKE
La política de la organización se aplica de manera forzosa cuando creas cualquiera de las dos principales regionales:
BackupPlan
: La ubicación de este recurso determina la región de destino. donde se almacenan todos los datos de las copias de seguridad creadas con este plan. Hay puede haber varios recursosBackupPlan
en un proyecto.RestorePlan
: La ubicación de este recurso controla la región permitida del clúster de destino en el que se restablecen los datos de una copia de seguridad. Puede haber puede haber varios recursosRestorePlan
en un proyecto
Si deseas obtener más información, consulta Copias de seguridad para ubicaciones de GKE.
BigQuery
Los recursos dataset
de BigQuery pueden regionales y multirregionales.
El cumplimiento de las políticas de la organización no se aplica forzosamente de forma retroactiva. Para aplicar de forma forzosa una nueva restricción de las ubicaciones del recurso en un dataset
existente, borra el recurso dataset
y vuelve a crearlo con la política de la organización aplicada en el recurso superior.
Puedes crear recursos Database
dentro de un recurso dataset
con una ubicación denegada en la política de la organización de las ubicaciones del recurso. La ubicación del recurso dataset
no determina la ubicación del recurso database
. Para aplicar de forma forzosa una nueva restricción de las ubicaciones del recurso en un database
existente, borra el recurso database
y vuelve a crearlo con la política de la organización aplicada en el recurso superior.
Para obtener una lista de las ubicaciones disponibles, consulta la página Ubicaciones de conjuntos de datos de BigQuery.
Servicio de transferencia de datos de BigQuery
El recurso TransferConfig
puede ser regional o multirregional. Cumplimiento de las políticas de la organización
no se aplica de manera retroactiva. La política de la organización solo se marca cuando se crea
TransferConfig
Para aplicar una nueva restricción de ubicaciones de recursos en un
TransferConfig
existente, borra el recurso TransferConfig
y créalo
de nuevo con la política de la organización aplicada al recurso superior.
Para obtener una lista de las ubicaciones disponibles, consulta el Servicio de transferencia de datos de BigQuery ubicaciones.
Servicio de migración de BigQuery
El recurso MigrationWorkflow
se describen las tareas y subtareas que conforman el flujo de trabajo de migración. Ellas
se pueden crear con la consola de Google Cloud o la API cuando se ejecuta el comando de
evaluación o traducción de SQL.
El flujo de trabajo de migración debe crearse en la misma ubicación que la
los recursos que usa. Por ejemplo, si tu proyecto de BigQuery
conjunto de datos y el bucket de Cloud Storage están en la multirregión US
; por lo tanto, el
el flujo de trabajo de migración se puede crear en la multirregión US
o en us-west1
región.
La política de la organización solo se verifica cuando se crea un flujo de trabajo de migración, ya que es un recurso inmutable.
Para obtener una lista de las ubicaciones disponibles, consulta Servicio de migración de BigQuery ubicaciones.
Certificate Authority Service
Recursos de CA Service, como plantillas de certificados, certificados Los grupos de autoridades (AC) y las AC se pueden crear en cualquier ubicación disponible. Estos no se pueden mover después de su creación.
Las plantillas de certificados se pueden replicar con los comandos de Google Cloud CLI. Puedes usar los comandos de gcloud CLI para crear recursos con el mismo nombre en otra ubicación admitida. Para obtener más información, consulta Cómo crear plantillas de certificados.
Las AC se pueden clonar a partir de AC existentes en el mismo grupo de AC. Estas nuevas AC se crean en en la misma ubicación que la AC desde la que se clonaron. Para obtener más información, consulta Crea autoridades certificadoras.
Para ver la lista de ubicaciones disponibles, consulta Ubicaciones del servicio de CA.
Bigtable
Un recurso de instancia de Bigtable es un contenedor lógico de clústeres. Cada uno de estos clústeres está ubicado en una zona. Todos los datos en una instancia se replican de forma uniforme en todos los clústeres que contiene esa instancia. La política de la organización se aplica de forma forzosa cuando se crea un clúster. No puedes crear nuevos contenedores de almacenamiento en una ubicación denegada por la política de la organización. Las instancias y los clústeres existentes seguirán funcionando incluso si se encuentran en ubicaciones denegadas por un cambio posterior en la política de la organización.
Puedes remediar manualmente los recursos que violan una nueva política de la organización si los eliminas y los vuelves a crear una vez que la política de la organización se haya implementado. Por ejemplo, si tienes una instancia de múltiples clústeres en la que un clúster violó una nueva política de la organización, podrías eliminarla y, luego, agregar un nuevo clúster en una zona permitida.
Para obtener una lista de las ubicaciones disponibles, consulta la Página Ubicaciones de Bigtable
Cloud Build
La política de la organización se aplica de forma forzosa cuando creas una nueva región recursos de Cloud Build. Aunque puedes crear recursos en cualquier región, Cloud Build garantiza que selecciones una región aprobada por tu organización. La política de la organización solo se aplica de manera forzosa en las apps Cloud Build en una región no global después de crear la política de la organización.
Para obtener una lista de las regiones disponibles, consulta locations.
Cloud Composer
Un entorno de Cloud Composer es un contenedor lógico para los recursos enumerados a continuación. Durante el proceso de creación del entorno, eliges una ubicación (región/zona) para el entorno, y los recursos subyacentes se crean según la ubicación seleccionada.
Clúster de Google Kubernetes Engine
Instancia de Cloud SQL
VM de App Engine que ejecutan el servidor web de Airflow
Persistent Disks: Los usan el servidor web de Airflow y el clúster de GKE
Temas de Pub/Sub
Compila y almacena imágenes de Airflow con dependencias personalizadas de Python
Cuando no se especifican restricciones de ubicación, la configuración depende Composer puede compilar imágenes de Airflow dentro de un clúster de GKE o mediante Cloud Build. Obtén más información en Instala una dependencia de Python en un entorno de IP privada. Según la versión de Composer, las imágenes de Airflow pueden almacenarse 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 compila 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 para entornos y ejecuta DAG de Airflow en la región que especifiques.
- Algunas etiquetas de métricas pueden contener nombres de DAG y entornos de Cloud Composer.
Cloud Logging: de forma predeterminada, Cloud Composer se almacena en Cloud Logging, que es un servicio global de Google Cloud. Si quieres almacenar los registros de Cloud Composer en una ubicación específica, debes redireccionar los registros a un bucket de Cloud Storage en esa ubicación.
Para obtener una lista de las ubicaciones disponibles, consulta Regiones de Cloud Composer.
La documentación de Cloud Composer proporciona más información sobre los detalles arquitectónicos de los entornos de Cloud Composer.
Cloud Data Fusion
La política de la organización se aplica de forma forzosa cuando creas una instancia. La instancia es un recurso regional que se crea en la región que especificas.
Cuando creas una instancia con una clave de encriptación administrada por el cliente (CMEK), la ubicación de la clave debe ser la misma que la ubicación de la instancia.
De forma predeterminada, Cloud Data Fusion crea clústeres en la misma región que la instancia de cada canalización. La ubicación de estos clústeres efímeros se puede cambiar y no se aplica en la política de la organización de las ubicaciones del recurso. Para los clústeres estáticos de Dataproc, Puedes usar cualquiera de las ubicaciones compatibles con Dataproc y estas ubicaciones y no se aplican de manera forzosa por la política de la organización de las ubicaciones del recurso.
Para obtener una lista de las ubicaciones disponibles, consulta Regiones compatibles con Cloud Data Fusion.
Cloud Deploy
Estos son los tipos de recursos de Cloud Deploy:
- Canalización de entrega
- Objetivo
- Versión
- Lanzamiento
- Ejecución de trabajo
Todos los recursos de Cloud Deploy se crean en la misma región en la que se creó se creó la canalización de datos.
Si tienes una política de la organización contra el uso de ciertas ubicaciones, no puedes crear recursos de Cloud Deploy en esa región (canalización de entrega, destino, lanzamiento o lanzamiento).
Para obtener una lista de las ubicaciones disponibles para el servicio de Cloud Deploy y sus consulta Acerca de las regiones de Cloud Deploy.
Funciones de Cloud Run
La política de la organización se aplica de forma forzosa cuando creas o actualizas un recurso de la función de Cloud Run. No se aplicará de manera forzosa en ninguno de los servicios de Google Cloud.
Para obtener una lista de las regiones disponibles, consulta Ubicaciones de las funciones de Cloud Run.
API de Cloud Healthcare
La política de la organización se aplica cuando creas un recurso dataset
.
Los recursos dataset
son recursos regionales o multirregionales.
Los recursos del almacén de datos, como el almacén FHIR u otros recursos de nivel inferior, como los mensajes HL7v2, se pueden agregar a cualquier dataset
existente, incluso si el recurso dataset
está en una ubicación que niega la política de la organización. Para garantizar que tus recursos cumplan con la restricción de ubicación de recursos, crea nuevos recursos dataset
después de aplicar la política de la organización y, luego, migra los datos de los recursos dataset
antiguos a los nuevos.
Para obtener una lista de ubicaciones disponibles, consulta Regiones de la API de Cloud Healthcare.
Cloud Interconnect
Un adjunto de Cloud Interconnect puede crearse en cualquier región. Sin embargo, no puedes elegir una zona. La política de la organización se aplica de manera forzosa en el momento en que creas la adjunto de Cloud Interconnect.
Para obtener una lista de las regiones disponibles, consulta el Regiones y zonas.
Sistema de detección de intrusiones de Cloud
La política de la organización se aplica de forma forzosa cuando creas un extremo de Cloud IDS, que es un recurso zonal. El cumplimiento de las políticas de la organización no se aplica forzosamente de forma retroactiva. Los endpoints existentes seguirán funcionando incluso si están en ubicaciones rechazadas por la política de la organización. Para aplicar un nuevo restricción de ubicación de recursos en un extremo de IDS de Cloud existente, borrar la instancia y volver a crearla con la política de la organización se aplicó.
Para obtener 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 la organización se aplicará de forma forzosa en el momento en que creas ese recurso.
Para obtener más información, consulta la página ubicaciones de Cloud KMS.
Cloud Logging
La política de la organización se aplica de manera forzosa cuando creas un registro nuevo.
buckets. Si bien puedes crear un bucket nuevo en cualquier región o establecer su ubicación en global
, el registro se asegura de que selecciones una región aprobada por tu organización. La política de la organización solo se aplica a los buckets de registro creados recientemente después de crear tu política de la organización.
Para obtener una lista de las regiones disponibles, consulta la sección Regionalización del Página de descripción general del almacenamiento de Cloud Logging.
Cloud NAT
Se puede crear una puerta de enlace de Cloud NAT en cualquier ubicación regional. Sin embargo, pero no puedes elegir una zona para una puerta de enlace de Cloud NAT. La política de la organización se aplica de manera forzosa en el momento en que creas la de Cloud NAT.
Para obtener una lista de las ubicaciones regionales disponibles, consulta la Compute Engine Regiones y zonas.
Cloud Router
Se puede crear un Cloud Router en cualquier ubicación regional. Sin embargo, no puede elegir una zona para un Cloud Router. La política de la organización se aplica de manera forzosa en el momento en que creas la de Cloud Router.
Para obtener una lista de las ubicaciones regionales disponibles, consulta la Compute Engine Regiones y zonas.
Cloud Load Balancing
Los balanceadores de cargas con los siguientes productos se pueden crear en cualquier región ubicación:
- balanceador de cargas de aplicaciones externo regional
- balanceador de cargas de red del proxy externo regional
- balanceador de cargas de aplicaciones interno regional
- balanceador de cargas de red del proxy interno regional
- balanceador de cargas de red de transferencia externo
- balanceador de cargas de red de transferencia interno
Sin embargo, no puedes elegir una zona para estos balanceadores de cargas. La política de la organización se aplica de manera forzosa en el momento en que creas la recurso de balanceo de cargas.
Para obtener una lista de las ubicaciones regionales disponibles, consulta la Compute Engine Regiones y zonas.
Google Cloud Armor
Cuando creas una política de seguridad de Google Cloud Armor, la organización se aplique la política según la región que especifiques en la solicitud de creación. La política no se aplica de manera forzosa en los recursos existentes. Recursos globales no están sujetos a la restricción de ubicaciones de recursos.
Para obtener una lista de las ubicaciones regionales disponibles, consulta la Compute Engine Regiones y zonas.
Cloud Run
La política de la organización se aplica de forma forzosa cuando creas un recurso de nivel superior, como un
Service
No se aplica en los recursos existentes ni en las actualizaciones de
recursos existentes, incluso si esas actualizaciones llevan a la creación de un nivel
como Revision
.
Para obtener una lista de las regiones disponibles, consulta la página ubicaciones de Cloud Run.
Cloud Service Mesh
La política de la organización se aplica de forma forzosa cuando intentas aprovisionar Cloud Service Mesh cargas de trabajo para la malla. Cloud Service Mesh no aplicar políticas de la organización cuando las cargas de trabajo se registran en la malla.
Consulta la documentación relevante para tus cargas de trabajo de servicio específicas:
Consulta la lista de regiones disponibles para tu malla de servicios de Cloud. de procesamiento de la nube:
- Plano de control administrado con APIs de Istio
- Control plane administrado con las APIs de Google Cloud
Spanner
La política de la organización se aplica de forma forzosa cuando creas una instancia. Las instancias son recursos regionales o multirregionales. Si la política de la organización de las ubicaciones del recurso bloquea una instancia, la única forma de hacer que el recurso cumpla es a través de la eliminación de la instancia. Las instancias que bloquea la política de la organización de las ubicaciones del recurso aún permitirán las lecturas, las escrituras y la creación de recursos de bases de datos.
Para obtener una lista de las ubicaciones disponibles, consulta el Instancias.
Cloud SQL
La política de la organización se aplica de forma forzosa cuando creas una instancia. La instancia es un recurso regional que creará una base de datos zonal, en la que no se aplicará de forma forzosa la ubicación del recurso. Cuando creas réplicas de lectura o clones de bases de datos, ubicas los recursos nuevos en la misma región que el original, por lo que no se aplica de forma forzosa la política de la organización de las ubicaciones del recurso.
Para obtener una lista de ubicaciones disponibles, consulta la página Ubicaciones de las instancias de Cloud SQL.
Cloud Storage
La política de la organización se aplica de forma forzosa cuando creas un recurso bucket
. Los recursos Bucket
son regionales o multirregionales. Se pueden agregar recursos Object
a cualquier bucket
existente, incluso si el object
se encuentra en una ubicación denegada en la política de la organización de las ubicaciones del recurso. Para asegurarte de que tus recursos cumplan con la política de la organización de las ubicaciones del recurso, crea recursos bucket
nuevos después de aplicar la política de la organización y, luego, migra los datos de los recursos bucket
antiguos a los nuevos.
Para obtener una lista de las ubicaciones disponibles, consulta la página Ubicaciones de depósitos de Cloud Storage.
Cloud Tasks
La política de la organización se aplica de forma forzosa cuando creas una cola. No se aplica en colas creadas antes de establecer la política de la organización, o con actualizaciones a esas colas.
Para obtener una lista de las ubicaciones disponibles, consulta Productos disponibles por ubicación.
Limitaciones
Se aplican limitaciones a las siguientes regiones:
us-central1
us-central2
(región privada de Google Cloud)
Si tienes alguna de las regiones mencionadas anteriormente en la política de tu organización,
debes incluir us-central1
y us-central2
, incluso si no
creando recursos de Cloud Tasks en estas regiones. Puedes incluir la región us-central2
en la política de tu organización, incluso si esta no usa regiones privadas.
API de Cloud Translation Advanced (v3)
Para garantizar que tus recursos de Cloud Translation cumplan con las restricción de ubicación del recurso, especifica un extremo regional cuando crees el recurso. La restricción de ubicación del recurso se aplica de forma forzosa cuando creas un Recurso de Cloud Translation.
Para obtener información sobre cómo usar extremos regionales, consulta Cómo especificar un extremo regional.
Cloud VPN
Se puede crear una puerta de enlace de Cloud VPN en cualquier ubicación regional. Sin embargo, no puedes elegir una zona para una puerta de enlace de Cloud VPN. La política de la organización se aplica de forma forzosa en el momento en que creas la de Cloud VPN.
Para obtener una lista de las ubicaciones regionales disponibles, consulta la Compute Engine Regiones y zonas.
Cloud Workstations
La política de la organización se aplica cuando creas recursos regionales nuevos, como clústeres, configuraciones y estaciones de trabajo. La creación de una configuración de estación de trabajo puede generar la creación de VMs y discos persistentes de Compute Engine, por lo que puedes crear estos recursos solo en las zonas que permita la política de tu organización.
Para obtener una lista de las ubicaciones disponibles, consulta Ubicaciones de Cloud Workstations.
Compute Engine
Compute Engine ofrece una variedad de recursos, y estos pueden ser globales, regionales o zonales. Los recursos regionales y zonales 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 zonales; esos recursos regionales y zonales están sujetos a la restricción de ubicaciones de recursos.
Por ejemplo, una plantilla de instancia es un recurso global, pero puede especificar discos regionales o zonales en una plantilla de instancia. Esos discos están sujetos a las restricciones de ubicaciones de recursos, por lo tanto, en tu plantilla de instancia, debes especificar discos en regiones y zonas que permitan 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.
Instantáneas e imágenes
- Cuando creas una instantánea o una imagen, debes especificar una ubicación de almacenamiento en una ubicación permitida; de lo contrario, la creación de la instantánea o imagen podría fallar.
Grupos de instancias administrados
Algunas operaciones de grupo de instancias administradas (MIG) dependen de la creación o recreación de máquinas virtuales en zonas permitidas. Estas operaciones incluyen: escalamiento horizontal (manual o mediante ajuste de escala automático), reparación automática, actualización automática y redistribución proactiva de instancias. Para que esas operaciones tengan éxito, sus MIG deben existir en ubicaciones permitidas por la restricción de ubicación de recursos de su organización.
Crea MIG en ubicaciones permitidas. Para MIG regionales, selecciona zonas que no están restringidas por ubicación.
Si tienes un MIG zonal o regional preexistente y, luego, estableces un recurso restricción de ubicación, las operaciones del MIG fallarán si infringen la “compute.vmExternalIpAccess”. Debes recrear el MIG en una ubicación permitida.
Nodos de usuario único
- Si tienes un grupo de nodos preexistente y, luego, configuras la ubicación del recurso no puedes escalar horizontalmente el grupo para agregar nuevos hosts (manualmente a través del ajuste de escala automático) si la ubicación del grupo infringe la restricción.
Para obtener una lista de las ubicaciones disponibles, consulta la página Regiones y zonas de Compute Engine.
Config Controller
El controlador de configuración usa Regiones y zonas de Compute Engine. Aplicación de las ubicaciones de recursos se controla a nivel de la instancia de Compute Engine cuando crees el clúster. Para escalar un clúster agregando 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 restringidas. Si configuras las ubicaciones manualmente, Todas las zonas de esa región deben estar en la lista de permitidos para tener el mismo nivel de la redundancia. Los clústeres de ajuste de escala automático pueden romperse si alguna de las ubicaciones en las que se escala no se encuentra en la lista de las ubicaciones permitidas definidas en la política de la organización.
Contact Center AI Insights
La política de la organización se aplica de forma forzosa cuando creas un conversation
en Contact Center AI Insights. conversation
de recursos son regionales.
Para obtener una lista de las ubicaciones disponibles, consulta la Página de ubicaciones de Contact Center AI Insights.
API de Data Lineage
La política de la organización se aplica cuando creas o actualizas un Process
con el método CreateProcess, UpdateProcess o ProcessOpenLineageRunEvent.
Los recursos secundarios (Runs
o Events
) se pueden actualizar o agregar a cualquier Process
existente, incluso si el Process
se encuentra en una ubicación denegada en la política de la organización de las ubicaciones del recurso. Para garantizar que todos tus recursos cumplan
con la política de la organización de ubicación de recursos, crea un objeto Process
nuevo después del
de la política de la organización.
Dataflow
La política de la organización se aplica de forma forzosa cuando creas un job
. Un job
es un recurso regional que usa Cloud Storage y Compute Engine.
Puedes configurar los trabajadores de Compute Engine para que se ejecuten en una zona fuera de la región del trabajo mediante la especificación del parámetro de la 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 dentro de la región en la que se configuró el job
para que se ejecute.
Si no especificas la zona del job
, la ubicación de los trabajadores estará en una de las zonas dentro de la región en la que se configuró el job
para que se ejecute.
Dataflow seleccionará la zona en función de la capacidad disponible en la zona. Todas las zonas dentro de la región del job
se deben configurar como valores admitidos en la política de la organización de las ubicaciones del recurso.
Los clústeres con ajuste de escala automático pueden fallar si se produce alguna de las ubicaciones en las que se escala no están en la lista de ubicaciones permitidas definidas en la política de la organización.
Para obtener una lista de las ubicaciones disponibles, consulta la página Extremos regionales de Dataflow.
Dataform
Los recursos de Dataform son regionales. Cuando creas un Repositorio de Dataform, el repositorio y todos sus recursos secundarios están restringidas a la región especificada en la creación del repositorio.
Para obtener una lista de las ubicaciones disponibles, consulta Ubicaciones de Dataform.
Dataplex
La política de la organización se aplica de forma forzosa cuando creas grupos de entrada, Tipos de entradas y tipos de aspecto usando la API de Dataplex.
Dataproc
Cuando creas un cluster
, la política de la organización se aplica de forma forzosa en función de la región que especificaste en la solicitud de creación. A la ubicación de un job
la vincula la ubicación del cluster
, que es su superior, cuando se llama al método submit
.
Para obtener una lista de las ubicaciones disponibles, consulta la página Extremos regionales de Dataproc.
Dataproc Metastore
Cuando creas un service
, la política de la organización se aplica de forma forzosa en función de la región que especificaste en la solicitud de creación. La ubicación de backups
y
Las metadataImports
están vinculadas por la ubicación del service
que es su superior
cuando se llama a los métodos importMetadata
y backupService
.
Para obtener una lista de las ubicaciones disponibles, consulta la página sobre las ubicaciones de Dataproc Metastore.
Datastore
Los recursos database
de Datastore dependen directamente de la aplicación de App Engine en el proyecto superior y su ubicación definida.
La inhabilitación de la aplicación de App Engine bloqueará el acceso a la API para la base de datos asociada. Para borrar datos replicados de las ubicaciones físicas, borra el proyecto como se describe en la sección App Engine.
Para obtener una lista de las ubicaciones disponibles, consulta la página sobre las ubicaciones de Datastore.
Dialogflow
La política de la organización se aplica de forma forzosa cuando creas un agent
o un location setting
.
recurso en Dialogflow CX (Dialogflow ES no aplica
política de la organización). agent
recursos y location setting
recursos
son regionales o multirregionales. Se pueden agregar otros recursos de Dialogflow, como intents
o flows
, a cualquier agent
existente, incluso si el recurso agent
se encuentra en una ubicación denegada en la política de la organización. Para asegurarte de que tus
recursos cumplen con la restricción de ubicación de recursos, crea nuevos
agent
recursos después de aplicar la política de la organización y, luego, migrar
datos de los recursos agent
antiguos a los nuevos.
Para obtener 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 Processor
o
LabelerPool
recurso, se aplica la política de la organización sobre la ubicación del recurso
y restringe las regiones en las que se pueden crear o almacenar nuevos recursos.
El cumplimiento de las políticas de la organización no se aplica forzosamente de forma retroactiva. Nuevo Los recursos de Document AI se pueden crear en recursos superiores existentes. incluso si las ubicaciones de los recursos deniegan la ubicación de los recursos del elemento superior política de la organización. Para aplicar una nueva restricción de ubicación de recursos recurso existente, borrarlo y volver a crearlo con la organización política aplicada.
Para obtener una lista de las ubicaciones disponibles, consulta Document AI Página Asistencia multirregional.
Eventarc
La política de la organización se aplica de forma forzosa cuando creas un evento de Eventarc activador. La política no se aplica recursos o en actualizaciones de recursos existentes. Los activadores pueden ser globales o recurso regional. Los recursos globales no están sujetos a las ubicaciones de los recursos “compute.vmExternalIpAccess”.
Si se aplica la restricción de ubicaciones de recursos, solo se pueden crear activadores regionales cuyas regiones coincidan exactamente con las aplicadas 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
en la lista de ubicaciones permitidas definidas en la política de la organización, puedes crear
un activador us-central1
Para obtener una lista de las ubicaciones disponibles, consulta Ubicaciones de Eventarc.
Filestore
La política de la organización se aplica de forma forzosa cuando creas un Filestore que puede ser zonal o regional. El cumplimiento de las políticas de la organización no se aplica forzosamente de forma retroactiva. Las instancias existentes seguirán operar incluso si se encuentran en ubicaciones rechazadas por la política de la organización. Para aplicar una nueva restricción de ubicación de recursos en un Filestore existente borrar la instancia y, luego, crearla de nuevo con la organización política aplicada.
Para obtener una lista de las ubicaciones disponibles, consulta la página Regiones y zonas de Filestore.
Firestore
Los recursos database
de Firestore dependen directamente de la aplicación de App Engine en el proyecto superior y su ubicación definida.
La inhabilitación de la aplicación de App Engine bloqueará el acceso a la API para la base de datos asociada. Para borrar datos replicados de las ubicaciones físicas, borra el proyecto como se describe en la sección App Engine.
Para obtener una lista de las ubicaciones disponibles, consulta la página Ubicaciones de Firestore.
Firewall Enterprise de nueva generación de Cloud
La política de la organización se aplica de forma forzosa cuando creas una Cloud NGFW Enterprise. extremo, que es un recurso zonal. El cumplimiento de las políticas de la organización no se aplica forzosamente de forma retroactiva. Los extremos existentes seguirán funcionando incluso si se encuentran en ubicaciones denegadas en la política de la organización. Para aplicar de forma forzosa una nueva restricción de ubicación de recursos en un extremo de Cloud NGFW Enterprise existente, borra la instancia y vuelve a crearla con la política de la organización aplicada.
Para obtener una lista de las ubicaciones disponibles, consulta Productos disponibles por ubicación.
Proxy web seguro
Un Proxy web seguro se puede crear en cualquier ubicación regional. Sin embargo, no puedes elegir una zona para un Proxy web seguro. La política de la organización se aplica la hora en que se crea el Proxy web seguro.
Para obtener una lista de las ubicaciones disponibles, consulta Productos disponibles por ubicación.
Flota
El recurso membership
de la flota de Cloud solo admite ubicaciones de regiones en
Regiones y zonas de Compute Engine.
La aplicación de las ubicaciones de recursos se controla a nivel del
recurso membership
cuando registras un clúster. Las membresías de flotas se admiten en ubicaciones globales y regionales.
Para crear membresías con suficiente redundancia, usa value
grupos
para controlar las regiones que están restringidas. Restricciones de la multirregión
las ubicaciones y las ubicaciones de zonas no tienen efecto en la flota membership
. Sin embargo,
restricciones en los grupos de valores que contienen regiones sí tienen un efecto. Por ejemplo:
el valor asia
en una política de la organización no tiene efecto en la membresía de la flota.
pero el valor in:asia-locations
sí tiene efecto.
IA generativa en Vertex AI
Las restricciones de las ubicaciones de 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 forzosamente de forma retroactiva. Esto significa que aplicar una restricción de ubicaciones de recursos no afecta ninguna restricción recursos o las actualizaciones de esos recursos. Los modelos de Google no son recursos de Google Cloud y las restricciones de las ubicaciones de los recursos no se aplican a ellos.
Para obtener una lista de las regiones disponibles, consulta IA generativa en Vertex AI ubicaciones.
GKE Multi-Cloud
La política de la organización se aplica de forma forzosa cuando usas el API de múltiples nubes de GKE para crear los siguientes clústeres:
- GKE en AWS
- GKE en Azure
- Clústeres conectados de GKE
Para obtener una lista de las ubicaciones disponibles, consulta las siguientes páginas de cada plataforma de clúster.
- Regiones de GKE en AWS
- Regiones de GKE en Azure
- Clústeres conectados a GKE: Regiones de EKS
- Clústeres conectados a GKE: Regiones de AKS
- Clústeres conectados de GKE: Regiones de clústeres que cumplen con la CNCF
Google Kubernetes Engine
Google Kubernetes Engine usa regiones y zonas de Compute Engine. La aplicación forzosa de las ubicaciones del recurso se controla a nivel del recurso de Compute Engine cuando se crea la VM de un clúster. Si deseas escalar un clúster mediante el agregado de más instancias o de otra zona, estos agregados nuevos también deben estar en una ubicación admitida.
Para crear clústeres con suficiente redundancia, usa grupos de valores para controlar las ubicaciones que se restringen. Si configuras las ubicaciones de forma manual, todas las zonas de esa región deben estar en la lista de las ubicaciones admitidas para tener el mismo nivel de redundancia. Los clústeres de ajuste de escala automático pueden romperse si alguna de las ubicaciones en las que se escala no se encuentra en la lista de las ubicaciones permitidas definidas en la política de la organización.
Infrastructure Manager
Infrastructure Manager usa estas regiones de Google Cloud para crear implementaciones de Infra Manager.
Además, Infrastructure Manager usa HCL como lenguaje de configuración para activar recursos usando Terraform.
Las restricciones de ubicación de recursos se aplican a Infra Manager. Implementación de Google Cloud, así como los recursos de Google Cloud admitidos que se definen en HCL.
API de Integration Connectors
La política de la organización se aplica de forma forzosa cuando usas el API de Integration Connectors para crear los siguientes recursos:
Para obtener una lista de las ubicaciones disponibles, consulta Ubicaciones de los conectores de integración.
Looker (Google Cloud Core)
Los recursos de Looker (Google Cloud Core) pueden crearse en ubicaciones regionales. La política de la organización se aplicará de manera forzosa cuando crees ese recurso.
Para obtener una lista de las regiones disponibles, consulta la página Crea una instancia de Looker (Google Cloud Core).
Servicio administrado para Microsoft Active Directory
La política de la organización se aplica cuando creas dominios administrados de Microsoft AD o actualizas los recursos existentes de AD. Microsoft AD administrado requiere que se permita la ubicación global
. Si la ubicación global
no está permitida, la creación del dominio y las actualizaciones de recursos fallarán.
Aprende a ver y actualizar la restricción de ubicación de recursos a global
.
Memorystore para Memcached
La política de la organización se aplica de forma forzosa cuando creas una instancia. La instancia es un recurso regional que crea una o más cachés zonales según el la cantidad de nodos seleccionados. Cuando agregas nodos con una operación de escalamiento vertical, ubicar los recursos nuevos en la misma región que la instancia original. El la política de la organización de ubicación se aplica durante el escalamiento vertical.
Para obtener una lista de las ubicaciones disponibles, consulta la página Regiones y zonas de Memorystore para Memcached.
Memorystore for Redis
La política de la organización se aplica de forma forzosa cuando creas una instancia. La instancia es un recurso regional que creará una o más cachés zonales según el nivel de instancia seleccionado. Las instancias de nivel básico implementan una sola caché dentro de una región y zona especificadas. Las instancias de nivel estándar implementan una caché zonal y una o más réplicas de caché zonales que se encuentran dentro de la región de la instancia. Cuando creas réplicas adicionales, debes ubicar los recursos nuevos en la misma región que la caché zonal original. La política de la organización de ubicación se aplica de forma forzosa cuando se crean réplicas adicionales.
Para obtener una lista de las ubicaciones disponibles, consulta Memorystore for Redis Regiones y zonas.
Memorystore for Redis Cluster
La política de la organización se aplica de forma forzosa cuando creas una instancia. La instancia es un recurso regional que creará una o más cachés zonales según el modo de distribución de la zona seleccionado. Cuando creas réplicas o fragmentos adicionales, ubicas los recursos nuevos en la misma región que la caché zonal original. La política de organización de la ubicación se aplica de forma forzosa cuando se crean réplicas adicionales.
Para obtener una lista de las ubicaciones disponibles, consulta el clúster de Memorystore para Redis. Ubicaciones.
Network Connectivity Center
Los recursos de Network Connectivity Center Hub y radio de VPC se pueden crear en la ubicación global. Los recursos de radios híbridos de Network Connectivity Center se pueden crear en cualquier ubicación regional. La política de la organización se aplicará de forma forzosa en el momento en que creas ese recurso.
Para obtener una lista de las ubicaciones regionales disponibles, consulta la Compute Engine Regiones y zonas.
Network Intelligence Center: pruebas de conectividad
Los recursos de pruebas de conectividad pueden crearse en la ubicación global. La política de la organización se aplicará de manera forzosa cuando crees ese recurso.
Persistent Disk
La política de la organización se aplica de forma forzosa cuando creas un recurso disk
, que luego se puede adjuntar a máquinas virtuales:
- Después de crear un recurso
disk
zonal, puedes adjuntarlo a las instancias de máquinas virtuales en la misma zona. - Después de crear un recurso
disk
regional, puedes adjuntarlo a las instancias de máquinas virtuales en una de las dos zonas en las que reside eldisk
.
El cumplimiento de las políticas de la organización no se aplica forzosamente de forma retroactiva. Para aplicar de forma forzosa una nueva política de la organización de las ubicaciones del recurso en recursos disk
existentes, debes borrar los recursos disk
y volver a crearlos con la política de la organización aplicada al recurso superior.
Para obtener una lista de las ubicaciones disponibles, consulta la página Regiones y zonas de Compute Engine.
Pub/Sub
La política de la organización de las ubicaciones del recurso afecta las ubicaciones
qué mensajes publicados en un topic
pueden persistir en reposo. La política de la organización se aplica de forma forzosa cuando publicas mensajes en un topic
. Ten en cuenta que un topic
sigue siendo un recurso global al que los clientes autorizados pueden acceder desde cualquier parte del mundo.
Los cambios en la política de la organización no son retroactivos y no serán
se aplicó a topics
existente. Si una nueva restricción de ubicaciones de recursos rechaza
una ubicación donde ya estén almacenados los mensajes publicados en un topic
, esos
mensajes no se moverán automáticamente.
Para obtener más información, consulta la página de Pub/Sub sobre cómo restringir las ubicaciones del recurso de Pub/Sub.
Pub/Sub Lite
La política de la organización de las ubicaciones del recurso afecta las ubicaciones en las que se puede crear un topic
, que determina dónde se conservarán los mensajes.
Una 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
existentes. Si una nueva restricción de ubicaciones de recursos rechaza
una ubicación donde ya estén almacenados los mensajes publicados en un topic
, esos
mensajes no se moverán automáticamente.
Secret Manager
Los secretos pueden tener una política de replicación automática o una política de replicación administrada por el usuario.
Cuando se utiliza una política de replicación automática, los datos de carga útil se replican sin restricción. El administrador de secretos requiere que la ubicación global
se permita cuando se crea un secreto con una política de replicación automática. Si la ubicación global
no está permitida, la creación del secreto fallará.
Cuando se utiliza una política de replicación administrada por el usuario, los datos de carga útil se replican en un conjunto de ubicaciones admitidas definido por el usuario. Secret Manager requiere que todas las ubicaciones en la política de replicación se permitan cuando se crea un secreto con una política de replicación administrada por el usuario. Si no se permite ninguna de las ubicaciones en la política de replicación de un secreto, fallará la creación de secretos.
La política de la organización se aplicará de forma forzosa en el momento en que creas ese secreto.
Para obtener más información, consulta la página ubicaciones del administrador de secretos.
Acceso a VPC sin servidores
La política de la organización se aplica de manera forzosa cuando creas una nueva Instancias del conector de Acceso a VPC sin servidores. La política de la organización es solo se aplica en el conector de Acceso a VPC sin servidores creado recientemente instancias en una región después de crear la política de la organización.
Para obtener más información, consulta la documentación Regiones admitidas.
Secure Source Manager
La política de la organización se aplica de forma forzosa cuando creas un nuevo Secure Source Manager individuales. Secure Source Manager garantiza que selecciones una región aprobada por tu organización. Organización la política solo se aplica en instancias de Secure Source Manager recién creadas en un región después de crear la política de la organización.
Para obtener más información, consulta la Página de descripción general de Secure Source Manager.
Protección de datos sensibles
Las restricciones de ubicación de recursos se aplican a toda la protección de datos sensibles de Google Cloud.
Los cambios en la política de la organización no son retroactivos y no serán se aplican a los recursos existentes.
Más información sobre las regiones disponibles para Protección de datos sensibles.
Speaker ID
La política de la organización de las ubicaciones del recurso afecta a las ubicaciones en las que un
Se puede crear el recurso speaker
, que determina dónde se encuentran las frases de inscripción y
se almacenan las impresiones de voz.
La política de la organización de las ubicaciones del recurso también afecta las ubicaciones
Se puede actualizar settings
.
Obtén más información sobre las regiones en las que está disponible Speaker ID.
Speech-to-Text
La política de la organización de las ubicaciones del recurso afecta las ubicaciones en las que
se puede crear cualquier recurso de Speech-to-Text. También afecta a las ubicaciones en
que el recurso config
se puede actualizar.
Speech-to-Text v1 está disponible en las regiones global
, eu
y us
. Más información
sobre las regiones disponibles de Speech-to-Text v2.
API de Timeseries Insights
Las restricciones de ubicaciones de recursos se aplican a todos los recursos de la API de Timeseries Insights.
La API de Timeseries Insights solo admite ubicaciones de regiones. Una integración
creados en una región específica solo pueden acceder a los recursos dentro de esa región.
Las restricciones de las ubicaciones multirregionales y de zona no tienen efecto en
API de Timeseries Insights. Sin embargo, las restricciones
grupos de valores
que contienen regiones sí tienen efecto. Por ejemplo, el valor asia
en una
la política de la organización no tiene efecto en la API de Timeseries Insights, pero el valor
in:asia-locations
sí tiene efecto.
Para obtener una lista de las ubicaciones disponibles en las que puedes crear tus integraciones, consulta Regiones admitidas.
API de Transcoder
Los recursos job
y jobTemplate
son regionales. Puedes especificar una ubicación
cuando se crea el recurso. La política de la organización se aplica de manera forzosa cuando se aplica la política.
de crear el recurso.
Para obtener una lista de las regiones disponibles, consulta Ubicaciones de la API de Transcoder.
Vertex AI
Las restricciones de ubicaciones de recursos se aplican a todos los recursos de Vertex AI, excepto a los recursos de DataLabelingJob
.
Vertex AI solo es compatible con ubicaciones de región. Las restricciones de ubicaciones multirregión y ubicaciones de zona no tienen efecto en Vertex AI. Sin embargo, las restricciones sobre grupos de valores que contienen regiones sí tienen un efecto. Por ejemplo, el valor asia
en una política de la organización no tiene efecto en AI Platform, pero el valor in:asia-locations
sí tiene un efecto.
Más información sobre las regiones disponibles para AI Platform Training
Vertex AI Search
Las restricciones de las ubicaciones de 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 manera forzosa de manera retroactiva. Esto significa que aplicar una restricción de ubicaciones de recursos no afecta ninguna restricción recursos o las actualizaciones de esos recursos.
Para obtener una lista de las regiones disponibles, consulta Vertex AI Search ubicaciones.
Nube privada virtual
Las redes de nube privada virtual (VPC) son redes virtuales globales. que contengan subredes virtuales regionales (subredes). Las restricciones de ubicación de recursos no se aplican a las redes de VPC, ya que son recursos globales. En este momento, las restricciones de ubicación de recursos se aplican en las subredes de la creación de subredes. Si creas una VPC en modo automático , las subredes se crean solo en el regiones permitidas por la restricción de ubicación del recurso.
Para obtener una lista de las regiones disponibles, consulta el Regiones y zonas.
Workflows
La política de la organización se aplica cuando creas un flujo de trabajo de Workflows. La política no se aplica a los recursos existentes ni a las actualizaciones de los recursos existentes. Workflows son recursos regionales y están sujetos al recurso de ubicación del mapa.
Si se aplica la restricción de ubicaciones de recursos, solo se pueden crear flujos de trabajo cuyas regiones coincidan exactamente con las aplicadas 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
en la lista de ubicaciones permitidas definidas en la política de la organización, puedes crear
un flujo de trabajo de us-central1
Para obtener una lista de las ubicaciones disponibles, consulta Ubicaciones de los flujos de trabajo.