As setas no diagrama indicam apenas a direção do estabelecimento da conexão - não o fluxo de tráfego.
Sim, o tráfego de retorno volta pelo ELB.
Mas, não é um NAT com estado - é um proxy de conexão TCP. As máquinas ELB aceitam conexões TCP nas portas de atendimento configuradas, encerrando a sessão SSL, se houver, e estabelecem uma nova conexão TCP com o servidor back-end. Se o ouvinte estiver configurado para HTTP, o ELB operará em um modo com reconhecimento de carga útil, analisando, registrando e encaminhando solicitações HTTP para o back-end, caso contrário, ele é independente da carga, estabelecendo uma nova conexão TCP 1: 1 para o back-end. para cada conexão de entrada e "amarrando os pipes" (sem reconhecimento ou modificação no nível de HTTP).
De qualquer maneira, o endereço de origem da conexão de entrada para o seu aplicativo será o do nó ELB, não o cliente original. É assim que o tráfego de resposta retorna ao ELB para retornar ao cliente.
No modo http, o ELB adiciona (ou anexa a) o X-Forwarded-Forcabeçalho para que seu aplicativo possa identificar o IP do cliente original, bem como X-Forwarded-Proto: [ http | https ]para indicar se a conexão do cliente usa SSL e X-Forwarded-Portpara indicar a porta front-end.
Atualização: o item acima se refere a um tipo de balanceador de carga que agora é conhecido como "ELB Classic" ou ELB / 1.0 (encontrado na cadeia de agentes do usuário que ele envia com verificações de integridade HTTP).
O balanceador de camada 7 mais recente, o Application Load Balancer ou ELB / 2.0 opera de maneira semelhante, com relação ao fluxo de tráfego. O recurso Camada 4 (TCP "transparente") é removido do ALB e os recursos da camada 7 aprimorados significativamente.
O mais novo tipo de balanceador de carga, o Network Load Balancer, é um balanceador de Camada 3. Ao contrário dos outros dois, ele se comporta de maneira semelhante ao NAT dinâmico, manipulando apenas conexões de entrada (de origem externa), mapeando source-addr + port através do EIP-addr + port para instance-private-ip: adde + port - com o EIP vinculadas ao "balanceador" - e, ao contrário dos outros dois tipos de balanceadores, as instâncias precisam estar em sub-redes públicas e usar seus próprios IPs públicos para isso.
Conceitualmente falando, o Network Load Balancer parece realmente modificar o comportamento do Gateway da Internet - que é, por si só, um objeto lógico que não pode ser desativado, substituído ou sofrer uma falha em qualquer sentido significativo. Isso contrasta com ELB e ALB, que realmente operam em instâncias "ocultas" do EC2. O NLB opera na infraestrutura de rede, por si só, sob todas as aparências.
and unlike the other two types of balancers, the instances need to be on public subnets, and use their own public IPs for this.Estou muito feliz em ler isso. Você pode fornecer uma referência a essas informações?De acordo com a documentação da AWS para NLB, é a camada 4 e não a camada 3. Além disso, os servidores de back-end ou de destino não precisam estar em uma sub-rede pública. Por uma questão de fato, os intervalos de endereços IP dos grupos-alvo devem ser um dos seguintes: Os seguintes são os tipos de destino possíveis:
instância Os destinos são especificados pelo ID da instância.
ip Os destinos são especificados pelo endereço IP.
Quando o tipo de destino é ip, você pode especificar endereços IP de um dos seguintes blocos CIDR:
As sub-redes da VPC para o grupo-alvo
10.0.0.0/8 (RFC 1918)
100.64.0.0/10 (RFC 6598)
172.16.0.0/12 (RFC 1918)
192.168.0.0/16 (RFC 1918)
Importante
Você não pode especificar endereços IP roteados publicamente.
Eu espero que isso ajude.
fonte