Application Load Balancers - Elastic Load Balancing

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.

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:

  • Não é possível usar o AWS WAF com o load balancer.

  • 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 datacenter on-premises. É necessário ter uma conexão de rede confiável entre o Outpost e a região da AWS. Para obter mais informações, consulte o AWS OutpostsGuia do Usuário.

  • 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 destinos na região da AWS para o Outpost, 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.

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 não IGW (por exemplo, por meio de emparelhamento, do gateway de trânsito, do AWS Direct Connect ou da 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 habilitado para AWS WAF pode ou não encaminhar solicitações para destinos se ele não conseguir 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.

Veja a seguir os 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 sobre o balanceador de carga dualstack
  • 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, esse atributo não impede o acesso à Internet não IGW (por exemplo, por meio de emparelhamento, do gateway de trânsito, do AWS Direct Connect ou da AWS VPN).

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.

Tempo limite de inatividade da conexão

Para cada solicitação que um cliente faz por meio de um load balancer, o load balancer mantém duas conexões. A conexão front-end é entre um cliente e o load balancer. A conexão back-end está entre o balanceador de carga e um destino. O load balancer tem um período de tempo limite ocioso configurado que se aplica às suas conexões. Se nenhum dado tiver sido enviado ou recebido até o período que o tempo limite de inatividade terminar, o load balancer fechará a conexão. Para garantir que operações demoradas, como uploads de arquivo, tenham tempo para serem concluídas, envie pelo menos 1 byte de dados antes de decorrer cada período de tempo limite de inatividade e aumente a duração do período do tempo limite de inatividade conforme o necessário.

Para conexões de back-end, recomendamos que você habilite a opção de keep-alive do HTTP para as suas instâncias do EC2. Você pode habilitar a opção de keep-alive do HTTP nas configurações do servidor web para suas instâncias do EC2. Se você habilitar o keep-alive do HTTP, o balanceador de carga poderá reutilizar as conexões de back-end até que o tempo limite do keep-alive expire. 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 como 60 segundos o valor do tempo limite de inatividade para o balanceador de carga. Use o procedimento a seguir para definir um valor de tempo limite ocioso diferente.

Para atualizar o valor do tempo limite de inatividade 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 em segundos para Tempo limite de inatividade. O intervalo válido é de 1 a 4.000.

  6. Escolha Salvar alterações.

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

Use o modify-load-balancer-attributescomando com o idle_timeout.timeout_seconds atributo.

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 habilitar ou desabilitar a proteção contra exclusão usando a AWS CLI

Use o modify-load-balancer-attributescomando com o deletion_protection.enabled atributo.

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 a AWS CLI

Use o modify-load-balancer-attributescomando com o routing.http.desync_mitigation_mode atributo definido como monitordefensive, oustrictest.

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 exemplo.com exemplo.com exemplo.com
A solicitação é enviada no receptor HTTP padrão e o cabeçalho do host tem uma porta (80 ou 443). GET /index.html HTTP/1.1 Host: example.com:80 example.com:80 exemplo.com example.com:80
A solicitação tem um caminho absoluto. GET https://dns_name/index.html HTTP/1.1 Host: example.com exemplo.com dns_name exemplo.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 exemplo.com example.com:8080 exemplo.com
Para habilitar a preservação de cabeçalho do host
  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 de cabeçalho do host usando a AWS CLI

Use o modify-load-balancer-attributescomando com o routing.http.preserve_host_header.enabled atributo definido comotrue.

Application Load Balancers e AWS WAF

Você pode usar o AWS WAF com seu Application Load Balancer para permitir ou bloquear solicitações com base nas regras de uma lista de controle de acesso da Web (ACL Web). 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 do 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 contatoAWS WAF, você pode ativar a AWS WAF integração. Para verificar se o load balancer se integra com o AWS WAF, selecione seu load balancer no AWS Management Console e selecione a guia Integrated services (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.

Como habilitar o AWS WAF 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 Integrações, AWSexpanda 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 falha na abertura do AWS WAF usando a AWS CLI

Use o modify-load-balancer-attributescomando com o waf.fail_open.enabled atributo definido comotrue.