Configurar um balanceador de carga de rede de proxy interno entre regiões com back-ends de grupos de instâncias de VM

Neste documento, você aprenderá a configurar um balanceador de carga de rede proxy entre regiões para seus serviços executados em VMs do Compute Engine.

Antes de começar

Antes de seguir as instruções deste guia, familiarize-se com os itens abaixo:

Permissões

Para seguir as instruções deste guia, você precisa ser capaz de criar instâncias e modificar uma rede em um projeto. É necessário ser um proprietário ou editor de projeto, ou ter todos os seguintes papéis do IAM do Compute Engine:

Tarefa Papel necessário
Criar redes, sub-redes e componentes do balanceador de carga Administrador de rede do Compute
Adicionar e remover regras de firewall Administrador de segurança do Compute
Criar instâncias Administrador da instância da computação

Para mais informações, consulte estes guias:

Visão geral da configuração

É possível configurar o balanceador de carga como mostrado no seguinte diagrama:

Balanceador de carga de rede de proxy interno entre regiões com implantação de alta disponibilidade.
Balanceador de carga de rede de proxy interno entre regiões com implantação de alta disponibilidade (clique para ampliar).

Conforme mostrado no diagrama, este exemplo cria um balanceador de carga de rede de proxy interno entre regiões em uma rede VPC, com um serviço de back-end e dois grupos de instâncias gerenciadas (MIGs) de back-end na região REGION_A e nas regiões REGION_B.

O diagrama mostra estes elementos:

  1. Uma rede VPC com as seguintes sub-redes:

    • Sub-rede SUBNET_A e uma sub-rede somente proxy em REGION_A.
    • Sub-rede SUBNET_B e uma sub-rede somente proxy em REGION_B.

    É preciso criar sub-redes somente proxy em todas as regiões de uma rede VPC em que você usa balanceadores de carga de rede de proxy internos entre regiões. A sub-rede somente proxy da região é compartilhada com todos os balanceadores de carga de rede de proxy internos entre regiões que estão na região. Os endereços de origem dos pacotes enviados dos balanceadores de carga para os back-ends do serviço são alocados por meio da sub-rede somente proxy. Neste exemplo, a sub-rede somente proxy da região REGION_B tem um intervalo de endereços IP primário 10.129.0.0/23. A região REGION_A tem um intervalo de endereços IP primário 10.130.0.0/23, que é o tamanho de sub-rede recomendado.

  2. A configuração de alta disponibilidade tem back-ends de grupo de instâncias gerenciadas para implantações de VM do Compute Engine nas regiões REGION_A e REGION_B. Se os back-ends de uma região ficarem inativos, o tráfego fará o failover para a outra região.

  3. Um serviço de back-end global que monitora o uso e a integridade dos back-ends.

  4. Um proxy TCP de destino global, que recebe uma solicitação do usuário e a encaminha ao serviço de back-end.

  5. Regras de encaminhamento global, que têm o endereço IP interno regional do seu balanceador de carga e podem encaminhar cada solicitação recebida para o proxy de destino.

    O endereço IP interno associado à regra de encaminhamento pode ser proveniente de uma sub-rede na mesma rede e região dos back-ends. Observe as seguintes condições:

    • O endereço IP pode (mas não precisa) vir da mesma sub-rede que os grupos de instâncias de back-end.
    • O endereço IP não pode vir de uma sub-rede exclusiva de proxy reservada que tenha a sinalização --purpose definida como GLOBAL_MANAGED_PROXY.
    • Se você quiser usar o mesmo endereço IP interno com várias regras de encaminhamento, defina a sinalização --purpose do endereço IP como SHARED_LOADBALANCER_VIP.

Configurar a rede e as sub-redes

Na rede VPC, configure uma sub-rede em cada região em que os back-ends estão configurados. Além disso, configure um proxy-only-subnet em cada região em que você quer configurar o balanceador de carga.

Neste exemplo, usamos a seguinte rede VPC, região e sub-redes:

  • Rede. Uma rede VPC de modo personalizado denominada NETWORK.

  • Sub-redes para back-ends.

    • uma sub-rede chamada SUBNET_A na região REGION_A usa 10.1.2.0/24 para o intervalo de IP primário.
    • uma sub-rede chamada SUBNET_B na região REGION_B usa 10.1.3.0/24 para o intervalo de IP primário.
  • Sub-redes para proxies.

    • uma sub-rede chamada PROXY_SN_A na região REGION_A usa 10.129.0.0/23 para o intervalo de IP primário.
    • uma sub-rede chamada PROXY_SN_B na região REGION_B usa 10.130.0.0/23 para o intervalo de IP primário.

Os balanceadores de carga de aplicativo internos entre regiões podem ser acessados de qualquer região dentro da VPC. Assim, clientes de qualquer região podem acessar globalmente os back-ends do balanceador de carga.

Configurar as sub-redes de back-end

Console

  1. No Console do Google Cloud, acesse a página Redes VPC.

    Acessar redes VPC

  2. Clique em Criar rede VPC.

  3. Atribua um Nome à rede.

  4. Na seção Sub-redes, defina o Modo de criação da sub-rede como Personalizado.

  5. Crie uma sub-rede para os back-ends do balanceador de carga. Na seção Nova sub-rede, insira as informações a seguir:

    • Forneça um Nome para a sub-rede.
    • Selecione uma Região: REGION_A
    • Digite um Intervalo de endereço IP: 10.1.2.0/24
  6. Clique em Concluído.

  7. Clique em Add subnet.

  8. Crie uma sub-rede para os back-ends do balanceador de carga. Na seção Nova sub-rede, insira as seguintes informações:

    • Forneça um Nome para a sub-rede.
    • Selecione uma Região: REGION_B
    • Digite um Intervalo de endereço IP: 10.1.3.0/24
  9. Clique em Concluído.

  10. Clique em Criar.

gcloud

  1. Crie a rede VPC personalizada com o comando gcloud compute networks create:

    gcloud compute networks create NETWORK \
        --subnet-mode=custom
    
  2. Crie uma sub-rede na rede NETWORK na região REGION_A com o comando gcloud compute networks subnets create:

    gcloud compute networks subnets create SUBNET_A \
        --network=NETWORK \
        --range=10.1.2.0/24 \
        --region=REGION_A
    
  3. Crie uma sub-rede na rede NETWORK na região REGION_B com o comando gcloud compute networks subnets create:

    gcloud compute networks subnets create SUBNET_B \
        --network=NETWORK \
        --range=10.1.3.0/24 \
        --region=REGION_B
    

Terraform

Para criar a rede VPC, use o recurso google_compute_network.

resource "google_compute_network" "default" {
  auto_create_subnetworks = false
  name                    = "lb-network-crs-reg"
  provider                = google-beta
}

Para criar sub-redes VPC na rede lb-network-crs-reg, use o recurso google_compute_subnetwork.

resource "google_compute_subnetwork" "subnet_a" {
  provider      = google-beta
  ip_cidr_range = "10.1.2.0/24"
  name          = "lbsubnet-uswest1"
  network       = google_compute_network.default.id
  region        = "us-west1"
}
resource "google_compute_subnetwork" "subnet_b" {
  provider      = google-beta
  ip_cidr_range = "10.1.3.0/24"
  name          = "lbsubnet-useast1"
  network       = google_compute_network.default.id
  region        = "us-east1"
}

API

Faça uma solicitação POST ao método networks.insert. Substitua PROJECT_ID pelo ID do projeto.

POST https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/global/networks

{
 "routingConfig": {
   "routingMode": "regional"
 },
 "name": "NETWORK",
 "autoCreateSubnetworks": false
}

Faça uma solicitação POST ao método subnetworks.insert. Substitua PROJECT_ID pelo ID do projeto.

POST https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/regions/REGION_A/subnetworks

{
 "name": "SUBNET_A",
 "network": "projects/PROJECT_ID/global/networks/lb-network-crs-reg",
 "ipCidrRange": "10.1.2.0/24",
 "region": "projects/PROJECT_ID/regions/REGION_A",
}

Faça uma solicitação POST ao método subnetworks.insert. Substitua PROJECT_ID pelo ID do projeto.

POST https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/regions/REGION_B/subnetworks

{
 "name": "SUBNET_B",
 "network": "projects/PROJECT_ID/global/networks/NETWORK",
 "ipCidrRange": "10.1.3.0/24",
 "region": "projects/PROJECT_ID/regions/REGION_B",
}

Configurar a sub-rede somente proxy

Uma sub-rede somente proxy fornece um conjunto de endereços IP que o Google Cloud usa para executar proxies Envoy em seu nome. Os proxies encerram as conexões do cliente e criam novas conexões com os back-ends.

Essa sub-rede somente proxy é usada por todos os balanceadores de carga regionais baseados no Envoy que estão na mesma região que a rede VPC. Só pode haver uma sub-rede somente proxy ativa para uma determinada finalidade, por região e por rede.

Console

Se você estiver usando o Console do Google Cloud, poderá esperar e criar a sub-rede somente proxy depois na página Balanceamento de carga.

Se você quiser criar a sub-rede somente proxy agora, siga estas etapas:

  1. No Console do Google Cloud, acesse a página Redes VPC.

    Acessar redes VPC

  2. Clique no nome da rede VPC.
  3. Na guia Sub-rede, clique em Adicionar sub-rede.
  4. Forneça um Nome para a sub-rede somente proxy.
  5. Selecione uma Região: REGION_A
  6. Na lista Finalidade, selecione Proxy gerenciado entre regiões.
  7. No campo Intervalo de endereços IP, insira 10.129.0.0/23.
  8. Clique em Adicionar.

Crie a sub-rede somente proxy em REGION_B

  1. Na guia Sub-rede, clique em Adicionar sub-rede.
  2. Forneça um Nome para a sub-rede somente proxy.
  3. Selecione uma Região: REGION_B
  4. Na lista Finalidade, selecione Proxy gerenciado entre regiões.
  5. No campo Intervalo de endereços IP, insira 10.130.0.0/23.
  6. Clique em Adicionar.

gcloud

Crie a sub-rede somente proxy com o comando gcloud compute networks subnets create.

    gcloud compute networks subnets create PROXY_SN_A \
        --purpose=GLOBAL_MANAGED_PROXY \
        --role=ACTIVE \
        --region=REGION_A \
        --network=NETWORK \
        --range=10.129.0.0/23
    
    gcloud compute networks subnets create PROXY_SN_B \
        --purpose=GLOBAL_MANAGED_PROXY \
        --role=ACTIVE \
        --region=REGION_B \
        --network=NETWORK \
        --range=10.130.0.0/23
    

Terraform

Para criar a sub-rede somente proxy VPC na rede lb-network-crs-reg, use o recurso google_compute_subnetwork.

resource "google_compute_subnetwork" "proxy_subnet_a" {
  provider      = google-beta
  ip_cidr_range = "10.129.0.0/23"
  name          = "proxy-only-subnet1"
  network       = google_compute_network.default.id
  purpose       = "GLOBAL_MANAGED_PROXY"
  region        = "us-west1"
  role          = "ACTIVE"
  lifecycle {
    ignore_changes = [ipv6_access_type]
  }
}
resource "google_compute_subnetwork" "proxy_subnet_b" {
  provider      = google-beta
  ip_cidr_range = "10.130.0.0/23"
  name          = "proxy-only-subnet2"
  network       = google_compute_network.default.id
  purpose       = "GLOBAL_MANAGED_PROXY"
  region        = "us-east1"
  role          = "ACTIVE"
  lifecycle {
    ignore_changes = [ipv6_access_type]
  }
}

API

Crie as sub-redes somente proxy com o método subnetworks.insert, substituindo PROJECT_ID pelo ID do projeto.

    POST https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/regions/REGION_A/subnetworks

    {
      "name": " PROXY_SN_A",
      "ipCidrRange": "10.129.0.0/23",
      "network": "projects/PROJECT_ID/global/networks/NETWORK",
      "region": "projects/PROJECT_ID/regions/REGION_A",
      "purpose": "GLOBAL_MANAGED_PROXY",
      "role": "ACTIVE"
    }
   
    POST https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/regions/REGION_B/subnetworks

    {
      "name": "PROXY_SN_B",
      "ipCidrRange": "10.130.0.0/23",
      "network": "projects/PROJECT_ID/global/networks/NETWORK",
      "region": "projects/PROJECT_ID/regions/REGION_B",
      "purpose": "GLOBAL_MANAGED_PROXY",
      "role": "ACTIVE"
    }
   

Configurar regras de firewall

Este exemplo usa as seguintes regras de firewall:

  • fw-ilb-to-backends: uma regra de entrada, aplicável às instâncias cuja carga está sendo balanceada, que permite a conectividade SSH de entrada na porta TCP 22 proveniente de qualquer endereço. Escolha um intervalo de endereços IP de origem mais restritivo para esta regra. Por exemplo, é possível especificar apenas os intervalos de endereços IP do sistema do qual você inicia as sessões SSH. Neste exemplo, usamos a tag de destino allow-ssh para identificar as VMs a que a regra de firewall se aplica.

  • fw-healthcheck. Uma regra de entrada, aplicável às instâncias cuja carga está sendo balanceada, que permite todo o tráfego TCP dos sistemas de verificação de integridade do Google Cloud (em 130.211.0.0/22 e 35.191.0.0/16). Este exemplo usa a tag de destino load-balanced-backend para identificar as VMs a que a regra de firewall se aplica.

  • fw-backends: uma regra de entrada, aplicável às instâncias cuja carga está sendo balanceada, que permite o tráfego TCP nas portas 80, 443 e 8080 proveniente do proxies gerenciados pelo balanceador de carga de rede de proxy interno. Neste exemplo, usamos a tag de destino load-balanced-backend para identificar as VMs a que a regra de firewall se aplica.

Sem essas regras de firewall, a regra padrão de negação de entrada bloqueará o tráfego que chega para as instâncias de back-end.

As tags de destino definem as instâncias de back-end. Sem as tags de destino, as regras de firewall se aplicam a todas as instâncias de back-end na rede VPC. Ao criar as VMs de back-end, inclua as tags de destino especificadas, conforme mostrado em Como criar um grupo gerenciado de instâncias.

Console

  1. No Console do Google Cloud, acesse a página políticas de Firewall.

    Acessar as políticas de firewall

  2. Clique em Criar regra de firewall para criar a regra que autorize conexões SSH de entrada:

    • Name: fw-ilb-to-backends
    • Rede: NETWORK
    • Direção do tráfego: entrada
    • Ação na correspondência: permitir
    • Destinos: tags de destino especificadas
    • Tags de meta: allow-ssh
    • Filtro de origem: intervalos IPv4
    • Intervalos IPv4 de origem: 0.0.0.0/0
    • Protocolos e portas:
      • Escolha Protocolos e portas especificados.
      • Marque a caixa de seleção tcp e insira 22 como o número da porta.
  3. Clique em Criar.

  4. Clique em Criar regra de firewall pela segunda vez para criar a regra que autorize as verificações de integridade do Google Cloud:

    • Name: fw-healthcheck
    • Rede: NETWORK
    • Direção do tráfego: entrada
    • Ação na correspondência: permitir
    • Destinos: tags de destino especificadas
    • Tags de meta: load-balanced-backend
    • Filtro de origem: intervalos IPv4
    • Intervalos IPv4 de origem: 130.211.0.0/22 e 35.191.0.0/16
    • Protocolos e portas:

      • Escolha Protocolos e portas especificados.
      • Marque a caixa de seleção tcp e insira 80 como o número da porta.

      Como prática recomendada, limite esta regra somente aos protocolos e portas que correspondem aos usados por sua verificação de integridade. Se você usar tcp:80 para o protocolo e a porta, o Google Cloud poderá usar HTTP na porta 80 para entrar em contato com suas VMs, mas não poderá usar HTTPS na porta 443 para entrar em contato com elas.

  5. Clique em Criar.

  6. Clique em Criar regra de firewall uma terceira vez para criar a regra que permite que os servidores proxy do balanceador de carga se conectem aos back-ends:

    • Name: fw-backends
    • Rede: NETWORK
    • Direção do tráfego: entrada
    • Ação na correspondência: permitir
    • Destinos: tags de destino especificadas
    • Tags de meta: load-balanced-backend
    • Filtro de origem: intervalos IPv4
    • Intervalos IPv4 de origem: 10.129.0.0/23 e 10.130.0.0/23
    • Protocolos e portas:
      • Escolha Protocolos e portas especificados.
      • Marque a caixa de seleção tcp e insira 80, 443, 8080 como os números da porta.
  7. Clique em Criar.

gcloud

  1. Crie a regra de firewall fw-ilb-to-backends que permita a conectividade SSH para VMs com a tag de rede allow-ssh. Se você omitir source-ranges, o Google Cloud interpretará que a regra autoriza a conexão proveniente de qualquer origem.

    gcloud compute firewall-rules create fw-ilb-to-backends \
        --network=NETWORK \
        --action=allow \
        --direction=ingress \
        --target-tags=allow-ssh \
        --rules=tcp:22
    
  2. Crie a regra fw-healthcheck para permitir verificações de integridade do Google Cloud. Neste exemplo, é permitido todo o tráfego TCP de sondagens de verificação de integridade. No entanto, é possível configurar um conjunto mais restrito de portas para atender às suas necessidades.

    gcloud compute firewall-rules create fw-healthcheck \
        --network=NETWORK \
        --action=allow \
        --direction=ingress \
        --source-ranges=130.211.0.0/22,35.191.0.0/16 \
        --target-tags=load-balanced-backend \
        --rules=tcp
    
  3. Crie a regra fw-backends para permitir que os proxies do balanceador de carga de rede de proxy interno se conectem aos seus back-ends. Defina source-ranges para os intervalos alocados da sub-rede somente proxy, por exemplo, 10.129.0.0/23 and 10.130.0.0/23.

    gcloud compute firewall-rules create fw-backends \
        --network=NETWORK \
        --action=allow \
        --direction=ingress \
        --source-ranges=SOURCE_RANGE \
        --target-tags=load-balanced-backend \
        --rules=tcp:80,tcp:443,tcp:8080
    

API

Crie a regra de firewall fw-ilb-to-backends fazendo uma solicitação POST ao método firewalls.insert, substituindo PROJECT_ID pelo ID do projeto.

POST https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/global/firewalls

{
 "name": "fw-ilb-to-backends",
 "network": "projects/PROJECT_ID/global/networks/NETWORK",
 "sourceRanges": [
   "0.0.0.0/0"
 ],
 "targetTags": [
   "allow-ssh"
 ],
 "allowed": [
  {
    "IPProtocol": "tcp",
    "ports": [
      "22"
    ]
  }
 ],
"direction": "INGRESS"
}

Crie a regra de firewall fw-healthcheck fazendo uma solicitação POST ao método firewalls.insert, substituindo PROJECT_ID pelo ID do projeto.

POST https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/global/firewalls

{
 "name": "fw-healthcheck",
 "network": "projects/PROJECT_ID/global/networks/NETWORK",
 "sourceRanges": [
   "130.211.0.0/22",
   "35.191.0.0/16"
 ],
 "targetTags": [
   "load-balanced-backend"
 ],
 "allowed": [
   {
     "IPProtocol": "tcp"
   }
 ],
 "direction": "INGRESS"
}

Crie a regra de firewall fw-backends para permitir o tráfego TCP na sub-rede proxy para o método firewalls.insert, substituindo PROJECT_ID pelo ID do projeto.

POST https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/global/firewalls

{
 "name": "fw-backends",
 "network": "projects/PROJECT_ID/global/networks/NETWORK",
 "sourceRanges": [
   "10.129.0.0/23",
   "10.130.0.0/23"
 ],
 "targetTags": [
   "load-balanced-backend"
 ],
 "allowed": [
   {
     "IPProtocol": "tcp",
     "ports": [
       "80"
     ]
   },
 {
     "IPProtocol": "tcp",
     "ports": [
       "443"
     ]
   },
   {
     "IPProtocol": "tcp",
     "ports": [
       "8080"
     ]
   }
 ],
 "direction": "INGRESS"
}

criar um grupo gerenciado de instâncias

Nesta seção, você verá como criar um modelo e um grupo de instâncias gerenciadas. O grupo gerenciado de instâncias fornece instâncias de VM que executam os servidores de back-end de um exemplo de balanceador de carga de rede de proxy interno entre regiões. Para o grupo de instâncias, é possível definir um serviço HTTP e mapear um nome de porta para a porta relevante. O serviço de back-end do balanceador de carga encaminha o tráfego para as portas nomeadas. É feito o balanceamento de carga do tráfego dos clientes para os servidores de back-end. Para fins de demonstração, os back-ends veiculam nomes de host próprios.

Console

  1. No console do Google Cloud, acesse a página Modelos de instância.

    Acessar "Modelos de instância"

    1. Clique em Criar modelo de instância.
    2. Em Nome, insira gil4-backendeast1-template.
    3. Verifique se Disco de inicialização está definido como uma imagem Debian, como Debian GNU/Linux 12 (bookworm): Estas instruções usam comandos que estão disponíveis apenas no Debian, como apt-get.
    4. Clique em Opções avançadas.
    5. Clique em Rede e configure os seguintes campos:
      1. Em Tags de rede, insira allow-ssh e load-balanced-backend.
      2. Em Interfaces de rede, selecione o seguinte:
        • Rede: NETWORK
        • Sub-rede: SUBNET_B
    6. Clique em Gerenciamento. Insira o script a seguir no campo Script de inicialização.

      #! /bin/bash
      apt-get update
      apt-get install apache2 -y
      a2ensite default-ssl
      a2enmod ssl
      vm_hostname="$(curl -H "Metadata-Flavor:Google" \
      http://169.254.169.254/computeMetadata/v1/instance/name)"
      echo "Page served from: $vm_hostname" | \
      tee /var/www/html/index.html
      systemctl restart apache2
      
    7. Clique em Criar.

    8. Clique em Criar modelo de instância.

    9. Em Nome, insira gil4-backendwest1-template.

    10. Verifique se Disco de inicialização está definido como uma imagem Debian, como Debian GNU/Linux 12 (bookworm): Estas instruções usam comandos que estão disponíveis apenas no Debian, como apt-get.

    11. Clique em Opções avançadas.

    12. Clique em Rede e configure os seguintes campos:

      1. Em Tags de rede, insira allow-ssh e load-balanced-backend.
      2. Em Interfaces de rede, selecione o seguinte:
        • Rede: NETWORK
        • Sub-rede: SUBNET_A
    13. Clique em Gerenciamento. Insira o script a seguir no campo Script de inicialização.

      #! /bin/bash
      apt-get update
      apt-get install apache2 -y
      a2ensite default-ssl
      a2enmod ssl
      vm_hostname="$(curl -H "Metadata-Flavor:Google" \
      http://169.254.169.254/computeMetadata/v1/instance/name)"
      echo "Page served from: $vm_hostname" | \
      tee /var/www/html/index.html
      systemctl restart apache2
      
    14. Clique em Criar.

  2. No Console do Google Cloud, acesse a página Grupos de instâncias.

    Acesse grupo de instâncias

    1. Clique em Criar grupo de instâncias.
    2. Selecione Novo grupo gerenciado de instâncias (sem estado). Para mais informações, consulte MIGs sem estado ou com estado.
    3. Em Nome, insira gl4-ilb-miga.
    4. Em Local, selecione Zona única.
    5. Em Região, selecione REGION_A.
    6. Em Zona, selecione ZONE_A.
    7. Em Modelo de instância, selecione gil4-backendwest1-template.
    8. Especifique o número de instâncias que você quer criar no grupo.

      Neste exemplo, especifique as seguintes opções em Escalonamento automático:

      • Em Modo de escalonamento automático, selecione Off:do not autoscale.
      • Em Número máximo de instâncias, insira 2.

      Se preferir, na seção Escalonamento automático da IU, configure o grupo de instâncias para adicionar ou remover instâncias automaticamente com base no uso de CPU da instância.

    9. Clique em Criar.

    10. Clique em Criar grupo de instâncias.

    11. Selecione Novo grupo gerenciado de instâncias (sem estado). Para mais informações, consulte MIGs sem estado ou com estado.

    12. Em Nome, insira gl4-ilb-migb.

    13. Em Local, selecione Zona única.

    14. Em Região, selecione REGION_B.

    15. Em Zona, selecione ZONE_B.

    16. Em Modelo de instância, selecione gil4-backendeast1-template.

    17. Especifique o número de instâncias que você quer criar no grupo.

      Neste exemplo, especifique as seguintes opções em Escalonamento automático:

      • Em Modo de escalonamento automático, selecione Off:do not autoscale.
      • Em Número máximo de instâncias, insira 2.

      Se preferir, na seção Escalonamento automático da IU, configure o grupo de instâncias para adicionar ou remover instâncias automaticamente com base no uso de CPU da instância.

    18. Clique em Criar.

gcloud

As instruções deste guia relativas à CLI gcloud pressupõem que você está usando o Cloud Shell ou outro ambiente com o bash instalado.

  1. Crie um modelo de instância de VM com o servidor HTTP usando o comando gcloud compute instance-templates create.

    gcloud compute instance-templates create gil4-backendwest1-template \
       --region=REGION_A \
       --network=NETWORK \
       --subnet=SUBNET_A \
       --tags=allow-ssh,load-balanced-backend \
       --image-family=debian-12 \
       --image-project=debian-cloud \
       --metadata=startup-script='#! /bin/bash
         apt-get update
         apt-get install apache2 -y
         a2ensite default-ssl
         a2enmod ssl
         vm_hostname="$(curl -H "Metadata-Flavor:Google" \
         http://169.254.169.254/computeMetadata/v1/instance/name)"
         echo "Page served from: $vm_hostname" | \
         tee /var/www/html/index.html
         systemctl restart apache2'
    
    gcloud compute instance-templates create gil4-backendeast1-template \
        --region=REGION_B \
        --network=NETWORK \
        --subnet=SUBNET_B \
        --tags=allow-ssh,load-balanced-backend \
        --image-family=debian-12 \
        --image-project=debian-cloud \
        --metadata=startup-script='#! /bin/bash
          apt-get update
          apt-get install apache2 -y
          a2ensite default-ssl
          a2enmod ssl
          vm_hostname="$(curl -H "Metadata-Flavor:Google" \
          http://169.254.169.254/computeMetadata/v1/instance/name)"
          echo "Page served from: $vm_hostname" | \
          tee /var/www/html/index.html
          systemctl restart apache2'
    
  2. Crie um grupo gerenciado de instâncias na zona com o comando gcloud compute instance-groups managed create.

    gcloud compute instance-groups managed create gl4-ilb-miga \
        --zone=ZONE_A \
        --size=2 \
        --template=gil4-backendwest1-template
    
    gcloud compute instance-groups managed create gl4-ilb-migb \
        --zone=ZONE_B \
        --size=2 \
        --template=gil4-backendeast1-template
    

API

Crie o modelo de instância com o método instanceTemplates.insert, substituindo PROJECT_ID pelo ID do projeto.

POST https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/global/instanceTemplates

{
  "name":"gil4-backendwest1-template",
  "properties":{
     "machineType":"e2-standard-2",
     "tags":{
       "items":[
         "allow-ssh",
         "load-balanced-backend"
       ]
     },
     "metadata":{
        "kind":"compute#metadata",
        "items":[
          {
            "key":"startup-script",
            "value":"#! /bin/bash\napt-get update\napt-get install
            apache2 -y\na2ensite default-ssl\na2enmod ssl\n
            vm_hostname=\"$(curl -H \"Metadata-Flavor:Google\"           
            \\\nhttp://169.254.169.254/computeMetadata/v1/instance/name)\"\n
            echo \"Page served from: $vm_hostname\" | \\\ntee
            /var/www/html/index.html\nsystemctl restart apache2"
          }
        ]
     },
     "networkInterfaces":[
       {
         "network":"projects/PROJECT_ID/global/networks/NETWORK",
         "subnetwork":"regions/REGION_A/subnetworks/SUBNET_A",
         "accessConfigs":[
           {
             "type":"ONE_TO_ONE_NAT"
           }
         ]
       }
     ],
     "disks":[
       {
         "index":0,
         "boot":true,
         "initializeParams":{
           "sourceImage":"projects/debian-cloud/global/images/family/debian-12"
         },
         "autoDelete":true
       }
     ]
  }
}
POST https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/global/instanceTemplates

{
  "name":"gil4-backendeast1-template",
  "properties":{
     "machineType":"e2-standard-2",
     "tags":{
       "items":[
         "allow-ssh",
         "load-balanced-backend"
       ]
     },
     "metadata":{
        "kind":"compute#metadata",
        "items":[
          {
            "key":"startup-script",
            "value":"#! /bin/bash\napt-get update\napt-get install
            apache2 -y\na2ensite default-ssl\na2enmod ssl\n
            vm_hostname=\"$(curl -H \"Metadata-Flavor:Google\"           
            \\\nhttp://169.254.169.254/computeMetadata/v1/instance/name)\"\n
            echo \"Page served from: $vm_hostname\" | \\\ntee
            /var/www/html/index.html\nsystemctl restart apache2"
          }
        ]
     },
     "networkInterfaces":[
       {
         "network":"projects/PROJECT_ID/global/networks/NETWORK",
         "subnetwork":"regions/REGION_B/subnetworks/SUBNET_B",
         "accessConfigs":[
           {
             "type":"ONE_TO_ONE_NAT"
           }
         ]
       }
     ],
     "disks":[
       {
         "index":0,
         "boot":true,
         "initializeParams":{
           "sourceImage":"projects/debian-cloud/global/images/family/debian-12"
         },
         "autoDelete":true
       }
     ]
  }
}

Crie um grupo gerenciado de instâncias em cada zona com o método instanceGroupManagers.insert, substituindo PROJECT_ID pelo ID do projeto.

POST https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/zones/{zone}/instanceGroupManagers

{
  "name": "gl4-ilb-miga",
  "zone": "projects/PROJECT_ID/zones/ZONE_A",
  "instanceTemplate": "projects/PROJECT_ID/global/instanceTemplates/gil4-backendwest1-template",
  "baseInstanceName": "gl4-ilb-miga",
  "targetSize": 2
}
POST https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/zones/{zone}/instanceGroupManagers

{
  "name": "gl4-ilb-migb",
  "zone": "projects/PROJECT_ID/zones/ZONE_A",
  "instanceTemplate": "projects/PROJECT_ID/global/instanceTemplates/gil4-backendwest1-template",
  "baseInstanceName": "gl4-ilb-migb",
  "targetSize": 2
}

Configurar o balanceador de carga

Neste exemplo, mostramos como criar os seguintes recursos do balanceador de carga de rede de proxy interno entre regiões:

  • Uma verificação de integridade TCP global.
  • Um serviço de back-end global com os mesmos MIGs que o back-end.
  • Um proxy de destino global.
  • Duas regras de encaminhamento global com endereços IP regionais. Para o endereço IP da regra de encaminhamento, use o intervalo de endereços IP SUBNET_A ou SUBNET_B. Se você tentar usar a sub-rede somente proxy, a criação da regra de encaminhamento falhará.

Disponibilidade de proxy

Às vezes, as regiões do Google Cloud não têm capacidade de proxy suficiente para um novo balanceador de carga. Se isso acontecer, o console do Google Cloud fornecerá uma mensagem de aviso sobre a disponibilidade de proxy quando você criar o balanceador de carga. Para resolver esse problema, siga um destes procedimentos:

  • Selecione uma região diferente para seu balanceador de carga. Essa opção pode ser prática se você tiver back-ends em outra região.
  • Selecione uma rede VPC que já tenha uma sub-rede somente proxy alocada.
  • Aguarde o problema de capacidade ser resolvido.

Console

Iniciar a configuração

  1. No console do Google Cloud, acesse a página Balanceamento de carga.

    Acessar o "Balanceamento de carga"

  2. Clique em Criar balanceador de carga.
  3. Em Tipo de balanceador de carga, selecione Balanceador de carga de rede (TCP/UDP/SSL) e clique em Próxima.
  4. Em Proxy ou passagem, selecione Balanceador de carga de proxy e clique em Próxima.
  5. Em Voltado ao público ou interno, selecione Interno e clique em Próxima.
  6. Em Implantação entre regiões ou região única, selecione Melhor para cargas de trabalho entre regiões e clique em Próxima.
  7. Clique em Configurar.

Configuração básica

  1. Dê um Nome para o balanceador de carga.
  2. Em Rede, selecione NETWORK.

Configure o front-end com duas regras de encaminhamento

  1. Clique em Configuração de front-end.
    1. Dê um Nome para a regra de encaminhamento.
    2. Na lista Região da sub-rede, selecione REGION_A.

      Reservar uma sub-rede somente proxy

    3. Na lista Sub-rede, selecione SUBNET_A.
    4. Na lista de Endereços IP, clique em Criar endereço IP. A página Reservar um endereço IP interno estático é aberta.
      • Forneça um Nome para o endereço IP estático.
      • Na lista Endereço IP estático, selecione Quero escolher.
      • No campo Endereço IP, digite 10.1.2.99.
      • Selecione Reservar.
  2. Clique em Concluído.
  3. Para adicionar a segunda regra de encaminhamento, clique em Adicionar IP e porta do front-end.
    1. Dê um Nome para a regra de encaminhamento.
    2. Na lista Região da sub-rede, selecione REGION_B.

      Reservar uma sub-rede somente proxy

    3. Na lista Sub-rede, selecione SUBNET_B.
    4. Na lista de Endereços IP, clique em Criar endereço IP. A página Reservar um endereço IP interno estático é aberta.
      • Forneça um Nome para o endereço IP estático.
      • Na lista Endereço IP estático, selecione Quero escolher.
      • No campo Endereço IP, digite 10.1.3.99.
      • Selecione Reservar.
  4. Clique em Concluído.
Configurar o serviço de back-end
  1. Clique em Configuração de back-end.
  2. Na lista Criar ou selecionar serviços de back-end, clique em Criar um serviço de back-end.
  3. Forneça um Nome para o serviço de back-end.
  4. Em Protocol, selecione TCP.
  5. Em Porta nomeada, insira http.
  6. Na lista Tipo de back-end, selecione Grupo de instâncias.
  7. Na seção Novo back-end:
    • Na lista Grupo de instâncias, selecione gl4-ilb-miga em REGION_A.
    • Defina Números de portas como 80.
    • Clique em Concluído.
    • Para adicionar outro back-end, clique em Adicionar back-end.
    • Na lista Grupo de instâncias, selecione gl4-ilb-migb em REGION_B.
    • Defina Números de portas como 80.
    • Clique em Concluído.
  8. Na seção Verificação de integridade, clique em Criar verificação de integridade.
    • No campo Nome, use global-http-health-check.
    • Defina o Protocolo como HTTP.
    • Defina a Porta como 80.
    • Clique em Salvar.

Analise a configuração

  1. Clique em Analisar e finalizar.
  2. Revise suas configurações do balanceador de carga.
  3. Clique em Criar.

gcloud

  1. Defina a verificação de integridade TCP com o comando gcloud compute health-checks create tcp.

    gcloud compute health-checks create tcp global-health-check \
       --use-serving-port \
       --global
    
  2. Defina o serviço de back-end com o comando gcloud compute backend-services create.

    gcloud compute backend-services create gl4-gilb-backend-service \
      --load-balancing-scheme=INTERNAL_MANAGED \
      --protocol=TCP \
      --enable-logging \
      --logging-sample-rate=1.0 \
      --health-checks=global-health-check \
      --global-health-checks \
      --global
    
  3. Adicione back-ends ao serviço de back-end com o comando gcloud compute backend-services add-backend.

    gcloud compute backend-services add-backend gl4-gilb-backend-service \
      --balancing-mode=CONNECTION \
      --max-connections=50 \
      --instance-group=gl4-ilb-miga \
      --instance-group-zone=ZONE_A \
      --global
    
    gcloud compute backend-services add-backend gl4-gilb-backend-service \
      --balancing-mode=CONNECTION \
      --max-connections=50 \
      --instance-group=gl4-ilb-migb \
      --instance-group-zone=ZONE_B \
      --global
    
  4. Crie o proxy de destino.

    Crie o proxy de destino com o comando gcloud compute target-tcp-proxies create.

    gcloud compute target-tcp-proxies create gilb-tcp-proxy \
      --backend-service=gl4-gilb-backend-service \
      --global
    
  5. Crie duas regras de encaminhamento, uma com um VIP (10.1.2.99) em REGION_B e outra com outro VIP (10.1.3.99) em REGION_A. Para mais informações, consulte Reservar um endereço IPv4 interno estático.

    Para redes personalizadas, referencie a sub-rede na regra de encaminhamento. Observe que esta é a sub-rede da VM, não a do proxy.

    Use o comando gcloud compute forwarding-rules create com as sinalizações corretas.

    gcloud compute forwarding-rules create gil4forwarding-rule-a \
      --load-balancing-scheme=INTERNAL_MANAGED \
      --network=NETWORK \
      --subnet=SUBNET_A \
      --subnet-region=REGION_A \
      --address=10.1.2.99 \
      --ports=80 \
      --target-tcp-proxy=gilb-tcp-proxy \
      --global
    
    gcloud compute forwarding-rules create gil4forwarding-rule-b \
      --load-balancing-scheme=INTERNAL_MANAGED \
      --network=NETWORK \
      --subnet=SUBNET_B \
      --subnet-region=REGION_B \
      --address=10.1.3.99 \
      --ports=80 \
      --target-tcp-proxy=gilb-tcp-proxy \
      --global
    

API

Crie a verificação de integridade fazendo uma solicitação POST ao método healthChecks.insert, substituindo PROJECT_ID pelo ID do projeto.

POST https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/global/healthChecks

{
"name": "global-health-check",
"type": "TCP",
"httpHealthCheck": {
  "portSpecification": "USE_SERVING_PORT"
}
}

Crie o serviço de back-end regional fazendo uma solicitação POST ao método backendServices.insert, substituindo PROJECT_ID pelo ID do projeto.

POST https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/global/backendServices

{
"name": "gl4-gilb-backend-service",
"backends": [
  {
    "group": "projects/PROJECT_ID/zones/ZONE_A/instanceGroups/gl4-ilb-miga",
    "balancingMode": "CONNECTION"
  },
  {
    "group": "projects/PROJECT_ID/zones/ZONE_B/instanceGroups/gl4-ilb-migb",
    "balancingMode": "CONNECTION"
  }
],
"healthChecks": [
  "projects/PROJECT_ID/regions/global/healthChecks/global-health-check"
],
"loadBalancingScheme": "INTERNAL_MANAGED"
}

Crie o proxy TCP de destino fazendo uma solicitação POST ao método targetTcpProxies.insert, substituindo PROJECT_ID pelo ID do projeto.

POST https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/global/targetTcpProxy

{
"name": "l4-ilb-proxy",
}

Crie a regra de encaminhamento fazendo uma solicitação POST ao método forwardingRules.insert, substituindo PROJECT_ID pelo ID do projeto.

POST https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/global/forwardingRules

{
"name": "gil4forwarding-rule-a",
"IPAddress": "10.1.2.99",
"IPProtocol": "TCP",
"portRange": "80-80",
"target": "projects/PROJECT_ID/global/targetTcpProxies/l4-ilb-proxy",
"loadBalancingScheme": "INTERNAL_MANAGED",
"subnetwork": "projects/PROJECT_ID/regions/REGION_A/subnetworks/SUBNET_A",
"network": "projects/PROJECT_ID/global/networks/NETWORK",
"networkTier": "PREMIUM"
}
POST https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/global/forwardingRules

{
"name": "gil4forwarding-rule-b",
"IPAddress": "10.1.3.99",
"IPProtocol": "TCP",
"portRange": "80-80",
"target": "projects/PROJECT_ID/global/targetTcpProxies/l4-ilb-proxy",
"loadBalancingScheme": "INTERNAL_MANAGED",
"subnetwork": "projects/PROJECT_ID/regions/REGION_B/subnetworks/SUBNET_B",
"network": "projects/PROJECT_ID/global/networks/NETWORK",
"networkTier": "PREMIUM"
}

Crie a regra de encaminhamento fazendo uma solicitação POST ao método globalForwardingRules.insert, substituindo PROJECT_ID pelo ID do projeto.

POST https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/global/forwardingRules

{
"name": "gil4forwarding-rule-a",
"IPAddress": "10.1.2.99",
"IPProtocol": "TCP",
"portRange": "80-80",
"target": "projects/PROJECT_ID/global/targetTcpProxies/l4-ilb-proxy",
"loadBalancingScheme": "INTERNAL_MANAGED",
"subnetwork": "projects/PROJECT_ID/regions/REGION_A/subnetworks/SUBNET_A",
"network": "projects/PROJECT_ID/global/networks/NETWORK",
"networkTier": "PREMIUM"
}
POST https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/global/forwardingRules

{
"name": "gil4forwarding-rule-b",
"IPAddress": "10.1.3.99",
"IPProtocol": "TCP",
"portRange": "80-80",
"target": "projects/PROJECT_ID/global/targetTcpProxies/l4-ilb-proxy",
"loadBalancingScheme": "INTERNAL_MANAGED",
"subnetwork": "projects/PROJECT_ID/regions/REGION_B/subnetworks/SUBNET_B",
"network": "projects/PROJECT_ID/global/networks/NETWORK",
"networkTier": "PREMIUM"
}

Testar o balanceador de carga

Criar uma instância de VM para testar a conectividade

  1. Crie uma VM cliente nas regiões REGION_B e REGION_A:

    gcloud compute instances create l4-ilb-client-a \
        --image-family=debian-12 \
        --image-project=debian-cloud \
        --network=NETWORK \
        --subnet=SUBNET_A \
        --zone=ZONE_A \
        --tags=allow-ssh
    
    gcloud compute instances create l4-ilb-client-b \
        --image-family=debian-12 \
        --image-project=debian-cloud \
        --network=NETWORK \
        --subnet=SUBNET_B \
        --zone=ZONE_B \
        --tags=allow-ssh
    
  2. Use o SSH para se conectar a cada instância do cliente.

    gcloud compute ssh l4-ilb-client-a --zone=ZONE_A
    
    gcloud compute ssh l4-ilb-client-b --zone=ZONE_B
    
  3. Verifique se o endereço IP está exibindo o nome do host

    • Verifique se a VM cliente pode acessar os dois endereços IP. O comando será bem-sucedido e retornará o nome da VM de back-end que veiculou a solicitação:

      curl 10.1.2.99
      
      curl 10.1.3.99
      

Testar o failover

  1. Verifique o failover para back-ends na região REGION_A quando os back-ends em REGION_B não estiverem íntegros ou acessíveis. Para simular o failover, remova todos os back-ends de REGION_B:

    gcloud compute backend-services remove-backend gl4-gilb-backend-service \
      --instance-group=gl4-ilb-migb \
      --instance-group-zone=ZONE_B \
      --global
    
  2. Conecte-se usando SSH a uma VM cliente em REGION_B.

    gcloud compute ssh l4-ilb-client-b \
       --zone=ZONE_B
    
  3. Envie solicitações ao endereço IP com carga balanceada na região REGION_B. A resposta ao comando mostra as respostas das VMs de back-end em REGION_A:

    {
    RESULTS=
    for i in {1..100}
    do
      RESULTS="$RESULTS:$(curl -k -s 'https://test.example.com:443' --connect-to test.example.com:443:10.1.3.99:443)"
    done
    echo "***"
    echo "*** Results of load-balancing to 10.1.3.99: "
    echo "***"
    echo "$RESULTS" | tr ':' '\n' | grep -Ev "^$" | sort | uniq -c
    echo
    }
    

Outras opções de configuração

Nesta seção, o exemplo é detalhado para fornecer outras opções de configuração. Todas as tarefas são opcionais. É possível realizá-las em qualquer ordem.

Protocolo PROXY para manter informações de conexão do cliente

O balanceador de carga de rede do proxy interno encerra as conexões TCP do cliente e cria novas conexões com as instâncias. Por padrão, as informações de IP e porta do cliente original não são preservadas.

Para preservar e enviar as informações de conexão originais para suas instâncias, ative o protocolo PROXY (versão 1). Esse protocolo envia à instância como parte da solicitação um cabeçalho extra que contém os endereços IP de origem e de destino e os números de porta.

Verifique se as instâncias de back-end do balanceador de carga de rede de proxy interno estão executando servidores HTTP ou HTTPS compatíveis com cabeçalhos de protocolo PROXY. Se os servidores HTTP ou HTTP(S) não estiverem configurados para aceitar cabeçalhos de protocolo PROXY, as instâncias de back-end retornarão respostas vazias. Por exemplo, o protocolo PROXY não funciona com o software servidor Apache HTTP. É possível usar um software de servidor da Web diferente, como o Nginx.

Se você definir o protocolo PROXY para o tráfego de usuários, também precisará configurá-lo para as verificações de integridade. Se você estiver verificando a integridade e a exibição de conteúdo na mesma porta, defina o --proxy-header da verificação de integridade para corresponder à configuração do balanceador de carga.

Normalmente, o cabeçalho do protocolo PROXY é uma linha de texto legível no formato a seguir:

PROXY TCP4 <client IP> <load balancing IP> <source port> <dest port>\r\n

Veja a seguir um exemplo do protocolo PROXY:

PROXY TCP4 192.0.2.1 198.51.100.1 15221 110\r\n

No exemplo anterior, o IP do cliente é 192.0.2.1, o IP do balanceamento de carga é 198.51.100.1, a porta do cliente é 15221 e a porta de destino é 110.

Nos casos em que o IP do cliente não é conhecido, o balanceador de carga vai gerar um cabeçalho de protocolo PROXY no seguinte formato:

PROXY UNKNOWN\r\n

Atualizar o cabeçalho do protocolo PROXY para o proxy TCP de destino

O exemplo de configuração do balanceador de carga nesta página mostra como ativar o cabeçalho do protocolo PROXY ao criar o balanceador de carga de rede de proxy interno. Siga estas etapas para alterar o cabeçalho do protocolo PROXY para um proxy TCP de destino existente.

Console

  1. No Console do Google Cloud, acesse a página Balanceamento de carga.

    Acessar o "Balanceamento de carga"

  2. Clique em Editar para seu balanceador de carga.

  3. Clique em Configuração de front-end.

  4. Altere o valor do campo Protocolo de proxy para Ativado.

  5. Clique em Update to save your changes.

gcloud

No comando a seguir, edite o campo --proxy-header e defina-o como NONE ou PROXY_V1, dependendo do seu requisito.

gcloud compute target-ssl-proxies update int-tcp-target-proxy \
    --proxy-header=[NONE | PROXY_V1]

Usar o mesmo endereço IP entre várias regras de encaminhamento internas

Para que várias regras de encaminhamento interno compartilhem o mesmo endereço IP interno, é necessário reservar o endereço IP e definir a sinalização --purpose como SHARED_LOADBALANCER_VIP.

gcloud

gcloud compute addresses create SHARED_IP_ADDRESS_NAME \
    --region=REGION \
    --subnet=SUBNET_NAME \
    --purpose=SHARED_LOADBALANCER_VIP

Ativar a afinidade de sessão

A configuração de exemplo cria um serviço de back-end sem afinidade da sessão.

Nestes procedimentos, você verá um exemplo de como atualizar um serviço de back-end para um balanceador de carga. Com isso, o serviço de back-end usa a afinidade de IP do cliente ou a afinidade de cookie gerado.

Quando a afinidade de IP do cliente está ativada, o balanceador de carga direciona as solicitações de um determinado cliente para a mesma VM de back-end. Isso é feito com base em um hash criado a partir do endereço IP do cliente e do endereço IP do balanceador de carga (o endereço IP externo de uma regra de encaminhamento externo).

Console

Para ativar a afinidade da sessão de IP do cliente:

  1. No Console do Google Cloud, acesse a página Balanceamento de carga.
    Acessar balanceamento de carga
  2. Clique em Back-ends.
  3. Clique no nome do serviço de back-end que você criou para este exemplo e clique em Editar.
  4. Na página Detalhes do serviço de back-end, clique em Configuração avançada.
  5. Em Afinidade da sessão, selecione IP do cliente no menu.
  6. Clique em Atualizar.

gcloud

Use o comando gcloud a seguir para atualizar o serviço de back-end BACKEND_SERVICE, especificando a afinidade da sessão de IP do cliente:

gcloud compute backend-services update BACKEND_SERVICE \
    --global \
    --session-affinity=CLIENT_IP

Ativar a diminuição da conexão

Ative a diminuição da conexão em serviços de back-end para garantir interrupção mínima aos usuários quando uma instância que está veiculando tráfego é encerrada, removida manualmente ou removida por um autoescalador. Para mais informações, leia sobre Como ativar a diminuição da conexão.

A seguir