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.

AI Platform

As restrições de locais de recursos se aplicam aos seguintes recursos da AI Platform:

Os recursos de treinamento e previsão da IA Platform são compatíveis apenas com os locais da região. As restrições nos locais de várias regiões e nas zonas não têm efeito na IA Platform. 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 regiões disponíveis para o treinamento da AI Platform e regiões disponíveis para a previsão da AI Platform.

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 poderão 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.

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 falharão se violarem a restrição. Você deve recriar o MIG em um local permitido.

  • Nós de locatário único

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

    • Você pode criar um gateway de VPN de alta disponibilidade em qualquer local. Os gateways de VPN de alta disponibilidade não são restritos por restrições de localização de recursos.

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

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.

Cloud Bigtable

Um recurso de instância do Cloud 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 Cloud Bigtable.

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.

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

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.

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 disk atual, exclua o disk 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.

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.

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.

Pub/Sub

A política da organização de localização 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 alterações na política da organização não são aplicadas automaticamente a topics existentes. 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.

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

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.