Server Load Balancer:ALB FAQ

Especificações de instância do ALB

O ALB não exige a seleção de uma especificação de instância. Após upgrade an ALB instance, o ALB utiliza o recurso de dimensionamento automático de VIP para atingir 1 milhão de QPS por instância. Para obter detalhes sobre o desempenho da instância, consulte Instance metrics.

Conversão de instâncias IPv4 e de pilha dupla

Não.

É possível criar apenas uma nova instância IPv4 ou uma nova instância de pilha dupla.

Desativar pings para o VIP do ALB

• Para upgraded ALB instances, gerencie o tráfego de acesso por meio de um security group. Configure uma regra de entrada no grupo de segurança da instância para negar solicitações ICMP.

• Para instâncias do ALB não atualizadas, adicione os EIPs associados à instância ao Cloud Firewall e configure uma política de entrada para negar solicitações ICMP.

Aumentar a largura de banda pública do ALB

Se não for adicionada a uma instância de Shared Bandwidth, uma única instância do ALB implantada em duas zonas de disponibilidade tem largura de banda pública de pico padrão de 400 Mbps.

Usar um Data Transfer Plan com o ALB

• Se uma instância do ALB fornecer serviços públicos por meio de um Elastic IP Address (EIP), use um Data Transfer Plan para compensar os custos de transferência de dados de internet gerados pelo EIP.

• Se uma instância do ALB fornecer serviços públicos por meio de um Anycast Elastic IP Address (Anycast EIP), não é possível usar um Data Transfer Plan para compensar os custos de transferência de dados de internet gerados pelo Anycast EIP.

Tipos de EIP suportados

EIPs para instâncias privadas do ALB

Sim.

Caso precise associar um Elastic IP Address (EIP) a um ALB voltado para a rede privada, converta o ALB privado em um ALB voltado para a rede pública alterando o tipo de rede da instância. Para obter mais informações, consulte Change the network type of an ALB instance.

A alteração do tipo de rede de privada para pública associa um EIP à instância e gera cobranças pela transferência de dados resultante para a internet. Para obter mais informações, consulte EIP billing.

Substituir um EIP por um EIP BGP (Multi-ISP) Pro

Substitua o EIP ao changing the network type of the ALB instance:

1. Altere o tipo de rede da instância do ALB de pública para privada para desassociar o EIP.

2. Altere o tipo de rede da instância do ALB de volta de privada para pública. Durante esse processo, selecione dois EIPs BGP (Multi-ISP) Pro já criados.

Distribuição desigual de tráfego entre EIPs

Esse problema pode ter as seguintes causas:

• O nome de domínio do service é resolvido incorretamente para um único EIP associado à instância, em vez do nome DNS da instância do ALB.

• Um proxy de Camada 7, como o Web Application Firewall (WAF) ou o Anti-DDoS, está implantado na frente da instância do ALB. O algoritmo de back-to-origin do proxy, como o IP hash, impede que o tráfego seja distribuído uniformemente entre os EIPs.

• Alguns clientes armazenam em cache os registros A da resolução de DNS, o que faz com que um grande número de solicitações seja enviado consistentemente para o mesmo EIP.

Remoção de DNS para o ALB

Upgraded ALB instances suportam as operações de remoção e recuperação de DNS por padrão.

Após a conclusão da remoção de DNS, o sistema interrompe as verificações de integridade do VIP nessa zona de disponibilidade. O sistema também remove o VIP ou EIP (incluindo endereços IPv4 e IPv6) nessa zona de disponibilidade da resolução do nome de domínio do ALB. Não é possível remover apenas o endereço VIP IPv4 ou IPv6.

Alto tráfego público nas instâncias do ECS de backend

O tráfego encaminhado por uma instância do ALB para as instâncias do Elastic Compute Service (ECS) de backend trafega pela rede interna da Virtual Private Cloud (VPC) e não consome a largura de banda pública das instâncias do ECS. Se o tráfego público das suas instâncias do ECS permanecer alto, geralmente é por um dos seguintes motivos:

• O tráfego de entrada contorna a instância do ALB: o nome de domínio ainda é resolvido para um IP público do ECS, ou os clientes acessam a instância do ECS diretamente por meio de seu IP público. Como resultado, a instância do ALB não encaminha o tráfego.

• Solicitações de saída das instâncias do ECS: os aplicativos em execução nas instâncias do ECS iniciam solicitações externas, como atualizações de software, uploads de log ou chamadas de API externas, que geram tráfego público de saída.

Etapas de solução de problemas:

1. Verifique se o nome de domínio do seu service é resolvido para o endereço do ALB, e não para um endereço IP público do ECS.

2. Verifique as regras de entrada do grupo de segurança das instâncias do ECS para garantir que as portas de service não estejam expostas ao público.

3. Nas instâncias do ECS, use iftop ou nethogs para identificar os processos e endereços de destino que consomem largura de banda pública.

Qual endereço IP deve ser adicionado à lista de permissões de IP de uma plataforma de terceiros ao usar o ALB?

Ao usar uma instância do ALB voltada para a internet, as plataformas de terceiros (como a WeChat Merchant Platform ou callbacks de pagamento) devem vincular o elastic IP address (EIP) da instância do ALB, e não o endereço IP de uma instância do Elastic Compute Service (ECS) de backend.

Uma instância do ALB voltada para a internet fornece services por meio de seu EIP. Todo o tráfego externo, incluindo solicitações de callback de plataformas de terceiros, entra pelo EIP da instância do ALB e o ALB o encaminha para os servidores de backend. As instâncias do ECS de backend usam endereços IP privados dentro da Virtual Private Cloud (VPC), os quais não ficam expostos a chamadores externos. Mesmo que haja várias instâncias do ECS de backend, você só precisa vincular o EIP da instância do ALB na plataforma de terceiros.

O caminho do tráfego de uma instância do ALB voltada para a internet é o seguinte: solicitação do cliente > EIP do ALB (ponto de entrada público) > encaminhamento interno pelo ALB > endereço IP privado da instância do ECS de backend. Depois que uma solicitação de callback de uma plataforma de terceiros entra pela internet, ela atinge apenas o EIP da instância do ALB, e o ALB a encaminha para as instâncias do ECS de backend. Durante todo o processo, a plataforma de terceiros se comunica apenas com o EIP da instância do ALB, e os endereços IP privados das instâncias do ECS de backend permanecem invisíveis para os chamadores externos.

O ALB suporta espelhamento de tráfego?

Sim. Para obter mais informações, consulte Use ALB Traffic Mirroring for Stress Testing.

Falha ao atingir o limite de QPS do listener

• Como funciona: o sistema de balanceamento de carga usa um cluster de servidores para atender a cada instância do ALB. Esse cluster distribui uniformemente as solicitações de entrada entre seus servidores para encaminhamento. Portanto, o sistema também distribui o limite de QPS definido em uma regra de encaminhamento entre esses servidores.

  O sistema calcula o limite de QPS para um único servidor usando a seguinte fórmula: QPS limit per system server = Total QPS set / (N-1). N é o número de servidores do sistema no grupo de encaminhamento. Por exemplo, se você definir o limite de QPS para uma regra de encaminhamento como 1.000 QPS no console e houver 8 servidores do sistema, o QPS máximo para um único servidor do sistema será 1000/(8-1) = 142 QPS.

• Causa: com um número pequeno de conexões persistentes, alguns servidores do sistema no grupo de encaminhamento podem não receber nenhuma conexão. Isso pode impedir que a instância do ALB atinja o limite de QPS.

• Recomendação: defina um limite de QPS razoável para suas regras de encaminhamento com base nos requisitos do seu negócio. Isso garante a disponibilidade dos seus services e evita limitações inesperadas. Para obter mais informações sobre como definir um limite de QPS em uma regra de encaminhamento de listener, consulte Add a forwarding rule.

Limites de comprimento de solicitação

Escopo do tempo de processamento do ALB

Sim, o tempo de processamento do ALB inclui o tempo de recebimento e envio de dados do cliente.

• Tempo de recebimento dos dados do cliente: este é o read_request_time, o tempo total que o balanceador de carga leva para ler uma solicitação do cliente. Inclui o tempo para ler o cabeçalho da solicitação HTTP (read_header_time) e o corpo da solicitação (read_body_time).

• Tempo de envio dos dados de resposta: inclui o tempo de retorno dos dados de resposta ao cliente.

Máximo de solicitações por conexão persistente

Uma única conexão persistente suporta no máximo 100 solicitações consecutivas. Se esse limite for excedido, o sistema fechará a conexão automaticamente.

Esse limite aumenta para 1.000 se você usar um listener HTTPS e ativar o HTTP/2.

Limite de comprimento do Client Hello para listeners QUIC

Ao usar um listener QUIC, o ALB impõe um comprimento mínimo para o Client Hello do cliente. O pacote deve ter pelo menos 1.024 bytes. Caso contrário, o ALB retorna um erro "client hello too small" e fecha a conexão. Para passar nessa verificação, preencha o pacote Client Hello com caracteres nulos para atender ao requisito de 1.024 bytes.

Considerações para o ALB Ingress

Na maioria dos casos, não modifique manualmente as instâncias do ALB criadas pelo ALB Ingress no console. Use o AlbConfig como a source da verdade para as configurações do ALB. Para obter mais informações sobre o ALB Ingress, consulte Overview of ALB Ingresses e Use an ALB Ingress.

Se você fizer alterações manuais no console, elas não serão refletidas no recurso AlbConfig. A próxima sincronização do AlbConfig substituirá essas alterações manuais. Isso pode causar problemas, como logs de acesso desativados ou regras de encaminhamento excluídas.

Quando a persistência de sessão está desativada, várias solicitações do mesmo cliente são encaminhadas para o mesmo servidor de backend?

Podem ser, mas o ALB não garante isso. Quando a persistência de sessão está desativada, o ALB não registra o mapeamento entre um cliente e um servidor de backend. Em vez disso, ele trata cada solicitação como independente e seleciona um servidor de backend com base no scheduling algorithm configurado para o grupo de servidores. Para garantir que as solicitações do mesmo cliente sejam sempre encaminhadas para o mesmo servidor de backend, ative a session persistence para o grupo de servidores.

Perguntas frequentes sobre cross-origin do ALB

Referenciar valores de cabeçalho originais

Em Key, insira o nome do cabeçalho que você deseja gravar. Em Value, selecione o método de referência e insira o nome do cabeçalho original cujo valor você deseja referenciar. No exemplo a seguir, o sistema grava um novo cabeçalho chamado abc-abc, que referencia o valor do cabeçalho original abc. A regra de encaminhamento extrai o valor do cabeçalho original abc e o atribui ao novo cabeçalho abc-abc.

A condição para essa regra de encaminhamento é uma correspondência exata de caminho para /. Além da ação de gravação de cabeçalho, a regra também é configurada para Forward to um grupo de servidores específico com peso 100.

Cliente

Quando o cliente envia uma solicitação usando curl, ele inclui o cabeçalho de solicitação personalizado abc:123456 com o parâmetro -H. O servidor retorna 200 OK. O código a seguir mostra um comando de exemplo e sua saída:

curl http://xxx.xxx.174 -v -k -H abc:123456
*   Trying xxx.xxx.174:80...
* Connected to xxx.xxx.174 (xxx.xxx.174) port 80
> GET / HTTP/1.1
> Host: xxx.xxx 174
> User-Agent: curl/8.4.0
> Accept: */*
> abc:123456
>
< HTTP/1.1 200 OK
< Date: Sat, 13 Sep 2025 16:18:38 GMT
< Content-Type: text/html
< Content-Length: 4833
< Connection: keep-alive
< Vary: Accept-Encoding
< Set-Cookie: acw_tc=0a2a24fb17577803180911860e42646551283f5ec94793498a70af97834171;path=/;HttpOnly;Max-Age=1800
< Last-Modified: Fri, 16 May 2014 15:12:48 GMT
< ETag: "53762af0-12e1"
< Accept-Ranges: bytes

Servidor

GET / HTTP/1.1
RemoteIp: xxx.xxx.xxx.103
Host: xxx.xxx.xxx.174
X-Forwarded-For: xxx.xxx.xxx.103
User-Agent: curl/8.4.0
Accept: */*
abc: 123456
X-Sinfo: on
abc-abc: 123456
HTTP/1.1 200 OK
Server: nginx/1.20.1
Date: Sat, 13 Sep 2025 16:18:38 GMT
Content-Type: text/html
Content-Length: 4833

Autenticação mútua de CA

As instâncias do ALB Basic Edition não suportam autenticação mútua de CA. As instâncias do ALB Standard Edition e WAF-enabled Edition suportam autenticação mútua de CA quando você add an HTTPS listener. Se precisar usar o recurso de autenticação mútua de CA para uma instância do ALB Basic Edition, upgrade the instance edition.

Regras para certificados curinga

Upload de certificados

Não.

O ALB usa certificados do Alibaba Cloud SSL Certificates service. Portanto, faça o upload dos certificados para o console do SSL Certificate em vez do console do ALB. Para obter mais informações, consulte Upload an SSL Certificate.

Data de expiração do certificado inalterada

Esse problema geralmente ocorre quando sua instância do ALB está integrada ao WAF 2.0 no modo de proxy transparente e o certificado no WAF não foi atualizado. O WAF sincroniza os certificados do ALB periodicamente. Para acionar uma atualização imediata, desative e, em seguida, reative o desvio de tráfego para o seu domínio no console do WAF. Essa ação força a atualização do certificado. Note que essa operação causa uma breve interrupção de service de 1 a 2 segundos.

Modificar a configuração de verificação de integridade

1. Faça login no console do Application Load Balancer (ALB).

2. No painel de navegação à esquerda, escolha ALB > Server Groups.

3. Na página Server Groups, encontre o grupo de servidores de destino e clique em seu ID.

4. Na guia Details, na seção Health Check, clique em Modify Health Check.

5. Na caixa de diálogo Modify Health Check, clique em Edit ao lado de Health Check Settings, edite as configurações de verificação de integridade e clique em Save e salve.

   Para obter mais informações, consulte ALB health check.

Erros 502 apesar das verificações de integridade bem-sucedidas

Isso geralmente ocorre porque a carga nos servidores de backend da instância do ALB está muito alta. Cargas muito altas nos servidores de backend da instância do ALB podem causar inconsistências entre os resultados da verificação de integridade e os resultados da solicitação de acesso. Para obter informações sobre como verificar a carga do servidor de backend, consulte Troubleshooting and handling high load issues on Linux instances.

Encaminhamento de solicitações quando as verificações de integridade falham

A instância do ALB ainda encaminha solicitações com base no algoritmo de agendamento configurado para minimizar a interrupção do service. Se as solicitações não forem tratadas conforme o esperado, verifique se há erros do servidor de backend nos seus logs ou revise sua configuração de verificação de integridade para identificar problemas. Para obter mais informações, consulte Troubleshoot ALB health check failures.

Serviço inacessível via ALB

Siga estas etapas para diagnosticar o problema:

1. Verifique a resolução do nome de domínio (CNAME): não é possível acessar diretamente uma nova instância do ALB usando seu nome DNS. Mapeie seu nome de domínio personalizado para o nome DNS da instância do ALB usando um registro CNAME. Use o comando nslookup ou dig para verificar a resolução. Para obter mais informações, consulte ALB Instance DNS Names.

2. Verifique o tipo de rede da instância: uma instância do ALB de rede privada só pode ser acessada de dentro de sua Virtual Private Cloud (VPC). Para ativar o acesso público, altere o tipo de rede da instância para pública e associe um Elastic IP (EIP). Para obter mais informações, consulte Change the Network Type of an ALB Instance.

3. Verifique o listener e as regras de encaminhamento: no console do ALB, verifique se um listener foi criado com a porta e o protocolo corretos. Além disso, confirme se as regras de encaminhamento estão configuradas para corresponder ao nome de domínio e ao caminho das solicitações recebidas.

4. Verifique o status da verificação de integridade: no console do ALB, verifique o status da verificação de integridade dos seus servidores de backend. A instância do ALB não encaminha solicitações para servidores de backend não íntegros.

5. Confirme se o service de backend está em execução corretamente: faça login em um servidor de backend e execute o comando curl -I http://<backend_server_private_IP>:<port> para confirmar se o service de backend responde corretamente.

6. Verifique as configurações de controle de acesso e firewall: certifique-se de que as configurações de controle de acesso ou as regras do grupo de segurança da instância do ALB permitam o intervalo de endereços IP de origem do cliente. Além disso, confirme se o iptables ou o software de segurança de terceiros nas instâncias do Elastic Compute Service (ECS) de backend permitem o intervalo de endereços IP locais da instância do ALB.

Solucionar problemas de alta latência

O ALB opera na camada de aplicação, o que significa que ele encaminha as solicitações para os servidores de backend. Esse processo introduz uma pequena latência adicional em comparação com o acesso direto aos servidores de backend. Esse é um comportamento esperado.

Se a latência estiver significativamente alta, siga estas etapas para solucionar o problema:

1. Ative os logs de acesso e analise os campos de latência: ative ALB Access Logs e concentre-se nos seguintes campos:

   • request_time: o tempo em segundos desde o momento em que o balanceador de carga recebe o primeiro pacote de solicitação até o momento em que envia a resposta.

   • upstream_response_time: o tempo em segundos desde o momento em que o balanceador de carga começa a se conectar a um servidor de backend até receber todos os dados e fechar a conexão.

2. Identifique a origem da latência:

   • Se o upstream_response_time estiver alto, os servidores de backend provavelmente são a origem da latência. Verifique o desempenho do seu aplicativo de backend, a eficiência das suas consultas de banco de dados e o uso de recursos como CPU e memória. Você também pode adicionar mais servidores de backend para distribuir a carga.

   • Se o request_time for muito maior que o upstream_response_time, a latência provavelmente está no caminho de rede entre o cliente e a instância do ALB. A partir do cliente, execute testes contínuos de ping ou um rastreamento MTR para o endereço do service ALB para diagnosticar problemas no link de rede.

3. Considere cenários de acesso entre regiões: se o cliente e a instância do ALB estiverem em regiões diferentes, a latência de rede devido à distância física é inevitável. Recomendamos o uso do Global Accelerator (GA) para otimizar a experiência de acesso entre regiões.

Serviço inacessível via nome de domínio

Após mapear seu nome de domínio personalizado para o nome DNS da instância do ALB com um registro CNAME, você ainda pode não conseguir acessar o service. Se receber um erro HTTP 403 ou uma redefinição de conexão, a causa provavelmente é um registro ICP incompleto para o seu nome de domínio.

Siga estas etapas para diagnosticar o problema:

1. Verifique a configuração do registro CNAME: use o comando nslookup ou dig para verificar se o seu nome de domínio é resolvido corretamente para o nome DNS da instância do ALB. Para obter mais informações, consulte Configure a CNAME Record.

2. Verifique o status do registro ICP do seu nome de domínio: de acordo com os regulamentos, os nomes de domínio usados para acesso público na China continental devem ter um registro ICP válido. Caso contrário, o sistema bloqueará o acesso. Faça login no sistema de registro ICP da Alibaba Cloud para verificar o status de registro do seu nome de domínio. Se não estiver registrado, conclua primeiro o processo de registro ICP. Para obter mais informações, consulte ICP Filing Process.

3. Determine se é necessária uma transferência de registro ICP: se o seu nome de domínio foi registrado por meio de outro provedor de services de nuvem e você o está usando com a Alibaba Cloud pela primeira vez, é necessário concluir uma transferência de registro ICP. Esse processo registra suas informações de registro na Alibaba Cloud. O acesso poderá ser bloqueado se a transferência não estiver concluída.

500 (Internal Server Error)

O servidor de backend encontrou um erro interno e não pôde processar a solicitação.

• O backend retorna 500 diretamente: verifique o log de acesso. Se o upstream_status for 500, o ALB provavelmente repassou o código de status do backend. Investigue o service de backend.

• O servidor de backend fechou a conexão inesperadamente: o servidor de backend fechou a conexão antes de enviar uma resposta completa. Capture pacotes no servidor de backend para identificar a causa do fechamento inesperado da conexão.

502 (Bad Gateway)

Esse erro ocorre quando um listener HTTP ou HTTPS recebe uma solicitação de cliente, mas o ALB falha ao encaminhar a solicitação para um servidor de backend ou não recebe uma resposta dele.

Abordagem de solução de problemas: primeiro, verifique o valor do campo upstream_status no log de acesso para determinar as próximas etapas.

• Se upstream_status = 502: o ALB repassou o código de status 502 do servidor de backend. O problema está no próprio service de backend. Investigue seu service de backend. Por exemplo, verifique se uma camada de Nginx ou gateway de backend está tentando fazer proxy reverso para um upstream inacessível.

• Se upstream_status for outro valor (como 504, 444 ou 500): o status que o ALB retorna ao cliente é diferente do upstream_status, o que significa que o ALB alterou o código de status. Investigue por que o service de backend está retornando esse código de status específico verificando os logs do Nginx, gateway ou aplicativo de backend.

• Se upstream_status for - ou estiver vazio: o ALB não recebeu nenhuma resposta do backend. Isso significa que a solicitação nunca chegou ao backend ou o sistema encerrou a conexão com o backend anormalmente antes do envio de uma resposta. Verifique as seguintes causas em ordem:

  • A comunicação TCP entre o ALB e o servidor de backend está falhando. Verifique se o service de backend está em execução, se a porta do service está escutando corretamente e se nenhuma regra do iptables ou software de segurança de terceiros no ECS de backend bloqueia o bloco CIDR do vSwitch onde a instância do ALB está localizada. O ALB se comunica com os servidores de backend usando um Local IP atribuído pelo vSwitch. Capture pacotes para verificar se o handshake TCP foi bem-sucedido.

  • O backlog do servidor de backend está cheio. Isso faz com que o servidor descarte novas solicitações de conexão. Execute netstat -s | grep -i listen no servidor de backend e verifique se há um contador de drop.

  • O servidor de backend falhou ao processar a solicitação a tempo. Verifique os logs do servidor de backend e revise o uso de CPU e memória para identificar quaisquer gargalos de desempenho.

  • O tamanho do pacote da solicitação do cliente excede a MTU do servidor de backend. Isso pode fazer com que pacotes curtos (como verificações de integridade) tenham êxito, enquanto pacotes longos falham. Capture pacotes no servidor de backend para analisar se o comprimento do pacote está dentro dos limites exigidos.

  • A resposta do servidor de backend tem um formato inválido ou contém cabeçalhos HTTP inválidos. Capture pacotes no servidor de backend para analisar se o formato da resposta está em conformidade com o padrão.

503 (Service Temporarily Unavailable)

O servidor está temporariamente indisponível, geralmente devido ao tráfego que excede os limites ou a um service de backend indisponível.

• O backend retorna 503 diretamente: verifique o log de acesso. Se o upstream_status for 503, o ALB provavelmente repassou o código de status do backend. Investigue o service de backend.

• A solicitação do cliente aciona o limitador do ALB:

  • Em Cloud Monitor, verifique a métrica Requests per second.

  • O Cloud Monitor exibe dados no nível de minuto e pode não refletir picos no nível de segundo. Verifique o log de acesso. Se o campo upstream_status for -, a solicitação não chegou ao servidor de backend.

  • Verifique o cabeçalho do pacote de resposta. Se ele contiver o campo ALB-QPS-Limited:Limited, a solicitação acionou o limitador do ALB.

• Acesso direto por IP ou resolução de DNS anormal: isso pode concentrar o tráfego em apenas alguns endereços IP e acionar o limitador. Acesse o ALB por meio do seu nome de domínio (consulte Configure a CNAME for an ALB instance) e verifique se a resolução de DNS funciona conforme o esperado.

• O listener não tem servidores de backend configurados, ou os servidores de backend configurados têm peso 0.

504 (Gateway Time-out)

O ALB atingiu o tempo limite enquanto aguardava uma resposta do servidor de backend.

• O backend retorna 504 diretamente: verifique o log de acesso. Se o upstream_status for 504, o ALB provavelmente repassou o código de status do backend. Investigue o service de backend.

• A tentativa de conexão do ALB com o servidor de backend atinge o tempo limite: esse tempo limite é de 5 segundos por padrão e não é possível alterá-lo. Capture pacotes para identificar por que o servidor de backend não responde a tempo.

• Tempo limite de resposta do backend: o connection request timeout é de 60 segundos por padrão. Verifique a métrica UpstreamResponseTime no Cloud Monitor e o campo upstream_response_time no log de acesso para determinar se a resposta do servidor de backend atingiu o tempo limite.

Integração transparente do WAF 2.0 versus integração baseada em service do WAF 3.0

Para obter mais informações, consulte Comparison of WAF 3.0 and WAF 2.0.

Integração do ALB e WAF

• Recomendamos que você enable WAF 3.0 protection for an ALB instance usando a integração baseada em service do WAF 3.0. Isso significa usar uma instância do ALB aprimorada com WAF.

  • Regiões suportadas:

    Área	Região
    China	China (Chengdu), China (Qingdao), China (Beijing), China (Guangzhou), China (Hangzhou), China (Ulanqab), China (Shanghai), China (Shenzhen), China (Zhangjiakou), China (Hong Kong), e China (Heyuan)
    Ásia-Pacífico	Philippines (Manila), Indonesia (Jakarta), Japan (Tokyo), Malaysia (Kuala Lumpur), Singapore, Thailand (Bangkok) e South Korea (Seoul)
    Europa e Américas	Germany (Frankfurt), US (Silicon Valley), US (Virginia) e Mexico
    Oriente Médio	SAU (Riyadh - Partner Region) e UAE (Dubai)

  • As instâncias do ALB com WAF ativado usam o modelo de integração do SDK do WAF 3.0. Se você tiver uma instância do WAF 2.0 na sua conta, primeiro release the WAF 2.0 instance ou migrate it to WAF 3.0.

    Por padrão, o ALB não adiciona o cabeçalho X-Forwarded-Proto às solicitações. Após liberar uma instância do WAF 2.0, acessar a instância do ALB diretamente pode causar problemas de service, como redirecionamentos infinitos, porque os servidores de backend não conseguem identificar o protocolo original (HTTP ou HTTPS). Para evitar esse problema, ative manualmente o cabeçalho de solicitação X-Forwarded-Proto na configuração do listener do ALB.

  • As instâncias do ALB com WAF ativado não suportam o recurso de prevenção de vazamento de dados do WAF.

• Se quiser usar uma instância existente do WAF 2.0, as instâncias do ALB Basic e Standard voltadas para a internet suportam a integração transparente do WAF 2.0 nas seguintes regiões: China (Hangzhou), China (Shanghai), China (Shenzhen), China (Chengdu), China (Beijing) e China (Zhangjiakou). As instâncias do ALB voltadas para rede interna não suportam a integração transparente do WAF 2.0.

Suporte à integração do WAF para CLB e ALB

Problemas de integração transparente do WAF 2.0

Em uma integração transparente do WAF 2.0, as solicitações do cliente passam pelo WAF para inspeção antes de o WAF as enviar para uma instância do ALB ou CLB. Esse caminho de dois gateways exige a sincronização de várias configurações entre o WAF e o balanceador de carga. Alterações em tempos limite e certificados são especialmente propensas a atrasos na sincronização de configurações.