Visão geral dos endpoints de API regionais e multirregionais

Google Cloud recomenda o uso de endpoints regionais ou multirregionais nos seguintes cenários:

  • Os dados em trânsito precisam permanecer em uma região ou jurisdição específica.
  • Você precisa de evidências de tratamento de dados regionais para fins de compliance ou auditoria.
  • Você precisa de domínios de falha isolados regionalmente para acessar Google Cloud serviços.

Os endpoints regionais e multirregionais oferecem mais benefícios aos clientes que exigem o uso de serviços específicos do local. Esses endpoints também garantem que os dados em trânsito permaneçam em um local específico. Essa localidade de dados é mantida, seja acessada por conectividade particular ou pela Internet pública.

Os endpoints regionais e multirregionais são diferentes do Acesso privado do Google. O Acesso privado do Google permite que as VMs em sub-redes particulares alcancem as APIs do Google sem passar pela Internet. Os endpoints regionais oferecem isolamento regional e residência de dados mais rigorosos, porque todo o caminho da solicitação e o front-end do serviço são regionalizados.

Endpoints regionais

Os endpoints de API regionais fornecem acesso a Google Cloud serviços por um API endpoint com escopo para uma única Google Cloud região. O tráfego enviado a um endpoint regional é processado e encerrado por TLS na região especificada.

Para a maioria dos Google Cloud serviços, é possível usar endpoints regionais para trabalhar com recursos regionais na região especificada. As operações em recursos globais, multirregionais e regionais fora da região normalmente não são compatíveis com o endpoint regional.

Endpoints multirregionais

Os endpoints de API multirregionais fornecem acesso a Google Cloud serviços por um endpoint de API com escopo para um conjunto de Google Cloud regiões no mesmo país, como Estados Unidos, Índia ou Canadá, ou jurisdição, como a União Europeia. O tráfego enviado a um endpoint multirregional é processado e encerrado por TLS totalmente na jurisdição especificada.

Para a maioria dos Google Cloud serviços, é possível usar endpoints multirregionais para trabalhar com recursos multirregionais na multirregião especificada. As operações em recursos globais, regionais e multirregionais de outras jurisdições normalmente não são compatíveis.

Benefícios dos endpoints regionais e multirregionais

O uso de endpoints regionais e multirregionais tem os seguintes benefícios:

  • Residência de dados: ajuda a atender a requisitos rigorosos de residência de dados, mantendo os dados em trânsito na região escolhida. A sessão TLS é sempre encerrada na região especificada.
  • Isolamento regional: reduz as dependências entre regiões, o que diminui os problemas devido a falhas em outras regiões.
  • Conformidade: ajuda você a cumprir os requisitos regulatórios ou os requisitos da política que exigem que os dados sejam tratados e armazenados em limites geográficos específicos.

Limitações dos endpoints regionais e multirregionais

  • Os endpoints regionais e multirregionais não podem ser acessados pelo Acesso privado do Google. Para se conectar a endpoints regionais por acesso particular, use o Private Service Connect para criar endpoints particulares. Para mais informações, consulte Acessar APIs regionais do Google por endpoints particulares.

  • Muitos serviços não oferecem suporte a operações entre regiões de endpoints regionais. Para executar operações entre regiões, use endpoints globais. Se as operações entre regiões permanecerem em uma jurisdição, use endpoints multirregionais.

  • Alguns Google Cloud serviços não oferecem suporte a endpoints regionais ou multirregionais. Para uma lista completa de serviços com suporte, consulte Endpoints de serviço regionais.

  • Os endpoints regionais e multirregionais podem ter latência maior do que os endpoints globais. O desempenho varia de acordo com sua localização e a região que você está usando.

Implementar endpoints regionais e multirregionais

É possível acessar endpoints regionais ou multirregionais de forma particular na VPC por balanceadores de carga regionais. Por exemplo, é possível definir um perímetro do VPC Service Controls para isolar os recursos de nuvem de um determinado projeto da Internet e de redes não autorizadas. Para um determinado perímetro, você decide para quais serviços aplicar o VPC Service Controls e, em seguida, coloca projetos dentro do perímetro. Para mais informações, consulte a seção Usar o VPC Service Controls neste documento.

Acesso público

É possível acessar endpoints regionais e multirregionais publicamente pela Internet. Quando você acessa endpoints regionais pela Internet, o tráfego é roteado pela Google Cloud rede do nível Standard. A conexão, incluindo término de TLS, é processada na região de destino.

Para mais informações, consulte Acessar APIs regionais do Google por endpoints públicos.

Acesso particular

Para acesso particular a endpoints regionais e multirregionais, use o Private Service Connect. O Private Service Connect cria um endereço IP particular na sua nuvem privada virtual (VPC). O endereço IP particular é roteado para o serviço regional. Embora as APIs globais geralmente usem o Acesso privado do Google padrão usando intervalos especiais, como private.googleapis.com, os endpoints regionais e multirregionais exigem configuração explícita de endpoint particular.

Para mais informações, consulte Acessar APIs regionais do Google por endpoints particulares.

Configurar roteamento e firewalls

Siga estas diretrizes para configurar corretamente o roteamento e os firewalls.

Roteamento local

Se você se conectar a endpoints regionais de ambientes locais pelo Cloud Interconnect ou pelo Cloud VPN, será necessário anunciar os intervalos de IP particulares do endpoint regional. Essa configuração garante o roteamento adequado da sua rede local para os Google Cloud serviços.

  • Cloud Router: use divulgações de rotas personalizadas para anunciar todos os intervalos de IP particulares na conexão híbrida.
  • Firewalls locais: configure seus firewalls locais para permitir o tráfego de saída para os intervalos de endereços IP virtuais públicos ou particulares dos endpoints regionais. Para mais informações, consulte Usar regras de firewall da VPC.

Regras de firewall da VPC

Configure as políticas de firewall de saída para permitir o tráfego para os endereços IP particulares dos endpoints regionais. Se você remover as rotas padrão, verifique se as rotas adequadas estão em vigor para os intervalos de endereços IP virtuais (VIPs) do endpoint regional:

  • Para acesso público ao VIP, verifique se há rotas para os intervalos de VIP dos endpoints regionais com o próximo salto definido como o gateway de Internet padrão.

  • Para o Private Service Connect, use endereços IP ou roteamento interno padrão.

Para mais informações, consulte Configurar uma política de firewall hierárquica para permitir o tráfego de saída de uma rede VPC específica.

Usar o VPC Service Controls

Os endpoints regionais são compatíveis com os perímetros do VPC Service Controls. Para mais informações sobre o VPC Service Controls, consulte Detalhes e configuração do perímetro de serviço.

O VPC Service Controls ajuda a evitar a exfiltração de dados de Google Cloud serviços criando perímetros de segurança. Como não é possível acessar endpoints regionais pelo Acesso privado do Google, para acessar os endpoints em um perímetro da VPC, é necessário usar o Private Service Connect para configurar endpoints particulares.

  • Aplicação de perímetro: quando você adiciona um serviço, como storage.googleapis.com, à lista de Serviços restritos no perímetro do VPC Service Controls, as regras do VPC Service Controls são aplicadas a todos os métodos de acesso desse serviço, incluindo o acesso por endpoints regionais.

  • Verificações de controle de serviço:as solicitações de API para endpoints regionais, públicos ou particulares, estão sujeitas a verificações de política pela API Service Control. A API Service Control avalia a solicitação em relação à configuração do perímetro do VPC Service Controls e analisa a rede de origem, o projeto de origem e o projeto de recurso de destino.

  • Dentro do perímetro:os recursos em um perímetro do VPC Service Controls, como VMs, podem acessar serviços por endpoints regionais se o serviço fizer parte dos serviços acessíveis do perímetro. O endpoint de rede precisa estar dentro do perímetro da VPC, o que exige a criação de endpoints regionais particulares usando o Private Service Connect. Para mais informações, consulte Acessar APIs regionais do Google por endpoints particulares.

  • Fora do perímetro:as tentativas de acessar recursos protegidos dentro do perímetro de fora do perímetro usando qualquer tipo de endpoint são bloqueadas pelo VPC Service Controls, a menos que os níveis de acesso ou as regras de entrada e saída permitam explicitamente o acesso.

Por exemplo, você define um perímetro do VPC Service Controls para aplicar uma política aos recursos do Cloud Storage e, em seguida, coloca secure_project dentro do perímetro. Somente as VMs de secure_project podem acessar os recursos do Cloud Storage de secure_project. Além disso, as VMs são impedidas de acessar recursos do Cloud Storage fora do perímetro.

Benefícios do VPC Service Controls

O uso do VPC Service Controls oferece os seguintes benefícios:

  • Você tem os benefícios do isolamento regional e da residência de dados, além da proteção contra exfiltração de dados do VPC Service Controls.

  • Com o VPC Service Controls, o acesso com escopo para uma única região também é regido pelos limites de segurança dos perímetros do VPC Service Controls.

Configurar o VPC Service Controls

Em um perímetro do VPC Service Controls, é necessário acessar endpoints regionais particulares usando o Private Service Connect de dentro de um perímetro da VPC. Para mais informações, consulte Acessar APIs regionais do Google por endpoints particulares.

  • O acesso padrão ao endpoint regional público pode ser bloqueado, porque parece se originar de fora do perímetro.

  • Verifique se o serviço que você está acessando, como compute.googleapis.com ou bigquery.googleapis.com, está incluído na lista de serviços restritos pelo perímetro.

Usar políticas da organização para aplicação adicional

As políticas da organização fornecem controles adicionais para os recursos de nuvem da organização. As duas políticas a seguir funcionam com endpoints regionais para aplicar a residência de dados e melhorar o isolamento regional:

Aplicar o uso de endpoints regionais

Para aplicar o uso de endpoints regionais, use a restrição de política da organização Restringir o uso de endpoints para negar o acesso a endpoints globais. Para mais informações, consulte Restringir o uso de endpoints.

Os endpoints regionais garantem que os dados em trânsito permaneçam em uma região, e a restrição Restringir o uso de endpoints garante que os recursos usados para armazenar dados em repouso sejam criados apenas nas regiões permitidas. O uso de ambas as políticas oferece proteções mais abrangentes de residência de dados para dados em repouso e para dados em trânsito.

A restrição Restringir o uso de endpoints é definida usando uma lista de bloqueio, permitindo solicitações para endpoints de API de serviços com suporte que não são explicitamente negados. Depois de configurar endpoints regionais, os endpoints globais ainda poderão ser acessados, a menos que você use a restrição de política da organização Restringir o uso de endpoints.

A restrição Restringir o uso de endpoints controla os locais físicos em que os usuários podem criar e armazenar novos Google Cloud recursos, aplicando a residência de dados em repouso. Essa política se aplica apenas à criação de novos recursos para serviços com suporte. Os recursos atuais não serão afetados.

Aplicar restrições de local

A política de restrição de locais de recursos (constraints/gcp.resourceLocations) controla os locais físicos em que novos Google Cloud recursos podem ser criados e armazenados, o que aborda a residência de dados em repouso. Para mais informações, consulte Definir a política da organização na documentação do Resource Manager.

Ao usar a política de restrição de locais de recursos, você define uma lista de locais permitidos ou negados Google Cloud . Para os locais, é possível usar regiões, zonas ou multirregiões. A política se aplica apenas à criação de novos recursos para serviços com suporte. Os recursos atuais não serão afetados.

O uso dessa política com endpoints regionais é benéfico, porque os endpoints regionais garantem que os dados em trânsito permaneçam em uma região, e a política de restrição de local garante que os recursos que armazenam os dados sejam criados apenas nas regiões permitidas.

Aplicação combinada

Ao usar a política Restringir o uso de endpoints para negar endpoints globais e a política de restrição de locais de recursos para restringir os locais em que os recursos podem ser criados, você aplica dados em repouso e dados em trânsito.

  • Dados em repouso: os recursos são criados e armazenados apenas nas regiões permitidas.
  • Dados em trânsito: as interações de API com esses recursos são processadas totalmente na região especificada ao usar o endpoint regional correspondente.

Preços

Para endpoints regionais particulares, os preços são baseados no uso do Private Service Connect. As cobranças de faturamento incluem o endpoint e o tratamento de dados.

Para endpoints regionais públicos, o tráfego de entrada não é cobrado. O tráfego de saída é cobrado com base nos preços de rede do nível Standard.

Documentação de referência

A seguir