Serviços suportados por localizações de recursos

Os recursos usados por cada serviço são afetados pela localização de diferentes formas. Antes de adicionar uma restrição de localizações de recursos à sua política da organização, reveja a secção adequada abaixo para ver como os recursos aos quais está a aplicar a política se vão comportar.

Agent Assist

A política da organização é aplicada quando cria um recurso conversation profile ou knowledge base no Agent Assist. Ambos os recursos são regionais.

As restrições de localização de recursos não se aplicam à localização global; a criação de recursos é sempre permitida.

Para ver uma lista das localizações e limitações disponíveis, consulte a página Regionalização e residência de dados do Agent Assist.

AlloyDB para PostgreSQL

A política da organização é aplicada quando cria clusters, instâncias e determinados tipos de cópias de segurança. A criação de cópias de segurança a pedido está sujeita à política da organização, enquanto a criação de cópias de segurança automáticas e contínuas está isenta se estiver ativada para evitar a perda de dados.

O AlloyDB para PostgreSQL só suporta localizações de regiões. As restrições em localizações de várias regiões e localizações de zonas não têm efeito. No entanto, as restrições em grupos de valores que contêm regiões têm um efeito. Por exemplo, o valor asia numa política da organização não tem efeito, mas o valor in:asia-locations tem.

Para ver uma lista de localizações disponíveis, consulte o artigo Localizações do AlloyDB para PostgreSQL.

IA antilavagem de dinheiro

As restrições de localizações de recursos aplicam-se a todos os recursos de IA de combate ao branqueamento de capitais e são aplicadas no momento da criação de recursos.

Para ver uma lista de localizações disponíveis, consulte Localizações de IA da AML.

API Gateway

As restrições de localizações de recursos são aplicadas quando cria gateways, um recurso regional. Outros recursos do gateway da API, como APIs e configurações de APIs, são recursos globais e não estão sujeitos a restrições de localizações de recursos.

Para ver uma lista das localizações suportadas para o API Gateway, consulte a secção Escolher uma Google Cloud região.

Saiba como definir uma política da organização com restrições de localizações de recursos em Restringir localizações de recursos.

Apigee

As restrições de localizações de recursos são aplicadas quando cria os seguintes recursos do Apigee:

Para ver uma lista de localizações disponíveis, consulte Localizações do Apigee.

Saiba como definir uma política da organização com restrições de localizações de recursos em Restringir localizações de recursos.

Apigee API Hub

As restrições de localizações de recursos aplicam-se a todos os recursos do hub de APIs do Apigee. A conformidade com a política da organização não é aplicada retroativamente. Isto significa que a aplicação de uma restrição de localizações de recursos não afeta os recursos preexistentes nem as atualizações desses recursos.

Para ver uma lista de localizações disponíveis, consulte o artigo Localizações do hub de APIs do Apigee.

API Apigee Integration

A política da organização é aplicada quando usa a API Apigee Integrations para criar os seguintes recursos:

  • Integração
  • Configuração de autorização (AuthConfig)
  • Certificado para AuthConfig
  • Versão da integração
  • Canal do SFDC (Salesforce)
  • Instância do SFDC (Salesforce)

A política da organização também é aplicada quando executa, agenda ou testa uma integração.

As integrações do Apigee são específicas da região. Significa que uma integração criada numa região específica só pode aceder aos recursos nessa região.

Para ver uma lista das localizações disponíveis onde pode criar as suas integrações, consulte o artigo Regiões suportadas.

App Engine

O App Engine é uma propriedade do recurso application. A propriedade de localização é aplicada a todos os ambientes quando cria um application. Só pode criar um App Engine application em cada projeto. É criado automaticamente um contentor do Cloud Storage na mesma localização que o application. Se criar um application com uma localização ampla que não esteja em conformidade com a política da organização, tem de criar um novo projeto e um application do App Engine.

Quando desativa um application, este não é publicado no futuro, mas o código e os dados replicados permanecem nas localizações onde o application foi armazenado. Para apagar completamente estes dados, elimine o projeto principal.

O ambiente flexível do App Engine é criado com base no Compute Engine. As instâncias de escalabilidade automática podem falhar se alguma das localizações onde a escalabilidade ocorre não estiver na lista de localizações permitidas definidas na política da organização.

Para ver uma lista de localizações disponíveis, consulte o artigo Localizações do App Engine.

App Hub

A política da organização é aplicada quando cria uma aplicação no App Hub. Uma app regional só pode conter recursos dessa região, enquanto uma app global pode conter recursos globais e recursos de qualquer região. Para mais informações, consulte o artigo Aplicações do App Hub globais e regionais.

Para ver uma lista de localizações disponíveis, consulte o artigo Localizações do App Hub.

API Application Integration

A política da organização é aplicada quando usa a API Application Integration para criar os seguintes recursos:

A política da organização também é aplicada quando executa, agenda ou testa uma integração.

A integração de aplicações é regional, o que significa que uma integração criada numa região específica só pode aceder aos recursos nessa região.

Para ver uma lista de localizações disponíveis, consulte o artigo Localizações de integração de aplicações.

Limitações

Os seguintes recursos de integração de aplicações não suportam as restrições de localização de recursos que especificar:

Artifact Registry

Pode criar repositórios numa região ou em várias regiões. O Artifact Registry aplica a política da organização quando cria um repositório.

A conformidade com a política da organização não é aplicada retroativamente. Os artefactos podem ser adicionados a qualquer repositório existente, mesmo que a localização do repositório seja recusada pela política de organização de localizações de recursos. Para aplicar uma nova política de organização de localizações de recursos a repositórios existentes, crie novos repositórios após a aplicação da política de organização e, em seguida, migre os artefactos dos repositórios antigos para os novos. Pode usar a ferramenta gcrane para copiar imagens entre repositórios.

Para ver uma lista de localizações disponíveis, consulte a documentação do Artifact Registry.

Gestor de auditorias

Quando executa uma nova auditoria, a política da organização é aplicada com base na região que especificou quando criou o pedido de auditoria. Quando a localização da auditoria é selecionada como global, não está sujeita à restrição das localizações dos recursos.

Para ver uma lista de localizações regionais disponíveis, consulte o artigo Localizações do Gestor de auditorias.

Serviço de cópias de segurança e RD

A política da organização é aplicada quando cria o seguinte recurso regional:

  • BackupPlan: a localização deste recurso determina a região de destino onde todos os dados de cópia de segurança são armazenados.

Para mais informações, consulte o artigo Localizações do serviço de cópia de segurança e recuperação de desastres.

Cópia de segurança do GKE

A política da organização é aplicada quando cria um dos dois recursos regionais de nível superior:

  • BackupPlan: a localização deste recurso determina a região de destino onde todos os dados de cópia de segurança são armazenados para cópias de segurança criadas abaixo deste plano. Pode haver vários recursos BackupPlan num projeto.

  • RestorePlan: a localização deste recurso controla a região permitida do cluster de destino no qual os dados de uma cópia de segurança são restaurados. Pode haver vários recursos RestorePlan num projeto

Para mais informações, consulte o artigo Localizações da cópia de segurança do GKE.

BigQuery

Os recursos do BigQuery dataset podem ser regionais e multirregionais. A conformidade com a política da organização não é aplicada retroativamente. Para aplicar uma nova restrição de localizações de recursos a um dataset existente, elimine o recurso dataset e crie-o novamente com a política da organização aplicada ao recurso principal.

Pode criar recursos Database num recurso dataset com uma localização que é recusada pela política da organização de localizações de recursos. A localização do recurso dataset não determina a localização do recurso database. Para aplicar uma nova restrição de localizações de recursos a um database existente, elimine o recurso database e crie-o novamente com a política da organização aplicada ao recurso principal.

Para ver uma lista das localizações disponíveis, consulte a página Localizações de conjuntos de dados do BigQuery.

Serviço de transferência de dados do BigQuery

O recurso TransferConfig pode ser regional e multirregional. A conformidade com a política da organização não é aplicada retroativamente. A política da organização só é verificada quando cria um TransferConfig. Para aplicar uma nova restrição de localizações de recursos a um TransferConfig existente, elimine o recurso TransferConfig e crie-o novamente com a política da organização aplicada ao recurso principal.

Para ver uma lista das localizações disponíveis, consulte as localizações do Serviço de transferência de dados do BigQuery.

Serviço de migração do BigQuery

O recurso MigrationWorkflow descreve as tarefas e as subtarefas que constituem o fluxo de trabalho de migração. Podem ser criados através da consola ou da API quando executar a avaliação da migração ou a tradução de SQL. Google Cloud O fluxo de trabalho de migração tem de ser criado na mesma localização que os recursos que usa. Por exemplo, se o conjunto de dados do BigQuery e o contentor do Cloud Storage estiverem na multirregião US, o fluxo de trabalho de migração pode ser criado na multirregião US ou na região us-west1.

A política da organização é verificada apenas quando cria um fluxo de trabalho de migração, porque é um recurso imutável.

Para ver uma lista das localizações disponíveis, consulte as localizações do serviço de migração do BigQuery.

Bigtable

Um recurso de instância do Bigtable é um contentor lógico de clusters. Cada um destes clusters está localizado numa zona. Todos os dados numa instância são replicados uniformemente para todos os clusters contidos nessa instância. A política da organização é aplicada quando um cluster é criado. Não pode criar novos contentores de armazenamento numa localização recusada pela política da organização. As instâncias e os clusters existentes continuam a funcionar, mesmo que estejam em localizações recusadas por uma alteração subsequente à política da organização.

Pode corrigir manualmente os recursos que violam uma nova política da organização, eliminando-os e recriando-os assim que a política da organização for implementada. Por exemplo, se tiver uma instância com vários clusters em que um cluster violou uma nova política da organização, pode eliminá-lo e, em seguida, adicionar um novo cluster numa zona permitida.

Para ver uma lista de localizações disponíveis, consulte a página Localizações do Bigtable.

Certificate Authority Service

Os recursos do serviço de AC, como modelos de certificados, conjuntos de autoridades de certificação (AC) e ACs, podem ser criados em qualquer localização disponível. Não é possível mover estes recursos após a criação.

Os modelos de certificados podem ser replicados através de comandos da CLI do Google Cloud. Pode usar comandos da CLI gcloud para criar recursos com o mesmo nome noutra localização suportada. Para mais informações, consulte o artigo Criar modelos de certificados.

As ACs podem ser clonadas a partir de ACs existentes no mesmo conjunto de ACs. Estas novas CAs são criadas na mesma localização que a CA a partir da qual foram clonadas. Para mais informações, consulte o artigo Criar autoridades de certificação.

Para ver a lista de localizações disponíveis, consulte o artigo Localizações de serviços da CA.

Gestor de certificados

Exceto para CertificateMaps e CertificateMapEntries, que só podem ser globais, os recursos do Certificate Manager podem ser criados em quaisquer localizações regionais ou globais. No entanto, não pode escolher uma zona para um recurso. A política da organização é aplicada no momento em que cria o recurso do Gestor de certificados.

Para ver uma lista de localizações disponíveis, consulte o artigo Produtos disponíveis por localização.

Cloud Asset Inventory

Os recursos do feed do Cloud Asset Inventory são recursos globais e não estão sujeitos a restrições de localizações de recursos.

Cloud Build

A política da organização é aplicada quando cria novos recursos do Cloud Build regionais. Embora possa criar recursos em qualquer região, o Cloud Build garante que seleciona uma região aprovada pela sua organização. A política da organização só é aplicada aos recursos do Cloud Build criados recentemente numa região não global depois de criar a política da organização.

Para ver uma lista das regiões disponíveis, consulte a página de localizações do Cloud Build.

Cloud Composer

Um ambiente do Cloud Composer é um contentor lógico para os recursos indicados abaixo. Durante o processo de criação do ambiente, escolhe uma localização (região/zona) para o ambiente e os recursos subjacentes são criados com base na localização selecionada.

  • Cluster do Google Kubernetes Engine

  • Instância do Cloud SQL

  • VMs do App Engine que executam o servidor Web do Airflow

  • Discos persistentes: usados pelo servidor Web do Airflow e pelo cluster do GKE

  • Tópicos do Pub/Sub

  • Cloud Storage

  • Criar e armazenar imagens do Airflow com dependências personalizadas do Python

    • Quando as restrições de localização não são especificadas, dependendo da configuração, o Composer pode criar imagens do Airflow no cluster do GKE ou através do Cloud Build. Leia mais sobre este assunto no artigo Instalar uma dependência do Python num ambiente de IP privado. Consoante a versão do Composer, as imagens do Airflow podem ser armazenadas na região selecionada (através do Artifact Registry) ou em várias regiões às quais a região selecionada pertence (através do Container Registry).

    • Se forem especificadas restrições de localização, o Cloud Composer cria imagens do Airflow no cluster do GKE do ambiente e armazena-as no repositório do Artifact Registry na região selecionada.

  • Cloud Monitoring: armazena métricas para ambientes e DAGs do Airflow executados na região que especificar

    • Algumas etiquetas de métricas podem conter nomes de DAGs e ambientes do Cloud Composer.

  • Cloud Logging: por predefinição, o Cloud Composer armazena no Cloud Logging, que é um serviço global Google Cloud . Se quiser armazenar registos do Cloud Composer numa localização específica, tem de redirecionar os registos para um contentor do Cloud Storage nesta localização.

Para ver uma lista de localizações disponíveis, consulte o artigo Regiões do Cloud Composer.

A documentação do Cloud Composer oferece mais informações sobre os detalhes da arquitetura dos ambientes do Cloud Composer.

Cloud Data Fusion

A política da organização é aplicada quando cria uma instância. A instância é um recurso regional criado na região que especificar.

Quando cria uma instância com uma chave de encriptação gerida pelo cliente (CMEK), a localização da chave tem de ser igual à localização da instância.

Por predefinição, o Cloud Data Fusion cria clusters Dataproc efémeros na mesma região que a instância para cada pipeline. A localização destes clusters temporários pode ser alterada e não é aplicada pela política da organização de localizações de recursos. Para clusters do Dataproc estáticos, pode usar qualquer uma das localizações suportadas pelo Dataproc e estas localizações não são aplicadas pela política da organização de localizações de recursos.

Para ver uma lista das localizações disponíveis, consulte o artigo Regiões suportadas do Cloud Data Fusion.

Cloud Deploy

Seguem-se os tipos de recursos do Cloud Deploy:

  • Pipeline de fornecimento
  • Destino
  • Libertar
  • Implementação
  • Execução de tarefa

Todos os recursos do Cloud Deploy são criados na mesma região onde foi criada a pipeline de implementação.

Se tiver uma política da organização contra a utilização de determinadas localizações, não pode criar recursos do Cloud Deploy nessa região (pipeline de implementação, destino, versão ou implementação).

Para ver uma lista das localizações disponíveis para o serviço Cloud Deploy e os respetivos recursos, consulte o artigo Acerca das regiões do Cloud Deploy.

Cloud Domains

Os recursos de registo do Cloud Domains são recursos globais e não estão sujeitos a restrições de localizações de recursos.

API Cloud Healthcare

A política da organização é aplicada quando cria um recurso dataset. Os recursos do dataset são recursos regionais ou multirregionais. Os recursos de armazenamento de dados, como o armazenamento FHIR, ou outros recursos de nível inferior, como mensagens HL7v2, podem ser adicionados a qualquer dataset existente, mesmo que o recurso dataset esteja numa localização que seja recusada pela política da organização. Para garantir que os seus recursos estão em conformidade com a restrição de localização de recursos, crie novos recursos dataset após a aplicação da política da organização e, em seguida, migre os dados dos recursos dataset antigos para os novos.

Para uma lista das localizações disponíveis, consulte o artigo Regiões da Cloud Healthcare API.

Cloud Interconnect

Pode criar uma associação do Cloud Interconnect em qualquer região. No entanto, não pode escolher uma zona. A política organizacional é aplicada no momento em que cria a ligação do Cloud Interconnect.

Para ver uma lista das regiões disponíveis, consulte a página Regiões e zonas do Compute Engine.

Sistema de deteção de intrusões do Cloud

A política da organização é aplicada quando cria um ponto final do Cloud IDS, que é um recurso zonal. A conformidade com a política da organização não é aplicada retroativamente. Os pontos finais existentes continuam a funcionar, mesmo que estejam em localizações recusadas pela política da organização. Para aplicar uma nova restrição de localização de recursos a um ponto final do Cloud IDS existente, elimine a instância e, em seguida, crie-a novamente com a política da organização aplicada.

Para ver uma lista de localizações disponíveis, consulte o artigo Produtos disponíveis por localização.

Cloud Key Management Service

Os recursos do Cloud KMS podem ser criados em localizações regionais, em duas regiões, multirregionais ou globais. A política da organização é aplicada no momento em que cria esse recurso.

Para mais informações, consulte a página de localizações do Cloud KMS.

Cloud Load Balancing

Os balanceadores de carga que usam os seguintes produtos podem ser criados em qualquer localização regional:

  • Balanceador de carga de aplicações externo regional
  • Balanceador de carga de rede de proxy externo regional
  • Balanceador de carga de aplicações interno regional
  • Balanceador de carga de rede de proxy interno regional
  • Balanceador de carga de rede de encaminhamento externo
  • Balanceador de carga de rede de encaminhamento interno

No entanto, não pode escolher uma zona para estes equilibradores de carga. A política da organização é aplicada no momento em que cria o recurso de balanceamento de carga.

Para ver uma lista de localizações regionais disponíveis, consulte a página Regiões e zonas do Compute Engine.

Cloud Logging

A política da organização é aplicada quando cria novos recipientes de registos. Embora possa criar um novo contentor em qualquer região ou definir a respetiva localização como global, o Logging garante que seleciona uma região aprovada pela sua organização. A política da organização só é aplicada aos contentores de registos recém-criados depois de criar a política da organização.

Para ver uma lista das regiões disponíveis, consulte a secção Regionalização da página Vista geral do armazenamento do Cloud Logging.

NAT na nuvem

Pode criar um gateway NAT da nuvem em qualquer localização regional. No entanto, não pode escolher uma zona para um gateway NAT da nuvem. A política da organização é aplicada no momento em que cria o gateway Cloud NAT.

Para ver uma lista de localizações regionais disponíveis, consulte a página Regiões e zonas do Compute Engine.

Cloud Next Generation Firewall Enterprise

A política da organização é aplicada quando cria um ponto final do Cloud NGFW Enterprise, que é um recurso zonal. A conformidade com a política da organização não é aplicada retroativamente. Os pontos finais existentes continuam a funcionar, mesmo que estejam em localizações recusadas pela política da organização. Para aplicar uma nova restrição de localização de recursos num ponto final do Cloud NGFW Enterprise existente, elimine a instância e, em seguida, crie-a novamente com a política da organização aplicada.

Para ver uma lista de localizações disponíveis, consulte o artigo Produtos disponíveis por localização.

Cloud Next Generation Firewall Standard

Pode criar uma política de firewall de rede regional do Cloud NGFW Standard em qualquer localização regional. No entanto, não pode escolher uma zona para uma política de firewall de rede regional do Cloud NGFW Standard. A política da organização é aplicada no momento em que cria a política de firewall de rede regional do Cloud NGFW Standard.

Para ver uma lista de localizações regionais disponíveis, consulte a página Regiões e zonas do Compute Engine.

Cloud Router

Pode criar um Cloud Router em qualquer localização regional. No entanto, não pode escolher uma zona para um Cloud Router. A política organizacional é aplicada no momento em que cria o Cloud Router.

Para ver uma lista de localizações regionais disponíveis, consulte a página Regiões e zonas do Compute Engine.

Cloud Run

A política da organização é aplicada quando cria um recurso de nível superior, como um Service. Não é aplicada a recursos já existentes nem a atualizações de recursos existentes, mesmo que essas atualizações levem à criação de um recurso de nível inferior, como um Revision.

Para ver uma lista das regiões disponíveis, consulte a página de localizações do Cloud Run.

Funções do Cloud Run

A política da organização é aplicada quando cria ou atualiza um recurso de função do Cloud Run. Não é aplicada a recursos já existentes.

Para ver uma lista das regiões disponíveis, consulte o artigo Localizações das funções do Cloud Run.

Cloud Service Mesh

A política da organização é aplicada quando tenta aprovisionar a Cloud Service Mesh ou criar cargas de trabalho para a malha. A malha de serviços na nuvem não aplica políticas organizacionais quando as cargas de trabalho estão registadas na malha.

Consulte a documentação relevante para as cargas de trabalho de serviços específicos:

Consulte a lista de regiões disponíveis para a sua infraestrutura de computação do Cloud Service Mesh:

Cloud SQL

A política da organização é aplicada quando cria uma instância. A instância é um recurso regional que cria uma base de dados zonal, para a qual a localização do recurso não é aplicada. Quando cria réplicas de leitura ou clones de bases de dados, localiza os novos recursos na mesma região que os originais, pelo que a política de organização de localizações de recursos não é aplicada.

Para ver uma lista de localizações disponíveis, consulte a página Localizações de instâncias do Cloud SQL.

Cloud Storage

A política da organização é aplicada quando cria um recurso bucket. Bucket os recursos são regionais ou multirregionais. Os recursos Object podem ser adicionados a qualquer bucket existente, mesmo que o object esteja numa localização recusada pela política da organização de localizações de recursos. Para garantir que os seus recursos estão em conformidade com a política da organização de localizações de recursos, crie novos recursos bucket após a aplicação da política da organização e, em seguida, migre os dados dos recursos bucket antigos para os novos.

Para ver uma lista de localizações disponíveis, consulte a página Localizações dos contentores do Cloud Storage.

Cloud Tasks

A política da organização é aplicada quando cria uma fila. Não é aplicada a filas criadas antes de a política de organização ter sido definida nem a atualizações dessas filas.

Para ver uma lista de localizações disponíveis, consulte o artigo Produtos disponíveis por localização.

Limitações

Aplicam-se limitações às seguintes regiões:

  • us-central1
  • us-central2 (região Google Cloud privada)

Quando tem alguma das regiões mencionadas anteriormente na sua política da organização, tem de incluir us-central1 e us-central2, mesmo que não esteja a criar recursos do Cloud Tasks nestas regiões. Pode incluir a região us-central2 na política da sua organização, mesmo que a sua organização não use regiões privadas.

Cloud TPU

Os recursos do Cloud TPU (nós da TPU e VMs da TPU) são recursos zonais. Isto significa que tem de selecionar uma zona específica numa região quando cria um recurso de TPU na nuvem. Google Cloud

A disponibilidade de tipos de aceleradores de TPU do Google Cloud específicos (como v3, v4, v5e ou v5p) varia consoante a zona. Nem todas as zonas oferecem todos os tipos de TPUs. As políticas da organização que aplicam restrições de localização de recursos são verificadas durante a criação de recursos de TPUs do Google Cloud. Se uma política de organização restringir a implementação na zona escolhida, a criação de recursos de TPU é bloqueada.

Para ver uma lista das regiões e zonas disponíveis onde o Cloud TPU é suportado, consulte o artigo Localizações e zonas do Cloud TPU.

Cloud Translation - Advanced API (v3)

Para garantir que os seus recursos do Cloud Translation estão em conformidade com a restrição de localização de recursos, especifique um ponto final regional quando criar o recurso. A restrição de localização de recursos é aplicada quando cria um recurso do Cloud Translation.

Para obter informações sobre como usar pontos finais regionais, consulte o artigo Especifique um ponto final regional.

Cloud VPN

Pode criar um gateway de VPN do Cloud em qualquer localização regional. No entanto, não pode escolher uma zona para um gateway de VPN do Google Cloud. A política de organização é aplicada no momento em que cria o gateway da Cloud VPN.

Para ver uma lista de localizações regionais disponíveis, consulte a página Regiões e zonas do Compute Engine.

Cloud Workstations

A política da organização é aplicada quando cria novos recursos regionais, como clusters de estações de trabalho, configurações de estações de trabalho e estações de trabalho. A criação de uma configuração de estação de trabalho pode resultar na criação de discos persistentes e VMs do Compute Engine, pelo que só pode criar estes recursos em zonas que a política da sua organização permita.

Para ver uma lista de localizações disponíveis, consulte o artigo Localizações das Cloud Workstations.

Compute Engine

O Compute Engine oferece uma variedade de recursos, que podem ser globais, regionais ou zonais. Os recursos regionais e zonais estão sujeitos às restrições de localização de recursos. Os recursos globais não estão sujeitos à restrição de localizações de recursos, mas alguns recursos globais usam recursos regionais e zonais. Esses recursos regionais e zonais estão sujeitos à restrição de localizações de recursos.

Por exemplo, um modelo de instância é um recurso global, mas pode especificar discos regionais ou zonais num modelo de instância. Esses discos estão sujeitos às restrições de localizações de recursos. Por isso, no modelo de instância, tem de especificar discos em regiões e zonas que a sua política organizacional permite.

Limitações

Todos os recursos do Compute Engine suportam as restrições de localização de recursos que especificar, com as seguintes exceções.

  • Resumos e imagens

  • Grupos de instâncias geridas

    • Algumas operações de grupos de instâncias geridas (MIG) baseiam-se na criação ou recriação de VMs em zonas permitidas. Estas operações incluem: expansão (manual ou através do dimensionamento automático), autocura, atualização automática e redistribuição proativa de instâncias. Para que essas operações sejam bem-sucedidas, os MIGs têm de existir em localizações permitidas pela restrição de localização de recursos da sua organização.

    • Crie MIGs em localizações permitidas. Para MIGs regionais, selecione zonas que não tenham restrições de localização.

    • Se tiver um GIG zonal ou regional pré-existente e, posteriormente, definir uma restrição de localização de recursos, as operações do GIG falham se violarem a restrição. Tem de recriar o MIG numa localização permitida.

  • Nós de inquilino único

    • Se tiver um grupo de nós pré-existente e, posteriormente, definir uma restrição de localização de recursos, não pode aumentar a escala do grupo para adicionar novos anfitriões (manualmente ou através do ajuste automático) se a localização do grupo violar a restrição.

Para ver uma lista de localizações disponíveis, consulte a página Regiões e zonas do Compute Engine.

Config Controller

O Config Controller usa as regiões e as zonas do Compute Engine. A aplicação das localizações dos recursos é processada ao nível do recurso do Compute Engine quando cria o cluster. Para dimensionar um cluster adicionando mais instâncias, estas novas adições também têm de estar numa localização permitida.

Para criar clusters com redundância suficiente, use grupos de valores para controlar as localizações restritas. Se definir as localizações manualmente, todas as zonas nessa região têm de estar na lista permitida para ter o mesmo nível de redundância. Os clusters de escala automática podem falhar se alguma das localizações em que a escala ocorre não estiver na lista de localizações permitidas definida na política da organização.

Conversational Insights

A política da organização é aplicada quando cria um conversation no Conversational Insights. Os recursos do conversation são regionais.

Para ver uma lista de localizações disponíveis, consulte a página de localizações do Conversational Insights.

Database Migration Service

A política da organização é aplicada quando cria qualquer um dos seguintes recursos do serviço de migração de bases de dados:

A política é aplicada quando o recurso é criado. A aplicação de uma restrição de localizações de recursos não afeta os recursos existentes nem as atualizações desses recursos.

API Data Lineage

A política da organização é aplicada quando cria ou atualiza um Process usando o método CreateProcess, UpdateProcess ou ProcessOpenLineageRunEvent.

Os recursos filho (Runs ou Events) podem ser atualizados ou adicionados a qualquer Process existente, mesmo que o Process esteja numa localização que seja recusada pela política de organização de localização de recursos. Para garantir que todos os seus recursos estão em conformidade com a política de organização de localização de recursos, crie novos recursos Process após a aplicação da política de organização.

Dataflow

A política da organização é aplicada quando cria um job. Um job é um recurso regional que usa o Cloud Storage e o Compute Engine. Pode configurar trabalhadores do Compute Engine para execução numa zona fora da região da tarefa especificando o parâmetro de zona. Neste caso, o plano de controlo do Dataflow é executado na região especificada, enquanto os trabalhadores de processamento de dados são executados na zona especificada. Se não especificar a zona dos trabalhadores, estes são criados na região em que o job está configurado para ser executado.

Se não especificar a zona do job, a localização dos trabalhadores vai estar numa das zonas na região em que o job está configurado para ser executado. O Dataflow seleciona a zona com base na capacidade disponível na zona. Todas as zonas na região do job devem ser definidas como valores permitidos na política da organização de localizações de recursos.

Os clusters de escalabilidade automática podem falhar se alguma das localizações em que a escalabilidade ocorre não estiver na lista de localizações permitidas definida na política da organização.

Para ver uma lista de localizações disponíveis, consulte a página Pontos finais regionais do Dataflow.

Dataform

Os recursos do Dataform são regionais. Quando cria um repositório do Dataform, o repositório e todos os respetivos recursos secundários são restritos à região especificada na criação do repositório.

Para ver uma lista de localizações disponíveis, consulte o artigo Localizações do Dataform.

Dataplex Universal Catalog

A política da organização é aplicada quando cria qualquer um dos seguintes recursos do catálogo universal do Dataplex:

A política é aplicada quando o recurso é criado. A aplicação de uma restrição de localizações de recursos não afeta os recursos existentes nem as atualizações desses recursos.

Dataproc

Quando cria um cluster, a política da organização é aplicada com base na região especificada no pedido de criação. A localização de um job está limitada à localização do cluster que é o seu elemento principal quando o método submit é chamado.

Para ver uma lista de localizações disponíveis, consulte a página Pontos finais regionais do Dataproc.

Dataproc Metastore

Quando cria um service, a política da organização é aplicada com base na região especificada no pedido de criação. A localização de backups e metadataImports está limitada à localização do service que é o respetivo elemento principal quando os métodos importMetadata e backupService são chamados.

Para ver uma lista de localizações disponíveis, consulte a página Localizações do Dataproc Metastore.

Armazenamento de dados

Os recursos do Datastore database dependem diretamente da aplicação do App Engine no projeto principal e da respetiva localização definida. A desativação da aplicação do App Engine bloqueia o acesso à API para a base de dados associada. Para eliminar dados replicados das localizações físicas, elimine o projeto conforme descrito na secção App Engine.

Para ver uma lista de localizações disponíveis, consulte a página Localizações do Datastore.

Datastream

A política de organização é aplicada quando cria qualquer um dos seguintes recursos Datastream:

A política é aplicada quando o recurso é criado. A aplicação de uma restrição de localizações de recursos não afeta os recursos existentes nem as atualizações desses recursos.

Dialogflow

A política da organização é aplicada quando cria um recurso agent ou location setting no Dialogflow CX (o Dialogflow ES ainda não aplica a política da organização). Tanto os recursos agent como os recursos location setting são regionais ou multirregionais. Outros recursos do Dialogflow, como intents ou flows, podem ser adicionados a qualquer agent existente, mesmo que o recurso agent esteja numa localização recusada pela política da organização. Para garantir que os seus recursos estão em conformidade com a restrição de localização de recursos, crie novos recursos agent após a aplicação da política da organização e, em seguida, migre os dados dos recursos agent antigos para os novos.

As restrições de localização de recursos não se aplicam à localização global; a criação de recursos é sempre permitida.

Para ver uma lista de localizações disponíveis, consulte a página Localizações do Dialogflow.

Document AI

Os recursos da IA Documental são regionais. Quando cria um recurso Processor ou LabelerPool, a política da organização de localização de recursos é aplicada e restringe as regiões nas quais é possível criar ou armazenar novos recursos.

A conformidade com a política da organização não é aplicada retroativamente. É possível criar novos recursos da IA Documental em recursos principais existentes, mesmo que a localização do recurso principal seja recusada pela política da organização de localizações de recursos. Para aplicar uma nova restrição de localização de recursos a um recurso existente, elimine o recurso e crie-o novamente com a política da organização aplicada.

Para ver uma lista das localizações disponíveis, consulte a página Suporte multirregional da Document AI.

Eventarc

A política da organização é aplicada quando cria um acionador do Eventarc. A política não é aplicada a recursos já existentes nem a atualizações de recursos existentes. Os acionadores podem ser um recurso global ou regional. Os recursos globais não estão sujeitos à restrição de localizações de recursos.

Se a restrição de localizações de recursos for aplicada, só podem ser criados acionadores regionais cujas regiões correspondam exatamente às aplicadas na restrição de localizações de recursos ou estejam incluídas no grupo de valores. Por exemplo, se us-central1 ou us-locations estiverem na lista de localizações permitidas definidas na política da organização, pode criar um acionador us-central1.

Para ver uma lista das localizações disponíveis, consulte o artigo Localizações do Eventarc.

Filestore

A política da organização é aplicada quando cria uma instância do Filestore, que pode ser um recurso zonal ou regional. A conformidade com a política da organização não é aplicada retroativamente. As instâncias existentes continuam a funcionar, mesmo que estejam em localizações recusadas pela política da organização. Para aplicar uma nova restrição de localização de recursos a uma instância do Filestore existente, elimine a instância e, em seguida, crie-a novamente com a política da organização aplicada.

Para ver uma lista de localizações disponíveis, consulte a página Regiões e zonas do Filestore.

Firebase Data Connect

Quando cria uma base de dados regional, são aplicadas políticas organizacionais que produzem uma base de dados do Firebase Data Connect que contém informações de serviço, esquema e conetor. Além disso, estas informações são mapeadas para uma base de dados do Cloud SQL correspondente localizada na mesma região. A base de dados do Cloud SQL tem a sua própria política da organização.

Para ver uma lista de localizações disponíveis, consulte a página Localizações do Firebase Data Connect.

Firestore

Os recursos do Firestore database dependem diretamente da aplicação do App Engine no projeto principal e da respetiva localização definida. A desativação da aplicação do App Engine bloqueia o acesso à API para a base de dados associada. Para eliminar dados replicados das localizações físicas, elimine o projeto conforme descrito na secção App Engine.

Para ver uma lista das localizações disponíveis, consulte a página Localizações do Firestore.

Fleet

O recurso Cloud Fleet membership só suporta localizações de regiões nas regiões e zonas do Compute Engine. A aplicação das localizações dos recursos é processada ao nível do recurso membership quando regista um cluster. As subscrições de frotas são suportadas em localizações globais e regionais.

Para criar subscrições com redundância suficiente, use grupos de valores para controlar as regiões restritas. As restrições em localizações de várias regiões e localizações de zonas não têm efeito no Fleet membership. No entanto, as restrições em grupos de valores que contêm regiões têm um efeito. Por exemplo, o valor asia numa política da organização não tem efeito na associação ao Fleet, mas o valor in:asia-locations tem efeito.

IA generativa no Vertex AI

As restrições de localizações de recursos aplicam-se a todos os recursos de IA generativa na Vertex AI. A conformidade com a política da organização não é aplicada retroativamente. Isto significa que a aplicação de uma restrição de localizações de recursos não afeta os recursos preexistentes nem as atualizações desses recursos. Os modelos de publicadores do Model Garden não são Google Cloud recursos, e as restrições de localizações de recursos não se aplicam a eles.

Para ver uma lista das regiões disponíveis, consulte as localizações da IA generativa na Vertex AI.

Limitações

As restrições de localização de recursos são aplicadas nas seguintes interfaces para a IA generativa na Vertex AI:

  • Vertex AI Studio (IU)

As restrições de localização de recursos não são aplicadas nas seguintes 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

Siga este Issue Tracker para ver o progresso mais recente da limitação.

GKE Multi-cloud

A política de organização é aplicada quando usa a API GKE Multi-Cloud para criar os seguintes clusters:

  • GKE no AWS
  • GKE no Azure
  • Clusters associados do GKE

Para ver uma lista das localizações disponíveis, consulte as seguintes páginas para cada plataforma de cluster.

Google Cloud Armor

Quando cria uma política de segurança do Cloud Armor, a política da organização é aplicada com base na região que especificar no pedido de criação. A política não é aplicada aos recursos já existentes. Os recursos globais não estão sujeitos à restrição de localizações de recursos.

Para ver uma lista de localizações regionais disponíveis, consulte a página Regiões e zonas do Compute Engine.

Google Cloud Contact Center as a Service

O recurso ContactCenter é regional. A conformidade com a política da organização não é aplicada retroativamente. A política da organização é verificada quando cria um ContactCenter.

Para ver uma lista das localizações disponíveis, consulte as localizações do Google Cloud Contact Center as a Service.

Google Cloud Managed Lustre

A política de organização é aplicada quando cria uma instância no Lustre gerido.

As instâncias do Managed Lustre são recursos regionais. Isto significa que a localização do recurso determina a região de destino onde todos os dados são tratados e armazenados.

Para ver uma lista das localizações disponíveis onde pode criar as suas instâncias, consulte o artigo Regiões suportadas.

Google Cloud Managed Service para Apache Kafka

A política de organização é aplicada quando cria um cluster no Managed Service for Apache Kafka.

Os clusters do Managed Service for Apache Kafka são recursos regionais. Isto significa que a localização do recurso determina a região de destino onde todos os dados são tratados e armazenados.

Para ver uma lista das localizações disponíveis onde pode criar os seus clusters, consulte o artigo Regiões suportadas.

Google Cloud NetApp Volumes

A política da organização é aplicada quando cria um volume ou um conjunto de armazenamento do NetApp Volumes, que pode ser um recurso regional. A conformidade com a política da organização não é aplicada retroativamente. Os conjuntos de armazenamento existentes continuam a funcionar, mesmo que estejam em localizações recusadas pela política da organização. Para aplicar uma nova restrição de localização de recursos a um volume ou um conjunto de armazenamento do NetApp Volumes existente, elimine o recurso e, em seguida, crie-o novamente com a política da organização aplicada.

Para ver uma lista de localizações disponíveis, consulte a página Localizações dos volumes NetApp.

Google Kubernetes Engine

O Google Kubernetes Engine usa regiões e zonas do Compute Engine. A aplicação das localizações dos recursos é processada ao nível do recurso do Compute Engine quando cria a VM para um cluster. Se quiser dimensionar um cluster adicionando mais instâncias ou outra zona, estas novas adições também têm de estar numa localização permitida.

Para criar clusters com redundância suficiente, use grupos de valores para controlar as localizações restritas. Se definir as localizações manualmente, todas as zonas nessa região têm de estar na lista permitida para ter o mesmo nível de redundância. Os clusters de escala automática podem falhar se alguma das localizações em que a escala ocorre não estiver na lista de localizações permitidas definida na política da organização.

Infrastructure Manager

O Infrastructure Manager usa estas Google Cloud regiões para criar implementações do Infra Manager.

Além disso, o Infrastructure Manager usa o HCL como linguagem de configuração para acionar recursos através do Terraform.

As restrições de localização de recursos são aplicadas aos recursos de implementação do Infra Manager, bem como aos recursos Google Cloud suportados definidos em HCL.

API Integration Connectors

A política da organização é aplicada quando usa a API Integration Connectors para criar os seguintes recursos:

Para ver uma lista de localizações disponíveis, consulte o artigo Localizações dos conetores de integração.

Looker (Google Cloud Core)

Os recursos do Looker (Google Cloud core) podem ser criados em localizações regionais. A política da organização é aplicada no momento em que cria esse recurso.

Para ver uma lista das regiões disponíveis, consulte a página Crie uma instância do Looker (Google Cloud core).

Serviço gerido para o Microsoft Active Directory

A política da organização é aplicada quando cria domínios do Microsoft AD geridos ou atualiza recursos do AD existentes. O Microsoft AD gerido requer que a localização do global seja permitida. Se a localização global não for permitida, a criação de domínios e as atualizações de recursos vão falhar.

Saiba como ver e atualizar a restrição de localização de recursos para global.

Memorystore for Memcached

A política da organização é aplicada quando cria uma instância. A instância é um recurso regional que cria uma ou mais caches zonais, consoante o número de nós selecionados. Quando adiciona nós através de uma operação de expansão, localiza os novos recursos na mesma região que a instância original. A política da organização de localização é aplicada durante o aumento da escala.

Para ver uma lista de localizações disponíveis, consulte a página Regiões e zonas do Memorystore for Memcached.

Memorystore for Redis

A política da organização é aplicada quando cria uma instância. A instância é um recurso regional que cria uma ou mais caches zonais, consoante o nível da instância selecionado. As instâncias de nível básico implementam uma única cache numa região e zona especificadas. As instâncias de nível padrão implementam uma cache zonal e uma ou mais réplicas de cache zonais localizadas na região da instância. Quando cria réplicas adicionais, localiza os novos recursos na mesma região que a cache zonal original. A política de organização de localizações é aplicada quando são criadas réplicas adicionais.

Para ver uma lista de localizações disponíveis, consulte a página Regiões e zonas do Memorystore para Redis.

Memorystore for Redis Cluster

A política da organização é aplicada quando cria uma instância. A instância é um recurso regional que cria uma ou mais caches zonais, consoante o modo de distribuição de zonas selecionado. Quando cria réplicas ou fragmentos adicionais, localiza os novos recursos na mesma região que a cache zonal original. A política de organização de localizações é aplicada quando são criadas réplicas adicionais.

Para ver uma lista de localizações disponíveis, consulte a página Localizações do Memorystore for Redis Cluster.

Memorystore for Valkey

A política da organização é aplicada quando cria uma instância. A instância é um recurso regional que cria uma ou mais caches zonais, consoante o modo de distribuição de zonas selecionado. Quando cria réplicas ou fragmentos adicionais, localiza os novos recursos na mesma região que a cache zonal original. A política de organização de localizações é aplicada quando são criadas réplicas adicionais.

Para ver uma lista de localizações disponíveis, consulte a página Localizações do Memorystore for Valkey.

Migre para máquinas virtuais

A política da organização é aplicada quando cria um recurso Migrate to VMs. A imagem das VMs de migração e os recursos de migração são todos recursos regionais. O recurso TargetProject, que contém o ID do projeto usado como o projeto de destino das tarefas de migração e importação, é um recurso global.

Network Connectivity Center

Os recursos do hub do Network Connectivity Center e do VPC Spoke podem ser criados na localização global. Os recursos de spoke híbrido do Network Connectivity Center podem ser criados em qualquer localização regional. A política da organização é aplicada no momento em que cria esse recurso.

Para ver uma lista de localizações regionais disponíveis, consulte a página Regiões e zonas do Compute Engine.

Network Intelligence Center – Testes de conetividade

Os recursos dos testes de conetividade podem ser criados na localização global. A política da organização é aplicada no momento em que cria esse recurso.

Parallelstore

A política da organização é aplicada quando cria uma instância no Parallelstore.

As instâncias do Parallelstore são recursos regionais. Isto significa que a localização do recurso determina a região de destino onde todos os dados são tratados e armazenados.

Para ver uma lista das localizações disponíveis onde pode criar as suas instâncias, consulte o artigo Regiões suportadas.

Parameter Manager

As restrições de localizações de recursos aplicam-se a todos os recursos do Parameter Manager.

As políticas da organização são aplicadas quando cria um parâmetro. Os parâmetros existentes não são movidos automaticamente se as restrições de localização forem alteradas.

Para ver uma lista das localizações disponíveis onde pode criar os seus parâmetros, consulte Localizações para recursos do Gestor de parâmetros.

Persistent Disk

A política da organização é aplicada quando cria um recurso do disk, que pode ser anexado a máquinas virtuais:

  • Depois de criar um recurso disk zonal, pode anexá-lo a instâncias de máquinas virtuais na mesma zona.
  • Depois de criar um recurso disk regional, pode anexá-lo a instâncias de máquinas virtuais numa das duas zonas em que o disk reside.

A conformidade com a política da organização não é aplicada retroativamente. Para aplicar uma nova política da organização de localizações de recursos a recursos disk existentes, tem de eliminar os recursos disk e, em seguida, criá-los novamente com a política da organização aplicada ao recurso principal.

Para ver uma lista de localizações disponíveis, consulte a página Regiões e zonas do Compute Engine.

Pub/Sub

A política da organização de localizações de recursos afeta as localizações em que as mensagens publicadas num topic podem ser mantidas em repouso. A política da organização é aplicada quando publica mensagens num topic. Tenha em atenção que um topic continua a ser um recurso global acessível a partir de qualquer parte do mundo para clientes autorizados.

As alterações à política da organização não são retroativas e não são aplicadas aos topics existentes. Se uma nova restrição de localizações de recursos negar uma localização onde as mensagens publicadas num topic já estão armazenadas, essas mensagens não são movidas automaticamente.

Para mais informações, consulte a página Restringir localizações de recursos do Pub/Sub.

Pub/Sub Lite

A política da organização de localizações de recursos afeta as localizações nas quais um topic pode ser criado, o que determina onde as mensagens são mantidas. Um topic é um recurso zonal, mas as mensagens podem ser pedidas a partir de qualquer localização, incluindo fora de Google Cloud.

As alterações à política da organização não são retroativas e não são aplicadas aos topics existentes. Se uma nova restrição de localizações de recursos negar uma localização onde as mensagens publicadas num topic já estão armazenadas, essas mensagens não são movidas automaticamente.

Secret Manager

Os Secrets podem ter uma política de replicação automática ou uma política de replicação gerida pelo utilizador.

Quando usa uma política de replicação automática, os dados de conteúdo são replicados sem restrições. O Secret Manager requer que a localização global seja permitida quando cria um Secret com uma política de replicação automática. Se a localização global não for permitida, a criação do segredo falha.

Quando usa uma política de replicação gerida pelo utilizador, os dados de conteúdo são replicados para um conjunto de localizações suportadas definido pelo utilizador. O Secret Manager requer que todas as localizações na política de replicação sejam permitidas quando cria um Secret com uma política de replicação gerida pelo utilizador. Se alguma das localizações na política de replicação de um Secret não for permitida, a criação do Secret falha.

A política de organização é aplicada no momento em que cria esse segredo.

Para mais informações, consulte a página Localizações do Secret Manager.

Secure Source Manager

A política de organização é aplicada quando cria novas instâncias do Secure Source Manager. O Secure Source Manager garante que seleciona uma região aprovada pela sua organização. A política da organização só é aplicada a instâncias do Secure Source Manager criadas recentemente numa região depois de criar a política da organização.

Para mais informações, consulte a página Vista geral do Secure Source Manager.

Secure Web Proxy

Pode criar um Secure Web Proxy em qualquer localização regional. No entanto, não pode escolher uma zona para um Secure Web Proxy. A política organizacional é aplicada no momento em que cria o proxy Web seguro.

Para ver uma lista de localizações disponíveis, consulte o artigo Produtos disponíveis por localização.

Proteção de dados confidenciais

As restrições de localização de recursos aplicam-se a todos os recursos de proteção de dados confidenciais.

As alterações à política da organização não são retroativas e não são aplicadas aos recursos existentes.

Saiba mais sobre as regiões disponíveis para a proteção de dados confidenciais.

Acesso a VPC sem servidor

A política da organização é aplicada quando cria novas instâncias do conetor de acesso a VPC sem servidor. A política da organização só é aplicada a instâncias do conetor de acesso a VPC sem servidor criadas recentemente numa região depois de criar a política da organização.

Para mais informações, consulte as regiões suportadas do Acesso a VPC sem servidor.

Spanner

A política da organização é aplicada quando cria uma instância. As instâncias são recursos regionais ou multirregionais. Se uma instância for bloqueada pela política organizacional de localizações de recursos, a única forma de colocar o recurso em conformidade é eliminar a instância. As instâncias bloqueadas pela política da organização de localizações de recursos continuam a permitir leituras, escritas e a criação de recursos de base de dados.

Para ver uma lista de localizações disponíveis, consulte a página Instâncias do Spanner.

Speaker ID

A política de organização de localizações de recursos afeta as localizações nas quais um recurso pode ser criado, o que determina onde as frases de inscrição e as impressões vocais são armazenadas.speaker

A política da organização de localizações de recursos também afeta as localizações nas quais o settings pode ser atualizado.

Saiba mais sobre as regiões onde o Speaker ID está disponível.

Conversão de voz em texto

A política da organização de localizações de recursos afeta as localizações nas quais é possível criar qualquer recurso de Speech-to-Text. Também afeta as localizações nas quais o recurso config pode ser atualizado.

A API Speech-to-Text v1 está disponível nas regiões global, eu e us. Saiba mais acerca das regiões disponíveis do Speech-to-Text v2.

Serviço de transferência de armazenamento

A política da organização é aplicada quando cria uma tarefa do serviço de transferência de armazenamento. A política da organização garante a conformidade permitindo que os trabalhos do serviço de transferência de armazenamento sejam criados apenas em regiões permitidas. Se a região da tarefa do serviço de transferência de armazenamento estiver fora das restrições da política da organização, a tarefa não é criada com êxito.

Para saber como o Serviço de transferência de armazenamento escolhe a região na qual executar uma tarefa do Serviço de transferência de armazenamento, consulte o artigo Localização das tarefas do Serviço de transferência de armazenamento.

API Timeseries Insights

As restrições de localizações de recursos aplicam-se a todos os recursos da API Timeseries Insights.

A API Timeseries Insights só suporta localizações de regiões. Uma integração criada numa região específica só pode aceder aos recursos dessa região. As restrições nas localizações de várias regiões e nas localizações de zonas não têm efeito na API Timeseries Insights. No entanto, as restrições nos grupos de valores que contêm regiões têm um efeito. Por exemplo, o valor asia numa política de organização não tem efeito na API Timeseries Insights, mas o valor in:asia-locations tem efeito.

Para ver uma lista das localizações disponíveis onde pode criar as suas integrações, consulte o artigo Regiões suportadas.

API Transcoder

Os recursos do job e do jobTemplate são regionais. Pode especificar uma localização ao criar o recurso. A política da organização é aplicada no momento em que cria o recurso.

Para uma lista das regiões disponíveis, consulte as localizações da API Transcoder.

Vertex AI

As restrições de localizações de recursos aplicam-se a todos os recursos do Vertex AI, exceto aos recursos DataLabelingJob.

O Vertex AI só suporta localizações de regiões. As restrições em localizações multirregionais e localizações de zonas não têm efeito no Vertex AI. No entanto, as restrições nos grupos de valores que contêm regiões têm um efeito. Por exemplo, o valor asia numa política da organização não tem efeito no Vertex AI, mas o valor in:asia-locations tem efeito.

Saiba mais sobre as regiões disponíveis para o AI Platform Training.

As restrições de localizações de recursos aplicam-se a todos os recursos do Vertex AI Search. A conformidade com a política da organização não é aplicada retroativamente. Isto significa que a aplicação de uma restrição de localizações de recursos não afeta os recursos preexistentes nem as atualizações desses recursos.

Para uma lista das regiões disponíveis, consulte as localizações do Vertex AI Search.

Nuvem virtual privada

As redes de nuvem virtual privada (VPC) são redes virtuais globais que contêm sub-redes virtuais regionais (sub-redes). As restrições de localização de recursos não se aplicam às redes VPC, porque são recursos globais. As restrições de localização de recursos são aplicadas às sub-redes no momento da criação das mesmas. Se criar uma rede VPC no modo automático, as sub-redes são criadas apenas nas regiões permitidas pela restrição de localização de recursos.

Para ver uma lista das regiões disponíveis, consulte a página Regiões e zonas do Compute Engine.

Workflows

A política de organização é aplicada quando cria um fluxo de trabalho do Workflows. A política não é aplicada a recursos já existentes nem a atualizações de recursos existentes. Os fluxos de trabalho são recursos regionais e estão sujeitos à restrição de localizações de recursos.

Se a restrição de localizações de recursos for aplicada, só é possível criar fluxos de trabalho cujas regiões correspondam exatamente às aplicadas na restrição de localizações de recursos ou que estejam incluídas no grupo de valores. Por exemplo, se us-central1 ou us-locations estiverem na lista de localizações permitidas definidas na política da organização, pode criar um fluxo de trabalho us-central1.

Para ver uma lista de localizações disponíveis, consulte o artigo Localizações dos fluxos de trabalho.

Workload Manager

A política da organização é aplicada quando cria um recurso de Workload Manager Evaluation ou Deployment. As avaliações e as implementações são recursos regionais e estão sujeitas à restrição de localizações de recursos.

Para ver uma lista das localizações disponíveis, consulte as localizações suportadas.