O apagão da AWS e o papel do load balancing

Uma aplicação pode ter vários servidores e continuar vulnerável a uma única falha. Se todos dependem do mesmo serviço para descobrir endereços, criar capacidade ou receber tráfego, essa dependência limita a recuperação.

O apagão

Em outubro de 2025, o DNS do DynamoDB falhou em us-east-1. A recuperação do EC2 acumulou atrasos de rede. Depois, health checks do NLB retiraram capacidade saudável de operação. Essa sequência consta no relato da AWS.

A distinção importa para entender o incidente. A versão inicial deste artigo atribuía o início da falha ao monitoramento dos balanceadores. O relatório posterior permite corrigir essa explicação.

Para entender o papel do balanceamento nessa cadeia, vale começar pelo que ele faz em uma aplicação comum.

O que é load balancing?

Imagine um restaurante com apenas um caixa. Se 50 pessoas chegam ao mesmo tempo, forma-se uma fila. Abrir outros caixas permite dividir o atendimento, desde que alguém organize a distribuição.

Load balancing, ou balanceamento de carga, distribui tráfego entre servidores. Em uma aplicação web, o balanceador recebe as requisições e escolhe um destino entre os disponíveis. A distribuição reduz a concentração de trabalho em uma única máquina, mas não cria capacidade infinita.

Como funciona

O caminho de uma requisição pode ser representado assim:

[Usuário] → [Load balancer] → [Servidor 1]
                           → [Servidor 2]
                           → [Servidor 3]
                           → [Servidor 4]

A aplicação precisa suportar essa distribuição. Se a sessão do usuário existe apenas na memória de um servidor, a próxima requisição enviada a outro pode não encontrá-la. A decisão sobre onde guardar o estado faz parte da arquitetura.

Estratégias de distribuição

Round robin alterna os destinos em sequência. Least connections prefere o servidor com menos conexões ativas. A escolha depende do comportamento do tráfego. Uma conexão longa não representa o mesmo trabalho que uma resposta curta.

Pesos permitem enviar proporções diferentes para servidores com capacidades diferentes. Algumas estratégias usam o IP do cliente para manter afinidade com um destino. O roteamento geográfico atua em outra decisão, escolher a região que recebe o tráfego. As opções disponíveis dependem do balanceador.

Health checks

Health checks verificam periodicamente se um destino atende a critérios definidos. No Application Load Balancer da AWS, intervalos e limites de sucessos ou falhas determinam mudanças de estado. A remoção não é instantânea. Veja a documentação dos health checks.

A pergunta feita pelo teste também importa. Um endpoint que responde sempre com sucesso pode ignorar um processo incapaz de atender pedidos. No outro extremo, depender de todo serviço externo para responder ao teste pode retirar servidores que ainda conseguem executar parte do trabalho.

Por que usar um balanceador?

Ele permite adicionar servidores e distribuir novas requisições entre eles. Também ajuda na manutenção. É possível interromper o envio de novas requisições para um destino e esperar o trabalho em andamento terminar antes de desligá-lo.

Quando um servidor falha, os demais podem assumir novas requisições. Para isso, precisam ter capacidade disponível. Se quatro máquinas já operam no limite, perder uma aumenta a pressão sobre as outras.

Essa distribuição também não transfere automaticamente uma operação que já estava em andamento. A aplicação precisa definir o que o usuário vê e se uma tentativa pode ser repetida sem duplicar efeitos.

O efeito dominó

O desenho de quatro servidores no diagrama pode esconder um único banco, uma única fila ou uma configuração compartilhada. Repetir os servidores não duplica essas dependências.

Nossa leitura operacional é que vale testar a recuperação com uma dependência indisponível. Tentar criar mais instâncias durante uma falha ajuda apenas se o caminho de criação também funcionar. Da mesma forma, enviar tudo para os destinos restantes exige saber quanto trabalho eles suportam.

O que testar na sua aplicação

Retire um servidor do atendimento em um ambiente controlado e observe as requisições em andamento. Depois verifique se os destinos restantes suportam a carga e quanto tempo o monitoramento leva para perceber a mudança.

Teste também uma dependência lenta. Registre quando a aplicação para de esperar, quantas vezes repete a tentativa e como impede que as repetições aumentem a fila sem limite.

O balanceador resolve a distribuição de tráfego. A disponibilidade da aplicação depende também dessas decisões. Converse com a Tucupy se você precisa revisar como seu sistema reage a falhas.

Texto revisado em 12 de setembro de 2026, com correção da explicação do incidente.