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 especificar um dos seguintes tipos de sub-redes: Zona de disponibilidade, zona local ou posto avançado.

Uma VPC com zonas de disponibilidade e uma zona Wavelength.

É necessário selecionar pelo menos duas sub-redes da Zona de disponibilidade. As seguintes restrições são aplicáveis:

  • Cada sub-rede deve ser de uma Zona de disponibilidade diferente.

  • Para garantir que o load balancer possa ser dimensionado corretamente, verifique se cada sub-rede da zona de disponibilidade do load balancer tem um bloco CIDR com pelo menos um bloco CIDR com pelo menos uma/27bitmask (por exemplo,10.0.0.0/27) e pelo menos 8 endereços IP gratuitos por sub-rede. Seu load balancer usa esses endereços IP para estabelecer conexões com os destinos. Dependendo do seu perfil de tráfego, o balanceador de carga pode ser dimensionado mais alto e consumir até um máximo de 100 endereços IP distribuídos em todas as sub-redes habilitadas.

Zonas locais

É possível especificar uma ou mais sub-redes da 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.

Outposts

É possível especificar uma sub-rede do Outpost única. 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 Guia do usuário do AWS Outposts.

  • O balanceador de carga requer doislargeinstâncias no Outpost para os nós do load balancer. Os tipos de instâncias compatíveis são mostrados na tabela a seguir. O balanceador de carga é dimensionado conforme necessário, redimensionando os nós um tamanho de cada vez (delargeparaxlarge, entãoxlargepara2xlargee depois2xlargepara4xlarge). Depois de escalar os nós para o maior tamanho de instância, se você precisar de capacidade adicional, o balanceador de carga adicionará4xlargeinstâncias como nós do balanceador de carga. Se você não tiver capacidade de instância suficiente ou endereços IP disponíveis para dimensionar o balanceador de carga, o balanceador de carga reportará um evento aoAWS Health Dashboarde o estado do balanceador de carga éactive_impaired.

  • É possível registrar destinos por ID de instância ou endereço IP. Se você registrar alvos naAWSRegião para o posto avançado, eles não são usados.

  • Os seguintes recursos não estão disponíveis: Funções Lambda como destinosAWS WAFintegração, sessões fixas, suporte à autenticação e integração comAWS Global Accelerator.

Um Application Load Balancer pode ser implementado 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 da 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
r5r5d
grande 50
xlarge 100
2xlarge 100
4xlarge 100

Grupos de segurança do load balancer

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 security groups associadas ao load balancer devem permitir tráfego em ambas as direções tanto no listener 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 obter 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 obter mais informações, consulte Permissões do bucket.

access_logs.s3.prefix

O prefixo para a localização 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 de Internet (IGW) ao balanceador de carga, impedindo o acesso não intencional ao balanceador de carga interno por meio de um gateway da Internet. Está definido comofalsepara balanceadores de carga voltados para a Internet etruepara load balancers internos. Este atributo não impede o acesso à Internet não-IGW (como, por meio de peering, Transit Gateway,AWS Direct Connect, ouAWS VPN).

routing.http.desync_mitigation_mode

Determina como o load balancer lida com solicitações que podem representar risco de segurança para o seu aplicativo. 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 são válidos são removidos pelo load balancer (true), ou encaminhado para destinos (false). O padrão é false. O Elastic Load Balancing exige que os nomes de cabeçalho estejam em conformidade com a expressão regular.[-A-Za-z0-9]+, que descreve todos os cabeçalhos de mensagens da Internet registradas. Cada nome consiste em caracteres alfanuméricos ou hifens.

routing.http.preserve_host_header.enabled

Indica se o Application Load Balancer deve preservar aHostcabeçalho na solicitação HTTP e envie-o para destinos sem qualquer 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-versionex-amzn-tls-cipher-suite), que contêm informações sobre a versão negociada do TLS e o conjunto de cifras, são adicionados à solicitação do cliente antes de enviá-la ao destino. Ox-amzn-tls-versiontem informações sobre a versão do protocolo TLS negociada com o cliente ex-amzn-tls-cipher-suiteO cabeçalho 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ãotrueefalse. O padrão é false.

routing.http.xff_client_port.enabled

Indica se oX-Forwarded-Fordeve preservar a porta de origem que o cliente usou para se conectar ao load balancer. Os valores possíveis são true e false. O padrão é false.

routing.http.xff_header_processing.mode

Permite modificar, preservar ou remover oX-Forward-Forna 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 forappend, o Application Load Balancer adiciona o endereço IP do cliente (do último salto) aoX-Forward-Forcabeçalho na solicitação HTTP antes de enviá-la aos destinos.

  • Se o valor forpreserveO Application Load Balancer preservará aX-Forward-Forna solicitação HTTP e o envia aos destinos sem nenhuma alteração.

  • Se o valor forremoveO Application Load Balancer tirará aX-Forward-Forcabeçalho na solicitação HTTP antes de enviá-la aos destinos.

routing.http2.enabled

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

waf.fail_open.enabled

Indica se deve permitir umAWS WAFload balancer habilitado para rotear solicitações para destinos se ele não conseguir encaminhar a solicitação paraAWS WAF. Os valores possíveis são true e false. O padrão é false.

Tipo de endereço IP

É possível definir os tipos de endereços IP que os clientes podem usar para acessar seus load balancer interno e voltado 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 load balancer do Dualstack

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

  • Ao habilitar o modo de pilha dupla para o load balancer, o Elastic Load Balancing fornece um registro DNS AAAA para o load balancer. 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 de pilha dupla 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 não IWG (como, por meio de peering, Transit Gateway,AWS Direct Connect, ouAWS VPN).

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 load balancer 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 back-end, recomendamos que você habilite a opção de keep-alive do HTTP para suas instâncias 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 load balancer poderá reutilizar as conexões 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 o aplicativo fechar a conexão TCP com o balanceador de carga sem graça, o balanceador de carga poderá enviar uma solicitação ao aplicativo antes de receber o pacote indicando que a conexão está fechada. Se esse for o caso, o servidor recusará a solicitação do balanceador de carga e, em seguida, o balanceador de carga enviará um erro HTTP 502 Bad Gateway para o aplicativo.

Por padrão, o Elastic Load Balancing define o valor de tempo limite para o load balancer como 60 segundos. 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, em LOAD BALANCING (BALANCEAMENTO DE CARGA), escolha Load balancers (Balanceadores de carga).

  3. Selecione o load balancer.

  4. Na guia Descrição, selecione Editar atributos.

  5. Na página Edit load balancer attributes (Editar atributos do load balancer), insira um valor para o Idle timeout (Tempo limite de inatividade), em segundos. O intervalo válido é de 1 a 4000.

  6. Escolha Save (Salvar).

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

Usar amodify-load-balancer-attributescomando com oidle_timeout.timeout_secondsatributo.

Deletion protection (Proteção contra exclusão)

Para evitar que seu load balancer seja excluído acidentalmente, você pode 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, em LOAD BALANCING (BALANCEAMENTO DE CARGA), escolha Load balancers (Balanceadores de carga).

  3. Selecione o load balancer.

  4. Na guia Descrição, selecione Editar atributos.

  5. Na página Edit load balancer attributes (Editar atributos do load balancer), selecione Enable (Habilitar) em Delete Protection (Proteção contra a exclusão) e escolha Save (Salvar).

  6. Escolha Save (Salvar).

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, em LOAD BALANCING (BALANCEAMENTO DE CARGA), escolha Load balancers (Balanceadores de carga).

  3. Selecione o load balancer.

  4. Na guia Descrição, selecione Editar atributos.

  5. Na página Edit load balancer attributes (Editar atributos do load balancer), desmarque Enable (Habilitar) em Delete Protection (Proteção contra a exclusão) e escolha Save (Salvar).

  6. Escolha Save (Salvar).

Para habilitar ou desabilitar a proteção contra exclusão usando a AWS CLI

Usar amodify-load-balancer-attributescomando com odeletion_protection.enabledatributo.

Modo de mitigação da dessincronização

O modo de mitigação de dessincronização protege sua aplicação contra problemas causados por 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 para garantir que o seu aplicativo receba somente solicitações que estejam em conformidade com oRFC 7230.

A biblioteca http_desync_guardian analisa solicitações HTTP para evitar ataques de dessincronização HTTP. Para obter mais informações, consulteHTTP Dessincronizaçãoem 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 obter mais informações, consulte 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 registros de acesso incluirão um código de motivo de classificação. Para obter mais informações, consulte Critérios de classificação.

Modos

A tabela a seguir descreve como os Application Balancers tratam 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ê pode incorrer em cobranças adicionais se o 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 Unidades de Capacidade do Load Balancer (LCU) usadas por hora. Você pode usar oNewConnectionCountmétrica para comparar como o balanceador de carga estabelece novas conexões no modo Monitor 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, em LOAD BALANCING (BALANCEAMENTO DE CARGA), escolha Load balancers (Balanceadores de carga).

  3. Selecione o load balancer.

  4. Na guia Descrição, selecione Editar atributos.

  5. para oModo de mitigação da dessincronização, escolhaMonitor,defensivo, ouMais restrito.

  6. Escolha Save (Salvar).

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

Usar amodify-load-balancer-attributescomando com orouting.http.desync_mitigation_modeatributo definido comomonitor,defensive, oustrictest.

Preservação do cabeçalho

Quando você ativa oPreservar cabeçalho do host, o Application Load Balancer preserva aHostcabeçalho na solicitação HTTP e envia o cabeçalho aos destinos sem qualquer modificação. Se o Application Load Balancer receber váriosHostcabeçalhos, preserva todos eles. As regras do ouvinte são aplicadas apenas para o primeiroHostcabeçalho recebido.

Por padrão, quando oPreservar cabeçalho do hostnão estiver ativado, o Application Load Balancer modifica aHostcabeçalho da maneira a seguir:

Quando a preservação do cabeçalho do host não está habilitada e a porta do ouvinte é uma porta não padrão: Quando não estiver usando as portas padrão (portas 80 ou 443), acrescentamos o número da porta ao cabeçalho do host, se ele ainda não estiver anexado pelo cliente. Por exemplo, as receitasHostcabeçalho na solicitação HTTP comHost: www.example.comseria modificado paraHost: www.example.com:8080, se a porta do listener for uma porta não padrão, como8080.

Quando a preservação do cabeçalho do host não está habilitada e a porta do listener é uma porta padrão (porta 80 ou 443): Para portas de ouvinte padrão (porta 80 ou 443), não acrescentamos o número da porta ao cabeçalho do host de saída. Qualquer número de porta que já estivesse no cabeçalho do host de entrada será removido.

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

Porta listener

Exemplo de solicitação

Cabeçalho de host na solicitação

A preservação do cabeçalho do host está desativada (comportamento padrão)

A preservação do cabeçalho do host está ativada
A solicitação é enviada no ouvinte HTTP/HTTPS padrão. GET /index.html HTTP/1.1 Host: example.com exemplo.com exemplo.com exemplo.com
A solicitação é enviada no ouvinte 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 ouvinte não padrão e o cabeçalho do host tem 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 do cabeçalho do host

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

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

  3. Escolha o load balancer que você deseja usar.

  4. Na guia Descrição, selecione Editar atributos.

  5. para oPreservar cabeçalho do host, escolhaHabilitar o.

  6. Escolha Save (Salvar).

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

Usar amodify-load-balancer-attributescomando com orouting.http.preserve_host_header.enabledatributo definido comotrue.

Application Load ad ad ad balaners eAWS WAF

Você pode usarAWS WAFcom o Application Load Balancer para permitir ou bloquear solicitações baseadas nas regras de uma lista de controle de acesso (ACL) da web. Para obter mais informações, consulteTrabalhar com web ACLsnoAWS WAFGuia do desenvolvedor.

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).

Por padrão, se o balanceador de carga não puder obter uma resposta doAWS WAF, ele retorna um erro HTTP 500 e não encaminha a solicitação. Se você precisar que o balanceador de carga encaminhe solicitações aos destinos, mesmo que não seja possível entrar em contatoAWS WAF, você pode ativar oAWS WAFatributo fail open.

Para habilitar oAWS WAFfalha ao abrir usando o console

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

  2. No painel de navegação, em LOAD BALANCING (BALANCEAMENTO DE CARGA), escolha Load balancers (Balanceadores de carga).

  3. Selecione o load balancer.

  4. Na guia Descrição, selecione Editar atributos.

  5. para oAWS WAFfail open, escolhaHabilitar o.

  6. Escolha Save (Salvar).

Para habilitar oAWS WAFfalha ao abrir usando oAWS CLI

Usar amodify-load-balancer-attributescomando com owaf.fail_open.enabledatributo definido comotrue.