Como um erro de Load Balancing derrubou milhares de serviços
No dia 20 de outubro de 2025, a internet testemunhou um dos maiores apagões digitais da história recente. Por mais de oito horas, milhares de serviços ficaram fora do ar ou apresentaram instabilidade severa. O culpado? Um problema no sistema de load balancing da Amazon Web Services (AWS), o maior provedor de infraestrutura em nuvem do mundo.
Snapchat, Fortnite, PicPay, iFood, Mercado Livre e incontáveis outros serviços foram afetados. Mas o que exatamente aconteceu? E por que um único problema na AWS pode causar um efeito dominó tão devastador?
O apagão
Às 4h12 (horário de Brasília), começaram os primeiros relatos de problemas. A AWS identificou uma falha crítica em um subsistema interno responsável por monitorar a integridade dos balanceadores de carga de rede na região US-EAST-1, localizada no norte da Virgínia, Estados Unidos.
Essa região é a maior concentração de data centers do mundo, com quase 400 instalações. Por oferecer os preços mais baixos globalmente (graças a isenções fiscais), a US-EAST-1 é extremamente popular entre empresas brasileiras e do mundo todo. Estima-se que grande parte dos dados processados de serviços brasileiros passam por lá.
O problema inicial afetou o DynamoDB, banco de dados central da AWS, e rapidamente se espalhou para outros serviços críticos como EC2 (servidores virtuais) e Lambda (execução de código sem servidor). Como esses serviços são a base para milhares de aplicações, o impacto foi imediato e global.
Linha do tempo
Os primeiros relatos de problemas começaram às 04:12 da manhã. Menos de 40 minutos depois, às 04:51, a AWS confirmou o aumento de erros e latência nos seus sistemas. Às 05:26, o problema foi identificado no DynamoDB, o banco de dados central da plataforma. A aplicação das primeiras correções teve início às 06:22, mas o problema estava longe de ser resolvido.
A situação piorou drasticamente às 11:14, quando o status do sistema foi alterado para "em deterioração". Somente às 12:43 a AWS conseguiu identificar a causa raiz: o subsistema de monitoramento dos load balancers. Medidas adicionais de mitigação foram aplicadas às 13:13, mas o estrago já estava feito.
Mais de 6,5 milhões de notificações foram registradas no DownDetector ao longo do dia. Segundo a Amazon, 91 serviços internos da AWS foram impactados simultaneamente, criando um efeito cascata que se propagou por toda a internet.
O que é Load Balancing?
Imagine um restaurante com apenas um caixa. Se 50 pessoas chegam ao mesmo tempo, forma-se uma fila enorme e o atendimento fica lento. A solução? Abrir mais caixas e distribuir os clientes entre eles de forma inteligente.
Load balancing (balanceamento de carga) é exatamente isso, mas para servidores. É uma técnica fundamental que distribui o tráfego de rede ou as requisições de aplicações entre múltiplos servidores, garantindo que nenhum servidor fique sobrecarregado enquanto outros ficam ociosos.
Como funciona
Um load balancer atua como um "porteiro inteligente" que fica entre os usuários e os servidores. Quando você acessa um site ou app, sua requisição não vai direto para um servidor específico - ela passa primeiro pelo load balancer, que decide qual servidor está melhor posicionado para atendê-la.
[Usuário] → [Load Balancer] → [Servidor 1]
→ [Servidor 2]
→ [Servidor 3]
→ [Servidor 4]
Estratégias de distribuição
Existem diferentes algoritmos para decidir qual servidor deve receber cada requisição. O método Round Robin, por exemplo, distribui as requisições de forma circular, enviando uma para cada servidor em sequência. Já o algoritmo Least Connections envia cada nova requisição para o servidor com menos conexões ativas no momento, equilibrando melhor a carga real.
Outras estratégias incluem o IP Hash, que usa o endereço IP do cliente para determinar consistentemente qual servidor o atenderá, e o método Weighted, que distribui o tráfego com base na capacidade de cada servidor. Há também o roteamento Geographic, que direciona usuários para servidores mais próximos geograficamente, reduzindo a latência.
Health Checks
Um aspecto crítico dos load balancers é o monitoramento de integridade, conhecido como health check. Constantemente, o balanceador verifica se cada servidor está saudável e pronto para receber tráfego. Quando um servidor está respondendo rapidamente, ele recebe a carga normal de requisições. Se o servidor começa a ficar lento ou apresentar erros, o load balancer automaticamente reduz a quantidade de tráfego direcionado a ele. E quando um servidor fica completamente fora do ar, ele é imediatamente retirado da rotação, garantindo que nenhum usuário seja prejudicado.
Foi justamente nesse sistema de monitoramento que ocorreu a falha da AWS.
Por que é crítico?
O load balancing é fundamental para manter a internet funcionando de forma confiável e eficiente. Primeiro, ele garante alta disponibilidade: se um servidor cair, o load balancer automaticamente redireciona o tráfego para servidores saudáveis, e os usuários nem percebem que houve um problema. Essa capacidade de recuperação automática é essencial para serviços que não podem parar.
A escalabilidade é outro benefício crucial. Quando é necessário atender mais usuários, basta adicionar mais servidores ao pool e o load balancer distribui automaticamente o tráfego para eles. Não é preciso reconfigurar toda a infraestrutura ou fazer mudanças complexas.
Além disso, distribuir a carga entre múltiplos servidores evita que qualquer um deles fique sobrecarregado, mantendo a resposta rápida e consistente para todos os usuários. Isso impacta diretamente a experiência do usuário final, que percebe o serviço como rápido e responsivo.
Por fim, o load balancing oferece flexibilidade para manutenção. É possível retirar servidores do pool para atualizações, correções ou melhorias sem derrubar o serviço inteiro. O load balancer simplesmente para de enviar tráfego para esses servidores temporariamente, permitindo manutenção sem downtime.
O que deu errado
Segundo a Amazon, o problema estava em um subsistema interno responsável por monitorar a integridade dos balanceadores de carga de rede.
Em termos simples: o sistema que verificava se os load balancers estavam funcionando corretamente começou a ter problemas. Isso criou um efeito cascata devastador. Primeiro, o sistema de monitoramento falhou, fazendo com que os load balancers começassem a receber informações incorretas sobre a saúde dos servidores. Com dados errados, as requisições passaram a ser enviadas para servidores que não podiam atendê-las adequadamente.
A situação piorou quando novas instâncias EC2 não conseguiam mais ser criadas. A AWS precisou limitar isso propositalmente para evitar uma deterioração ainda maior do problema. Serviços que dependiam desses recursos começaram a falhar em sequência. O DynamoDB, Lambda e outros serviços críticos ficaram instáveis, e como milhares de aplicações dependem diretamente desses serviços fundamentais da AWS, elas também pararam de funcionar, criando o apagão generalizado que afetou usuários no mundo inteiro.
O efeito dominó
A AWS tem 37% do mercado global de cloud. Quando ela falha, não é apenas "um site" que sai do ar - é uma infraestrutura que sustenta boa parte da internet moderna.
Pense assim: se a AWS fosse uma companhia elétrica, seria como se o problema em uma usina causasse blecaute em toda uma região metropolitana. Não importa se sua casa tem bons fios ou equipamentos modernos - sem energia da fonte, nada funciona.
Conclusão
O apagão da AWS de outubro de 2025 foi um lembrete de que mesmo os sistemas mais sofisticados podem falhar - e quando falham em componentes críticos como load balancers, o impacto é massivo.
Load balancing não é apenas uma técnica de otimização; é a espinha dorsal da internet moderna. É o que permite que bilhões de pessoas acessem seus serviços favoritos simultaneamente sem que tudo desmorone.
Precisa de ajuda para arquitetar sistemas resilientes? Na Tucupy, ajudamos empresas a construir infraestruturas robustas que suportam falhas e escalam com confiança. Entre em contato para conversar sobre seu projeto.