Perguntas frequentes sobre o Elastic Load Balancing

Um Application Load Balancer aceita destinos usando qualquer sistema operacional aceito no momento com o serviço Amazon EC2.

Um Application Load Balancer oferece suporte ao balanceamento de carga de aplicativos usando os protocolos HTTP e HTTPS (Secure HTTP).

Sim. A compatibilidade com o HTTP/2 é habilitada de modo nativo em um balanceador de carga da aplicação. Os clientes que oferecem suporte ao HTTP/2 podem se conectar a um balanceador de carga da aplicação por meio do TLS.

Você pode encaminhar o tráfego do Network Load Balancer, que fornece suporte ao PrivateLink e a um endereço IP estático por zona de disponibilidade para o Application Load Balancer. Crie um grupo de destino do tipo balanceador de carga da aplicação, registre seu balanceador de carga da aplicação nele e configure seu balanceador de carga da rede para encaminhar o tráfego ao grupo de destino do tipo balanceador de carga da aplicação.

Você pode realizar o balanceamento de carga para as seguintes portas TCP: de 1 a 65.535

Sim. A compatibilidade com WebSockets e Secure WebSockets está disponível de modo nativo e pronto para uso em um Application Load Balancer.

Sim. O monitoramento de solicitações é habilitado como padrão no Application Load Balancer.

Apesar da terem algo em comum, não há equivalência de recursos entre os dois tipos de balanceadores de carga. Os Application Load Balancers são a base da nossa plataforma de balanceamento de carga na camada da aplicação do futuro.

Sim.

Sim.

Não. Os Application Load Balancers precisam de um novo conjunto de interfaces de programação de aplicações (APIs).

O console do ELB permitirá que você gerencie Application e Classic Load Balancers usando a mesma interface. Caso esteja usando a interface de linha de comando (CLI) ou um Kit de Desenvolvimento de Software (SDK), você usará um “serviço” diferente para os balanceadores de carga da aplicação. Por exemplo, na ILC você descreverá os seus Classic Load Balancers usando "aws elb describe-load-balancers" e os seus Application Load Balancers usando "aws elbv2 describe-load-balancers".

Não é possível converter um tipo de load balancer em outro.

Sim. Você pode migrar do Classic Load Balancer para o Application Load Balancer usando uma das opções listadas neste documento.

Se você precisar de recursos de quatro camadas, use um Network Load Balancer.

Sim. É possível adicionar listeners para a porta 80 HTTP e a porta 443 HTTPS para um único Application Load Balancer.

Sim. Para receber um histórico das chamadas de API do Application Load Balancer realizadas na sua conta, use o AWS CloudTrail.

Sim. É possível encerrar uma conexão HTTPs no Application Load Balancer. Você deve instalar um certificado Secure Sockets Layer (SSL) em seu balanceador de carga. O load balancer usa esse certificado para encerrar a conexão e descriptografar solicitações de clientes antes de enviá-las para os destinos.

Você pode usar o AWS Certificate Manager para provisionar um certificado SSL ou TLS ou obtê-lo de outras fontes, criando uma solicitação de certificado, conseguindo a assinatura dessa solicitação por uma CA e fazendo upload do certificado com o AWS Certification Manager ou o serviço AWS Identity and Access Management (IAM).

O Application Load Balancer é integrado ao AWS Certificate Management (ACM). A integração ao ACM simplifica a associação de um certificado ao balanceador de carga, o que simplifica todo o processo de descarga do certificado SSL. Comprar, carregar e renovar certificados SSL/TLS é um processo manual complexo e demorado. Com a integração do ACM ao Application Load Balancer, todo esse processo foi reduzido para uma simples solicitação de um certificado SSL/TLS confiável e a seleção do certificado do ACM para provisioná-lo com o load balancer.

Não. Apenas a criptografia oferece back-ends compatíveis com o Application Load Balancer.

A SNI é habilitada automaticamente quando você associa mais de um certificado TLS ao mesmo listener seguro em um load balancer. Da mesma forma, o modo SNI de um listener seguro é desabilitado automaticamente quando você tem apenas um certificado associado ao listener seguro.

Sim. Você pode associar vários certificados do mesmo domínio a um listener seguro. Por exemplo, você pode associar:

• Certificados ECDSA e RSA
• Certificados com tamanhos de chave diferentes (por exemplo, 2 kbits e 4 kbits) para certificados SSL/TLS
• Certificados de domínio único, vários domínios (SAN) e curinga

Sim. O IPv6 é compatível com o Application Load Balancer.

É possível configurar regras para cada um dos receptores criados no balanceador de carga. Essas regras incluem condições e ações correspondentes, caso as condições sejam atendidas. As condições compatíveis são cabeçalho do host, caminho, cabeçalhos HTTP, métodos, parâmetros de consulta e roteamentos sem classe entre domínios (CIDRs) de IP de origem. As ações compatíveis são redirecionar, resposta fixa, autenticar e encaminhar. Depois dessa configuração, o balanceador de carga usará as regras para determinar como uma solicitação HTTP deverá ser encaminhada. É possível usar várias condições e ações em uma regra, e cada condição pode especificar uma correspondência em diversos valores.

Sua conta da AWS tem estes limites para um Application Load Balancer.

Você pode integrar o Application Load Balancer ao AWS Web Application Firewall (WAF), um firewall de aplicações Web que ajuda a proteger esse tipo de aplicação contra ataques, permitindo configurar regras baseadas em endereços IP, cabeçalhos HTTP e strings de identificador uniforme de recursos (URI) personalizados. Usando essas regras, o AWS WAF pode bloquear, permitir ou monitorar (fazer a contagem) de solicitações da web para o seu aplicativo. Consulte o Guia do desenvolvedor do AWS WAF para obter mais informações.

Você pode usar qualquer endereço IP do CIDR da VPC do balanceador de carga para destinos na VPC do balanceador de carga, bem como qualquer endereço IP dos intervalos RFC 1918 (10.0.0.0/8, 172.16.0.0/12 e 192.168.0.0/16) ou do intervalo RFC 6598 (100.64.0.0/10) para destinos localizados fora da VPC do balanceador de carga (por exemplo, destinos na VPC emparelhada, no Amazon EC2-Classic e nos ambientes on-premises acessíveis por meio do AWS Direct Connect ou de uma conexão VPN).

Existem várias maneiras de fazer um balanceamento de carga híbrido. Se um aplicativo for executado em destinos distribuídos entre uma VPC e um ambiente no local, você poderá adicioná-los ao mesmo grupo de destino usando seus endereços IP. Para migrar para a AWS sem prejudicar o aplicativo, recomendamos adicionar gradualmente os destinos da VPC ao grupo de destino e remover os destinos locais do grupo de destino. 

Se houver dois aplicativos diferentes, em que os destinos de um aplicativo estejam em uma VPC e os destinos do outro estejam no ambiente local, será possível colocar os destinos da VPC em um grupo de destino e os destinos locais em outro grupo de destino, bem como usar o roteamento baseado em conteúdo para rotear o tráfego para cada grupo de destino. Também é possível separar load balancers para destinos locais e da VPC, bem como usar a ponderação de DNS para obter o balanceamento de carga ponderado entre os destinos locais e da VPC.

Não é possível balancear a carga para instâncias EC2-Classic registrando seus IDs de instância como destinos. No entanto, se você vincular essas instâncias EC2-Classic à VPC do load balancer utilizando o ClassicLink e usar os IPs privados dessas instâncias EC2-Classic como destinos, será possível balancear a carga para instâncias EC2-Classic. Se atualmente você estiver usando instâncias EC2-Classic com um Classic Load Balancer, poderá fazer facilmente a migração para um Application Load Balancer.

O balanceamento de cargas entre zonas já está habilitado por padrão no Application Load Balancer.

Você deve usar a autenticação por meio do Amazon Cognito se:

• Desejar oferecer flexibilidade para que seus usuários façam a autenticação por meio de identidades de redes sociais (Google, Facebook e Amazon), identidades empresariais (SAML) ou por meio dos seus próprios diretórios de usuário disponibilizados pelo grupo de usuários do Amazon Cognito.
• Estiver gerenciando vários provedores de identidade, inclusive o OpenID Connect, e desejar criar uma regra de autenticação única no balanceador de carga da aplicação (ALB) que possa usar o Amazon Cognito para federar seus vários provedores de identidade.
• Precisar gerenciar ativamente perfis de usuários com um ou mais provedores de identidade social ou de OpenID Connect por meio de um único local centralizado. Por exemplo, você pode colocar usuários em grupos e adicionar atributos personalizados para representar o status de usuário e controlar o acesso de usuários pagos.

Como opção, se você tiver investido no desenvolvimento de soluções personalizadas de IdP e desejar apenas fazer a autenticação com um provedor de identidade único compatível com o OpenID Connect, recomendamos o uso da solução de OIDC nativa do balanceador de carga da aplicação.

Os três tipos de redirecionamentos a seguir têm suporte.

HTTP para HTTP
http://hostA para http://hostB

HTTP para HTTPS
http://hostA para https://hostB
https://hostA:portA/pathA para https://hostB:portB/pathB

HTTPS para HTTPS
https://hostA para https://hostB

Os seguintes tipos de conteúdo têm suporte: text/plain, text/css, text/html, application/javascript, application/json.

As solicitações HTTP e HTTPS recebidas por um balanceador de carga são processadas pelas regras de roteamento baseadas no conteúdo. Se o conteúdo da solicitação corresponder à regra (com uma ação para direcioná-la ao grupo de destino tendo uma função Lambda como destino), a função Lambda correspondente será invocada. O conteúdo da solicitação (incluindo cabeçalho e corpo) é transmitido para a função Lambda no formato JavaScript Object Notation (JSON). A resposta da função Lambda deve estar no formato JSON. A resposta da função Lambda é transformada em uma resposta HTTP e enviada para o cliente. O balanceador de carga invoca a função Lambda usando a API Invoke do AWS Lambda e requer que você forneça permissões de invocação para a função Lambda para o serviço Elastic Load Balancing.

Sim. O balanceador de carga da aplicação oferece suporte a invocações do Lambda para solicitações por protocolos HTTP e HTTPS.

Você pode usar o Lambda como destino com o Application Load Balancer nas seguintes regiões da AWS: Leste dos EUA (Norte da Virgínia), Leste dos EUA (Ohio), Oeste dos EUA (Norte da Califórnia), Oeste dos EUA (Oregon), Ásia-Pacífico (Mumbai), Ásia-Pacífico (Seul), Ásia-Pacífico (Singapura), Ásia-Pacífico (Sydney), Ásia-Pacífico (Tóquio), Canadá (Central), UE (Frankfurt), UE (Irlanda), UE (Londres), UE (Paris), América do Sul (São Paulo) e GovCloud (Oeste dos EUA).

Sim, o Application Load Balancer está disponível na zona local de Los Angeles. Dentro da zona local de Los Angeles, o Application Load Balancer operará em uma única sub-rede e será dimensionado automaticamente para atender a vários níveis de carga do aplicativo sem intervenção manual.

Você é cobrado por hora completa ou parcial de execução de um Application Load Balancer e pelo número de Load Balancer Capacity Units (LCUs – Unidades de capacidade de load balancer) usadas por hora.

Uma LCU é uma nova métrica usada para determinar como você paga por um Application Load Balancer. Uma LCU define o máximo de recursos consumidos em qualquer uma das dimensões (novas conexões, conexões ativas, largura de banda e avaliações de regras) em que o Application Load Balancer processa seu tráfego.

Não. Os Classic Load Balancers continuarão sendo cobrados por largura de banda e uso por hora.

O uso de todas as quatro dimensões que constituem uma LCU é exposto pelo Amazon CloudWatch.

Não. O número de LCUs por hora será determinado com base no máximo de recursos consumidos entre as quatro dimensões que constituem uma LCU.

Sim.

Sim. Para novas contas da AWS, o nível gratuito de um Application Load Balancer oferece 750 horas e 15 LCUs. Essa oferta do nível gratuito está disponível somente para novos clientes da AWS por 12 meses a partir da data de cadastramento na AWS.

Sim. Você pode usar balanceadores de carga clássicos e da aplicação dentro dos respectivos limites de 15 GB e 15 LCUs. As 750 horas de load balancer são compartilhadas entre os Classic Load Balancers e os Application Load Balancers.

As avaliações de regras são definidas como o produto do número de regras processadas e a taxa de solicitações média por hora.

O tamanho da chave do certificado afeta apenas o número de novas conexões por segundo no cálculo da LCU para cobrança. A tabela a seguir mostra o valor dessa dimensão para diferentes tamanhos de chave de certificados RSA e ECDSA.

Certificados RSA
Tamanho da chave: <=2K 
Novas conexões por segundo: 25

Tamanho da chave <=4K 
Novas conexões por segundo: 5

Tamanho da chave: <=8K 
Novas conexões por segundo: 1

Tamanho da chave: >8K
Novas conexões por segundo: 0,25

Certificados ECDSA
Tamanho da chave: <=256
Novas conexões por segundo: 25

Tamanho da chave: <=384
Novas conexões por segundo: 5

Tamanho da chave: <=521 
Novas conexões por segundo: 1

Tamanho da chave: >521 
Novas conexões por segundo: 0,25

Não. Como o balanceamento de carga entre zonas está sempre habilitado no Application Load Balancer, você não é cobrado por esse tipo de transferência de dados regional.

Não. Não há cobranças separadas para a habilitação da funcionalidade de autenticação no Application Load Balancer. Ao usar o Amazon Cognito com o Application Load Balancer, a definição de preço do Amazon Cognito será aplicada.

Você paga como de costume por hora completa ou parcial de execução de um Application Load Balancer e pelo número de unidades de capacidade do balanceador de carga (LCU) usadas por hora. Para destinos do Lambda, cada LCU oferece 0,4 GB de bytes processados por hora, 25 novas conexões por segundo, 3.000 conexões ativas por minuto e 1.000 avaliações de regras por segundo. Para a dimensão de bytes processados, cada LCU fornece 0,4 GB por hora por destinos do Lambda contra 1 GB por hora para todos os outros tipos de destino, como contêineres, endereços IP e instâncias do Amazon EC2. Observe que cobranças comuns do AWS Lambda são aplicadas às invocações do Lambda pelo balanceador de carga da aplicação.

Os Application Load Balancers emitem duas novas métricas do CloudWatch. A métrica LambdaTargetProcessedBytes indica os bytes processados por destinos do Lambda, e a métrica StandardProcessedBytes indica os bytes processados por todos os outros tipos de destino.

Sim. Os Network Load Balancers oferecem suporte a listeners TCP, UDP e TCP+UDP (camada 4), bem como a listeners TLS.

O Network Load Balancer fornece balanceamento de carga TCP e UDP (Nível 4). Sua arquitetura processa milhões de solicitações por segundo e padrões súbitos de tráfego volátil, além de oferecer latências extremamente baixas. Além disso, o balanceador de carga da rede também oferece suporte a terminação TLS, preserva o IP de origem dos clientes e dá suporte a IP estável e isolamento zonal. Também oferece suporte a conexões demoradas, muito úteis para aplicações do tipo WebSocket.

Sim. Para fazer isso, você pode usar um listener TCP+UDP. Por exemplo, para um serviço de DNS que usa TCP e UDP, é possível criar um listener TCP+UDP na porta 53, e o balanceador de carga processará o tráfego de solicitações UDP e TCP nessa porta. Você deve associar um listener TCP+UDP a um grupo de destino TCP+UDP.

O Network Load Balancer preserva o IP de origem do cliente, o que não ocorre no Classic Load Balancer. Os clientes podem usar um protocolo de proxy com o balanceador de carga clássico para obter o IP de origem. O balanceador de carga da rede oferece automaticamente um IP estático por zona de disponibilidade ao balanceador de carga, além de habilitar a atribuição de um IP elástico por zona de disponibilidade ao balanceador de carga. O balanceador de carga clássico não oferece suporte a esse recurso.

Sim. Você pode migrar de um Classic Load Balancer para um Network Load Balancer usando uma das opções listadas neste documento.

Sim. Consulte a documentação sobre os limites do Network Load Balancer para obter mais informações.

Sim. Você pode usar o Console de Gerenciamento da AWS, o AWS CLI ou a API para configurar um Network Load Balancer.

Não. Para criar um Classic Load Balancer, use a API 2012-06-01. Para criar um Network Load Balancer ou um Application Load Balancer, use a API 2015-12-01.

Sim. Você pode criar um Network Load Balancer em uma única AZ fornecendo uma única sub-rede durante a criação do balanceador de carga.

Sim. Você pode usar os recursos de verificação de integridade e de failover de DNS do Amazon Route 53 para aprimorar a disponibilidade de aplicativos em execução por trás de Network Load Balancers. O uso do failover de DNS do Route 53 permite executar aplicações em várias zonas de disponibilidade da AWS e designar balanceadores de carga alternativos para failover entre regiões. 

Caso o balanceador de carga da rede esteja configurado para multi-AZ, se não houver instâncias do Amazon EC2 íntegras registradas no balanceador de carga para essa AZ ou se os nós de balanceador de carga de determinada zona não estiverem íntegros, o Route 53 executará failover para nós de balanceador de carga alternativos em outras AZs íntegras.

Não. Os endereços de um Network Load Balancer devem ser completamente controlados por você ou completamente controlados pelo ELB. Esse requisito garante que, ao usar IPs elásticos com um Network Load Balancer, nenhum endereço conhecido pelos clientes seja alterado.

Não. Para cada sub-rede associada que contenha um Network Load Balancer, esse Network Load Balancer poderá oferecer suporte a apenas um endereço IP público ou voltado à Internet.

Os endereços IP elásticos associados ao balanceador de carga serão devolvidos ao grupo alocado e disponibilizados para uso futuro.

O Network Load Balancer pode ser configurado como um balanceador de carga voltado à Internet ou como um balanceador de carga interno, de forma semelhante ao que pode ser feito com o Application Load Balancer e o Classic Load Balancer.

Não. Para cada sub-rede associada que contém um load balancer, o Network Load Balancer pode oferecer suporte a apenas um IP privado.

Sim. Configure listeners TCP que roteiam o tráfego aos destinos que implementam o protocolo WebSockets (https://tools.ietf.org/html/rfc6455). Como o WebSockets é um protocolo da camada 7 e o Network Load Balancer opera na camada 4, o Network Load Balancer não oferece nenhum processamento especial de WebSockets ou outros protocolos de nível mais alto.

Sim. Você pode usar qualquer endereço IP do CIDR da VPC do load balancer para destinos na VPC do load balancer, bem como qualquer endereço IP dos intervalos RFC 1918 (10.0.0.0/8, 172.16.0.0/12 e 192.168.0.0/16) ou do intervalo RFC 6598 (100.64.0.0/10) para destinos localizados fora da VPC do load balancer (locais no EC2-Classic e em ambientes no local acessíveis por meio do AWS Direct Connect). O balanceamento de carga para tipo de destino de endereço IP é permitido apenas para listeners TCP. No momento, não é possível usar esse recurso para listeners UDP.

Sim, os Network Load Balancers com receptores TCP e TLS podem ser usados para configurar o AWS PrivateLink. Não é possível configurar o PrivateLink com listeners UDP em balanceadores de carga da rede.

Embora o protocolo de datagrama do usuário (UDP) não mantenha conexões, o balanceador de carga mantém o estado do fluxo de UDP com base em um hash de cinco tuplas, garantindo que os pacotes enviados no mesmo contexto sejam encaminhados de forma consistente ao mesmo destino. O fluxo será considerado ativo desde que o tráfego esteja fluindo e até que o tempo limite de ociosidade seja atingido. Quando o tempo limite for atingido, o balanceador de carga esquecerá a afinidade e novos pacotes UDP recebidos serão considerados como um novo fluxo e encaminhados pelo balanceamento de carga para um novo destino.

O tempo limite de inatividade do Network Load Balancer para conexões TCP é de 350 segundos. O tempo limite de ociosidade para fluxos de UDP é 120 segundos.

Agora, cada contêiner em uma instância tem o seu próprio grupo de segurança e não precisa compartilhar regras de segurança com outros contêineres. É possível anexar grupos de segurança a uma ENI, e cada ENI em uma instância poderá ter um grupo de segurança diferente. Também existe a possibilidade de mapear um contêiner para o endereço IP de uma ENI específica para associar os grupos de segurança por contêiner. O balanceamento de carga por meio de endereços IP também permite vários contêineres em execução em uma instância usando a mesma porta (porta 80, por exemplo). A capacidade de usar a mesma porta entre vários contêineres permite que os contêineres em uma instância se comuniquem entre si por meio de portas conhecidas, em vez de portas aleatórias.

Existem várias maneiras de fazer um balanceamento de carga híbrido. Se um aplicativo for executado em destinos distribuídos entre uma VPC e um ambiente no local, você poderá adicioná-los ao mesmo grupo de destino usando seus endereços IP. Para migrar para a AWS sem prejudicar o aplicativo, recomendamos adicionar gradualmente os destinos da VPC ao grupo de destino e remover os destinos locais do grupo de destino. Também é possível separar load balancers para destinos locais e da VPC, bem como usar a ponderação de DNS para obter o balanceamento de carga ponderado entre os destinos locais e da VPC.

Não é possível balancear a carga para instâncias EC2-Classic registrando seus IDs de instância como destinos. No entanto, se você vincular essas instâncias EC2-Classic à VPC do load balancer utilizando o ClassicLink e usar os IPs privados dessas instâncias EC2-Classic como destinos, será possível balancear a carga para instâncias EC2-Classic. Se atualmente você estiver usando instâncias EC2 Classic com um Classic Load Balancer, poderá migrar facilmente para um Application Load Balancer.

Você somente pode habilitar o balanceamento de carga entre zonas após criar o seu Network Load Balancer. Isso pode ser feito editando a seção de atributos de balanceamento de carga e marcando a caixa de seleção do suporte ao balanceamento de carga entre zonas.

Sim. Você será cobrado pela transferência regional de dados entre zonas de disponibilidade decorrente da habilitação do balanceamento de carga entre zonas no Network Load Balancer. Verifique as cobranças na seção de transferência de dados da página de preço sob demanda do Amazon EC2.

Sim. No momento, o balanceador de carga da rede permite 200 destinos por zona de disponibilidade. Por exemplo, se você estiver em duas AZs, poderá ter até 400 destinos registrados no balanceador de carga da rede. Se o balanceamento de cargas entre zonas for ativado, o número máximo de destinos será reduzido de 200 por AZ para 200 por balanceador de carga. Portanto, no exemplo acima, quando o balanceamento de carga for ativado, mesmo que o balanceador de carga esteja em duas AZs, você será limitado a 200 destinos registrados no balanceador de carga.

Sim, você pode encerrar conexões TLS no Network Load Balancer. Você deve instalar um certificado SSL no seu balanceador de carga. O load balancer usa esse certificado para encerrar a conexão e descriptografar solicitações de clientes antes de enviá-las para os destinos.

O IP de origem continua a ser preservado, mesmo que você encerre o TLS no Network Load Balancer.

Você pode usar o AWS Certificate Manager para provisionar um certificado SSL ou TLS ou obtê-lo de outras fontes, criando uma solicitação de certificado, conseguindo a assinatura dessa solicitação por uma autoridade de certificação (CA) e carregando o certificado com o AWS Certification Manager (ACM) ou o serviço AWS Identity and Access Management (IAM).

A SNI é habilitada automaticamente quando você associa mais de um certificado TLS ao mesmo listener seguro em um load balancer. Da mesma forma, o modo SNI de um listener seguro é desabilitado automaticamente quando você tem apenas um certificado associado ao listener seguro.

Um Network Load Balancer é integrado ao AWS Certificate Management (ACM). A integração ao ACM simplifica muito a associação de um certificado ao balanceador de carga, o que torna todo o processo de descarga do certificado SSL muito fácil. A compra, o upload e a renovação de certificados SSL/TLS são um processo manual complexo e demorado. Com a integração do ACM ao balanceador de carga da rede, todo esse processo foi reduzido para uma simples solicitação de um certificado SSL/TLS confiável e a seleção do certificado do ACM para provisioná-lo com o balanceador de carga. Depois de criar seu balanceador de carga da rede, é possível configurar um listener TLS e ter uma opção para selecionar um certificado do ACM ou do Identity Access Manager (IAM). Essa experiência é similar à que você tem no balanceador de carga da aplicação ou no balanceador de carga clássico.

Não, apenas a criptografia é compatível com os backends no Network Load Balancer.

O Network Load Balancer é compatível apenas com certificados RSA cujo tamanho de chave seja 2K. Atualmente, não suportamos tamanhos de chave do certificado RSA maiores que 2K ou certificados ECDSA no Network Load Balancer.

Você pode usar o encerramento de TLS no Network Load Balancer nas seguintes regiões da AWS: Leste dos EUA (Norte da Virgínia), Leste dos EUA (Ohio), Oeste dos EUA (Norte da Califórnia), Oeste dos EUA (Oregon), Ásia-Pacífico (Mumbai), Ásia-Pacífico (Seul), Ásia-Pacífico (Singapura), Ásia-Pacífico (Sydney), Ásia-Pacífico (Tóquio), Canadá (Central), UE (Frankfurt), UE (Irlanda), UE (Londres), UE (Paris), América do Sul (São Paulo) e GovCloud (Oeste dos EUA).

Você é cobrado por hora completa ou parcial de execução de um Network Load Balancer e pelo número de Load Balancer Capacity Units (LCUs – Unidades de capacidade de load balancer) usadas pelo Network Load Balancer por hora.

Uma LCU é uma nova métrica usada para determinar como você paga por um Network Load Balancer. Uma LCU define o máximo de recursos consumidos em uma entre as três dimensões (novas conexões/fluxos, conexões/fluxos ativos e largura de banda) em que o Network Load Balancer processa seu tráfego.

As métricas da LCU para o tráfego de TCP são definidas da seguinte forma:

• 800 novas conexões TCP por segundo.
• 100.000 conexões TCP ativas (amostradas por minuto).
• 1 GB por hora para instâncias do Amazon EC2, contêineres e endereços IP como destinos.

As métricas da LCU para o tráfego de UDP são definidas da seguinte forma:

• 400 novos fluxos por segundo.
• 50.000 fluxos de UDP ativos (amostrados por minuto).
• 1 GB por hora para instâncias do Amazon EC2, contêineres e endereços IP como destinos.

As métricas da LCU para o tráfego de TLS são definidas da seguinte forma:

• 50 novas conexões TLS por segundo.
• 3.000 conexões TLS ativas (amostradas por minuto).
• 1 GB por hora para instâncias do Amazon EC2, contêineres e endereços IP como destinos.

Não. Para cada protocolo, você terá que pagar apenas por uma das três dimensões (a mais alta a cada hora).

Não. Várias solicitações podem ser enviadas em uma única conexão.

Não. Os Classic Load Balancers continuarão sendo cobrados pela largura de banda e pela taxa horária.

Nós demonstraremos o uso de todas as três dimensões que constituem uma LCU por meio do Amazon CloudWatch.

Não. O número de LCUs por hora será determinado com base no máximo de recursos consumidos entre as três dimensões que constituem uma LCU.

Sim.

Sim. Para novas contas da AWS, o nível gratuito de um Network Load Balancer oferece 750 horas e 15 LCUs. Essa oferta do nível gratuito está disponível somente para novos clientes da AWS por 12 meses a partir da data de cadastramento na AWS.

Sim. Você pode usar os balanceadores de carga da aplicação e da rede dentro dos respectivos limites de 15 LCUs e 15 GB. As 750 horas de balanceador de carga são compartilhadas entre balanceadores de carga da aplicação, da rede e clássico.

Você deve usar o Gateway Load Balancer ao implantar dispositivos virtuais sequenciais nos quais o tráfego de rede não é destinado ao próprio Gateway Load Balancer. O Gateway Load Balancer passa de maneira transparente todo o tráfego da Camada 3 por meio de dispositivos virtuais de terceiros e é invisível para a origem e o destino do tráfego. Para obter mais detalhes sobre a comparação desses balanceadores de carga, consulte a página de comparação de recursos.

O Gateway Load Balancer é executado em uma AZ.

O Gateway Load Balancer oferece recursos de gateway de Nível 3 e de balanceamento de carga de Nível 4. Ele é um dispositivo bump-in-the-wire transparente que não muda nenhuma parte do pacote. Sua arquitetura processa milhões de solicitações/segundo e padrões de tráfego volátil, e oferece latências extremamente baixas. Consulte os recursos do Gateway Load Balancer nesta tabela. 

O Gateway Load Balancer não executa a terminação TLS e não mantém nenhum estado de aplicação. Essas funções são executadas pelos dispositivos virtuais de terceiros para os quais ele direciona e dos quais ele recebe o tráfego.

O Gateway Load Balancer não mantém o estado da aplicação, mas mantém a aderência do fluxo a um dispositivo específico usando cinco tuplas (para fluxos com TCP e UDP) ou três tuplas (para fluxos sem TCP e UDP).

Por padrão, o Gateway Load Balancer define um fluxo como uma combinação de 5 tuplas que inclui IP de origem, IP de destino, protocolo IP, porta de origem e porta de destino. Usando o hash padrão de cinco tuplas, o balanceador de carga do gateway garante que ambas as direções de um fluxo (ou seja, origem para destino e destino para origem) sejam encaminhadas de forma consistente ao mesmo destino. O fluxo será considerado ativo desde que o tráfego esteja fluindo e até que o tempo limite de ociosidade seja atingido. Quando o tempo limite for atingido, o balanceador de carga esquecerá a afinidade, e novos pacotes de tráfego recebidos serão considerados um novo fluxo e encaminhados pelo balanceamento de carga para um novo destino.

A aderência padrão de 5 tuplas (IP de origem, IP de destino, protocolo IP, porta de origem e porta de destino) fornece a melhor distribuição de tráfego para os destinos e é adequada para a maioria dos aplicativos baseados em TCP e UDP, com algumas exceções. A aderência padrão de 5 tuplas não é adequada para aplicativos baseados em TCP ou UDP que usam fluxos ou números de porta separados para controle e dados, como FTP, Microsoft RDP, Windows RPC e SSL VPN. O controle e os fluxos de dados dessas aplicações podem chegar em dispositivos de destino diferentes e causar interrupção do tráfego. Se quiser oferecer suporte a esses protocolos, você deve ativar a aderência do fluxo GWLB usando 3 tuplas (IP de origem, IP de destino, protocolo IP) ou 2 tuplas (IP de origem, IP de destino).

Alguns aplicativos não usam nenhum transporte TCP ou UDP, mas usam protocolos IP, como SCTP e GRE. Com a aderência padrão de 5 tuplas do GWLB, os fluxos de tráfego desses protocolos podem chegar a diferentes dispositivos de destino e causar interrupções. Se quiser oferecer suporte a esses protocolos, você deve ativar a aderência do fluxo GWLB usando 3 tuplas (IP de origem, IP de destino, protocolo IP) ou 2 tuplas (IP de origem, IP de destino).

Consulte a documentação sobre aderência do fluxo para saber como alterar o tipo de aderência do fluxo.

O tempo limite de inatividade do Gateway Load Balancer para conexões TCP é de 350 segundos. O tempo limite de ociosidade para fluxos não TCP é 120 segundos. Esses limites de tempo são fixos e não podem ser alterados.

Como um bump-in-the-wire transparente, o próprio GWLB não fragmenta nem remonta pacotes.

O GWLB encaminha fragmentos UDP de/para dispositivos de destino. No entanto, o GWLB descarta fragmentos TCP e ICMP porque o cabeçalho da camada 4 não está presente nesses fragmentos.

Além disso, se o dispositivo de destino converter o pacote de entrada original em fragmentos e enviar os fragmentos recém-criados de volta para o GWLB, o GWLB descartará esses fragmentos recém-criados porque eles não contêm o cabeçalho da camada 4. Para evitar a fragmentação no dispositivo de destino, recomendamos habilitar o quadro jumbo nesse dispositivo ou configurar a interface de rede do dispositivo de destino para usar a MTU máxima desejada, alcançando assim um comportamento de encaminhamento transparente mantendo o conteúdo original do pacote no estado em que se encontra. 

Quando uma única instância de dispositivo virtual falha, o Gateway Load Balancer a remove da lista de roteamento e redireciona o tráfego para uma instância de dispositivo íntegra.

Se todos os dispositivos virtuais na zona de disponibilidade falharem, o Gateway Load Balancer descartará o tráfego de rede. Recomendamos a implantação de balanceadores de carga do gateway em várias AZs para obter maior disponibilidade. Se todos os dispositivos falharem em uma AZ, os scripts poderão ser usados para adicionar novos dispositivos ou direcionar o tráfego para um balanceador de carga do gateway em uma AZ diferente.

Sim, vários Gateway Load Balancers podem apontar para o mesmo conjunto de dispositivos virtuais.

O Gateway Load Balancer é um dispositivo transparente bump-in-the-wire que recebe todos os tipos de tráfego IP (incluindo TCP, UDP, ICMP, GRE, ESP e outros). Portanto apenas o ouvinte IP é criado em um Gateway Load Balancer.

Sim. Consulte a documentação sobre os limites do Gateway Load Balancer para obter mais informações.

Sim. Você pode usar o Console de Gerenciamento da AWS, a AWS CLI ou a API para configurar um Gateway Load Balancer.

Sim. Você pode gerar um Gateway Load Balancer em uma única zona de disponibilidade fornecendo uma única sub-rede durante a criação do balanceador de carga. Porém, recomendamos usar várias zonas de disponibilidade para uma melhor disponibilidade. Não é possível adicionar ou remover zonas de disponibilidade de um Gateway Load Balancer depois dele ser criado.

Por padrão, o balanceamento de carga entre zonas está desabilitado. Você só pode habilitar o balanceamento de carga entre zonas após criar o seu Gateway Load Balancer. Isso pode ser feito editando a seção de atributos de balanceamento de carga e marcando a caixa de seleção do suporte ao balanceamento de carga entre zonas.

Sim, você pagará pela transferência de dados entre zonas de disponibilidade com o Gateway Load Balancer quando o balanceamento de carga entre zonas estiver habilitado. Verifique a cobrança na seção de transferência de dados da página de definição de preço sob demanda do Amazon EC2.

Sim. No momento, o Gateway Load Balancer permite 300 destinos por Zona de Disponibilidade. Por exemplo, se você criou o Gateway Load Balancer em três Zonas de Disponibilidade, poderá ter até 900 destinos registrados. Se o balanceamento de cargas entre zonas for ativado, o número máximo de destinos será reduzido de 300 por Zona de Disponibilidade para 300 por Gateway Load Balancer.

Você paga por hora completa ou parcial de execução de um Gateway Load Balancer e pelo número de unidades de capacidade de Gateway Load Balancer usadas pelo Gateway Load Balancer por hora.

Uma LCU é uma métrica do Elastic Load Balancing para determinar como você paga por um Gateway Load Balancer. Uma LCU define o máximo de recursos consumidos em uma entre as três dimensões (novas conexões/fluxos, conexões/fluxos ativos e largura de banda) em que o Gateway Load Balancer processa seu tráfego.

As métricas de LCU para o tráfego TCP são as seguintes:

• 600 novos fluxos (ou conexões) por segundo.
• 60.000 fluxos (ou conexões) ativos (amostrados por minuto).
• 1 GB por hora para instâncias do EC2, contêineres e endereços IP como destinos.

Não, você pagará apenas por uma das três dimensões (a mais alta a cada hora).

Não. Várias solicitações podem ser enviadas em uma única conexão.

Você pode acompanhar o uso de todas as três dimensões de uma LCU no Amazon CloudWatch.

Sim.

Para serem valiosos, os dispositivos virtuais precisam introduzir o mínimo de latência adicional possível, e o tráfego que flui de e para o dispositivo virtual deve seguir uma conexão segura. Os endpoints do balanceador de carga do gateway criam as conexões seguras e de baixa latência necessárias para atender a esses requisitos.

Usando um terminal de Gateway Load Balancer, os dispositivos podem residir em diferentes contas AWS e VPCs. Isso permite que os dispositivos fiquem centralizados em um local para facilitar o gerenciamento e reduzir a sobrecarga operacional.

Os Gateway Load Balancer Endpoints são um novo tipo de VPC endpoint que usa a tecnologia PrivateLink. Conforme o tráfego de rede flui de uma origem (um gateway da Internet, uma VPC, etc.) para o Gateway Load Balancer e vice-versa, um Gateway Load Balancer Endpoint garante a conectividade privada entre os dois. Todo o tráfego flui pela rede AWS e os dados nunca são expostos à Internet, aumentando a segurança e a performance.

Um endpoint da Interface PrivateLink é emparelhado com um Network Load Balancer (NLB) para distribuir o tráfego TCP e UDP que é destinado às aplicações Web. Em contraste, os Gateway Load Balancer Endpoints são usados com Gateway Load Balancers para conectar a origem e o destino do tráfego. O tráfego flui do Gateway Load Balancer Endpoint para o Gateway Load Balancer por meio dos dispositivos virtuais e retorna ao destino por meio de conexões PrivateLink protegidas.

O Endpoint do Gateway Load Balancer é um Endpoint de VPC, e não há limite para quantos Endpoints de VPC podem se conectar a um serviço que usa o Gateway Load Balancer. No entanto, recomendamos conectar no máximo 50 terminais do Gateway Load Balancer por um Gateway Load Balancer para reduzir o risco de um impacto mais amplo em caso de falha no serviço.