Application Load Balancers - Elastic Load Balancing
Sub-redes para seu balanceador de cargaGrupos de segurança do balanceador de cargaEstado do load balancerAtributos do load balancerTipo de endereço IPMapa de recursos do balanceador de cargaConexões do balanceador de cargaBalanceamento de carga entre zonasProteção contra exclusãoModo de mitigação de dessincronizaçãoPreservação de cabeçalho do hostAWS WAF

As traduções são geradas por tradução automática. Em caso de conflito entre o conteúdo da tradução e da versão original em inglês, a versão em inglês prevalecerá.

Application Load Balancers

Um load balancer serve como ponto único de contato para os clientes. Os clientes enviam solicitações para o load balancer e o load balancer as envia para os destinos, como instâncias do EC2. Para configurar o load balancer, você cria grupos de destino e, em seguida, registra os destinos nesses grupos. Você também pode criar listeners para verificar a solicitações de conexão de clientes, além de regras dos listeners para rotear solicitações dos clientes para os destinos em um ou mais grupos de destino.

Para obter mais informações, consulte Como o Elastic Load Balancing funciona no Manual do usuário do Elastic Load Balancing.

Conteúdo

Sub-redes para seu balanceador de carga

Ao criar um Application Load Balancer, você deve habilitar as zonas que contêm seus destinos. Para habilitar uma zona, especifique uma sub-rede na zona. O Elastic Load Balancing cria um nó de balanceador de carga em cada zona que você especificar.

Considerações

  • O balanceador de carga será mais eficaz se você garantir que cada zona de disponibilidade habilitada tenha ao menos um destino registrado.

  • Se você registrar destinos em uma zona, mas não habilitá-la, esses destinos registrados não receberão tráfego do balanceador de carga.

  • Se você habilitar várias zonas para seu balanceador de carga, elas precisarão ser do mesmo tipo. Por exemplo, você não pode habilitar uma zona de disponibilidade e uma zona local.

  • Você pode especificar uma sub-rede que tenha sido compartilhada com você.

Os Application Load Balancers são compatíveis com os seguintes tipos de sub-redes.

Sub-redes de zona de disponibilidade

Você deve selecionar ao menos duas sub-redes de zona de disponibilidade. As seguintes restrições são aplicáveis:

  • Cada sub-rede deve estar em uma zona de disponibilidade diferente.

  • Para garantir que o balanceador de carga possa escalar corretamente, verifique se cada sub-rede da zona de disponibilidade do balanceador de carga tem um bloco CIDR com ao menos uma bitmask /27 (por exemplo, 10.0.0.0/27) e pelo menos oito endereços IP livres por sub-rede. Esses oito endereços IP são necessários para permitir que o balanceador de carga aumente a escala horizontalmente, se for o caso. Seu load balancer usa esses endereços IP para estabelecer conexões com os destinos. Sem eles, seu Application Load Balancer pode ter dificuldades com as tentativas de substituição de nós, fazendo com que ele entre em um estado de falha.

    Obs.: se uma sub-rede do Application Load Balancer ficar sem endereços IP utilizáveis ao tentar escalar, o Application Load Balancer será executado com capacidade insuficiente. Durante esse período, os nós antigos continuarão a fornecer tráfego, mas a tentativa paralisada de escalonamento poderá causar erros 5xx ou tempos limite ao tentar estabelecer uma conexão.

Sub-redes de zona local

Você pode especificar uma ou mais sub-redes de zona local. As seguintes restrições são aplicáveis:

  • Você não pode usar AWS WAF com o balanceador de carga.

  • Não é possível usar uma função do Lambda como destino.

  • Você não pode usar sessões fixas ou aderência de aplicativos.

Sub-redes de Outpost

Você pode especificar uma só sub-rede de Outpost. As seguintes restrições são aplicáveis:

  • Um Outpost deve estar instalado e configurado no data center on-premises. É necessário ter uma conexão de rede confiável entre o Outpost e a região da AWS . Para mais informações, consulte o Guia do usuário do AWS Outposts.

  • O balanceador de carga requer duas instâncias large no Outpost para os nós do balanceador de carga. Os tipos de instância compatíveis são apresentados na tabela a seguir. O balanceador de carga escala conforme necessário, redimensionando os nós um tamanho por vez (de large para xlarge, depois de xlarge para 2xlarge e depois de 2xlarge para 4xlarge). Após escalar os nós para o maior tamanho de instância, se você precisar de capacidade adicional, o balanceador de carga adicionará instâncias 4xlarge como nós do balanceador de carga. Se você não tiver capacidade de instância suficiente ou endereços IP disponíveis para escalar o balanceador de carga, o balanceador de carga relatará um evento para o AWS Health Dashboard e o estado do balanceador de carga será active_impaired.

  • É possível registrar destinos por ID de instância ou por endereço IP. Se você registrar alvos na AWS região para o Posto Avançado, eles não serão usados.

  • Os seguintes recursos não estão disponíveis: funções do Lambda como destinos, integração com AWS WAF , sessões persistentes, compatibilidade com autenticação e integração com AWS Global Accelerator.

É possível implantar um Application Load Balancer em instâncias c5/c5d, m5/m5d ou r5/r5d em um Outpost. A tabela a seguir mostra o tamanho e o volume do EBS por tipo de instância que o balanceador de carga pode usar em um Outpost:

Tipo e tamanho de instância Volume do EBS (GB)
c5/c5d
grande 50
xlarge 50
2xlarge 50
4xlarge 100
m5/m5d
grande 50
xlarge 50
2xlarge 100
4xlarge 100
r5/r5d
grande 50
xlarge 100
2xlarge 100
4xlarge 100

Grupos de segurança do balanceador de carga

Um security group atua como um firewall que controla o tráfego permitido de e para o load balancer. Você pode escolher as portas e os protocolos para permitir tráfego tanto de entrada quanto de saída.

As regras para os grupos de segurança que estão associados ao balanceador de carga devem permitir tráfego em ambas as direções tanto no receptor quanto nas portas de verificação de integridade. Sempre que você adicionar um listener a um load balancer ou atualizar a porta de verificação de integridade de um grupo de destino, será necessário revisar as regras do security group para garantir que elas permitam tráfego na nova porta em ambas as direções. Para ter mais informações, consulte Regras recomendadas.

Estado do load balancer

O load balancer pode estar em um dos seguintes estados:

provisioning

O load balancer está sendo configurado.

active

O load balancer está totalmente configurado e pronto para rotear o tráfego.

active_impaired

O balanceador de carga está roteando o tráfego, mas não tem os recursos necessários para escalar.

failed

O load balancer não pôde ser configurado.

Atributos do load balancer

A seguir estão os atributos do load balancer:

access_logs.s3.enabled

Indica se os logs de acesso armazenados no Amazon S3 estão habilitados. O padrão é false.

access_logs.s3.bucket

O nome do bucket do Amazon S3 para os logs de acesso. Esse atributo é necessário se os logs de acesso estiverem habilitados. Para ter mais informações, consulte Habilitar logs de acesso.

access_logs.s3.prefix

O prefixo para o local no bucket do Amazon S3.

client_keep_alive.seconds

O valor do keepalive do cliente, em segundos. O padrão é 3600 segundos.

deletion_protection.enabled

Indica se a proteção contra exclusão está habilitada. O padrão é false.

idle_timeout.timeout_seconds

O valor de tempo limite de inatividade, em segundos. O padrão é 60 segundos.

ipv6.deny_all_igw_traffic

Bloqueia o acesso do gateway da Internet (IGW) ao balanceador de carga, impedindo o acesso não intencional ao balanceador de carga interno por meio de um gateway da Internet. Ele está configurado como false para balanceadores de carga voltados para a Internet e true para balanceadores de carga internos. Esse atributo não impede o acesso à Internet que não seja IGW (como, por meio de peering, AWS Direct Connect Transit Gateway ou). AWS VPN

routing.http.desync_mitigation_mode

Determina como o balanceador de carga processa solicitações que possam representar risco de segurança para a sua aplicação. Os valores possíveis são monitor, defensive e strictest. O padrão é defensive.

routing.http.drop_invalid_header_fields.enabled

Indica se os cabeçalhos HTTP com campos de cabeçalho que não sejam válidos serão removidos pelo balanceador de carga (true) ou roteados para destinos (false). O padrão é false. O Elastic Load Balancing exige que os nomes de cabeçalhos HTTP válidos estejam em conformidade com a expressão regular'[-A-Za-z0-9]+, conforme descrito no Registro de nomes de campos HTTP. Cada nome consiste em caracteres alfanuméricos ou hifens. Selecione true se quiser que os cabeçalhos HTTP que não estejam em conformidade com esse padrão sejam removidos das solicitações.

routing.http.preserve_host_header.enabled

Indica se o Application Load Balancer deve preservar o cabeçalho Host na solicitação HTTP e enviá-lo para o destino sem nenhuma alteração. Os valores possíveis são true e false. O padrão é false.

routing.http.x_amzn_tls_version_and_cipher_suite.enabled

Indica se os dois cabeçalhos (x-amzn-tls-version e x-amzn-tls-cipher-suite), que contêm informações sobre a versão negociada do TLS e o conjunto de cifras, serão adicionados à solicitação do cliente antes de enviá-la ao destino. O cabeçalho x-amzn-tls-version tem informações sobre a versão do protocolo TLS negociada com o cliente e o cabeçalho x-amzn-tls-cipher-suite tem informações sobre o pacote de criptografia negociado com o cliente. Ambos os cabeçalhos estão no formato OpenSSL. Os valores possíveis para o atributo são true e false. O padrão é false.

routing.http.xff_client_port.enabled

Indica se o cabeçalho X-Forwarded-For deve preservar a porta de origem que o cliente usou para se conectar ao balanceador de carga. Os valores possíveis são true e false. O padrão é false.

routing.http.xff_header_processing.mode

Permite que você modifique, preserve ou remova o cabeçalho X-Forward-For na solicitação HTTP antes que o Application Load Balancer envie a solicitação ao destino. Os valores possíveis são append, preserve e remove. O padrão é append.

  • Se o valor for append, o Application Load Balancer adicionará o endereço IP do cliente (do último salto) ao cabeçalho X-Forward-For na solicitação HTTP antes de enviá-la aos destinos.

  • Se o valor for preserve, o Application Load Balancer deverá preservar o cabeçalho X-Forward-For na solicitação HTTP e enviá-lo para o destino sem nenhuma alteração.

  • Se o valor for remove, o Application Load Balancer removerá o cabeçalho X-Forward-For na solicitação HTTP e o enviará para o destino sem nenhuma alteração.

routing.http2.enabled

Indica se HTTP/2 está habilitado. O padrão é true.

waf.fail_open.enabled

Indica se um balanceador de carga AWS WAF habilitado deve encaminhar solicitações para destinos caso não consiga encaminhar a solicitação para o. AWS WAF Os valores possíveis são true e false. O padrão é false.

nota

O atributo routing.http.drop_invalid_header_fields.enabled foi introduzido para oferecer proteção contra a dessincronização HTTP. O atributo routing.http.desync_mitigation_mode foi adicionado para fornecer uma proteção mais abrangente contra a dessincronização HTTP para suas aplicações. Você não precisa usar os dois atributos e pode escolher qualquer um deles de acordo com os requisitos da sua aplicação.

Tipo de endereço IP

É possível definir os tipos de endereços IP que os clientes podem usar para acessar seus balanceadores de carga internos e voltados para a Internet.

Os Application Load Balancers oferecem suporte aos seguintes tipos de endereço IP:

ipv4

Os clientes devem se conectar ao load balancer usando endereços IPv4 (por exemplo, 192.0.2.1)

dualstack

Os clientes podem se conectar ao load balancer usando endereços IPv4 (por exemplo, 192.0.2.1) e endereços IPv6 (por exemplo, 2001:0db8:85a3:0:0:8a2e:0370:7334).

Considerações

  • O balanceador de carga se comunica com os destinos com base no tipo de endereço IP do grupo de destino.

  • Quando você habilita o modo dualstack para o balanceador de carga, o Elastic Load Balancing fornece um registro DNS AAAA para o balanceador de carga. Os clientes que se comunicam com o load balancer usando endereços IPv4 resolvem o registro DNS A. Os clientes que se comunicam com o load balancer usando endereços IPv6 resolvem o registro DNS AAAA.

  • O acesso aos balanceadores de carga dualstack internos por meio do gateway da Internet é bloqueado para impedir o acesso não intencional à Internet. No entanto, isso não impede o acesso à Internet que não seja IGW (como, por meio de peering, AWS Direct Connect Transit Gateway ou). AWS VPN

dualstack-without-public-ipv4

Os clientes devem se conectar ao balanceador de carga usando endereços IPv6 (por exemplo, 2001:0 db 8:85 a 3:0:0:8 a2e: 0370:7334).

Considerações

  • A autenticação do Application Load Balancer só oferece suporte a IPv4 ao se conectar a um provedor de identidade (IdP) ou endpoint do Amazon Cognito. Sem um endereço IPv4 público, o balanceador de carga não pode concluir o processo de autenticação, resultando em erros HTTP 500.

Para obter mais informações sobre os tipos de endereço IP, consulteTipos de endereço IP para seu Application Load Balancer.

Mapa de recursos do Application Load Balancer

O mapa de recursos do Application Load Balancer fornece uma exibição interativa da arquitetura do seu balanceador de carga, incluindo seus ouvintes, regras, grupos-alvo e destinos associados. O mapa de recursos também destaca os relacionamentos e os caminhos de roteamento entre todos os recursos, produzindo uma representação visual da configuração do seu balanceador de carga.

Para visualizar o mapa de recursos do seu Application Load Balancer usando o console

  1. Abra o console do Amazon EC2 em https://console.aws.amazon.com/ec2/.

  2. No painel de navegação, selecione Balanceador de carga.

  3. Selecione o load balancer.

  4. Escolha a guia Mapa de recursos para exibir o mapa de recursos do balanceador de carga.

Componentes do mapa de recursos

Visualizações do mapa

Há duas visualizações disponíveis no mapa de recursos do Application Load Balancer: Overview e Unhealthy Target Map. A opção Visão geral é selecionada por padrão e exibe todos os recursos do seu balanceador de carga. Selecionar a visualização Mapa de Alvos Insalubres exibirá somente os alvos não íntegros e os recursos associados a eles.

A visualização Mapa de alvos não íntegros pode ser usada para solucionar problemas de alvos que estão falhando nas verificações de integridade. Para ter mais informações, consulte Solucione problemas de alvos não íntegros usando o mapa de recursos.

Grupos de recursos

O mapa de recursos do Application Load Balancer contém quatro grupos de recursos, um para cada tipo de recurso. Os grupos de recursos são Listeners, Rules, Target groups e Targets.

Blocos de recursos

Cada recurso dentro de um grupo tem seu próprio quadro, que exibe detalhes sobre esse recurso específico.

  • Passar o mouse sobre um bloco de recursos destaca as relações entre ele e outros recursos.

  • Selecionar um bloco de recursos destaca as relações entre ele e outros recursos e exibe detalhes adicionais sobre esse recurso.

    • condições da regra: as condições de cada regra.

    • resumo de saúde do grupo-alvo: o número de alvos registrados para cada estado de saúde.

    • status de saúde do alvo O status de saúde atual e a descrição do alvo.

    nota

    Você pode desativar Mostrar detalhes do recurso para ocultar detalhes adicionais no mapa do recurso.

  • Cada bloco de recursos contém um link que, quando selecionado, navega até a página de detalhes desse recurso.

    • Ouvintes ‐ Selecione o protocolo de ouvintes: porta. Por exemplo, HTTP:80.

    • Regras ‐ Selecione a ação das regras. Por exemplo, Forward to target group.

    • Grupos-alvo ‐ Selecione o nome do grupo-alvo. Por exemplo, my-target-group.

    • Alvos ‐ Selecione o ID dos alvos. Por exemplo, i-1234567890abcdef0.

Exportar o mapa de recursos

Selecionar Exportar oferece a opção de exportar a visualização atual do mapa de recursos do Application Load Balancer como PDF.

Conexões do balanceador de carga

Ao processar uma solicitação, o balanceador de carga mantém duas conexões: uma conexão com o cliente e outra com o destino. A conexão entre o balanceador de carga e o cliente também é chamada de conexão front-end. A conexão entre o balanceador de carga e o destino também é chamada de conexão de back-end.

Tempo limite de inatividade da conexão

O tempo limite de inatividade da conexão é o período em que uma conexão existente de cliente ou destino pode permanecer inativa, sem que nenhum dado seja enviado ou recebido, antes que o balanceador de carga feche a conexão.

Para garantir que operações demoradas, como uploads de arquivos, tenham tempo de ser concluídas, envie pelo menos 1 byte de dados antes que cada período de tempo limite de inatividade termine e aumente a duração do período de inatividade conforme necessário. Recomendamos também que você configure o tempo limite de inatividade do seu aplicativo como um valor maior do que o tempo limite de inatividade configurado para o load balancer. Caso contrário, se a aplicação fechar a conexão TCP com o balanceador de carga incorretamente, o balanceador de carga poderá enviar uma solicitação à aplicação antes de receber o pacote indicando que a conexão foi fechada. Se isso acontecer, o balanceador de carga enviará um erro HTTP 502 Gateway inadequado para o cliente.

Por padrão, o Elastic Load Balancing define o valor do tempo limite de inatividade do seu load balancer como 60 segundos ou 1 minuto. Use o procedimento a seguir para definir um valor de tempo limite ocioso diferente.

Para atualizar o valor do tempo limite de inatividade da conexão usando o console

  1. Abra o console do Amazon EC2 em https://console.aws.amazon.com/ec2/.

  2. No painel de navegação, selecione Balanceador de carga.

  3. Selecione o load balancer.

  4. Na guia Atributos, escolha Editar.

  5. Em Configuração de tráfego, insira um valor para Tempo limite de inatividade da conexão. O intervalo válido é de 1 a 4000 segundos.

  6. Escolha Salvar alterações.

Para atualizar o valor do tempo limite de inatividade usando o AWS CLI

Use o comando modify-load-balancer-attributes com o atributo idle_timeout.timeout_seconds.

Duração do keepalive do cliente HTTP

A duração do keepalive do cliente HTTP é o tempo máximo que um Application Load Balancer manterá uma conexão HTTP persistente com um cliente. Depois de decorrida a duração do keepalive do cliente HTTP configurado, o Application Load Balancer aceita uma solicitação e retorna uma resposta que fecha a conexão normalmente.

O tipo de resposta enviada pelo balanceador de carga depende da versão HTTP usada pela conexão do cliente. Para clientes conectados usando HTTP 1.x, o balanceador de carga envia um cabeçalho HTTP contendo o campo. Connection: close Para clientes conectados usando HTTP/2, o balanceador de carga envia um quadro. GOAWAY

Por padrão, os Application Load Balancers definem o valor da duração do keepalive do cliente HTTP como 3.600 segundos ou 1 hora. A duração do keepalive do cliente HTTP não pode ser desativada ou definida abaixo do mínimo de 60 segundos, mas você pode aumentar a duração do keepalive do cliente HTTP para um máximo de 604.800 segundos ou 7 dias. O Application Load Balancer inicia o período de duração do keepalive do cliente HTTP quando uma conexão HTTP com um cliente é estabelecida inicialmente. O período de duração continua em execução quando não há tráfego e não é reiniciado até que uma nova conexão seja estabelecida.

nota

Ao mudar o tipo de endereço IP do seu Application Load Balancer para dualstack-without-public-ipv4 o balanceador de carga, aguarda a conclusão de todas as conexões ativas. Para diminuir o tempo necessário para trocar o tipo de endereço IP do Application Load Balancers, considere reduzir a duração do keepalive do cliente HTTP.

O Application Load Balancer atribui à duração do keepalive do cliente HTTP uma vez durante a conexão inicial. Ao atualizar a duração do keepalive do cliente HTTP, isso pode resultar em conexões simultâneas com diferentes valores de duração do keepalive do cliente HTTP. As conexões existentes manterão o valor de duração de keepalive do cliente HTTP aplicado durante sua conexão inicial, enquanto todas as novas conexões receberão o valor de duração de keepalive do cliente HTTP atualizado.

Para atualizar o valor da duração do keepalive do cliente usando o console

  1. Abra o console do Amazon EC2 em https://console.aws.amazon.com/ec2/.

  2. No painel de navegação, selecione Balanceador de carga.

  3. Selecione o load balancer.

  4. Na guia Atributos, escolha Editar.

  5. Em Configuração de tráfego, insira um valor para a duração da manutenção de atividade do cliente HTTP. O intervalo válido é de 60 a 604800 segundos.

  6. Escolha Salvar alterações.

Para atualizar o valor da duração do keepalive do cliente usando o AWS CLI

Use o comando modify-load-balancer-attributes com o atributo client_keep_alive.seconds.

Balanceamento de carga entre zonas

Com os Application Load Balancers, o balanceamento de carga entre zonas é habilitado por padrão e não pode ser alterado por balanceador de carga. Para mais informações, consulte a seção Balanceamento de carga entre zonas no Guia do usuário do Elastic Load Balancing.

É possível desativar o balanceamento de carga entre zonas por grupo de destino. Para ter mais informações, consulte Desativar o balanceamento de carga entre zonas.

Proteção contra exclusão

Para evitar que seu load balancer seja excluído acidentalmente, é possível ativar a proteção contra exclusão. Por padrão, a proteção contra exclusão está desativada para seu load balancer.

Se você ativar a proteção contra exclusão para o load balancer, deverá desativá-la antes de excluir o load balancer.

Para habilitar a proteção contra exclusão usando o console

  1. Abra o console do Amazon EC2 em https://console.aws.amazon.com/ec2/.

  2. No painel de navegação, selecione Balanceador de carga.

  3. Selecione o load balancer.

  4. Na guia Atributos, escolha Editar.

  5. Em Configuração, ative a Proteção contra exclusão..

  6. Escolha Salvar alterações.

Para desabilitar a proteção contra exclusão usando o console

  1. Abra o console do Amazon EC2 em https://console.aws.amazon.com/ec2/.

  2. No painel de navegação, selecione Balanceador de carga.

  3. Selecione o load balancer.

  4. Na guia Atributos, escolha Editar.

  5. Na página Configuração, ative a Proteção contra exclusão.

  6. Escolha Salvar alterações.

Para ativar ou desativar a proteção contra exclusão usando o AWS CLI

Use o comando modify-load-balancer-attributes com o atributo deletion_protection.enabled.

Modo de mitigação de dessincronização

O modo de mitigação de dessincronização protege sua aplicação contra problemas causados por dessincronização de HTTP. O balanceador de carga classifica cada solicitação com base em seu nível de ameaça, permite solicitações seguras e, em seguida, reduz o risco, conforme instruído pelo modo de mitigação especificado. Os modos de mitigação de dessincronização são: monitor (monitorado), defensive (defensivo) e strictest (mais rigoroso). O padrão é o modo defensivo, que fornece mitigação durável contra HTTP Desync, mantendo a disponibilidade da sua aplicação. Você pode alternar para o modo mais restrito a fim de garantir que sua aplicação receba somente solicitações que estejam em conformidade com a RFC 7230.

A biblioteca http_desync_guardian analisa solicitações HTTP para prevenir ataques de dessincronização de HTTP. Para obter mais informações, consulte HTTP Desync Guardian em. GitHub

Classificações

As classificações são as seguintes:

  • Compatível: a solicitação está em conformidade com o RFC 7230 e não representa ameaças de segurança conhecidas.

  • Aceitável: a solicitação não está em conformidade com o RFC 7230, mas não representa ameaças de segurança conhecidas.

  • Ambígua: a solicitação não está em conformidade com o RFC 7230, mas representa um risco, pois vários servidores Web e proxies podem lidar com ela de formas diferentes.

  • Grave: a solicitação representa um alto risco de segurança. O balanceador de carga bloqueia a solicitação, atende uma resposta 400 ao cliente e fecha a conexão do cliente.

Se uma solicitação não estiver em conformidade com o RFC 7230, o balanceador de carga incrementará a métrica DesyncMitigationMode_NonCompliant_Request_Count. Para ter mais informações, consulte Métricas do Application Load Balancer.

A classificação de cada solicitação está incluída nos logs de acesso do balanceador de carga. Se a solicitação não estiver em conformidade, os logs de acesso incluirão um código de motivo de classificação. Para ter mais informações, consulte Motivos de classificação.

Modos

A tabela a seguir descreve como os Application Load Balancers processam solicitações com base no modo e na classificação.

Classificação Modo monitorado Modo defensivo Modo mais restrito
Compatível Permitido Permitido Permitido
Aceitável Permitido Permitido Bloqueado
Ambíguo Permitido Permitido¹ Bloqueado
Grave Permitido Bloqueado Bloqueado

¹ Encaminha as solicitações, mas fecha as conexões entre cliente e destino. Você poderá incorrer em cobranças adicionais se seu balanceador de carga receber um grande número de solicitações ambíguas no modo Defensivo. Isso ocorre porque o aumento do número de novas conexões por segundo contribui para as Load Balancer Capacity Units (LCU – Unidades de capacidade do balanceador de carga) usadas por hora. Você pode usar a métrica NewConnectionCount para comparar como seu balanceador de carga estabelece novas conexões no modo Monitorar e no modo Defensivo.

Para atualizar o modo de mitigação de dessincronização usando o console

  1. Abra o console do Amazon EC2 em https://console.aws.amazon.com/ec2/.

  2. No painel de navegação, selecione Balanceador de carga.

  3. Selecione o load balancer.

  4. Na guia Atributos, escolha Editar.

  5. Em Tratamento de pacotes, para o Modo de mitigação de dessincronização, escolha Defensivo, Mais rigoroso ou Monitorar.

  6. Escolha Salvar alterações.

Para atualizar o modo de mitigação de dessincronização usando o AWS CLI

Use o comando modify-load-balancer-attributes com o atributo routing.http.desync_mitigation_mode configurado como monitor, defensive ou strictest.

Preservação de cabeçalho do host

Quando você habilitar o atributo Preservar cabeçalho do host, o Application Load Balancer vai preservar o cabeçalho Host na solicitação HTTP e enviá-lo para o destino sem nenhuma modificação. Se o Application Load Balancer receber vários cabeçalhos Host, ele preservará todos eles. As regras do receptor são aplicadas somente ao primeiro cabeçalho Host recebido.

Por padrão, quando o atributo Preservar cabeçalho do host não estiver habilitado, o Application Load Balancer modificará o cabeçalho Host da seguinte maneira:

Quando a preservação de cabeçalho do host não estiver habilitada e a porta do receptor for uma porta não padrão: quando não estiver usando as portas padrão (portas 80 ou 443), anexaremos o número da porta ao cabeçalho do host, caso ele ainda não tenha sido anexado pelo cliente. Por exemplo, o cabeçalho Host na solicitação HTTP com Host: www.example.com seria modificado para Host: www.example.com:8080 se a porta do receptor fosse uma porta não padrão, como 8080.

Quando a preservação de cabeçalho do host não estiver habilitada e a porta do receptor for uma porta padrão (porta 80 ou 443): para portas padrão do receptor (porta 80 ou 443), não anexamos o número da porta ao cabeçalho do host de saída. Qualquer número de porta que já esteja no cabeçalho do host de entrada será removido.

A tabela a seguir mostra mais exemplos de como os Application Load Balancers processam os cabeçalhos do host na solicitação HTTP com base na porta do receptor.

Porta do receptor Exemplo de solicitação Cabeçalho do host na solicitação Preservação de cabeçalho do host desabilitada (comportamento padrão) Preservação de cabeçalho do host habilitada
A solicitação é enviada no receptor HTTP/HTTPS padrão. GET /index.html HTTP/1.1 Host: example.com example.com example.com example.com
A solicitação é enviada no ouvinte HTTP padrão e o cabeçalho do host tem uma porta (por exemplo, 80 ou 443). GET /index.html HTTP/1.1 Host: example.com:80 example.com:80 example.com example.com:80
A solicitação tem um caminho absoluto. GET https://dns_name/index.html HTTP/1.1 Host: example.com example.com dns_name example.com
A solicitação é enviada em uma porta de ouvinte não padrão (por exemplo, 8080) GET /index.html HTTP/1.1 Host: example.com example.com example.com:8080 example.com
A solicitação é enviada em uma porta de receptor não padrão e o cabeçalho do host tem uma porta (por exemplo, 8080). GET /index.html HTTP/1.1 Host: example.com:8080 example.com:8080 example.com:8080 example.com:8080
Para habilitar a preservação do cabeçalho do host usando o console

  1. Abra o console do Amazon EC2 em https://console.aws.amazon.com/ec2/.

  2. No painel de navegação, selecione Load Balancers.

  3. Selecione o load balancer.

  4. Na guia Atributos, escolha Editar.

  5. Em Tratamento de pacotes, ative Preservar cabeçalho do host.

  6. Escolha Salvar alterações.

Para habilitar a preservação do cabeçalho do host usando o AWS CLI

Use o comando modify-load-balancer-attributes com o atributo routing.http.preserve_host_header.enabled definido como true.

Balanceadores de carga de aplicativos e AWS WAF

Você pode usar AWS WAF com seu Application Load Balancer para permitir ou bloquear solicitações com base nas regras de uma lista de controle de acesso à web (web ACL). Para obter mais informações, consulte Como trabalhar com ACLs Web no Guia do usuário do AWS WAF .

Por padrão, se o balanceador de carga não conseguir obter uma resposta AWS WAF, ele retornará um erro HTTP 500 e não encaminhará a solicitação. Se você precisar que seu balanceador de carga encaminhe solicitações aos destinos, mesmo que ele não consiga entrar em contato AWS WAF, você pode ativar a AWS WAF integração. Para verificar se seu balanceador de carga se integra com AWS WAF, selecione seu balanceador de carga na guia Serviços integrados AWS Management Console e escolha a guia Serviços integrados.

ACLs da web predefinidas

Ao habilitar a AWS WAF integração, você pode optar por criar automaticamente uma nova Web ACL com regras predefinidas. A Web ACL predefinida inclui três regras AWS gerenciadas que oferecem proteções contra as ameaças de segurança mais comuns.

Para habilitar AWS WAF o uso do console

  1. Abra o console do Amazon EC2 em https://console.aws.amazon.com/ec2/.

  2. No painel de navegação, selecione Balanceador de carga.

  3. Selecione o load balancer.

  4. Na guia Integrações, AWS expanda Web Application Firewall (WAF) e escolha Associar uma WAF Web ACL.

  5. Em Web ACL, escolha Criar automaticamente ACL da Web predefinida ou selecione uma ACL da Web existente.

  6. Em Ação de regra, escolha Bloquear ou Contar.

  7. Selecione a opção Confirmar.

Para habilitar a abertura de AWS WAF falhas usando o AWS CLI

Use o comando modify-load-balancer-attributes com o atributo waf.fail_open.enabled definido como true.