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.
Conteúdo
Configuração do receptor
Os listeners são compatíveis com os seguintes protocolos e portas:
-
Protocolos: TCP, TLS, UDP, TCP_UDP, QUIC, TCP_QUIC
-
Ports (Portas): 1-65535
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 a RFC9000
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 receptor UDP para um balanceador de carga de pilha dupla requer grupos de destino 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.
Considerações
-
No caso de receptores TLS, não é possível adicionar grupos de destino TCP e grupos de destino TLS à regra do receptor. Todos os grupos de destino devem usar o mesmo protocolo.
-
No caso de receptores TLS, a persistência do grupo de destino não é compatível.
-
Quanto a balanceadores de carga de pilha dupla, não é possível adicionar grupos de destino IPv4 e grupos de destino IPv6 à mesma ação padrão. Todos os grupos de destino na ação padrão devem usar o mesmo tipo de endereço IP.
-
No caso de receptores, se uma ação de encaminhamento contiver vários grupos de destino e qualquer um deles tiver a persistência habilitada, a ação de encaminhamento também deverá ter a persistência do grupo de destino habilitada.
Atributos do receptor
Os atributos de receptor para Network Load Balancers são:
tcp.idle_timeout.seconds-
O valor de tempo limite de inatividade de TCP, em segundos. O intervalo válido é de 60-6.000 segundos. O padrão é 350 segundos.
Para obter mais informações, consulte Atualizar o tempo limite de inatividade.
Regras do listener
As regras de ouvinte do seu Network Load Balancer determinam como ele encaminha as solicitações para os destinos. Cada ouvinte tem uma ação padrão que encaminha solicitações para um grupo-alvo especificado. Você pode adicionar regras personalizadas que avaliam as condições e direcionam o tráfego para diferentes grupos-alvo com base no tipo de endereço IP de origem do tráfego de entrada. Isso permite rotear o tráfego IPv4 e IPv6 para grupos de destino separados usando um único balanceador de carga de pilha dupla, eliminando a necessidade de tradução de IPv4/IPv6 protocolo e preservando a conectividade IP de origem de ponta a ponta.
Noções básicas de regras
-
Cada regra consiste nos seguintes componentes: prioridade, ações e condição.
-
Ao criar um ouvinte, você define a ação para a regra padrão. A regra padrão não pode ter condições. Se nenhuma das condições de qualquer outra regra for atendida, a ação para a regra padrão será executada.
-
As regras são avaliadas em ordem de prioridade, do valor mais baixo para o valor mais alto. A regra padrão é avaliada por último. Você não pode alterar a prioridade da regra padrão.
-
Cada regra deve incluir exatamente uma
forwardação, que encaminha as solicitações para um ou mais grupos-alvo. -
As regras do listener só estão disponíveis em balanceadores de carga de rede de pilha dupla.
Condições de regra
Cada condição de regra possui um tipo e informações de configuração. Quando as condições de uma regra são atendidas, a ação da regra é executada.
Veja a seguir o tipo de condição compatível com as regras de ouvinte do Network Load Balancer:
source-ip-
Roteamento com base no tipo de endereço IP do tráfego de origem. Você especifica um
IpAddressTypevalor deipv4ouipv6. Quando a versão IP de origem de uma solicitação recebida corresponde à condição, a ação da regra é executada.Veja a seguir um exemplo de uma condição de IP de origem:
{ "Field": "source-ip", "SourceIpConfig": { "IpAddressType": "ipv4" } }
nota
A source-ip condição usada pelos balanceadores de carga de rede é IpAddressType combinar o tráfego por versão IP (IPv4 ou IPv6). Isso difere da source-ip condição do Application Load Balancer, que usa intervalos CIDR para corresponder a endereços IP de origem específicos.
Ações de regra
Cada ação de regra possui um tipo e informações de configuração. Veja a seguir o tipo de ação compatível com as regras de ouvinte do Network Load Balancer:
forward-
Encaminhe solicitações para um ou mais grupos-alvo especificados. Se especificar vários grupos de destino para uma ação
forward, você deverá especificar um peso para cada grupo de destino. Cada peso de grupo de destino é um valor de 0 a 999. As solicitações que correspondem a uma regra de listener com grupos de destino ponderados são distribuídas para esses grupos de destino com base em seus pesos. 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.
Veja a seguir um exemplo de uma ação direta que encaminha para um único grupo-alvo:
{ "Type": "forward", "TargetGroupArn": "arn:aws:elasticloadbalancing:region:account-id:targetgroup/my-ipv4-tg/target-group-id" }
Veja a seguir um exemplo de uma ação direta que encaminha para dois grupos-alvo ponderados:
{ "Type": "forward", "ForwardConfig": { "TargetGroups": [ { "TargetGroupArn": "arn:aws:elasticloadbalancing:region:account-id:targetgroup/my-tg-1/target-group-id", "Weight": 70 }, { "TargetGroupArn": "arn:aws:elasticloadbalancing:region:account-id:targetgroup/my-tg-2/target-group-id", "Weight": 30 } ] } }
Prioridade das regras
Cada regra tem uma prioridade. As regras são avaliadas em ordem de prioridade, do valor mais baixo para o valor mais alto. A regra padrão é avaliada por último. Você pode alterar a prioridade de uma regra não padrão a qualquer momento usando o comando https://docs.aws.amazon.com/cli/latest/reference/elbv2/set-rule-priorities.html set-rule-priority.
Cada regra deve ter um valor de prioridade exclusivo. Você não pode criar várias regras com a mesma prioridade. Se várias regras corresponderem ao tráfego de entrada, a regra com a maior prioridade (menor valor numérico) terá precedência.
Avaliação da regra
Quando o tráfego chega ao ouvinte do Network Load Balancer, as regras são avaliadas na seguinte ordem:
-
Non-default as regras são avaliadas em ordem de prioridade (primeiro o valor mais baixo).
-
Quando as condições de uma regra são atendidas, a ação da regra é executada.
-
Se nenhuma condição da regra for atendida, a ação padrão será executada.
Se as regras do ouvinte cobrirem todos os cenários de tráfego (IPv4 e IPv6), a ação padrão talvez nunca seja usada. No entanto, uma ação padrão é sempre necessária.
Considerações
- Pré-requisitos
-
As regras do listener exigem um balanceador de carga de rede de pilha dupla. A VPC e as sub-redes devem ter blocos CIDR IPv6 associados, e as tabelas de rotas da sub-rede devem rotear o tráfego IPv6.
- Avaliação da regra e a ação padrão
-
As regras são avaliadas em ordem de prioridade, em que um número de prioridade mais baixa é avaliado primeiro. O tráfego que não corresponde a nenhuma regra passa para a ação padrão. Defina a ação padrão para a família de endereços IP que você deseja como alternativa.
- Protocolos e grupos-alvo
-
As regras de ouvinte se aplicam aos ouvintes TCP, UDP, TCP_UDP e TLS. Um ouvinte UDP em um balanceador de carga de rede de pilha dupla exige um grupo-alvo IPv6, portanto, certifique-se de que o grupo de destino IPv6 exista antes de dividir o tráfego UDP.
- Verificações de integridade
-
Cada grupo-alvo verifica a integridade de seus alvos em sua própria família de endereços IP. Confirme se os grupos de segurança de destino permitem o tráfego de verificação de integridade do balanceador de carga em IPv4 e IPv6.
- Desempenho e disponibilidade
-
Um balanceador de carga de rede consolidado de pilha dupla transporta o tráfego combinado das famílias de endereços IPv4 e IPv6, potencialmente dobrando a carga em comparação com dois balanceadores de carga de rede individuais. Enquanto um balanceador de carga de rede fornece simplificação, dois balanceadores de carga de rede separados fornecem isolamento natural de falhas por família de endereços. Avalie seus requisitos de escala e disponibilidade antes de consolidar.
- Compatibilidade com os recursos existentes do Network Load Balancer
-
As regras do listener funcionam junto com o conjunto de recursos existente do Network Load Balancer: drenagem da conexão (atraso no cancelamento do registro), permanência do grupo-alvo (sessões fixas), balanceamento de carga entre zonas, preservação do IP do cliente (
preserve_client_ip) e terminação de TLS nos ouvintes TLS. Cada grupo-alvo mantém sua própria configuração. - Preservação do IP de origem
-
Quando as versões IP do cliente e do destino coincidem (habilitadas pelas regras do ouvinte), o tráfego flui diretamente sem tradução de protocolo, mantendo a preservação do IP de origem de ponta a ponta. Isso
preserve_client_ipprecisa ser ativado no grupo-alvo. - Grupos de destino ponderados
-
As regras do Listener são compatíveis
ForwardConfigcom vários grupos-alvo ponderados, o que é útil para implementações canárias ou migrações graduais. Cada grupo-alvo assume um peso de 0 a 999, e um grupo com peso 0 não recebe novas conexões. - Relação com as regras de ouvinte do Application Load Balancer
-
Tanto os Network Load Balancers quanto os Application Load Balancers usam uma
source-ipcondição, mas eles coincidem em atributos diferentes. O Application Load Balancer combina o endereço de origem com um ou mais blocos CIDR (SourceIpConfig.Values), enquanto o Network Load Balancer corresponde ao tipo de endereço IP da conexão de origem ().SourceIpConfig.IpAddressTypeResumindo, o Application Load Balancer roteia por intervalo de endereços específico e o Network Load Balancer roteia por versão IP. - Preços e disponibilidade
-
As regras do listener estão disponíveis em todas as regiões AWS comerciais e nas regiões AWS GovCloud (EUA). Não há cobrança adicional pelo recurso. Você paga o preço padrão do Network Load Balancer para horas e LCUs do balanceador de carga. A consolidação de balanceadores de carga de rede IPv4 e IPv6 separados em um único balanceador de carga de rede de pilha dupla remove as horas e as cobranças de LCU do segundo balanceador de carga.
Para obter mais informações, consulte Regras de ouvinte para seu balanceador de carga de rede.
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
Políticas ALPN
Application-Layer A Negociação de Protocolo (ALPN) é uma extensão TLS enviada nas mensagens iniciais de saudação do handshake TLS. O ALPN permite que a camada de aplicação negocie quais protocolos devem ser usados em uma conexão segura, como e. HTTP/1 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.
Políticas ALPN com suporte
Veja a seguir as políticas ALPN com suporte:
HTTP1Only-
Negocie somente HTTP/1 .*. A lista de preferências do ALPN é http/1 .1, http/1 .0.
HTTP2Only-
Negocie somente HTTP/2. A lista de preferências de ALPN é h2.
HTTP2Optional-
Prefira HTTP/1 .* em vez de HTTP/2 (o que pode ser útil para HTTP/2 testes). A lista de preferências do ALPN é http/1 .1, http/1 .0, h2.
HTTP2Preferred-
Prefiro HTTP/2 HTTP/1 .*. A lista de preferências do ALPN é h2, http/1 .1, .0. http/1
None-
Não negocie ALPN. Esse é o padrão.
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.