Apagão da AWS - Bastidores e lições aprendidas

Na semana passada, dia 20 de Outubro de 2025 vimos um problema da AWS afetando o mundo todo. Mais de 1000 empresas ficaram com seus serviços indisponíveis ou parcialmente indisponíveis ao longo de um dia inteiro.

Na madrugada de segunda-feira começamos a experimentar uma instabilidade em nossos sistemas, e a medida que o tempo passava mais serviços da AWS eram impactados. 

Segundo a AWS o problema começou em um processo de automação que gerencia os endereços de DNS, e tudo isso começou no DynamoDB. Fazendo com que os clientes não conseguissem chegar nos seus bancos, porém, esse problema se estendeu e afetou diversos outros serviços da AWS. 

Ao longo do dia experimentamos bastante intermitência e indisponibilidade dos serviços.

No report da AWS víamos a lista de serviços impactados crescer chegando a mais de 120 serviços afetados.

Foi só em torno de 19hrs horário de Brasília que começamos a experimentar uma retomada, e logo em seguida a AWS declarou o fim da crise. E foi aí que respiramos bem mais aliviados!

Esse problema afetou uma região específica, que foi Norte-Virginia (US-EAST-1) e por ser a região mais antiga da AWS existem muitos clientes que possuem seus serviços hospedados nela. Além disso, serviços globais da AWS rodam nessa região, então mesmo aqueles que estavam hospedados em outras regiões experimentaram certa intermitência nos serviços.

Quero compartilhar aqui com você a estratégia que usamos parar mitigar o problema do lado do Mongodb Atlas. Talvez você tenha tido problemas em outras bases de dados, mas no meu caso específico experienciei apenas o impacto no Mongodb. 

Quero deixar claro aqui que este texto não é sobre como resolver um problema, mas sim como lhe dar com um cenário de crise e ter clareza das ações que precisam ser tomadas. 

A estratégia

Bom, assim que entendemos o problema verificamos que não estávamos conseguindo criar nenhum tipo de máquina, seja ela um cluster de banco de dados ou uma EC2, e isso nos acendeu um alerta!

Algumas das nossas bases possuem o auto scaling habilitado, o que é uma facilidade em questão de custo e disponibilidade. Ou seja, elas podem subir e descer conforme o uso (com uma razão e proporção entre porcentagem de uso x tempo), isso é uma forma de reduzir custos quando a base está ociosa e aumentar a disponibilidade caso você receba uma rajada de requisição na base de dados.

Verificando o ambiente onde estavam os bancos de dados e a forma como estavam configurados, a estratégia que adotei foi de desabilitar todos os scalings das máquinas, ou seja, o up e down scaling assim como o scaling de disco. Dessa forma garantiríamos que nossas bases não entrariam em manutenção e poderíamos manter nossos bancos ativos no estado que eles estavam (nesse cenário todos disponíveis).

Caso tivéssemos mantido as configurações de scaling habilitadas teríamos grande impacto, porque sem liberação de máquina do lado da AWS o processo não funcionaria. E como o processo de manutenção nesse caso é automático, o cluster de banco de dados entraria em manutenção e por não conseguir aplicar as mudanças ficaríamos com no mínimo um dos nodes do replica-set fora. 

Como nosso tráfego estava muito baixo dado o problema, não sofreríamos com aumento do uso das máquinas e pelo fluxo estar mais baixo corria risco delas fazerem down scaling. Então essa foi a melhor estratégia que adotamos naquele momento. 

Você pode pensar, mas porque desabilitar também o up scaling já que o trafego estava baixo? Mas naquele momento não sabíamos como seria o dia, então na dúvida meu pensamento é: seja conservador e peque pelo excesso e não pela falta.

Se tivéssemos qualquer aumento de conexão durante esse período que gerasse impacto nas bases nós também não conseguiríamos escalar, e sairíamos de uma base disponível para uma parcialmente disponível. Se este cenário ocorresse, limitaríamos o tráfego via aplicação e assim conseguiríamos controlar os acessos aos nossos serviços e bancos. Já que aumentar o recurso não era uma opção disponível naquele momento.

O único ponto dessa ação é que ficamos o tempo todo atento para que no momento que a AWS estivesse 100% recuperada e disponível, iniciássemos o processos de reabilitar o up scaling, já que junto com essa retomada possivelmente teríamos um grande aumento das requisições. E assim fizemos.

Com isso conseguimos garantir que todos os nossos bancos estivessem disponíveis durante toda crise. Do contrário teríamos grande parte dos nosso bancos em manutenção, com nodes fora do ar e uma base de dados degradada e em alguns casos indisponível. 

Como lhe dar com a crise

Não estou dizendo que esta é a solução para todo os problemas, mas com esse aprendizado quero que você entenda que resiliência não é resistência. Não é sobre resistir ao problema, é sobre ser flexível e saber se adaptar-se rapidamente. 

Durante os momentos de crise lembre-se que a companhia conta com você e espera que você tenha calma e clareza nesses momentos. Não deixe que a crise afete você, mas pense que seu papel é trazer luz a um caminho ainda obscuro e junto com seu time vocês vão sair do outro lado.

O que me lembra mais um ponto importante nesses momentos que é o: dialogo! Comunique o que você está vendo, como está pensando em resolver, quais o impactos e as estratégias de correção. Em situações de crise, ainda mais quando perdura por muito tempo as vezes ficamos cegos para alguns cenários pela exaustão ou até pelo desconhecimento mesmo de determinado processo. Mas compartilhando com outras pessoas podemos ter mais clareza para chegarmos na melhor solução comum.

E então, depois que tudo se estabiliza, começa o trabalho mais importante: transformar aprendizados em práticas preventivas.

Espero que esse conteúdo tenha sido útil a você.

Até mais!

Você também pode acompanhar esse conteúdo em vídeo: https://youtu.be/PKWGvF1FB8g