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

Receptores para Network Load Balancers

Um receptor é um processo que verifica solicitações de conexão, usando o protocolo e a porta que você configura. Antes de começar a usar o Network Load Balancer, você deve adicionar ao menos um receptor. Se o balanceador de carga não tiver receptores, não poderá receber tráfego de clientes. As regras que você define para um receptor determinam como o balanceador de carga roteia solicitações para os destinos registrados, como instâncias do EC2.

Configuração do receptor

Os listeners são compatíveis com os seguintes protocolos e portas:

Você pode usar um listener TLS para transferir o trabalho de criptografia e descriptografia para seu load balancer, de forma que os aplicativos possam se concentrar na respectiva lógica de negócios. Se o protocolo do receptor for TLS, você deverá implantar pelo menos um certificado de servidor SSL no receptor. Para obter mais informações, consulte Certificados de servidor.

Se você precisar garantir que os destinos descriptografem o tráfego TLS em vez do balanceador de carga, será possível criar um receptor TCP na porta 443 em vez de criar um receptor TLS. Com um receptor TCP, o balanceador de carga transmite o tráfego criptografado para os destinos sem descriptografá-lo.

Você pode usar um receptor QUIC para aceitar o tráfego QUIC. O Network Load Balancer atua como um balanceador de carga de passagem de acordo com. RFC9000 Use um receptor QUIC e backends habilitados para QUIC para permitir uma migração de conexão perfeita para dispositivos móveis.

Para oferecer suporte a TCP e UDP na mesma porta, crie um listener TCP_UDP. Os grupos de destino de um listener TCP_UDP devem usar o protocolo TCP_UDP.

Para oferecer suporte a TCP e QUIC na mesma porta, crie um receptor TCP_QUIC. Os grupos de destino de um receptor TCP_QUIC devem usar o protocolo TCP_QUIC.

Um ouvinte UDP para um balanceador de carga de pilha dupla requer grupos-alvo. IPv6

WebSockets é suportado somente em ouvintes TCP, TLS, TCP_UDP e TCP_QUIC.

O tráfego QUIC não oferece suporte à negociação de versões. QUIC v1 é a única versão compatível com o QUIC.

Todo o tráfego de rede enviado para um listener configurado é classificado como tráfego intencional. O tráfego de rede que não corresponde a um listener configurado é classificado como tráfego não intencional. Solicitações ICMP diferentes do Tipo 3 também são consideradas tráfego não intencional. Os Network Load Balancers eliminam o tráfego não intencional sem encaminhá-lo para quaisquer destinos. Os pacotes de dados TCP enviados para a porta de um configurado que não são novas conexões ou parte de uma conexão TCP ativa são rejeitados com uma redefinição de TCP (RST).

Para obter mais informações, consulte Roteamento de solicitação no Guia do usuário do Elastic Load Balancing.

Ações padrão

Quando você cria um receptor, você especifica uma ação padrão para rotear as solicitações. A ação padrão encaminha as solicitações para os grupos de destino que você especificar.

Distribuir tráfego para vários grupos de destino

Se você especificar vários grupos de destino para uma ação padrão, as solicitações serão distribuídas para esses grupos de destino com base nos respectivos pesos relativos. Você deve especificar um peso de 0 a 999 para cada grupo de destino. Um grupo de destino com peso 0 não recebe tráfego. Após adicionar um grupo de destino ou atualizar os pesos do grupo de destino, as novas conexões são roteadas com base nos novos pesos do grupo de destino. As conexões atuais não são afetadas e continuam até serem encerradas normalmente.

Por exemplo, se você especificar dois grupos de destino, cada um com um peso de 10, cada grupo de destino receberá metade das solicitações. Se você especificar dois grupos de destino, um com peso de 10 e o outro com peso de 20, o grupo de destino com peso de 20 receberá duas vezes mais solicitações do que o outro grupo de destino com peso de 10.

Um caso de uso comum é migrar o tráfego de um grupo de destino para outro. Isso significa que você aumenta gradualmente o peso do novo grupo de destino enquanto diminui o peso do grupo de destino original até que seja 0. Se você atualizar o peso de um grupo de destino como 0, após um curto período ele não receberá novas conexões e as conexões existentes serão encerradas.

Sessões persistentes e grupos de destino ponderados

As ações de encaminhamento executadas nos receptores podem especificar se a persistência do grupo de destino deve ser habilitada. Quando habilitada, a persistência do grupo de destino faz com que as conexões subsequentes do mesmo endereço IP de origem prefiram o grupo de destino escolhido anteriormente.

Atributos do receptor

Os atributos de receptor para Network Load Balancers são:

Para obter mais informações, consulte Atualizar o tempo limite de inatividade.

Receptores seguros

Para usar um listener TLS, é necessário implantar pelo menos um certificado de servidor no load balancer. O load balancer usa um certificado de servidor para encerrar a conexão de frontend e para descriptografar solicitações dos clientes antes de enviá-las aos destinos. Observe que, se você precisar transmitir tráfego criptografado para os destinos sem que o balanceador de carga o descriptografe, crie um receptor TCP na porta 443 em vez de criar um receptor TLS. O balanceador de carga transmite a solicitação para o destino no estado em que ela se encontra, sem descriptografá-la.

O Elastic Load Balancing usa uma configuração de negociação TLS, conhecida como política de segurança, para negociar conexões TLS entre um cliente e o balanceador de carga. Uma política de segurança é uma combinação de cifras e protocolos. O protocolo estabelece uma conexão segura entre um cliente e um servidor, além de garantir que todos os dados transmitidos entre o cliente e o balanceador de carga sejam privados. A cifra é um algoritmo criptográfico que usa chaves de criptografia para criar uma mensagem codificada. Os protocolos usam várias cifras para criptografar dados na internet. Durante o processo de negociação de conexão, o cliente e o load balancer apresentam uma lista de cifras e protocolos que cada um suporta, em ordem de preferência. A primeira cifra na lista do servidor que corresponder a qualquer uma das cifras do cliente será selecionada para a conexão segura.

Os Network Load Balancers não são compatíveis com autenticação TLS mútua (mTLS). Para compatibilidade com mTLS, crie um receptor TCP em vez de um receptor TLS. O balanceador de carga transmite a solicitação no estado em que ela se encontra para que você possa implementar a mTLS no destino.

Os Network Load Balancers são compatíveis com a retomada de TLS usando PSK para TLS 1.3 e tíquetes de sessão para TLS 1.2 e anteriores. Não há suporte para retomadas com ID de sessão ou quando vários certificados são configurados no receptor usando SNI. O atributo de dados 0-RTT e a extensão early_data não estão implementados.

Para demonstrações relacionadas, consulte Suporte TLS no Network Load Balancer e Suporte SNI no Network Load Balancer.

Políticas ALPN

A Application-Layer Protocol Negotiation (ALPN) é uma extensão TLS que é enviada nas mensagens Hello iniciais de handshake de TLS. ALPN permite que a camada do aplicativo negocie quais protocolos devem ser usados em uma conexão segura, como HTTP/1 e HTTP/2.

Quando o cliente inicia uma conexão ALPN, o load balancer compara a lista de preferências de ALPN do cliente com a política ALPN. Se o cliente oferecer suporte a um protocolo da política ALPN, o load balancer estabelecerá a conexão com base na lista de preferências da política ALPN. Caso contrário, o load balancer não usará ALPN.

Habilitar conexões ALPN

É possível habilitar conexões ALPN ao criar ou modificar um listener TLS. Para obter mais informações, consulte Adicionar um listener e Atualizar a política ALPN.