Amazon ANS-C01: Balanceamento de Carga e Gerenciamento de Tráfego — Guia de estudos
Faz parte do AWS Advanced Networking Specialty ANS-C01 — Guia de estudos. Pratique com respostas verificadas no centro de exames da Amazon, ou faça testes cronometrados no ExamRoll.io.
Conceito principal
O balanceamento de carga na AWS opera em duas camadas fundamentais: L4 (transporte) e L7 (aplicação). O Network Load Balancer (NLB) fornece distribuição na L4 (TCP/UDP/TLS) e é otimizado para desempenho extremo, preservando o IP de origem do cliente e suportando milhões de conexões simultâneas com latência muito baixa e pouca rotatividade de conexões (connection churn). O Application Load Balancer (ALB) opera na L7 (HTTP/HTTPS/WebSocket e HTTP/2/gRPC), fornece roteamento baseado em host e caminho (path), inspeção de cabeçalhos, verificações de saúde (health checks) baseadas em HTTP e persistência de sessão com cookies (cookie stickiness), e realiza a terminação de TLS quando configurado com certificados no ACM. O Gateway Load Balancer (GWLB) é um load balancer de propósito específico para escalar appliances virtuais de terceiros (firewalls, IDS/IPS) usando o encapsulamento GENEVE e endpoints do Gateway Load Balancer (GWLBe), permitindo a inspeção de tráfego em linha (inline) sem a necessidade de escalar os appliances manualmente.
Listeners e regras de listener são os pontos de entrada L4/L7 que mapeiam protocolos/portas para os target groups. Um listener em um ALB pode ter regras complexas que inspecionam host, caminho (path), cabeçalhos, CIDR do IP de origem e encaminham para diferentes target groups; o ALB também pode descarregar (terminar) o TLS e apresentar os cabeçalhos X-Forwarded-For, X-Forwarded-Proto e X-Forwarded-Port para os alvos (targets). Um listener de NLB é tipicamente um listener TCP/UDP/TLS que encaminha o tráfego para os target groups sem analisar o payload (a menos que você habilite a terminação de TLS no NLB): ao usar o modo passthrough de TCP, você preserva o TLS de ponta a ponta, de modo que o backend deve apresentar e validar certificados para TLS mútuo (mTLS). Target groups são a ligação entre um listener de load balancer e o conjunto de endpoints (instância, IP ou Lambda), e eles expõem atributos como protocolo/porta/caminho da verificação de saúde, atraso de cancelamento de registro (deregistration delay ou connection draining) e propriedades de persistência de sessão (stickiness).
Serviços e configurações principais
Escolha o balanceador certo para as características do tráfego e os requisitos de segurança. Use o ALB quando precisar de roteamento baseado em host/caminho, recursos HTTP/HTTPS como WebSockets ou HTTP/2/gRPC com roteamento ciente da aplicação e persistência de sessão baseada em cookies. Configure os listeners do ALB com CreateListener ou via AWS::ElasticLoadBalancingV2::Listener, anexe certificados do ACM e defina regras de listener usando CreateRule com condições (Field=path-pattern, host-header, http-header). Habilite a persistência de sessão (stickiness) nos target groups do ALB com ModifyTargetGroupAttributes, definindo Key=stickiness.enabled,Value=true e Key=stickiness.lb_cookie.duration_seconds,Value=<seconds> para usar cookies gerados pelo load balancer.
Use o NLB para conexões TCP de alta vazão (throughput) e longa duração, e quando a preservação do IP de origem do cliente for necessária no backend. Crie um NLB com aws elbv2 create-load-balancer –name my-nlb –type network –subnets <subnet-ids> e adicione um listener TCP com aws elbv2 create-listener –load-balancer-arn <arn> –protocol TCP –port 443 –default-actions Type=forward,TargetGroupArn=<tg-arn>. Para TLS passthrough e mTLS, configure o listener do NLB como TCP para que o TLS seja terminado pelo backend; defina o target group como target-type ip ao registrar IPs de pods para o Kubernetes. Use ModifyTargetGroupAttributes para definir Key=deregistration_delay.timeout_seconds,Value=<seconds> para permitir o esvaziamento de conexões (connection draining); para o NLB, você também pode habilitar a afinidade de IP de origem (persistência de sessão no target group) quando apropriado.
O Gateway Load Balancer é configurado com CreateLoadBalancer Type=gateway e apoiado por target groups de suas instâncias de appliance (ou um scale set em um autoscaling group), e usa um endpoint do Gateway Load Balancer em VPCs consumidoras para direcionar o tráfego para os appliances na VPC de serviço. Use este padrão quando precisar de inspeção transparente e quiser que os appliances escalem com o tráfego automaticamente; crie listeners na porta 6081 (encapsulamento GENEVE) e registre as ENIs dos appliances no target group do GWLB.
Configurações operacionais que você deve controlar programaticamente incluem o balanceamento de carga entre zonas (cross-zone load balancing), o atraso de cancelamento de registro (deregistration delay ou connection draining) e o ajuste fino das verificações de saúde (health check tuning). Para o balanceamento entre zonas, defina atributos no load balancer (aws elbv2 modify-load-balancer-attributes –load-balancer-arn <arn> –attributes Key=load_balancing.cross_zone.enabled,Value=true) para garantir a distribuição de tráfego entre as AZs, em vez de distorcer a capacidade por AZ. Defina o intervalo da verificação de saúde, o tempo limite (timeout) e os limiares de saudável/não saudável (healthy/unhealthy thresholds) nos target groups para evitar oscilações (flapping) durante eventos de autoscaling.
Padrões de design e trade-offs
Para TLS de ponta a ponta e TLS mútuo (mTLS), nos quais o tráfego precisa permanecer criptografado e os certificados de cliente devem ser apresentados ao backend, prefira o passthrough de Camada 4 (L4) usando um NLB com listeners TCP. Isso mantém a sessão TLS intacta para que os backends possam validar os certificados X.509 do cliente; configure os target groups para usar alvos de IP (IP targets) para que os IPs dos pods do Kubernetes possam ser registrados diretamente e o AWS Load Balancer Controller possa gerenciar o ciclo de vida dos alvos. O trade-off é a perda de recursos de Camada 7 (L7) do ALB, como roteamento por host/caminho, integrações com o Web Application Firewall e a aderência de sessão (stickiness) nativa por cookies HTTP na camada do load balancer.
Quando você precisar de roteamento baseado em conteúdo, terminação de TLS e recursos HTTP avançados, use um ALB e termine o TLS no próprio ALB (com certificados gerenciados pelo ACM). Para reter o IP do cliente para fins de logs e regras do WAF, leia o cabeçalho X-Forwarded-For que o ALB preenche ou use uma camada que injete o IP original do cliente nos cabeçalhos. Se você precisar que o sistema operacional/pilha de rede do backend veja o IP do cliente no nível do socket, use um NLB (ou habilite o Proxy Protocol para passar o IP original), mas observe que o Proxy Protocol deve ser habilitado no target group e sua aplicação ou proxy (por exemplo, Envoy) deve ser capaz de interpretá-lo.
Lidar com sessões aderentes (sticky sessions) em um ambiente de autoscaling exige consideração cuidadosa. A aderência de sessão por cookie do ALB pode vincular um cliente a um alvo por uma determinada duração, o que pode inibir o escalonamento balanceado entre os pods se o tráfego da sessão for intenso; padrões alternativos incluem o uso de aderência de curta duração combinada com a externalização do estado da sessão para o ElastiCache (Redis) ou DynamoDB, ou o uso de um proxy sidecar (Envoy) para lidar com a afinidade de sessão com hash consistente (consistent hashing). O esvaziamento de conexões (connection draining ou deregistration delay) é crítico para um desligamento gradual (graceful shutdown): defina o deregistration_delay.timeout_seconds para uma duração maior que a da requisição RPC/HTTP mais longa para evitar terminações abruptas e erros no cliente durante a terminação do pod; configure os preStop hooks do Kubernetes para coordenar o ciclo de vida do pod com o cancelamento do registro (deregistration).
O GWLB é o padrão apropriado quando você precisa de inspeção inline escalável em várias VPCs e deseja controles de segurança centralizados. Combine o GWLB com arquiteturas de Transit Gateway ou VPC peering conforme necessário; o custo e a complexidade operacional do gerenciamento de appliances são os trade-offs em comparação com o uso de serviços gerenciados como o AWS Network Firewall.
Armadilhas comuns e critérios de decisão
Um erro frequente é encerrar o TLS no ALB sem levar em conta as necessidades downstream de autenticação do cliente ou do IP de origem original. Se os backends exigirem o certificado do cliente ou o verdadeiro IP de origem na camada TCP (para fins de log ou autorização), encerre o TLS no backend via passthrough do NLB ou use o Proxy Protocol e garanta que a aplicação o analise. Outra armadilha comum é habilitar sessões fixas (sticky sessions) sem um armazenamento de sessão externo ao usar o Horizontal Pod Autoscaler: à medida que os pods escalam para mais ou para menos (scale out/in), a afinidade fixa pode criar pontos de sobrecarga (hotspots) e capacidade desperdiçada; prefira backends sem estado (stateless) ou externalize o estado da sessão.
Erros operacionais também surgem de verificações de saúde (health checks) mal configuradas e atrasos de cancelamento de registro (deregistration delays) que levam à perda de requisições durante o escalonamento. Sempre defina os caminhos e os limites das verificações de saúde para refletir o aquecimento da aplicação e use deregistration_delay.timeout_seconds para permitir que conexões de longa duração sejam drenadas. O balanceamento de carga entre zonas (cross-zone load balancing) deve ser configurado intencionalmente: habilitá-lo reduz a latência de cauda (tail latency) e uniformiza a carga, mas pode aumentar os custos de transferência de dados entre AZs; avalie em relação à capacidade da AZ e aos padrões de tráfego. Por fim, o GWLB introduz encapsulamento (GENEVE) e sobrecarga de gerenciamento de appliances — automatize o registro de appliances usando as APIs da AWS (CreateTargetGroup/RegisterTargets) e instrumente com métricas do CloudWatch para orientar as políticas de autoscaling.
Problema Prático: Cenário de Caso de Uso
Empresa: Acme Telemetry. Desafio: Fornecer criptografia de ponta a ponta para um serviço gRPC (gRPC sobre TLS na porta TCP 443) implantado em um cluster Amazon EKS, suportar milhares de conexões simultâneas de longa duração, usar o Kubernetes Cluster Autoscaler e o HPA, e exigir TLS mútuo (mTLS) para que o certificado do cliente seja validado pelo backend (ou seja, o tráfego não deve ser descriptografado por nenhum balanceador de carga intermediário).
Abordagem de implementação do caso de uso: Provisione um Network Load Balancer com um listener TCP na porta 443 e um grupo de destino (target group) do tipo “ip” apontando para os IPs dos pods. Crie o NLB com
aws elbv2 create-load-balancer --name acme-nlb --type network --subnets <subnet-ids>, crie o grupo de destino comaws elbv2 create-target-group --name tg-grpc --protocol TCP --port 443 --target-type ip --vpc-id <vpc-id>, registre os alvos (targets) através das anotações do AWS Load Balancer Controller para Kubernetes (service.beta.kubernetes.io/aws-load-balancer-type: "nlb-ip") para que o controller registre os IPs dos pods automaticamente, e crie o listener comaws elbv2 create-listener --load-balancer-arn <arn> --protocol TCP --port 443 --default-actions Type=forward,TargetGroupArn=<tg-arn>. Defina o atributo do grupo de destinoderegistration_delay.timeout_secondspara um valor apropriado (por exemplo, 300) usandoaws elbv2 modify-target-group-attributespara habilitar a drenagem gradual (graceful draining).Configuração de TLS e mTLS no backend: Encerre o TLS e realize o TLS mútuo na camada do pod. Implante sidecars Envoy ou faça com que os servidores gRPC aceitem TLS diretamente, armazenando certificados de servidor e pacotes de CA (CA bundles) em Kubernetes Secrets e montando-os no pod. Configure os backends para validar os certificados do cliente em relação à sua CA e configure as verificações de saúde para usar TCP para evitar o encerramento do TLS no load balancer. Garanta que os hooks de ciclo de vida do HPA e do Cluster Autoscaler se coordenam com o cancelamento de registro do grupo de destino, implementando hooks preStop que permitem que os pods terminem a drenagem antes de serem encerrados.
Escalabilidade e controles operacionais: Habilite o balanceamento de carga entre zonas (cross-zone load balancing) no NLB, se necessário, com
aws elbv2 modify-load-balancer-attributes --load-balancer-arn <arn> --attributes Key=load_balancing.cross_zone.enabled,Value=truepara distribuir as conexões uniformemente entre as AZs. Monitore conexões simultâneas e taxas de fluxo com métricas do CloudWatch (NetworkPackets, ActiveFlowCount para o NLB) e defina políticas de autoscaling para o appliance (se estiver usando um sidecar) e para os nós de trabalho (worker nodes). UseModifyTargetGroupAttributespara drenagem de conexão e ajuste os intervalos das verificações de saúde para uma detecção de falhas mais rápida e sem instabilidade (flapping). Por fim, automatize a rotação de certificados usando a integração do AWS Secrets Manager com o cert-manager do Kubernetes.
Justificativa da AWS: O NLB em modo TCP preserva a sessão TLS de ponta a ponta para que o backend possa realizar a validação mTLS; sua arquitetura L4 é construída para milhões de fluxos simultâneos e conexões de longa duração, e o uso do tipo de destino ip permite que o AWS Load Balancer Controller registre os IPs dos pods diretamente, permitindo que o HPA/Cluster Autoscaler escalem de forma transparente. A drenagem de conexão (deregistration_delay) e as verificações de saúde evitam a perda de requisições durante o encerramento do pod, e o balanceamento entre zonas garante uma distribuição uniforme entre as AZs, trocando o custo de transferência entre AZs por desempenho.
← DNS e Route 53 · Todos os domínios · Segurança de Rede e Conformidade →
Pratique estas questões → · Prática cronometrada no ExamRoll.io →
Pass the whole exam — not just this question
You found this answer. Get every verified question and explanation in one place, and save hours of prep. Free to start.
Passe no seu exame →