Visão geral de grupos de endpoints de rede da Internet

O Cloud Load Balancing é compatível com o proxy de tráfego para back-ends externos fora do Google Cloud. Para definir um back-end externo para um balanceador de carga, use um recurso chamado de grupo de endpoints de rede (NEG, na sigla em inglês) da Internet.

Use esse tipo de implantação quando quiser exibir conteúdo de um back-end externo, mas quiser que o balanceador de carga do Google Cloud seja o front-end. Isso permite que você faça o seguinte:

Usar a infraestrutura do Google Edge para encerrar conexões de usuário.
Direcionar as conexões para o back-end externo.
Com balanceadores de carga globais, é possível usar o Cloud CDN para armazenar conteúdo em cache do seu back-end externo.
Enviar tráfego para o endpoint público por meio do backbone privado do Google, o que aumenta a confiabilidade e pode diminuir a latência entre o cliente e o servidor.

A Figura 1 mostra um balanceador de carga de aplicativo externo com vários tipos de back-end, em que um deles é um back-end externo configurado com um NEG da Internet.

Grupos de endpoints de rede da Internet no balanceamento de carga. — **Figura 1.** Grupos de endpoints de rede da Internet no balanceamento de carga (clique para ampliar).

Os back-ends de NEG da Internet são compatíveis com vários balanceadores de carga regionais e globais. Dependendo do seu balanceador de carga (global ou regional), a compatibilidade com NEG da Internet varia em relação a DNS, verificação de integridade, número de endpoints disponíveis e comportamentos de roteamento de tráfego.

Nas seções a seguir, explicamos como os back-ends externos são usados com o Cloud Load Balancing. Se você quiser usar um back-end externo com o Traffic Director, consulte Traffic Director com grupos de endpoints de rede da Internet.

Terminologia

Às vezes, os termos a seguir são usados de maneira intercambiável porque têm significados iguais ou semelhantes:

Back-end externo: um back-end que reside fora do Google Cloud e pode ser acessado pela Internet. O endpoint em um NEG da Internet.
Origem personalizada: igual a um back-end externo. Na CDN, origem é o termo padrão do setor para uma instância de back-end que exibe conteúdo da web.
Grupo de endpoints da rede na Internet (NEG): o recurso da API Google Cloud usado para especificar um back-end externo.
Endpoint externo: igual a um back-end externo.

Este documento usa o termo back-end externo, exceto ao se referir ao recurso de API do NEG da Internet.

Componentes do balanceador de carga

Nesta seção, descrevemos a arquitetura de balanceamento de carga e os recursos necessários para configurar um balanceador de carga com um back-end externo. O balanceador de carga requer uma configuração especial apenas para o serviço de back-end. A configuração do front-end é a mesma que qualquer outro balanceador de carga.

As figuras a seguir mostram os recursos do Google Cloud necessários para configurar um balanceador de carga com um back-end externo.

Global externo

Esta figura mostra os recursos do Google Cloud necessários para configurar um balanceador de carga de aplicativo externo global com um back-end externo.

Balanceador de carga de aplicativo externo global com back-end externo. — Balanceador de carga de aplicativo externo global com back-end externo (clique para ampliar).

Regional externo

Esta figura mostra os recursos do Google Cloud necessários para configurar um balanceador de carga de aplicativo externo regional com um back-end externo.

Balanceador de carga de aplicativo externo regional com um back-end externo. — Balanceador de carga de aplicativo externo regional com um back-end externo (clique para ampliar).

Esta figura mostra os recursos do Google Cloud necessários para configurar um balanceador de carga de rede de proxy externo regional com um back-end externo.

Balanceador de carga de rede de proxy externo regional com um back-end externo. — Balanceador de carga de rede de proxy externo regional com um back-end externo (clique para ampliar).

Regional interno

Esta figura mostra os recursos do Google Cloud necessários para configurar um balanceador de carga de aplicativo interno regional com um back-end externo.

Balanceador de carga de aplicativo interno regional com um back-end externo. — Balanceador de carga de aplicativo interno regional com um back-end externo (clique para ampliar).

Esta figura mostra os recursos do Google Cloud necessários para configurar um balanceador de carga de rede de proxy interno regional com um back-end externo.

Balanceador de carga de rede de proxy interno regional com um back-end externo. — Balanceador de carga de rede interno regional com um back-end externo (clique para ampliar).

Só é possível usar NEGs da Internet no nível de serviço de rede Premium.

Configuração de front-end

Nenhuma configuração de front-end especial é necessária para criar um balanceador de carga com um back-end de NEG da Internet. Regras de encaminhamento são usadas para rotear o tráfego por endereço IP, porta e protocolo para um proxy de destino. O proxy de destino encerra as conexões dos clientes. Além disso, balanceadores de carga baseados no Envoy exigem uma sub-rede somente proxy.

Os balanceadores de carga de aplicativo também usam mapas de URL para configurar o roteamento baseado em URL de solicitações aos serviços de back-end apropriados.

Para mais detalhes sobre cada um desses componentes, consulte as seções de arquitetura do respectivo balanceador de carga:

NEG da Internet

Um NEG da Internet é um recurso usado para definir um back-end externo para o balanceador de carga. O back-end externo referenciado pelo NEG da Internet precisa ser acessível pela Internet. O endpoint não pode ser acessado apenas pelo Cloud VPN ou Cloud Interconnect. Se o back-end externo se referir a um serviço ou uma API do Google, o serviço precisará ser acessível pela porta TCP 80 ou 443 usando o protocolo HTTP, HTTPS ou HTTP/2.

Há duas maneiras de configurar o endpoint externo referenciado pelo NEG: INTERNET_FQDN_PORT ou INTERNET_IP_PORT. Além disso, cada um desses endpoints está disponível em dois escopos: global ou regional.

Use a tabela a seguir para analisar as diferenças entre os dois tipos de endpoints e como eles se comportam nos escopos global e regional.

Balanceadores de carga	Tipo de endpoint	Definição do endpoint	Escopo	Verificações de integridade
Balanceador de carga de aplicativo externo global Balanceador de carga de aplicativo clássico	`INTERNET_FQDN_PORT`	Um nome de domínio totalmente qualificado que pode ser resolvido publicamente e uma porta opcional. Por exemplo, `backend.example.com:443`¹. O nome de domínio precisa ser resolvido pela infraestrutura pública de DNS do Google. Só é permitido um endpoint por NEG.	Global	Sem suporte
	`INTERNET_IP_PORT`	Um endereço IP roteável publicamente e uma porta opcional. Por exemplo, `8.8.8.8:443`¹. O endereço IP não pode ser RFC 1918. Só é permitido um endpoint por NEG.	Global	Sem suporte
Balanceador de carga de aplicativo externo regional Balanceador de carga de aplicativo interno regional Balanceador de carga de rede de proxy externo regional Balanceador de carga de rede de proxy interno regional	`INTERNET_FQDN_PORT`	Um nome de domínio totalmente qualificado que pode ser resolvido publicamente e uma porta opcional. Por exemplo, `backend.example.com:443`². O nome de domínio precisa ser resolvido pelo Cloud DNS ou pela infraestrutura pública de DNS do Google. São permitidos no máximo 256 endpoints por NEG.	Regional	Verificações de integridade distribuídas do Envoy
	`INTERNET_IP_PORT`	Um endereço IP roteável publicamente e uma porta opcional. Por exemplo, `8.8.8.8:443`². O endereço IP não pode ser RFC 1918. São permitidos no máximo 256 endpoints por NEG.	Regional	Verificações de integridade distribuídas do Envoy

¹ Se você não especificar uma porta ao adicionar o endpoint, a porta padrão do NEG será usada. Se você não especificou uma porta padrão para o NEG, será usada a porta conhecida do protocolo de back-end (80 para HTTP e 443 para HTTPS e HTTP/2).

² Com NEGs da Internet regionais, é necessário especificar uma porta. É possível especificar uma porta padrão ao criar o NEG, especificar uma porta sempre que adicionar um endpoint ao NEG ou realizar as duas ações. Se você não especificar uma porta ao adicionar um endpoint, a porta padrão do NEG será usada.

Resolução DNS para endpoints regionais `INTERNET_FQDN_PORT`

Se seu domínio puder ser resolvido pela Internet, nenhuma outra configuração precisará ser definida no DNS. No entanto, se você estiver resolvendo FQDNs particulares, será necessário configurar o Cloud DNS para facilitar a resolução de DNS. O nome precisa estar hospedado no Cloud DNS ou ser resolvido via encaminhamento de DNS do Cloud DNS para um DNS local.

Comece criando uma zona do Cloud DNS para hospedar os registros DNS no seu projeto. Em seguida, adicione os registros DNS a ele. Para ver etapas específicas de configuração, consulte a documentação do Cloud DNS.

Se você estiver usando a VPC compartilhada, observe os requisitos de rede específicos. Também é possível usar outros recursos do Cloud DNS, como as zonas de encaminhamento, para buscar registros de um servidor DNS local.

Resolução de endereços IP para endpoints globais `INTERNET_FQDN_PORT`

Quando um endpoint INTERNET_FQDN_PORT aponta para um registro DNS que retorna vários endereços IP, o endereço IP é resolvido da seguinte forma:

O balanceador de carga usa um resolvedor de DNS em uma região do Google Cloud mais próxima do cliente na Internet. Se o registro DNS do endpoint INTERNET_FQDN_PORT retornar endereços IP diferentes com base na localização do cliente, verifique se cada um deles pode ser acessado pelo balanceador de carga.
O balanceador de carga tenta se conectar ao primeiro endereço IP na resposta DNS. Se esse endereço IP não estiver acessível, o balanceador de carga retornará uma resposta HTTP 502 (Bad Gateway). Isso ocorre mesmo que outros endereços IP da resposta DNS estejam disponíveis.

Para mais informações sobre os locais e intervalos de IP usados pela infraestrutura do resolvedor de DNS do Google, consulte a documentação do DNS público do Google. Nomes que não podem ser resolvidos pelo sistema DNS público não são utilizáveis como back-ends externos.

Resolução de endereços IP para endpoints regionais `INTERNET_FQDN_PORT`

Os NEGs regionais da Internet são compatíveis com a resolução de nome de domínio usando o Cloud DNS e o DNS público do Google. No caso de servidores DNS públicos, o Cloud DNS encaminha o tráfego para servidores DNS públicos.

Se o servidor DNS retornar vários endereços IP, o Envoy fará o balanceamento de carga do tráfego entre os endereços IP retornados com base no algoritmo de balanceamento de carga configurado (round-robin, solicitação mínima e assim por diante). A lista de endpoints é atualizada periodicamente com base no TTL do DNS. É possível configurar políticas de nova tentativa para forçar o Envoy a tentar se conectar a outro endereço IP se um deles falhar.

Serviço de back-end

Os serviços de back-end fornecem informações de configuração ao balanceador de carga. Os balanceadores de carga usam as informações de um serviço de back-end para direcionar o tráfego de entrada para um ou mais back-ends anexados.

Para configurar um balanceador de carga com um back-end externo, configure o serviço de back-end com um back-end de NEG da Internet. Quando você adiciona um NEG da Internet a um serviço de back-end, as seguintes considerações se aplicam, dependendo do escopo do NEG:

O serviço de back-end também não pode usar outros tipos de back-end (como NEGs zonais ou grupos de instâncias) como back-ends.
Número de NEGs por serviço de back-end
- NEGs globais. Só é possível adicionar um back-end de NEG da Internet a um serviço de back-end.
- NEGs regionais. É possível adicionar até 50 NEGs da Internet ao mesmo serviço de back-end.
Número de endpoints por NEG
- NEGs globais. Apenas um endpoint pode ser adicionado a um NEG da Internet.
Como é permitido apenas um endpoint em cada NEG global da Internet, o balanceamento de carga não é realmente realizado. O balanceador de carga serve apenas como front-end e faz o proxy do tráfego para o back-end externo especificado. Isso significa que não é possível usar nenhum dos modos de balanceamento de carga, como taxa, conexão ou utilização.
- NEGs regionais. É possível adicionar até 256 endpoints por NEG ao mesmo serviço de back-end.
Os NEGs regionais não são compatíveis com modos de balanceamento de carga, como taxa, conexão ou utilização. Todos os endpoints de todos os NEGs anexados a um serviço de back-end são agrupados em um único pool. O balanceamento de carga do tráfego entre esse pool de endpoints é processado usando algoritmos de balanceamento de carga do Envoy. Para saber os algoritmos da política de balanceamento de carga compatíveis, consulte localityLbPolicy na documentação da API do serviço de back-end regional.
Verificações de integridade
- NEGs globais. O serviço de back-end não pode se referir a uma verificação de integridade.
- NEGs regionais. O balanceador de carga usa verificações de integridade distribuídas do Envoy.
O esquema de balanceamento de carga do serviço de back-end precisa corresponder ao esquema necessário ao balanceador de carga que você está implantando. Para ver a lista completa, consulte Serviços de back-end.
O protocolo do serviço de back-end precisa ser HTTP, HTTPS ou HTTP2.

É altamente recomendável usar HTTPS ou HTTP/2 como protocolo ao configurar um serviço de back-end com um NEG da Internet para que a comunicação entre o balanceador de carga e o back-end seja criptografada e autenticada durante s transição para Internet pública.

Além disso, ao usar HTTPS ou HTTP/2 como protocolo de back-end, use um endpoint INTERNET_FQDN_PORT para criar o back-end externo. Você terá estas duas vantagens:
- Isso garante que o balanceador de carga valide o certificado do servidor SSL apresentado pelo back-end externo e verifique se as seguintes informações são verdadeiras:
  - O certificado é assinado por autoridades de certificação (CAs, na sigla em inglês) conhecidas.
  - o certificado não expirou;
  - a assinatura do certificado é válida;
  - O FQDN configurado corresponde a um dos nomes alternativos para o requerente (SANs) no certificado.
  Se você criar o back-end externo usando um endpoint INTERNET_IP_PORT, a validação do certificado do servidor SSL não será executada.
- A extensão de indicação de nome do servidor (SNI, na sigla em inglês) SSL é compatível apenas com endpoints INTERNET_FQDN_PORT. O FQDN configurado recebe um SNI no client hello durante o handshake de SSL entre o balanceador de carga e o endpoint externo. A SNI não é enviada quando você usa um endpoint INTERNET_IP_PORT porque os literais de endereço IP não são permitidos no campo HostName de um payload de SNI.

Verificações de integridade

A configuração da verificação de integridade varia de acordo com o tipo de balanceador de carga:

Balanceador de carga de aplicativo externo global e balanceador de carga de aplicativo clássico. Um serviço de back-end com um NEG global da Internet não é compatível com verificações de integridade.

Se o back-end externo ficar inacessível ou o nome do host configurado (FQDN, na sigla em inglês) não puder ser resolvido, o balanceador de carga retornará uma resposta HTTP 502 (Bad Gateway) aos clientes.

Balanceador de carga de aplicativo externo regional, balanceador de carga de aplicativo interno regional, balanceador de carga de rede de proxy externo regional e balanceador de carga de rede de proxy interno regional. As verificações de integridade são opcionais. As sondagens da verificação de integridade nesses balanceadores de carga são provenientes da sub-rede somente proxy e, em seguida, são convertidas por NAT (usando o Cloud NAT) para endereços IP pré-reservados ou endereços IP NAT alocados automaticamente. Para detalhes, consulte NEGs regionais: usar um gateway do Cloud NAT.
As verificações de integridade do Envoy distribuídas são criadas usando os mesmos processos do console do Google Cloud, da CLI gcloud e da API que as verificações de integridade centralizadas. Nenhuma outra configuração é necessária.

Observações:
- As verificações de integridade do gRPC não são suportadas.
- As verificações de integridade com o protocolo PROXY v1 ativado não são suportadas.
- Como o plano de dados do Envoy processa verificações de integridade, não é possível usar o console do Google Cloud, a API ou a CLI gcloud para verificar o status de integridade desses endpoints externos. Nos NEGs híbridos com balanceadores de carga baseados no Envoy, o console do Google Cloud mostra o status da verificação de integridade como N/A. Isso já era esperado.
- Cada proxy Envoy atribuído à sub-rede somente proxy da região na rede VPC inicia verificações de integridade de maneira independente. Portanto, talvez você perceba um aumento no tráfego de rede devido a uma verificação de integridade. O aumento depende do número de proxies Envoy atribuídos à sua rede VPC em uma região, da quantidade de tráfego recebida por esses proxies e do número de endpoints que cada proxy Envoy precisa verificar. Na pior das hipóteses, o tráfego de rede aumenta a uma taxa quadrática (O(n^2)) devido às verificações.
- Os registros das verificações de integridade distribuídas do Envoy não incluem estados de integridade detalhados. Para detalhes sobre o que é registrado, consulte Geração de registros de verificação de integridade. Para uma melhor resolução de problemas de conectividade via proxies do Envoy com os endpoints do NEG, verifique também os respectivos registros do balanceador de carga.

Ativar o back-end externo para receber solicitações

O tráfego de balanceadores de carga que usam NEGs regionais da Internet é proveniente da sub-rede somente proxy e, em seguida, é convertido por NAT (usando o Cloud NAT) para endereços IP NAT pré-reservados ou alocados automaticamente. Isso inclui sondagens de verificação de integridade e solicitações de usuários do balanceador de carga aos back-ends.

A configuração do seu back-end externo para permitir o tráfego do Google Cloud depende do escopo do NEG: global ou regional.

NEGs globais: lista de permissões de endereços IP de saída padrão do Google

Se você estiver usando um NEG global da Internet, será necessário colocar na lista de permissões os intervalos de endereços IP que o Google usa para enviar solicitações a back-ends externos. Para procurar os endereços IP que serão incluídos na lista de permissões, consulte o registro TXT do DNS _cloud-eoips.googleusercontent.com usando uma ferramenta como dig ou nslookup.

Por exemplo, consulte Permitir que o back-end externo receba tráfego do Google Cloud.

NEGs regionais: usar um gateway do Cloud NAT

Se você estiver usando um NEG regional da Internet, primeiro configure um gateway do Cloud NAT para alocar um conjunto de intervalos de endereços IP que originará o tráfego do Google Cloud.

O endpoint do gateway precisa ser do tipo ENDPOINT_TYPE_MANAGED_PROXY_LB.

O gateway do Cloud NAT pode ser configurado para alocar dinamicamente endereços IP externos com base na demanda ou usar um conjunto de endereços IP externos pré-reservados manualmente.

Endereços IP alocados automaticamente

Use endereços IP alocados automaticamente se o ambiente de back-end externo não precisar de uma lista de permissões de endereços IP específicos do Google Cloud que podem enviar tráfego ao back-end externo.
Endereços IP alocados manualmente

Use endereços IP alocados manualmente apenas se o ambiente de back-end externo precisar de uma lista de permissões de endereços IP específicos do Google Cloud. Como cada Envoy atribuído à sub-rede do proxy consome um endereço IP inteiro. Verifique se o pool de endereços IP reservados é grande o suficiente para acomodar todos os Envoy.

Aviso: se você provisionar menos endereços IP NAT do que o número de proxies Envoy atribuídos, as solicitações enviadas ao NEG da Internet poderão resultar em erros HTTP 5xx. Para receber informações sobre quando esse evento ocorrer, configure um alerta para a métrica nat_allocation_failed. Entre em contato com o suporte se precisar de ajuda para calcular o número de endereços IP que precisam ser alocados para o balanceador de carga em uma região específica.

Se você tiver problemas de conectividade em escala, verifique se atingiu os limites do Cloud NAT. Por padrão, o limite é de 50 endereços IP NAT alocados manualmente por gateway.

Essa configuração do Cloud NAT se aplica a toda a sub-rede somente proxy. O tráfego da Internet associado a todos os balanceadores de carga baseados no Envoy na região compartilha o mesmo gateway NAT.

O uso do Cloud NAT gera cobranças pelo tráfego do usuário e pelo tráfego da verificação de integridade. Para detalhes sobre como funcionam os preços de NEG regional da Internet, consulte este link.

Há algumas limitações para gateways NAT configurados em sub-redes somente proxy:

Apenas a conversão NAT um para um é realizada. O compartilhamento de endereços IP não é compatível.
A geração de registros e o monitoramento não são compatíveis. Ou seja, as flags --enable-logging e --log-filter não são compatíveis.
Recursos relacionados a portas, como alocação de portas estáticas e dinâmicas, configuração de portas máximas e mínimas por VM e mapeamento independente de endpoint, não são compatíveis. Cada proxy recebe todas as 65.536 portas.

Autenticar solicitações para o back-end externo

Esta seção se aplica somente aos balanceadores de carga de aplicativo.

Para autenticar as solicitações enviadas ao seu back-end externo, siga um destes procedimentos:

Defina um cabeçalho personalizado para indicar que a solicitação veio de um balanceador de carga de aplicativo do Google Cloud usando um cabeçalho de solicitação personalizado. Por exemplo, é possível usar 16 ou mais bytes criptograficamente aleatórios como uma chave compartilhada.

A implementação de transformações de cabeçalho personalizado depende do tipo de balanceador de carga em uso:
- Balanceador de carga de aplicativo externo global e balanceador de carga de aplicativo clássico. As transformações de cabeçalho personalizadas podem ser configuradas no serviço de back-end ou no mapa de URL.
  
  Por exemplo, é possível configurar o back-end externo para que espere um valor específico para o cabeçalho Host da solicitação HTTP e configurar o balanceador de carga para que defina o cabeçalho Host com esse valor esperado. Se você não configurar um cabeçalho de solicitação personalizado, o balanceador de carga preservará os cabeçalhos usados pelo cliente para se conectar ao balanceador de carga e incluirá o mesmo cabeçalho na resposta. No entanto, lembre-se que modificar o cabeçalho Host não é possível no mapa de URL.
  
  Há outras limitações associadas à configuração do cabeçalho Host. Para detalhes, consulte Criar cabeçalhos personalizados em serviços de back-end. Para um exemplo específico, consulte Configurar um balanceador de carga de aplicativo externo global com um back-end externo.
- Balanceador de carga de aplicativo externo regional e balanceador de carga de aplicativo interno regional. As transformações de cabeçalhos personalizados só podem ser configuradas no mapa de URL.
  
  Para esses balanceadores de carga baseados no Envoy, Host e authority são palavras-chave especiais reservadas pelo Google Cloud. Não é possível modificar esses cabeçalhos nesses balanceadores de carga. Em vez disso, recomendamos que você crie outros cabeçalhos personalizados (por exemplo, MyHost) para que não interfira nos nomes de cabeçalho reservados.
Ative o IAP e verifique se o JWT assinado no cabeçalho da solicitação foi assinado pelo Google e se a declaração (público-alvo) aud contém o número do projeto em que o balanceador de carga está definido.

O IAP não é compatível com o Cloud CDN. O IAP não é compatível com balanceadores de carga de aplicativo externos regionais e balanceadores de carga de rede de proxy (internos e externos).
Ative a autenticação de origem particular, que fornece a um balanceador de carga de aplicativo externo acesso de longo prazo a um bucket particular do Amazon Simple Storage Service (Amazon S3) ou a outros armazenamentos de objetos compatíveis. O Cloud CDN (e, portanto, a autenticação de origem particular) não é compatível com balanceadores de carga de aplicativo externos regionais e balanceadores de carga de aplicativo internos regionais.

Registros

As solicitações encaminhadas por proxy para um back-end externo são registradas no Cloud Logging da mesma forma que as solicitações de outros back-ends.

Para ver mais informações, consulte os seguintes tópicos:

Se você ativar o Cloud CDN para um balanceador de carga de aplicativo externo usando um back-end externo, as ocorrências em cache também serão registradas.

Processamento de cabeçalho com back-ends externos

Balanceadores de carga de aplicativo externos globais e Balanceadores de carga de aplicativo clássicos

Quando um balanceador de carga de aplicativo global ou clássico envia solicitações por proxy a um back-end externo, ele ajusta os cabeçalhos HTTP das seguintes maneiras:

Alguns cabeçalhos são agrupados. Quando houver várias instâncias da mesma chave de cabeçalho (por exemplo, Via), o balanceador de carga combinará os valores delas em uma lista separada por vírgulas para uma chave de cabeçalho. Serão agrupados somente cabeçalhos com valores que possam ser representados como uma lista separada por vírgulas. Outros cabeçalhos, como Set-Cookie, nunca são agrupados.
Os cabeçalhos têm a primeira letra de cada palavra exibida em maiúscula quando o protocolo do serviço de back-end é HTTP ou HTTPS:
- A primeira letra da chave do cabeçalho e todas as letras após um hífen (-) são exibidas em maiúsculas para preservar a compatibilidade com clientes HTTP/1.1. Por exemplo, user-agent é alterado para User-Agent e content-encoding é alterado para Content-Encoding.
- Alguns cabeçalhos, como Accept-CH (dicas de cliente), são convertidos para corresponder à representação padrão de letras mistas.
Alguns cabeçalhos são adicionados ou têm valores anexados a eles. Os balanceadores de carga de aplicativo externos sempre adicionam ou modificam determinados cabeçalhos, como Via e X-Forwarded-For.

Balanceadores de carga de aplicativo externos regionais e balanceadores de carga de aplicativo internos regionais

Não há processamento de cabeçalhos especiais para balanceadores de carga baseados no Envoy usando NEGs da Internet. Para saber como o Envoy normalmente processa cabeçalhos, consulte Manipulação de cabeçalho HTTP.

Limitações

Consulte a seção do serviço de back-end para ver as limitações associadas à configuração de NEGs da Internet como back-ends.
Quando você modifica um balanceador de carga para alterar o back-end de um NEG da Internet para qualquer outro tipo de back-end ou vice-versa, o aplicativo passa por uma inatividade temporária de cerca de 30 a 90 segundos. Por exemplo, durante essa inatividade, os clientes que enviam solicitações a balanceadores de carga de aplicativo externos globais encontram erros 502 com o código failed_to_connect_to_backend. Esse comportamento é esperado.
Os seguintes recursos avançados de gerenciamento de tráfego não são compatíveis com back-ends de NEG globais da Internet:
- Solicitar espelhamento
- Políticas de repetição
- Políticas de tráfego (incluindo política de localidade de balanceamento de carga, afinidade de sessão e detecção de outlier)
Consulte a seção Gateway do Cloud NAT para ver as limitações associadas aos gateways NAT configurados nas sub-redes somente proxy.

Cotas e limites

As cotas e os limites a seguir se aplicam a NEGs da Internet:

A cota atual de grupos de endpoints de rede é que estabelece quantos NEGs com endpoints de rede externos poderão ser configurados.
O número de NEGs por serviço de back-end depende do tipo de NEG da Internet (global ou regional):
- Para NEGs globais, é possível adicionar apenas um back-end de NEG da Internet ao mesmo serviço de back-end.
- Para NEGs regionais, é possível adicionar até 50 NEGs da Internet ao mesmo serviço de back-end.
O número de endpoints por NEG também depende do tipo de NEG da Internet (global ou regional):
- Para NEGs globais, é possível adicionar apenas um endpoint a um NEG da Internet.
- Para NEGs regionais, é possível adicionar até 256 endpoints a um NEG da Internet.

Para mais informações, consulte a cota de back-ends de NEG e a cota de endpoints por NEG.

Preços

O tráfego de saída para endpoints de NEG externos da Internet é cobrado de acordo com as taxas de saída da Internet para rede de nível Premium. A origem é baseada na localização do cliente, e o destino é baseado na localização do endpoint público.

Se você configurou um gateway do Cloud NAT para mapear a sub-rede somente proxy do balanceador de carga baseado no Envoy, haverá cobranças do Cloud NAT. Os gateways Cloud NAT alocados para balanceadores de carga geram cobranças por hora equivalentes a uma rede com mais de 32 instâncias de VM. Para detalhes, consulte Preços do Cloud NAT.

Para mais informações, consulte Preços do Cloud Load Balancing.