Auto Scaling e Elastic Load Balancing: Guia de Alta Disponibilidade na AWS

Eduardo Souza | CEO Dominit

Uma aplicação dimensionada para o pico de tráfego de sexta-feira passa a maior parte da semana com capacidade ociosa — e uma aplicação dimensionada para a média passa a sexta-feira inteira derrubando conexão. O EC2 Auto Scaling e o Elastic Load Balancing resolvem esse dilema há mais de uma década na AWS, ajustando a capacidade de computação em tempo real e distribuindo o tráfego entre instâncias saudáveis — sem que ninguém precise ficar de plantão decidindo quando ligar ou desligar servidor. Neste guia, você vai entender como as políticas de escala funcionam na prática, as diferenças reais entre Application, Network e Gateway Load Balancer, como CloudWatch e health checks conversam com o Auto Scaling Group, e quanto tudo isso custa.

O Que É Alta Disponibilidade na AWS e Por Que Ela Importa

Alta disponibilidade, na prática da AWS, não é sinônimo de "muitos servidores" — é a capacidade de um sistema continuar respondendo mesmo quando uma instância, uma zona de disponibilidade ou um componente falha, sem intervenção manual. Isso exige três coisas trabalhando juntas: redundância (mais de um recurso fazendo o mesmo trabalho, em locais fisicamente diferentes), detecção de falha (algo precisa perceber que uma instância parou de responder) e redirecionamento automático (o tráfego precisa parar de ir para quem falhou e continuar indo para quem está saudável).

O Auto Scaling Group cuida da primeira parte — mantém o número certo de instâncias rodando, substituindo automaticamente qualquer uma que falhe. O Elastic Load Balancing cuida da segunda e da terceira — verifica a saúde de cada instância e distribui o tráfego só para as que estão respondendo. Separadamente, cada serviço já resolve um problema. Juntos, formam o padrão de arquitetura que sustenta a maior parte das aplicações web sérias rodando na AWS hoje, de e-commerce a sistemas internos de missão crítica.

O erro mais comum em empresas que ainda não passaram por essa migração é tratar disponibilidade como um problema de hardware — "comprar um servidor maior" — quando na nuvem o problema vira um problema de arquitetura: quantas instâncias, em quantas zonas, com que política de substituição.

Como Funciona o EC2 Auto Scaling: Launch Templates e Políticas de Escala

Um Auto Scaling Group (ASG) é definido por um launch template — o "molde" que descreve a AMI, o tipo de instância, a configuração de rede, o par de chaves e o IAM role de cada instância nova — e por três números de capacidade: mínimo, desejado e máximo. O ASG nunca deixa a capacidade sair desses limites, e é dentro deles que as políticas de escala atuam.

Existem três formas de definir quando e quanto escalar:

Target tracking scaling — a política mais usada hoje. Você escolhe uma métrica (CPU média do grupo, rede, ou ALBRequestCountPerTarget do load balancer) e um valor-alvo, e o Auto Scaling Group cria e gerencia sozinho o alarme do CloudWatch necessário para manter aquele alvo — de forma parecida com um termostato mantendo uma temperatura. Se a CPU média sobe acima do alvo, o grupo escala para fora (adiciona instância); se cai abaixo, escala para dentro (remove instância), sempre priorizando disponibilidade — o grupo só reduz capacidade quando todas as políticas ativas concordam que dá para reduzir.

Step scaling — dá mais controle explícito do que o target tracking: você define degraus de resposta diferentes conforme o tamanho do desvio da métrica (por exemplo, adicionar 1 instância se a CPU passar de 70%, e 3 instâncias se passar de 90%). É a opção certa quando o padrão de carga da aplicação não é linear e o time quer decidir manualmente a agressividade da resposta, em vez de deixar o algoritmo de target tracking decidir sozinho.

Scheduled scaling — ajusta a capacidade mínima e máxima em horários previsíveis, como aumentar a capacidade antes da abertura do mercado ou reduzir durante a madrugada. Não reage a métrica nenhuma — reage ao relógio. Costuma ser combinada com uma das outras duas políticas: o scheduled scaling garante um piso de capacidade, e o target tracking cuida da variação dentro daquele piso.

Um detalhe que pega muita implantação de primeira viagem: o tempo de warm-up da instância. Enquanto uma instância nova ainda está inicializando a aplicação, ela não deveria contar nas métricas agregadas do grupo nem receber tráfego do load balancer — configurar esse tempo errado faz o Auto Scaling achar que já tem capacidade suficiente quando na verdade as instâncias novas ainda não estão prontas para atender.

Como Funciona o Elastic Load Balancing: ALB, NLB e Gateway Load Balancer

O Elastic Load Balancing não é um produto único — é uma família de três balanceadores com propósitos diferentes, e escolher o errado é um erro de arquitetura que só aparece sob carga.

Application Load Balancer (ALB) opera na camada 7 (aplicação) do modelo OSI — ele entende HTTP e HTTPS de verdade, o que permite rotear requisições por conteúdo: por path (/api para um grupo de instâncias, /admin para outro), por host header, ou por cabeçalho customizado. É a escolha padrão para aplicações web e microsserviços, e o único dos três com suporte nativo a WebSocket e a roteamento baseado em regras.

Network Load Balancer (NLB) opera na camada 4 (transporte), lidando com TCP, UDP e TLS puro, sem inspecionar o conteúdo da requisição. Isso o torna capaz de sustentar milhões de requisições por segundo com latência ultra baixa, e é a escolha certa para tráfego que não é HTTP (bancos de dados, protocolos proprietários, jogos multiplayer) ou para quem precisa de IP estático — o NLB atribui um endereço IP fixo por zona de disponibilidade, o que o ALB não faz.

Gateway Load Balancer (GWLB) resolve um problema diferente dos outros dois: não distribui tráfego de aplicação, distribui tráfego para uma camada de appliances de terceiros — firewalls de próxima geração, sistemas de detecção de intrusão, ferramentas de inspeção de pacote. Ele opera na camada 3 usando o protocolo GENEVE, funcionando como um ponto único de entrada e saída transparente para essas appliances, tipicamente combinado com VPC endpoints via PrivateLink para expor esse serviço entre contas.

Não existe "o melhor load balancer" — existe o load balancer certo para o protocolo e o padrão de tráfego da carga de trabalho. É comum uma arquitetura séria usar os três ao mesmo tempo: ALB na borda para o tráfego web, NLB internamente para um serviço TCP de baixa latência, e GWLB na frente de uma appliance de segurança que inspeciona tudo que passa entre VPCs.

Como Auto Scaling e Elastic Load Balancing Trabalham Juntos

A integração entre os dois serviços acontece em dois pontos: health checks e distribuição de tráfego.

Quando um Auto Scaling Group é associado a um target group de um load balancer, o ELB passa a fazer health checks periódicos em cada instância — normalmente uma requisição HTTP para um path configurado, esperando um código de resposta específico. Uma instância que falha nesse check repetidamente é marcada como "unhealthy" e para de receber tráfego novo imediatamente, mesmo antes do Auto Scaling decidir substituí-la. O Auto Scaling Group, por sua vez, pode ser configurado para usar esse mesmo resultado de health check do ELB (em vez de só o status básico da instância na EC2) como critério de substituição — uma instância que está "up" na camada de rede mas cuja aplicação travou é derrubada e recriada automaticamente.

Do outro lado, o load balancer é quem informa ao Auto Scaling, via a métrica ALBRequestCountPerTarget, o volume real de requisições que cada instância está processando — permitindo que a política de escala reaja ao volume de trabalho de verdade, e não a um proxy indireto como CPU, que nem sempre reflete carga real em aplicações com gargalo de I/O ou de rede.

Esse ciclo fechado — health check informa remoção de tráfego, métrica de tráfego informa decisão de escala, escala informa quantas instâncias existem para receber tráfego — é o que permite a uma aplicação absorver tanto uma falha pontual de instância quanto um pico de demanda sustentado, com o mesmo conjunto de dois serviços.

ALB vs NLB vs Gateway Load Balancer: Tabela Comparativa

Critério	Application Load Balancer	Network Load Balancer	Gateway Load Balancer
Camada OSI	7 (aplicação)	4 (transporte)	3 (rede, com GENEVE)
Protocolos	HTTP, HTTPS, WebSocket, gRPC	TCP, UDP, TLS	IP (encapsulado em GENEVE)
Roteamento	Por path, host, header, método	Por porta/IP, sem inspeção de conteúdo	Transparente, para appliances de terceiros
Latência	Baixa (processa camada de aplicação)	Ultra baixa (repasse quase direto)	Depende da appliance por trás
IP estático	Não (usa DNS)	Sim, por zona de disponibilidade	Não se aplica (uso interno)
Caso de uso típico	Apps web, APIs REST, microsserviços	Alta vazão, protocolos não-HTTP, jogos	Firewalls, IDS/IPS, inspeção de tráfego
Preço-base (us-east-1)	US$ 0,0225/hora + LCU	US$ 0,0225/hora + NLCU	US$ 0,0125/hora por AZ + GLCU

Os valores de LCU/NLCU/GLCU (Load Balancer Capacity Unit) variam por região e são a parte do custo que mais surpreende quem só olha o preço-base — o próximo item detalha como eles são calculados.

Métricas e Alarmes CloudWatch Que Disparam a Escala

Toda decisão de escala automática nasce de uma métrica publicada no CloudWatch e de um alarme (criado automaticamente pelo próprio Auto Scaling, no caso do target tracking) observando essa métrica. As mais usadas na prática:

CPUUtilization — a métrica mais comum para target tracking, mas a menos confiável isoladamente para aplicações com gargalo em memória, disco ou rede em vez de processamento.
ALBRequestCountPerTarget — número médio de requisições por instância atrás de um Application Load Balancer; captura carga real de forma mais direta que CPU para APIs e aplicações web.
NetworkIn / NetworkOut — úteis para cargas com gargalo de I/O de rede, como serviços de streaming ou transferência de arquivo.
Métricas customizadas — publicadas pela própria aplicação (profundidade de fila, tempo de resposta de um componente interno, latência de um serviço downstream), quando nenhuma métrica nativa da EC2 reflete o gargalo real.

Um princípio que vale a pena levar da documentação oficial: a métrica escolhida para target tracking precisa variar proporcionalmente ao número de instâncias do grupo — é por isso que RequestCount do load balancer (o total, não o "por target") e Latency não funcionam bem para essa política, mesmo sendo métricas relevantes para observar a saúde do sistema. Consolidar essas métricas junto com traços de aplicação é o objetivo de uma estratégia de observabilidade madura na AWS, que vai além do que o Auto Scaling consome sozinho.

Custos: ALB/NLB, LCU e Auto Scaling com Spot Instances

O custo de um load balancer tem duas partes: uma taxa fixa por hora e uma taxa por capacidade consumida, medida em LCU (ALB), NLCU (NLB) ou GLCU (GWLB). Em us-east-1, o ALB cobra US$ 0,0225 por hora mais US$ 0,008 por LCU-hora, e o NLB cobra a mesma taxa-base de US$ 0,0225 por hora mais US$ 0,006 por NLCU-hora (o Gateway Load Balancer cobra US$ 0,0125 por hora por zona de disponibilidade mais US$ 0,004 por GLCU-hora). Cada LCU do ALB cobre até 25 novas conexões por segundo, 3.000 conexões ativas por minuto, 1 GB de dados processados por hora e 1.000 avaliações de regra por segundo — o maior desses quatro valores, em qualquer instante, é o que determina quantos LCUs estão sendo cobrados. Vale consultar a página oficial de preços do Elastic Load Balancing antes de orçar uma migração, porque esses números mudam por região.

Do lado do Auto Scaling Group, o serviço em si não cobra nada — o custo é inteiramente da capacidade de computação que ele liga e desliga. É aí que mora a maior alavanca de economia: combinar instâncias On-Demand com Spot Instances dentro do mesmo Auto Scaling Group, usando uma política de alocação mista. Cargas de trabalho stateless e tolerantes a interrupção — a maioria dos front-ends web, por exemplo — podem rodar em boa parte com Spot, com desconto que costuma passar de 60% em relação ao preço On-Demand, mantendo uma base menor de On-Demand para garantir capacidade mínima mesmo se a Spot for interrompida. Essa é a mesma lógica de rightsizing e otimização contínua que já tratamos no guia de FinOps na AWS — só que aplicada a um recurso que muda de tamanho sozinho, o que torna o monitoramento ainda mais necessário, não menos.

Casos de Uso por Porte de Empresa

Empresas de 30 a 100 funcionários, normalmente com uma aplicação principal e tráfego mais previsível, tendem a se beneficiar mais de um ALB simples com um único Auto Scaling Group em target tracking por CPU ou por requisição — a complexidade de step scaling ou de múltiplos load balancers raramente se paga nesse estágio, e o ganho real está em substituir o "servidor único que às vezes cai" por uma configuração mínima de duas instâncias em duas zonas de disponibilidade.

Empresas de 100 a 300 funcionários, com mais de um sistema ou com picos de tráfego sazonais reconhecíveis (fechamento de mês, campanhas, lançamento de produto), ganham mais de combinar scheduled scaling (garantindo capacidade extra em janelas conhecidas) com target tracking cuidando da variação dentro dessas janelas, e de separar tráfego HTTP externo (ALB) de comunicação interna entre serviços (NLB).

Empresas de 300 a 700 funcionários, geralmente operando arquiteturas mais distribuídas — múltiplos serviços, algum tráfego não-HTTP, eventualmente uma camada de segurança de rede própria — são as que mais se beneficiam de usar os três tipos de load balancer de forma deliberada, com step scaling ajustado por carga histórica e uma política de Spot mais agressiva, apoiada por métricas customizadas de aplicação além das nativas da EC2.

Em qualquer um dos três portes, o desenho errado mais comum não é técnico — é organizacional: ninguém revisita os limites mínimo e máximo do Auto Scaling Group depois que o sistema cresce, e a "rede de segurança" vira um teto artificial de capacidade que ninguém lembra de ter configurado.

Tendências: Escala Preditiva e Integração com Contêineres

Duas direções estão mudando como Auto Scaling e Elastic Load Balancing são operados. A primeira é a escala preditiva: em vez de reagir à métrica depois que ela já subiu, o Auto Scaling Group pode usar previsão baseada em padrão histórico de carga para provisionar capacidade minutos antes do pico esperado, reduzindo o atraso natural entre "métrica cruzou o limite" e "instância nova está pronta para receber tráfego" — importante para cargas com subida muito abrupta, onde esperar o ciclo normal de target tracking significa alguns minutos de degradação real.

A segunda é a integração cada vez mais próxima com orquestração de contêineres. Em clusters Amazon EKS ou Amazon ECS, o autoscaling deixou de ser só "quantas instâncias EC2 existem" e passou a operar em duas camadas simultâneas: quantos pods ou tasks estão rodando (escala da aplicação) e quantos nós existem para hospedá-los (escala da infraestrutura) — com ferramentas como o Karpenter assumindo boa parte do papel que o Auto Scaling Group tradicional exercia sozinho em arquiteturas não conteinerizadas. Load balancers continuam no centro dessa evolução: um ALB na frente de um Ingress Controller do Kubernetes é hoje um dos padrões mais comuns de exposição de aplicação na AWS.

Perguntas Frequentes sobre Auto Scaling na AWS

Qual a diferença entre Auto Scaling Group e Elastic Load Balancing?

O Auto Scaling Group controla quantas instâncias EC2 existem, ligando e desligando capacidade conforme demanda ou horário. O Elastic Load Balancing distribui o tráfego de rede entre as instâncias que já existem, verificando a saúde de cada uma. São serviços complementares, não concorrentes — a grande maioria das arquiteturas de produção usa os dois juntos.

Target tracking ou step scaling: qual escolher?

Target tracking é a opção mais simples e recomendada como padrão, porque o próprio Auto Scaling calcula e ajusta os alarmes necessários. Step scaling faz sentido quando o padrão de carga não é proporcional e o time quer definir manualmente respostas diferentes para desvios pequenos e grandes da métrica.

O Auto Scaling Group pode escalar a zero instâncias?

Sim, em cenários específicos — por exemplo, usando a métrica ALBRequestCountPerTarget, que emite valor real zero quando não há tráfego, com a capacidade mínima do grupo configurada como zero. Fora desse caso, a maioria das configurações mantém ao menos uma instância mínima para evitar o tempo de cold start no primeiro pedido.

Application Load Balancer é sempre mais caro que Network Load Balancer?

Não necessariamente — a taxa-base por hora é igual para os dois em us-east-1 (US$ 0,0225). A diferença de custo real aparece no preço por unidade de capacidade (LCU vs NLCU) e principalmente no volume de tráfego processado, que depende do padrão de uso de cada aplicação, não do tipo de load balancer isoladamente.

O que acontece quando uma instância falha no health check do load balancer?

O load balancer para de enviar tráfego novo para essa instância imediatamente, marcando-a como "unhealthy". Se o Auto Scaling Group estiver configurado para usar o health check do ELB (não só o status da EC2), ele também inicia a substituição dessa instância automaticamente, sem intervenção manual.

Vale a pena usar Spot Instances em produção com Auto Scaling?

Para cargas stateless e tolerantes a interrupção, sim — o desconto costuma superar 60% frente ao preço On-Demand, e o próprio Auto Scaling Group substitui automaticamente uma instância Spot interrompida. O cuidado necessário é manter uma base mínima de capacidade On-Demand ou usar diversificação entre vários tipos de instância, para não depender de um único pool de Spot que pode ficar indisponível.

Preciso de Auto Scaling se meu tráfego é sempre estável?

Mesmo com tráfego previsível, o Auto Scaling Group continua valendo pelo papel de substituição automática de instância com falha — a parte de "escala" da configuração pode simplesmente manter mínimo e máximo iguais, funcionando como uma rede de segurança de disponibilidade, não de elasticidade.

Auto Scaling e Elastic Load Balancing Como Base da Disponibilidade na AWS

Auto Scaling e Elastic Load Balancing não são dois recursos avançados para operações de grande escala — são a configuração mínima recomendável para qualquer aplicação que uma empresa não pode se dar ao luxo de ver cair. A combinação resolve, com configuração e não com mais servidor fixo comprado por precaução, o mesmo problema que antes exigia superdimensionar hardware físico para um pico que só acontece algumas vezes por ano.

As empresas que tratam essa configuração como arquitetura — escolhendo o load balancer certo para cada tipo de tráfego, ajustando a política de escala à carga real observada, e revisitando os limites do grupo conforme o negócio cresce — são as que conseguem folga de capacidade sem folga de custo. É a mesma disciplina de revisão contínua que sustenta uma arquitetura de rede bem desenhada e uma estratégia sólida de continuidade de negócio na AWS: nenhuma das duas se resolve uma vez e se esquece.