Quando a AWS sofreu uma série de falhas em cascata que bloqueou os seus sistemas durante horas no final de outubro, a indústria foi mais uma vez lembrada da sua extrema dependência dos grandes hiperscaladores. (Como se para provar o ponto, A Microsoft sofreu um colapso semelhante alguns dias depois.)

O incidente também lançou uma luz desconfortável sobre o quão frágeis estes ambientes massivos se tornaram. Na Amazon relatório post-mortem detalhadoa gigante da nuvem detalhou uma vasta gama de sistemas delicados que mantêm as operações globais funcionando – pelo menos, na maior parte do tempo.

É impressionante que esta combinação de sistemas funcione tão bem – e é aí que reside o problema. A base para este ambiente foi criada há décadas. E embora a Amazon mereça aplausos pelo quão brilhante esse sistema era quando foi criado, o ambiente, a escala e a complexidade que os hiperscaladores enfrentam hoje são ordens de magnitude além do que os designers originais imaginaram.

A abordagem de patch complementar simplesmente não é mais viável. Todos os hiperescaladores — especialmente a AWS — precisam de sistemas reprojetados, se não de sistemas totalmente novos que possam oferecer suporte a usuários globais em 2026 e além.

Chris CiabarraCTO da Athena Security, leu o post-mortem da AWS e ficou inquieto.

“A Amazon está admitindo que uma de suas ferramentas de automação derrubou parte de sua própria rede”, disse Ciabarra. “A interrupção expôs o quão profundamente interdependentes e frágeis nossos sistemas se tornaram. Ela não fornece nenhuma confiança de que isso não acontecerá novamente. ‘Garantias aprimoradas’ e ‘melhor gerenciamento de mudanças’ soam como soluções processuais, mas não são prova de resiliência arquitetônica. Se a AWS quiser reconquistar a confiança da empresa, ela precisa mostrar evidências concretas de que um incidente regional não pode se propagar novamente em sua rede global. No momento, os próprios clientes ainda assumem a maior parte desse risco.”

Catalin Voicuengenheiro de nuvem da N2W Software, expressou algumas das mesmas preocupações.

“A arquitetura subjacente e as dependências de rede ainda permanecem as mesmas e não desaparecerão a menos que haja uma rearquitetura completa da AWS”, disse Voicu. “A AWS afirma uma disponibilidade de 99,5% por esse motivo. Eles podem colocar band-aids nos problemas, mas a natureza desses hiperescaladores é que os serviços principais retornam chamadas para regiões específicas. Isso não vai mudar tão cedo.”

Analista principal da Forrester Brent EllisA interpretação do post-mortem da AWS é que a AWS – não muito diferente de outros hiperescaladores” – tem serviços que são pontos únicos de falha que não estão bem documentados.”

Embora Ellis tenha enfatizado que “a AWS está realizando uma quantidade incrível de operações aqui”, ele acrescentou que “nenhuma quantidade de (tecnologia) bem arquitetada os teria protegido desse problema”.

Ellis concordou com outros que a AWS não detalhou por que essa falha em cascata aconteceu naquele dia, o que torna difícil para os executivos de TI corporativos terem alta confiança de que algo semelhante não acontecerá em um mês. “Eles conversaram sobre o que falhou e não o que causou a falha. Normalmente, falhas como essa são causadas por uma mudança no ambiente. Alguém escreveu um script e ele mudou alguma coisa ou atingiu um limite. Poderia ter sido tão simples quanto uma falha de disco em um dos nós. Tenho tendência a pensar que é um problema de escala.”

A principal conclusão de Ellis: os hiperscaladores precisam considerar seriamente as principais mudanças arquitetônicas. “Eles criaram uma série de soluções alternativas para os problemas encontrados internamente. Isso significa que o primeiro hiperescalador está sofrendo de um pouco de dívida técnica. As decisões arquitetônicas não duram para sempre”, disse Ellis. “Estamos chegando ao ponto em que é necessário mais.”

Vamos nos aprofundar no que a AWS disse. Embora muitos relatórios atribuam as falhas em cascata a problemas de DNS, não está claro até que ponto isso é verdade. De fato, parece que os sistemas DNS foram onde os problemas foram detectados pela primeira vez, mas a AWS não disse explicitamente o que levou ao problema do DNS.

A AWS disse que os problemas começaram com “taxas de erro de API aumentadas” em sua região US-East-1, que foram imediatamente seguidas pelo AWS “Network Load Balancer (NLB) apresentou aumento de erros de conexão para alguns balanceadores de carga”. Ele disse que os problemas do NLB foram “causados ​​por falhas na verificação de integridade da frota do NLB, o que resultou no aumento de erros de conexão em alguns NLBs”. A AWS então detectou que “falha ao iniciar novas instâncias do EC2”, seguido por “algumas instâncias recém-lançadas apresentaram problemas de conectividade”.

Coisas ruins surgiram a partir daí. “Os clientes experimentaram um aumento nas taxas de erro de API do Amazon DynamoDB na região N. Virginia (us-east-1). Durante esse período, os clientes e outros serviços da AWS com dependências do DynamoDB não conseguiram estabelecer novas conexões com o serviço. O incidente foi desencadeado por um defeito latente no sistema automatizado de gerenciamento de DNS do serviço que causou falhas na resolução de endpoints para o DynamoDB.”

A AWS então ofereceu esta teoria: “A causa raiz desse problema foi uma condição de corrida latente no sistema de gerenciamento DNS do DynamoDB que resultou em um registro DNS vazio incorreto para o endpoint regional do serviço (dynamodb.us-east-1.amazonaws.com) que a automação não conseguiu reparar.”

E então esta coisa adorável aconteceu: “Embora o Centro de Suporte tenha feito failover com êxito para outra região conforme projetado, um subsistema responsável pelos metadados da conta começou a fornecer respostas que impediam que usuários legítimos acessassem o Centro de Suporte da AWS. Embora tenhamos projetado o Centro de Suporte para ignorar esse sistema se as respostas não tivessem êxito, nesse caso, esse subsistema estava retornando respostas inválidas. Essas respostas inválidas fizeram com que o sistema bloqueasse inesperadamente o acesso de usuários legítimos às funções do caso de suporte.”

Esta seção é bastante longa, mas quero deixar a AWS explicar isso com suas próprias palavras:

“A condição de corrida envolve uma interação improvável entre dois dos DNS Enactors. Em operações normais, um DNS Enactor escolhe o plano mais recente e começa a trabalhar nos endpoints de serviço para aplicar esse plano. Esse processo normalmente é concluído rapidamente e faz um trabalho eficaz de manter o estado do DNS atualizado recentemente. Antes de começar a aplicar um novo plano, o DNS Enactor faz uma verificação única de que seu plano é mais recente do que o plano aplicado anteriormente. À medida que o DNS Enactor percorre a lista de endpoints, é possível encontra atrasos ao tentar uma transação e é bloqueado por outro DNS Enactor atualizando o mesmo endpoint. Nesses casos, o DNS Enactor tentará novamente cada endpoint até que o plano seja aplicado com êxito a todos os endpoints.

“Pouco antes do início deste evento, um DNS Enactor experimentou atrasos excepcionalmente altos e precisou tentar novamente a atualização em vários endpoints de DNS. À medida que avançava lentamente nos endpoints, várias outras coisas também aconteciam. Primeiro, o DNS Planner continuou a funcionar e produziu muitas gerações mais recentes de planos. Em segundo lugar, um dos outros DNS Enators começou a aplicar um dos planos mais recentes e progrediu rapidamente em todos os endpoints. O momento desses eventos desencadeou a condição de corrida latente. Quando o segundo Enactor (aplicando o plano mais recente) concluiu suas atualizações de endpoint, ele invocou o processo de limpeza do plano, que identifica planos significativamente mais antigos do que aquele que acabou de aplicar e os exclui. Ao mesmo tempo que este processo de limpeza foi invocado, o primeiro Enator (que tinha sido anormalmente atrasado) aplicou o seu plano muito mais antigo ao ponto final regional da DDB, substituindo o plano mais recente. A verificação feita no início do processo de solicitação do plano, que garante que o plano é mais recente que o plano aplicado anteriormente, estava obsoleta nessa época devido aos atrasos excepcionalmente altos no processamento do Enactor. “

Portanto, isso não impediu que o plano mais antigo substituísse o plano mais novo. O processo de limpeza do segundo Enator excluiu então este plano mais antigo porque era muitas gerações mais antigo do que o plano que acabara de aplicar. Como este plano foi excluído, todos os endereços IP do endpoint regional foram imediatamente removidos. Além disso, como o plano ativo foi excluído, o sistema ficou em um estado inconsistente que impediu que atualizações subsequentes do plano fossem aplicadas por qualquer DNS Enators. Em última análise, esta situação exigiu a intervenção manual do operador para ser corrigida.”

Perto do final do relatório, a AWS falou sobre o que estava fazendo para corrigir a situação: “Estamos fazendo várias alterações como resultado deste evento operacional. Já desabilitamos o DynamoDB DNS Planner e a automação do DNS Enactor em todo o mundo. Antes de reativar essa automação, corrigiremos o cenário de condição de corrida e adicionaremos proteções adicionais para evitar a aplicação de planos DNS incorretos. Para o NLB, estamos adicionando um mecanismo de controle de velocidade para limitar a capacidade que um único NLB pode remover quando falhas na verificação de integridade causarem failover de AZ. Para o EC2, estamos construindo um conjunto de testes adicional para aumentar nossos testes de escala existentes, que exercitarão o fluxo de trabalho de recuperação DWFM para identificar quaisquer regressões futuras. Melhoraremos o mecanismo de aceleração em nossos sistemas de propagação de dados EC2 para limitar a taxa de trabalho recebido com base no tamanho da fila de espera para proteger o serviço durante períodos de alta carga.

Está tudo muito bem, mas parece que uma série de incêndios urgentes estão sendo apagados, sem nenhum grande plano para evitar que algo parecido com a interrupção aconteça novamente. Simplificando, a AWS parece estar travando a batalha de ontem.

É verdade que essas mudanças podem impedir isso exato conjunto de problemas aconteça novamente, mas há um número quase infinito de outros problemas que podem surgir. E essa situação não vai melhorar. À medida que o volume continua a aumentar e a complexidade – olá, IA agente – aumenta, desastres de trem como este acontecerão com frequência cada vez maior.

Se AWS, Microsoft, Google e outros estão tão investidos em seus ambientes que não conseguem fazer nada além de aplicar patches aqui e ali, é hora de algumas startups inteligentes entrarem com uma lista de tecnologia limpa e construirem o que for necessário.

A ameaça lógica: consertem vocês mesmos, hiperescaladores, ou deixem algumas startups financiadas por VC fazerem isso por vocês.