Serviços de suporte de localização de recursos

Os recursos usados por cada serviço são afetados pelo local de maneiras diferentes. Antes de adicionar uma restrição de localização de recursos à sua política da organização, consulte a seção apropriada abaixo para ver como os recursos a que você aplicará a política se comportarão.

Agent Assist

A política da organização é aplicada quando você cria um recurso conversation profile ou knowledge base no Assistente de agente. Ambos os recursos são regionais.

As restrições de local de recursos não se aplicam ao local global. A criação de recursos é sempre permitida.

Para conferir uma lista de locais disponíveis e limitações, consulte a página Regionalização e residência de dados da Assistente de IA.

API Gateway

As restrições de locais de recursos são aplicadas ao criar gateways, um recurso regional. Outros recursos do API Gateway, como APIs e configurações de API, são globais e não estão sujeitos a restrições de locais de recursos.

Para uma lista de locais compatíveis com o gateway de API, consulte Escolher uma região do Google Cloud .

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

Apigee

As restrições de locais de recursos são aplicadas ao criar os seguintes recursos do Apigee:

Para conferir uma lista de locais disponíveis, consulte Locais da Apigee.

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

Hub de APIs da Apigee

As restrições de locais de recursos se aplicam a todos os recursos do hub da API do Apigee. A conformidade com a política da organização não é aplicada retroativamente. Isso significa que a aplicação de uma restrição de locais de recursos não afeta recursos preexistentes nem atualizações deles.

Para uma lista de locais disponíveis, consulte Locais do hub de APIs da Apigee.

AlloyDB para PostgreSQL

A política da organização é aplicada quando você cria clusters, instâncias e determinados tipos de backups. A criação de backups sob demanda está sujeita à política da organização, enquanto a criação de backups automatizados e contínuos é isenta se estiver ativada para evitar a perda de dados.

O AlloyDB para PostgreSQL só é compatível com locais de região. As restrições em locais multirregionais e de zonas não têm efeito. No entanto, restrições em grupos de valores que contêm regiões têm efeito. Por exemplo, o valor asia em uma política da organização não tem efeito, mas o valor in:asia-locations tem.

Para uma lista de locais disponíveis, consulte Locais do AlloyDB para PostgreSQL.

IA antilavagem de dinheiro

As restrições de locais de recursos se aplicam a todos os recursos de IA de combate à lavagem de dinheiro e são aplicadas no momento da criação do recurso.

Para conferir uma lista de locais disponíveis, consulte Locais da IA de AML.

API Apigee Integration

A política da organização é aplicada quando você 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 você executa, programa ou testa uma integração.

As integrações da Apigee são específicas de cada região. Isso significa que uma integração criada em uma região específica só pode acessar os recursos dessa região.

Para conferir uma lista de locais disponíveis em que é possível criar integrações, consulte Regiões compatíveis.

App Engine

O App Engine é uma propriedade do recurso application. A propriedade de localização é aplicada a todos os ambientes quando você cria um application. É possível criar apenas um App Engine application em cada projeto. Um bucket do Cloud Storage é adicionado automaticamente no mesmo local que o application. Se você criar um application com uma localização ampla que não obedeça à política da organização, será necessário gerar um novo projeto e application do App Engine.

Quando você desativa um application, ele não é mais veiculado, mas o código e os dados replicados permanecem nos locais em que o application foi armazenado. Para apagar completamente essas informações, exclua o projeto pai.

O ambiente flexível do App Engine é construído sobre o Compute Engine. As instâncias de escalonamento automático podem falhar se os locais em que o escalonamento acontece não estiverem na lista de locais permitidos definidos na política da organização.

Para ver uma lista de locais disponíveis, consulte Locais do App Engine.

App Hub

A política da organização é aplicada quando você cria um aplicativo no App Hub. Um app regional só pode conter recursos dessa região, enquanto um app global pode conter recursos globais e de qualquer região. Para mais informações, consulte Aplicativos globais e regionais do App Hub.

Para conferir uma lista de locais disponíveis, consulte Locais do App Hub.

API Application Integration

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

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

O Application Integration é regional, o que significa que uma integração criada em uma região específica só pode acessar os recursos dessa região.

Para conferir uma lista de locais disponíveis, consulte Locais da integração de aplicativos.

Limitações

Os seguintes recursos do Application Integration não são compatíveis com as restrições de local de recursos especificadas:

Artifact Registry

Crie repositórios em uma multirregião ou região. O Artifact Registry aplica a política da organização quando você cria um repositório.

A conformidade com a política da organização não é aplicada retroativamente.Os artefatos podem ser adicionados a qualquer repositório existente, mesmo que o local do repositório seja negado pela política da organização de locais de recursos.Para aplicar uma nova política de locais de recursos a repositórios existentes, crie novos repositórios depois que a política da organização for aplicada. Em seguida, migre artefatos de repositórios antigos para os novos. É possível usar a ferramenta gcrane para copiar imagens entre repositórios.

Para uma lista de locais disponíveis, consulte a documentação do Artifact Registry.

Audit Manager

Quando você executa uma nova auditoria, a política da organização é aplicada com base na região especificada ao criar a solicitação de auditoria. Quando o local da auditoria é selecionado como global, ele não está sujeito à restrição de locais de recursos.

Para conferir uma lista de locais regionais disponíveis, consulte Locais do Audit Manager.

Serviço de backup e DR

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

  • BackupPlan: o local desse recurso determina a região de destino onde todos os dados de backup são armazenados.

Para mais informações, consulte Locais do serviço de backup e DR.

Backup para GKE

A política da organização é aplicada quando você cria um dos dois principais recursos regionais:

  • BackupPlan: o local desse recurso determina a região de destino em que todos os dados de backup são armazenados para backups criados abaixo desse plano. Pode haver vários recursos BackupPlan em um projeto.

  • RestorePlan: o local desse recurso controla a região permitida do cluster de destino em que os dados de um backup são restaurados. Pode haver vários recursos RestorePlan em um projeto.

Para mais informações, consulte Locais do Backup para GKE.

BigQuery

Os recursos dataset do BigQuery podem ser regionais e multirregionais. A conformidade com a política da organização não é aplicada de forma retroativa. Para aplicar uma nova restrição de localização de recursos em um dataset, exclua o dataset e crie-o novamente com a política da organização aplicada ao recurso pai.

É possível criar Databases em um dataset com um local que foi negado pela política da organização de localização de recursos. O local do dataset não determina o local do database. Para aplicar uma nova restrição de localização de recursos em um database atual, exclua o database e crie-o novamente com a política da organização aplicada ao recurso pai.

Para ver uma lista de locais disponíveis, consulte a página Locais do conjunto 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 é verificada apenas ao criar um TransferConfig. Para aplicar uma nova restrição de localização de recursos em um TransferConfig, exclua o recurso TransferConfig e crie-o novamente com a política da organização aplicada ao recurso pai.

Para conferir uma lista de locais disponíveis, consulte Locais do serviço de transferência de dados do BigQuery.

Serviço de migração do BigQuery

O recurso MigrationWorkflow descreve as tarefas e subtarefas que constituem o fluxo de trabalho de migração. Eles podem ser criados usando o console Google Cloud ou a API ao executar a avaliação de migração ou a tradução de SQL. O fluxo de trabalho de migração precisa ser criado no mesmo local que os recursos usados. Por exemplo, se o conjunto de dados do BigQuery e o bucket do Cloud Storage estiverem na multirregião US, o fluxo de trabalho de migração poderá ser criado na multirregião US ou na região us-west1.

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

Para conferir uma lista de locais disponíveis, consulte Locais do serviço BigQuery Migration.

Certificate Authority Service

Os recursos do serviço de CA, como modelos de certificado, pools de autoridade de certificação (CA, na sigla em inglês) e CAs, podem ser criados em qualquer local disponível. Esses recursos não podem ser movidos após a criação.

Os modelos de certificado podem ser replicados usando comandos da Google Cloud CLI. É possível usar comandos da CLI gcloud para criar recursos com o mesmo nome em outro local compatível. Para mais informações, consulte Como criar modelos de certificado.

As CAs podem ser clonadas de CAs existentes no mesmo pool de CAs. Essas novas CAs são criadas no mesmo local em que a CA foi clonada. Para mais informações, consulte Como criar autoridades de certificação.

Para ver a lista de locais disponíveis, consulte Locais de serviço de CA.

Bigtable

Um recurso de instância do Bigtable é um contêiner lógico de clusters. Cada um desses clusters está localizado em uma zona. Todos os dados em uma instância são replicados de maneira uniforme para todos os clusters contidos nela. A política da organização é aplicada quando um cluster é criado. Você não pode criar novos contêineres de armazenamento em um local negado pela política da organização. Instâncias e clusters existentes continuarão a funcionar, mesmo se estiverem em locais negados por uma alteração subsequente na política da organização.

Você pode corrigir manualmente os recursos que violam uma nova política da organização, excluindo-os e recriando-os assim que a política da organização for implementada. Por exemplo, se você tiver uma instância de vários clusters na qual um cluster violou uma nova política da organização, você poderá excluí-la e adicionar um novo cluster em uma zona permitida.

Para ver uma lista de locais disponíveis, consulte a página Locais do Bigtable.

Inventário de recursos do Cloud

Os recursos de feed do Inventário de recursos do Cloud são globais e não estão sujeitos a restrições de locais de recursos.

Cloud Build

A política da organização é aplicada quando você cria novos recursos regionais do Cloud Build. Embora seja possível criar recursos em qualquer região, o Cloud Build garante que você selecione uma região aprovada pela sua organização. A política da organização só é aplicada a recursos do Cloud Build recém-criados em uma região não global depois que você cria a política da organização.

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

Gerenciador de certificados

Com exceção de CertificateMaps e CertificateMapEntries, que só podem ser globais, os recursos do Certificate Manager podem ser criados em qualquer local regional ou global. No entanto, não é possível escolher uma zona para um recurso. A política da organização é aplicada quando você cria o recurso do Certificate Manager.

Para uma lista de locais disponíveis, consulte Produtos disponíveis por local.

Cloud Composer

Um ambiente do Cloud Composer é um contêiner lógico para os recursos listados abaixo. Durante o processo de criação do ambiente, você escolhe um local (região/zona) para o ambiente, e os recursos subjacentes são criados com base no local selecionado.

  • Cluster do Google Kubernetes Engine

  • Instância do Cloud SQL

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

  • Discos permanentes: usados pelo cluster da Web do Airflow e pelo cluster do GKE

  • Tópicos do Pub/Sub

  • Cloud Storage

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

    • Quando as restrições de local não são especificadas, dependendo da configuração, o Composer pode criar imagens do Airflow no cluster do GKE ou usando o Cloud Build. Leia mais sobre isso em Como instalar uma dependência do Python em um ambiente de IP particular. Dependendo das imagens do Airflow, a versão do Airflow pode ser armazenada na região selecionada (usando o Artifact Registry) ou na multirregião a que a região selecionada pertence (usando o Container Registry).

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

  • Cloud Monitoring: armazena métricas para ambientes e executa DAGs do Airflow na região especificada.

    • Alguns rótulos de métricas podem conter nomes de ambientes de DAGs e do Cloud Composer.

  • Cloud Logging: por padrão, o Cloud Composer armazena no Cloud Logging, que é um serviço global Google Cloud . Se você quiser armazenar os registros do Cloud Composer em um local específico, redirecione os registros para um bucket do Cloud Storage nesse local.

Para ver uma lista de locais disponíveis, consulte Regiões do Cloud Composer.

Na documentação do Cloud Composer, você encontra mais detalhes sobre os detalhes de arquitetura dos ambientes do Cloud Composer.

Cloud Data Fusion

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

Quando você cria uma instância com uma chave de criptografia gerenciada pelo cliente (CMEK), o local da chave precisa ser o mesmo da instância.

Por padrão, o Cloud Data Fusion cria clusters temporários do Dataproc na mesma região da instância para cada pipeline. O local desses clusters efêmeros pode ser alterado e não é aplicado pela política da organização de locais de recursos. Para clusters estáticos do Dataproc, é possível usar qualquer um dos locais compatíveis com o Dataproc, e esses locais não são aplicados pela política da organização de locais de recursos.

Para conferir uma lista de locais disponíveis, consulte Regiões compatíveis com o Cloud Data Fusion.

Cloud Deploy

Estes são os tipos de recursos do Cloud Deploy:

  • Pipeline de entrega
  • Destino
  • Versão
  • Lançamento
  • Execução do job

Todos os recursos do Cloud Deploy são criados na mesma região em que o pipeline de entrega foi criado.

Se você tiver uma política da organização contra o uso de determinados locais, não será possível criar recursos do Cloud Deploy nessa região (pipeline de entrega, destino, versão ou lançamento).

Para uma lista de locais disponíveis para o serviço Cloud Deploy e seus recursos, consulte Sobre as regiões do Cloud Deploy.

Funções do Cloud Run

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

Para conferir uma lista de regiões disponíveis, consulte Locais das funções do Cloud Run.

API Cloud Healthcare

A política da organização é aplicada quando você cria um recurso dataset. Recursos dataset são regionais ou multirregionais. Recursos de armazenamento de dados, como armazenamento FHIR, ou outros recursos de nível inferior, como mensagens HL7v2, podem ser adicionados a qualquer dataset existente, mesmo se o recurso dataset estiver em um local negado pela organização política. Para garantir que seus recursos estejam em conformidade com a restrição de local de recurso, crie novos dataset recursos após a aplicação da política da organização e migre dados dos antigos dataset recursos para os novos.

Para obter uma lista dos locais disponíveis, consulte Regiões da API Cloud Healthcare.

Cloud Interconnect

Um anexo do Cloud Interconnect pode ser criado em qualquer região. No entanto, não é possível escolher uma zona. A política da organização é aplicada quando você cria o anexo do Cloud Interconnect.

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

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

A política da organização é aplicada quando você cria um endpoint do Cloud IDS, que é um recurso zonal. A conformidade com a política da organização não é aplicada de forma retroativa. Os endpoints atuais vão continuar funcionando mesmo que estejam em locais negados pela política da organização. Para aplicar uma nova restrição de local de recursos em um endpoint do Cloud IDS, exclua a instância e crie-a novamente com a política da organização aplicada.

Para uma lista de locais disponíveis, consulte Produtos disponíveis por local.

Cloud Key Management Service

Os recursos do Cloud KMS podem ser criados em locais regionais, birregionais, multirregionais ou globais. A política da organização será aplicada no momento da criação do recurso.

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

Cloud Logging

A política da organização é aplicada quando você cria novos buckets de registro. É possível criar um novo bucket em qualquer região ou definir o local como global, mas o Logging garante que você selecione uma região aprovada pela organização. A política da organização só é aplicada em buckets de registros recém-criados depois que você cria a política da organização.

Para uma lista de regiões disponíveis, consulte a seção Regionalização da página Visão geral do armazenamento do Cloud Logging.

Cloud NAT

Um gateway do Cloud NAT pode ser criado em qualquer local regional. No entanto, não é possível escolher uma zona para um gateway NAT do Cloud. A política da organização é aplicada quando você cria o gateway do Cloud NAT.

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

Cloud Router

Um Cloud Router pode ser criado em qualquer local regional. No entanto, não é possível escolher uma zona para um Cloud Router. A política da organização é aplicada quando você cria o Cloud Router.

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

Cloud Load Balancing

É possível criar balanceadores de carga usando os seguintes produtos em qualquer local regional:

  • Balanceador de carga de aplicativo externo regional
  • Balanceador de carga de rede de proxy externo regional
  • Balanceador de carga de aplicativo interno regional
  • Balanceador de carga de rede de proxy interno regional
  • Balanceador de carga de rede de passagem externa
  • Balanceador de carga de rede de passagem interna

No entanto, não é possível escolher uma zona para esses balanceadores de carga. A política da organização é aplicada quando você cria o recurso de balanceamento de carga.

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

Google Cloud Armor

Quando você cria uma política de segurança do Google Cloud Armor, a política da organização é aplicada com base na região especificada durante a solicitação de criação. A política não é aplicada a recursos já existentes. Os recursos globais não estão sujeitos à restrição de locais de recursos.

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

Cloud Run

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

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

Cloud Service Mesh

A política da organização é aplicada quando você tenta provisionar o Cloud Service Mesh ou criar cargas de trabalho para a malha. O Cloud Service Mesh não aplica políticas da organização quando as cargas de trabalho são registradas na malha.

Consulte a documentação relevante para suas cargas de trabalho de serviço específicas:

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

Spanner

A política da organização é aplicada quando você cria uma instância, que são recursos regionais ou multirregionais. Se uma instância for bloqueada pela política da organização de localização de recursos, para manter o recurso em conformidade, será preciso excluir a instância. Ainda será possível ler, gravar e criar recursos de banco de dados nas instâncias bloqueadas pela política.

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

Cloud SQL

A política da organização é aplicada quando você cria uma instância, que é um recurso regional que gera um banco de dados zonal, em que as restrições de localização não são aplicadas. Ao criar réplicas de leitura ou clones de banco de dados, insira os novos recursos na mesma região que os originais para que a política da organização de localização de recursos não seja aplicada.

Para ver uma lista de locais disponíveis, consulte a página Locais de instâncias do Cloud SQL.

Cloud Storage

A política da organização é aplicada quando você cria um recurso bucket. Os recursos Bucket são regionais ou multirregionais. Os recursos Object podem ser adicionados a um bucket existente mesmo que o object esteja em um local negado pela política da organização de localização. Para garantir que seus recursos obedeçam a essa política, crie novos buckets após a aplicação dela e depois migre os dados dos buckets antigos para os novos.

Para ver uma lista de locais disponíveis, consulte a página Locais dos intervalos do Cloud Storage.

Cloud Tasks

A política da organização é aplicada quando você cria uma fila. Ela não é aplicada a filas criadas antes da definição da política da organização nem a atualizações dessas filas.

Para uma lista de locais disponíveis, consulte Produtos disponíveis por local.

Limitações

As limitações se aplicam às seguintes regiões:

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

Quando você tem qualquer uma das regiões mencionadas anteriormente na política da organização, é necessário incluir us-central1 e us-central2, mesmo que não esteja criando recursos do Cloud Tasks nessas regiões. É possível incluir a região us-central2 na política da organização, mesmo que ela não use regiões particulares.

Cloud TPU

Os recursos da Cloud TPU (nós e VMs de TPU) são recursos zonais. Isso significa que é preciso selecionar uma zona específica em uma Google Cloud região ao criar um recurso do Cloud TPU.

A disponibilidade de tipos específicos de aceleradores de Cloud TPU (como v3, v4, v5e ou v5p) varia de acordo com 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 da Cloud TPU. Se uma política da organização restringir a implantação na zona escolhida, a criação de recursos de TPU será bloqueada.

Para uma lista de regiões e zonas disponíveis em que o Cloud TPU é compatível, consulte Locais e zonas do Cloud TPU.

Cloud Translation – API Advanced (v3)

Para garantir que seus recursos do Cloud Translation estejam em conformidade com a restrição de local de recurso, especifique um endpoint regional ao criar o recurso. A restrição de localização de recursos é aplicada quando você cria um recurso do Cloud Translation.

Para informações sobre como usar endpoints regionais, consulte Especificar um endpoint regional.

Cloud VPN

Um gateway do Cloud VPN pode ser criado em qualquer local regional. No entanto, não é possível escolher uma zona para um gateway do Cloud VPN. A política da organização é aplicada quando você cria o gateway do Cloud VPN.

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

Cloud Workstations

A política da organização é aplicada quando você cria novos recursos regionais, como clusters, configurações e estações de trabalho. A criação de uma configuração de estação de trabalho pode resultar na criação de discos permanentes e VMs do Compute Engine. Portanto, só é possível criar esses recursos em zonas permitidas pela política da organização.

Para ver uma lista de locais disponíveis, consulte Locais do 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 locais 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 você pode especificar discos regionais ou zonais em um modelo de instância. Esses discos estão sujeitos às restrições dos locais dos recursos; portanto, no modelo da instância, você deve especificar discos nas regiões e zonas permitidas pela política da organização.

Limitações

Todos os recursos do Compute Engine suportam as restrições de local do recurso que você especificar, com as seguintes exceções.

  • Snapshots e imagens

  • Grupos de instâncias gerenciadas

    • Algumas operações do grupo de instâncias gerenciadas (MIG) dependem da criação ou recriação de VMs em zonas permitidas. Essas operações incluem: expansão (manualmente ou por meio de escalonamento automático), recuperação automática, atualização automática e redistribuição proativa de instância. Para que essas operações sejam bem-sucedidas, suas MIGs devem existir em locais permitidos pela restrição de localização de recursos da sua organização.

    • Crie MIGs em locais permitidos. Para MIGs regionais, selecione as zonas que não têm restrição de local.

    • Se você tiver um MIG zonal ou regional preexistente e depois definir uma restrição de local do recurso, as operações do MIG vão falhar se violarem a restrição. Você deve recriar o MIG em um local permitido.

  • Nós de locatário individual

    • Se você tiver um grupo de nós preexistente e depois definir uma restrição de local do recurso, não poderá escalonar horizontalmente o grupo para adicionar novos hosts (manualmente ou por escalonamento automático) se o local do grupo violar a restrição.

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

Controlador de configuração

O Config Controller usa regiões e zonas do Compute Engine. A restrição de localização de recursos é definida no nível do recurso do Compute Engine quando você cria o cluster. Para dimensionar um cluster adicionando mais instâncias, essas novas inclusões também precisam estar em um local permitido.

Para criar clusters com redundância suficiente, use grupos de valores para controlar os locais restritos. Se você definir os locais manualmente, todas as zonas da região precisam estar na lista permitida para ter o mesmo nível de redundância. Os clusters de escalonamento automático podem ser interrompidos se qualquer um dos locais em que o escalonamento acontece não estiver na lista de locais permitidos definidos na política da organização.

Insights de conversação

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

Para ver uma lista de locais disponíveis, consulte a página Locais do Conversational Insights.

Central de atendimento como serviço do Google Cloud

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

Para ver uma lista de locais disponíveis, consulte Locais da central de atendimento como serviço do Google Cloud.

Database Migration Service

A política da organização é aplicada quando você cria um dos seguintes recursos do Database Migration Service:

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

API Data Lineage

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

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

Dataflow

A política da organização é aplicada quando você cria um job. Um job é um recurso regional que usa o Cloud Storage e o Compute Engine. É possível configurar os workers do Compute Engine para executá-los em uma zona fora da região do job especificando o parâmetro da zona. Nesse caso, o plano de controle do Dataflow será executado na região especificada, enquanto os workers de processamento de dados serão executados na zona definida. Se você não especificar a zona dos workers, eles serão criados na região em que o job será executado.

Se você não especificar a zona do job, os workers serão localizados em uma das zonas da região em que o job será executado. O Dataflow selecionará a zona com base na capacidade disponível dela. Todas as zonas na região do job precisam ter os valores permitidos na política da organização de localização de recursos.

Os clusters de escalonamento automático poderão ser interrompidos se um dos locais em que o escalonamento acontece não estiver na lista de locais permitidos da política da organização.

Para ver uma lista de locais disponíveis, consulte a página Endpoints regionais do Dataflow.

Dataform

Os recursos do Dataform são regionais. Quando você cria um repositório do Dataform, ele e todos os recursos filhos são restritos à região especificada na criação do repositório.

Para uma lista de locais disponíveis, consulte Locais do Dataform.

Dataplex Universal Catalog

A política da organização é aplicada quando você cria qualquer um dos seguintes recursos do Dataplex Universal Catalog:

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

Dataproc

Quando você cria um cluster, a política da organização é aplicada com base na região especificada durante a solicitação de criação. O local de um job está vinculado ao local do cluster que é o pai quando o método submit é chamado.

Para ver uma lista de locais disponíveis, consulte a página Endpoints regionais do Dataproc.

Dataproc Metastore

Quando você cria um service, a política da organização é aplicada com base na região especificada durante a solicitação de criação. Os locais de backups e metadataImports estão vinculados ao local do service que é pai quando os métodos importMetadata e backupService são chamados.

Para ver uma lista de locais disponíveis, consulte a página Locais do metastore do Dataproc.

Datastore

Os recursos database do Datastore dependem diretamente do aplicativo do App Engine no projeto pai e do local definido. Desativar o aplicativo do App Engine bloqueará o acesso à API pelo banco de dados associado. Para excluir os dados replicados de locais físicos, remova o projeto conforme descrito na seção do App Engine.

Para ver uma lista de locais disponíveis, consulte a página Locais do Datastore.

Datastream

A política da organização é aplicada quando você cria um dos seguintes recursos do Datastream:

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

Dialogflow

A política da organização é aplicada quando você cria um recurso agent ou location setting no Dialogflow CX. O Dialogflow ES ainda não aplica a política da organização. Os recursos agent e 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 em um local negado pelo política da organização. Para garantir que seus recursos estejam em conformidade com a restrição de local de recurso, crie novos agent recursos após a aplicação da política da organização e migre dados dos antigos agent recursos para os novos.

As restrições de local de recursos não se aplicam ao local global. A criação de recursos é sempre permitida.

Para uma lista de locais disponíveis, consulte a página Locais do Dialogflow.

Document AI

Os recursos do Document AI são regionais. Quando você cria um recurso Processor ou LabelerPool, a política da organização de localização do recurso é aplicada e restringe as regiões em que novos recursos podem ser criados ou armazenados.

A conformidade com a política da organização não é aplicada retroativamente. Novos recursos do Document AI podem ser criados em recursos pai atuais, mesmo que o local do recurso pai seja negado pela política da organização dos locais. Para aplicar uma nova restrição de local a um recurso atual, exclua o recurso e crie-o novamente com a política da organização aplicada.

Para ver uma lista de locais disponíveis, consulte a página Suporte multirregional do Document AI.

Eventarc

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

Se a restrição de locais de recursos for aplicada, somente os gatilhos regionais com regiões que correspondem exatamente às aplicadas à restrição de locais de recursos ou serão incluídos no grupo de valores poderão ser criados. Por exemplo, se us-central1 ou us-locations estiverem na lista de locais permitidos definidos na política da organização, será possível criar um gatilho us-central1.

Para ver uma lista de locais disponíveis, consulte Locais do Eventarc.

Filestore

A política da organização é aplicada quando você 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 atuais vão continuar operando mesmo que estejam em locais negados pela política da organização. Para aplicar uma nova restrição de local de recursos em uma instância do Filestore, exclua a instância e crie-a novamente com a política da organização aplicada.

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

Firestore

Os recursos database do Datastore dependem diretamente do aplicativo do App Engine no projeto pai e do local definido. Desativar o aplicativo do App Engine bloqueará o acesso à API pelo banco de dados associado. Para excluir os dados replicados de locais físicos, remova o projeto conforme descrito na seção do App Engine.

Para ver uma lista de locais disponíveis, consulte a página Locais do Firestore.

Padrão de firewall de última geração do Cloud

Uma política de firewall de rede regional do Cloud NGFW Standard pode ser criada em qualquer local regional. No entanto, não é possível escolher uma zona para uma política de firewall de rede regional padrão do Cloud NGFW. A política da organização é aplicada quando você cria a política de firewall de rede regional padrão do Cloud NGFW.

Para ver uma lista de locais 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 você cria um endpoint do Cloud NGFW Enterprise, que é um recurso zonal. A conformidade com a política da organização não é aplicada de forma retroativa. Os endpoints atuais vão continuar funcionando mesmo que estejam em locais negados pela política da organização. Para aplicar uma nova restrição de local de recursos em um endpoint do Cloud NGFW Enterprise, exclua a instância e crie-a novamente com a política da organização aplicada.

Para uma lista de locais disponíveis, consulte Produtos disponíveis por local.

Proxy seguro da Web

É possível criar um Secure Web Proxy em qualquer local regional. No entanto, não é possível escolher uma zona para um Secure Web Proxy. A política da organização é aplicada quando você cria o Secure Web Proxy.

Para uma lista de locais disponíveis, consulte Produtos disponíveis por local.

Frota

O recurso membership do Cloud Fleet só é compatível com locais regionais em regiões e zonas do Compute Engine. A restrição de localização de recursos é definida no nível do recurso membership quando você registra um cluster. As associações da frota são compatíveis com locais globais e regionais.

Para criar assinaturas com redundância suficiente, use grupos de valores a fim de controlar as regiões restritas. As restrições em locais multirregionais e de zonas não afetam o Fleet membership. No entanto, restrições em grupos de valores que contêm regiões têm efeito. Por exemplo, o valor asia em uma política da organização não tem efeito na associação à frota, mas o valor in:asia-locations tem.

IA generativa na Vertex AI

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

Para uma lista de regiões disponíveis, consulte Locais da IA generativa na Vertex AI.

Limitações

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

  • Vertex AI Studio (UI)

As restrições de local 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

Acompanhe este Rastreador de problemas para saber o progresso mais recente da limitação.

GKE Multi-cloud

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

  • GKE na AWS
  • GKE no Azure
  • Clusters anexados do GKE

Para uma lista de locais disponíveis, consulte as páginas a seguir para cada plataforma de cluster.

Google Cloud Managed Service para Apache Kafka

A política da organização é aplicada quando você cria um cluster no Managed Service para Apache Kafka.

Os clusters do serviço gerenciado para Apache Kafka são recursos regionais. Isso significa que o local do recurso determina a região de destino em que todos os dados são tratados e armazenados.

Para conferir uma lista de locais disponíveis onde é possível criar clusters, consulte Regiões compatíveis.

Google Cloud NetApp Volumes

A política da organização é aplicada quando você cria um pool ou volume 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 pools de armazenamento atuais vão continuar funcionando mesmo que estejam em locais negados pela política da organização. Para aplicar uma nova restrição de local de recursos a um pool ou volume de armazenamento do NetApp Volumes, exclua o recurso e crie-o novamente com a política da organização aplicada.

Para uma lista de locais disponíveis, consulte a página Locais dos volumes da NetApp.

Google Kubernetes Engine

O Google Kubernetes Engine usa regiões e zonas do Compute Engine. A restrição de localização de recursos é definida no nível do recurso do Compute Engine quando você cria a VM em um cluster. Se você quiser dimensionar um cluster adicionando mais instâncias ou outra zona, essas novas inclusões também precisarão estar em um local permitido.

Para criar clusters com redundância suficiente, use grupos de valores a fim de controlar os locais restritos. Se você definir os locais manualmente, todas as zonas da região precisam estar na lista permitida para ter o mesmo nível de redundância. Os clusters de escalonamento automático podem ser interrompidos se qualquer um dos locais em que o escalonamento acontece não estiver na lista de locais permitidos definidos na política da organização.

Infrastructure Manager

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

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

As restrições de local de recursos são aplicadas aos recursos de implantação do Infra Manager e aos recursos Google Cloud compatíveis definidos em HCL.

API Integration Connectors

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

Para uma lista de locais disponíveis, consulte Locais do Integration Connectors.

Looker (Google Cloud Core)

Os recursos do Looker (Google Cloud Core) podem ser criados em locais regionais. A política da organização será aplicada no momento da criação do recurso.

Para conferir uma lista de regiões disponíveis, consulte a página Criar uma instância do Looker (Google Cloud Core).

Serviço gerenciado para Microsoft Active Directory

A política da organização é aplicada quando você cria domínios gerenciados do Microsoft AD ou atualiza os recursos existentes do AD. O Microsoft AD gerenciado exige que o local global seja permitido. Se o local global não for permitido, a criação do domínio e as atualizações de recursos falharão.

Saiba como exibir e atualizar a restrição de local do recurso para global.

Memorystore for Memcached

A política da organização é aplicada quando você cria uma instância. A instância é um recurso regional que cria um ou mais caches zonais, dependendo do número de nós selecionados. Ao adicionar nós usando uma operação de escalonamento vertical, você localiza os novos recursos na mesma região da instância original. A política de organização de local é aplicada durante o escalonamento vertical.

Para conferir uma lista de locais disponíveis, consulte a página Regiões e zonas do Memorystore para Memcached.

Memorystore for Redis

A política da organização é aplicada quando você cria uma instância, A instância é um recurso regional que cria um ou mais caches zonais, dependendo do nível selecionado. As instâncias de nível básico implantam um único cache em uma região e zona especificadas. As instâncias do nível Standard implantam um cache zonal e uma ou mais réplicas de cache zonal localizadas na região da instância. Ao criar réplicas adicionais, coloque os novos recursos na mesma região do cache zonal original. A política da organização de local é aplicada ao criar réplicas adicionais.

Para conferir uma lista de locais 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 você cria uma instância, A instância é um recurso regional que cria um ou mais caches zonais, dependendo do modo de distribuição de zona selecionado. Ao criar réplicas ou fragmentos adicionais, coloque os novos recursos na mesma região do cache zonal original. A política da organização de local é aplicada ao criar réplicas adicionais.

Para ver uma lista de locais disponíveis, consulte a página Locais do cluster do Memorystore para Redis.

Migrate to Virtual Machines

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

Network Connectivity Center

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

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

Network Intelligence Center: testes de conectividade

Os recursos dos Testes de conectividade podem ser criados no local global. A política da organização será aplicada no momento da criação do recurso.

Persistent Disk

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

  • Depois de criar um recurso disk zonal, você pode anexá-lo a instâncias de máquina virtual na mesma zona.
  • Depois de criar um recurso disk, você pode anexá-lo a instâncias de máquina virtual em uma das duas zonas em que disk está armazenado.

A conformidade com a política da organização não é aplicada de forma retroativa. Para aplicar uma nova política da organização de localização de recursos em disk, você precisa excluir os disks e criá-los novamente com a política aplicada ao recurso pai.

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

Pub/Sub

A política da organização de locais de recursos afeta os locais em que as mensagens publicadas em um topic podem ser mantidas em repouso. Ela é aplicada quando você publica mensagens em um topic. O recurso topic ainda é global e pode ser acessado de qualquer lugar do mundo por clientes autorizados.

As mudanças na política da organização não são retroativas e não serão aplicadas ao topics atual. Se uma nova política da organização de locais de recursos negar um local em que as mensagens publicadas em topic já estejam armazenadas, essas mensagens não serão movidas automaticamente.

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

Pub/Sub Lite

A política da organização de locais de recursos afeta os locais em que um topic pode ser criado, o que determina onde as mensagens serão mantidas. Um topic é um recurso zonal, mas as mensagens podem ser solicitadas de qualquer local, inclusive fora do Google Cloud.

As mudanças na política da organização não são retroativas e não serão aplicadas ao topics atual. Se uma nova política da organização de locais de recursos negar um local em que as mensagens publicadas em topic já estejam armazenadas, essas mensagens não serão movidas automaticamente.

Secret Manager

Os secrets podem ter uma política de replicação automática ou uma política de replicação pelo usuário.

Ao usar uma política de replicação automática, os dados do payload são replicados sem restrição. O Gerenciador de secrets exige que o local global seja permitido ao criar um secret com uma política de replicação automática. Se o local global não for permitido, a criação de secret falhará.

Ao usar uma política de replicação gerenciada pelo usuário, os dados de payload são replicados em um conjunto de locais compatíveis definidos pelo usuário. O Secret Manager requer que todos os locais na política de replicação sejam permitidos ao criar um secret com uma política de replicação gerenciada pelo usuário. Se qualquer um dos locais na política de replicação de um secret não for permitido, a criação do secret falhará.

A política da organização será aplicada no momento da criação da chave secreta.

Para mais informações, consulte a página locais do Gerenciador de secrets.

Gerenciador de parâmetros

As restrições de locais de recursos se aplicam a todos os recursos do Gerenciador de parâmetros.

As políticas da organização são aplicadas quando você cria um parâmetro. Os parâmetros atuais não são movidos automaticamente se as restrições de local mudarem.

Para conferir uma lista de locais disponíveis em que é possível criar parâmetros, consulte Locais para recursos do Gerenciador de parâmetros.

Acesso VPC sem servidor

A política da organização é aplicada quando você cria novas instâncias de conector de acesso VPC sem servidor. A política da organização só é aplicada em instâncias de conector de acesso VPC sem servidor recém-criadas em uma região depois que você cria a política da organização.

Para mais informações, consulte as Regiões compatíveis do acesso VPC sem servidor.

Secure Source Manager

A política da organização é aplicada quando você cria novas instâncias do Secure Source Manager. O Secure Source Manager garante que você selecione uma região aprovada pela sua organização. A política da organização só é aplicada em instâncias recém-criadas do Secure Source Manager em uma região depois que você cria a política da organização.

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

Proteção de dados sensíveis

As restrições de locais de recursos se aplicam a todos os recursos da Proteção de dados sensíveis.

As mudanças na política da organização não são retroativas e não serão aplicadas aos recursos atuais.

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

Speaker ID

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

A política da organização de locais de recursos também afeta os locais em que settings pode ser atualizado.

Saiba mais sobre as regiões em que o Voice Match está disponível.

Speech-to-Text

A política da organização de locais de recursos afeta os locais em que qualquer recurso do Speech-to-Text pode ser criado. Ela também afeta os locais em que o recurso config pode ser atualizado.

A Speech-to-Text v1 está disponível nas regiões global, eu e us. Saiba mais sobre as regiões disponíveis para a Speech-to-Text v2.

Serviço de transferência do Cloud Storage

A política da organização é aplicada quando você cria um job do Serviço de transferência do Cloud Storage. A política da organização garante a conformidade ao permitir que os jobs do Serviço de transferência do Cloud Storage sejam criados apenas em regiões permitidas. Se a região do job do serviço de transferência do Cloud Storage estiver fora das restrições da política da organização, o job não será criado.

Para saber como o Serviço de transferência do Cloud Storage escolhe a região em que um job do serviço é executado, consulte Localização dos jobs do Serviço de transferência do Cloud Storage.

API Timeseries Insights

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

A API Timeseries Insights é compatível apenas com locais de região. Uma integração criada em uma região específica só pode acessar os recursos dessa região. As restrições em locais multirregionais e de zonas não afetam a API Timeseries Insights. No entanto, restrições em grupos de valores que contêm regiões têm efeito. Por exemplo, o valor asia em uma política da organização não tem efeito na API Timeseries Insights, mas o valor in:asia-locations tem efeito.

Para conferir uma lista de locais disponíveis em que é possível criar integrações, consulte Regiões compatíveis.

API Transcoder

Os recursos job e jobTemplate são regionais. É possível especificar um local ao criar o recurso. A política da organização é aplicada quando você cria o recurso.

Para conferir uma lista de regiões disponíveis, consulte Locais da API Transcoder.

Vertex AI

As restrições de locais de recursos se aplicam a todos os recursos da Vertex AI, exceto recursos DataLabelingJob.

A Vertex AI é compatível apenas com locais de região. As restrições em locais multirregionais e de zonas não afetam a Vertex AI. No entanto, restrições em grupos de valores que contêm regiões têm efeito. Por exemplo, o valor asia em uma política da organização não tem efeito na IA Platform, 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 locais de recursos se aplicam a todos os recursos da Pesquisa da Vertex AI. A conformidade com a política da organização não é aplicada retroativamente. Isso significa que aplicar uma restrição de locais de recursos não afeta recursos preexistentes nem atualizações desses recursos.

Para uma lista de regiões disponíveis, consulte Locais da Pesquisa da Vertex AI.

Nuvem privada virtual

As redes de nuvem privada virtual (VPC) são redes virtuais globais que contêm sub-redes virtuais regionais (sub-redes). As restrições de local 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 delas. Se você criar uma rede VPC de modo automático, as sub-redes serão criadas apenas nas regiões permitidas pela restrição de local do recurso.

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

Fluxos de trabalho

A política da organização é aplicada quando você cria um fluxo de trabalho do Workflows. A política não é aplicada a recursos já existentes ou a atualizações de recursos existentes. Workflows são recursos regionais e estão sujeitos à restrição de locais de recursos.

Se a restrição de locais de recursos for aplicada, somente os fluxos de trabalho com regiões que correspondem exatamente às aplicadas à restrição de locais de recursos ou incluídas no grupo de valores poderão ser criados. Por exemplo, se us-central1 ou us-locations estiverem na lista de locais permitidos definidos na política da organização, será possível criar um fluxo de trabalho us-central1.

Para uma lista de locais disponíveis, consulte Locais do Workflows.

Gerenciador de cargas de trabalho

A política da organização é aplicada quando você cria um recurso de avaliação ou implantação do Workload Manager. As avaliações e implantações são recursos regionais e estão sujeitas à restrição de locais de recursos.

Para conferir uma lista de locais disponíveis, consulte locais compatíveis.