- Esta falha na região AWS US-EAST-1 está sendo analisada não como um simples defeito técnico, mas como um sinal de enfraquecimento organizacional causado pela saída de pessoal-chave
- A causa da falha acabou sendo um clássico problema de DNS, e um erro no endpoint de API do DynamoDB provocou interrupções em cascata em outros serviços
- Com a saída de engenheiros veteranos que se lembravam dos padrões de falha do sistema, surgiram indícios de que a identificação do problema e a velocidade de recuperação ficaram visivelmente mais lentas
- Grandes cortes de pessoal dentro da Amazon e uma alta “taxa de arrependimento nas saídas (69%–81%)” atuaram em conjunto, abalando a estabilidade operacional da AWS
- Trata-se de uma crise causada não pelo envelhecimento da tecnologia, mas pela ausência de pessoas, e é interpretada não como “um incidente isolado” da AWS, mas como um prenúncio de erosão contínua da confiança
Falha de DNS e interrupção de serviços
- Como na velha piada entre administradores de sistemas "It's always DNS", muitos incidentes de indisponibilidade têm no centro um problema de DNS
- Em 20 de outubro de 2025 às 12:11AM (PDT), foi relatado um aumento repentino na taxa de erros dos serviços AWS na região US-EAST-1
- À 1:26AM, as falhas nas requisições ao endpoint do DynamoDB começaram a se intensificar
- À 2:01AM, foi confirmado que a causa era um erro de resolução DNS no endpoint de API do DynamoDB, levando vários serviços dependentes a uma falha em cascata
- O DynamoDB é um serviço fundamental da infraestrutura da AWS, e quando os serviços dessa região caem, a internet como um todo é afetada
- Houve paralisações em larga escala em bancos, jogos, redes sociais, serviços governamentais e compras na Amazon.com
- Foram necessários 75 minutos entre a percepção do problema e a identificação da causa, uma resposta incomumente lenta para os padrões da tradição de “recuperação exemplar” da AWS
- A análise é que o longo tempo entre detectar a falha e identificar a causa se deveu mais à falta de experiência do que à falta de transparência
- Durante esse período, a página de status exibiu apenas a mensagem “operando normalmente”, o que gerou críticas da comunidade
O cumprimento da “profecia”: os alertas de quem saiu
- Tradicionalmente, a AWS ostentava uma capacidade altamente sofisticada de operação de infraestrutura, a ponto de uma falha em apenas uma região já virar grande notícia; porém, quanto maior a complexidade e quanto mais se repetem problemas parecidos com os do passado, mais importante se torna a experiência prática
- O ex-engenheiro da AWS Justin Garrison alertou ao sair da empresa, em 2023, que “eventos de grande escala (LSE) estão aumentando”
- Ele previu que “haveria uma grande falha em 2024”, e este caso acabou sendo visto como uma confirmação disso
- A sequência de saídas de profissionais técnicos sêniores dentro da AWS continuou,
e com ela se perdeu também o conhecimento tribal acumulado ao longo de décadas (conhecimento interno baseado em experiência)
- Em falhas de DNS, mais importante do que alguém que apenas conhece a causa técnica
é alguém que se lembre de perguntar: “este sistema já causou um problema parecido no passado?”
- Mas as pessoas que guardavam essa memória deixaram a empresa por causa da resistência à política de RTO (retorno ao escritório) e dos cortes
Evidências da fuga de talentos
- Entre 2022 e 2025, mais de 27 mil funcionários da Amazon foram demitidos,
e, embora a proporção por departamento não tenha sido divulgada, estima-se que a AWS também tenha sido diretamente atingida
- Segundo documentos internos, a “taxa de arrependimento nas saídas” chegou a 69%–81%,
o que significa que foram embora justamente pessoas que a empresa queria reter
- Com a explosão da insatisfação causada pela ordem de Return to Office,
há vários relatos de que muitos engenheiros veteranos e experientes deixaram a empresa em massa
- Como resultado, a AWS foi sendo reorganizada em torno de times mais baratos e menos experientes,
enfraquecendo gradualmente sua capacidade de operar uma infraestrutura complexa
Problema estrutural: a deformação da “Frugality”
- No passado, Frugality (frugalidade) era um valor central da Amazon,
uma filosofia de “maximizar a eficiência com poucos recursos”
- Porém, recentemente, isso passou a significar “fazer tudo com quase nenhum recurso”
- Com a redução de pessoal, chegou-se a um ponto em que até a manutenção básica ficou difícil
- Não é um problema de tecnologia antiga, mas de gente nova demais para manter o sistema
Perspectivas daqui para frente
- O mercado provavelmente tratará esta falha como algo pontual, mas a estrutura do problema permanece
- Profissionais experientes saem, a complexidade dos sistemas aumenta,
e se forma um ciclo em que a probabilidade do “próximo incidente” cresce cada vez mais
- É bem provável que a AWS apresente este caso como uma “falha única e isolada”,
mas, se os vazios internos se acumularem, o risco de repetição de grandes falhas semelhantes será alto
- Como na expressão “chickens are coming home to roost”,
a perda de capital humano, mais do que a tecnologia, surge como o maior risco da AWS
8 comentários
No fim, gente é tudo igual mesmo..
É uma história que vale para todos os mercados.
Parece que o know-how técnico de TI precisa ser tratado de forma semelhante ao know-how de um soldador experiente.
Lembro de um texto que vi há pouco tempo
falando que, na Amazon, é realmente muito difícil passar do nível de engenheiro sênior 2 para o próximo. Por algum motivo isso me veio à cabeça.
Imagino que esse tipo de demissão "lamentável" aconteça com bastante frequência justamente nessa faixa.
Por outro lado, aqui em cima alguém também pode pensar: "Cortaram tanto assim e, ainda assim, dá para contornar a situação nesse nível..."
Na Coreia, quando engenheiros chegam a certo ponto, todos acabam virando gerentes e a carreira técnica é interrompida...
Nos EUA, o problema é que, em nome da eficiência, demitem todos os seniores...
Realmente não é nada fácil...
Chegaram até a configurar multi-AZ... será que agora também vamos ter que nos preparar para falhas em nível de região..?
Acho que também é preciso considerar se esse custo é realmente maior do que o custo das perdas.
Comentários no Hacker News
Entre os engenheiros e os trabalhadores de armazém, dá a sensação de que, se continuarem demitindo gente desse jeito, não falta muito para até quem já trabalhou nesta empresa no passado ir embora de vez
Mesmo com centenas de milhares de candidatos a engenheiro com H1-B e dezenas de milhões de trabalhadores de armazém imigrantes ilegais, se uma empresa desse porte faz demissões em massa tão rapidamente, no fim os recursos humanos inevitavelmente se esgotam
Isso me lembra o episódio de paródia de Star Wars do Robot Chicken. Nele, os oficiais imperiais fingem que Darth Vader está dando um force choke e fingem morrer para escapar de serem cortados pelo sabre de luz, depois voltando com outro nome; a Amazon é ainda pior. Ninguém quer voltar https://www.youtube.com/watch?v=fFihTRIxCkg
Sinceramente, nunca vi um engenheiro minimamente competente querer trabalhar na Amazon uma segunda vez
Tem mesmo tantos imigrantes ilegais nos armazéns? Pelo que eu sei, a Amazon confere identidade e verifica os documentos com bastante rigor; pode até haver casos ocasionais de roubo de identidade, mas não imagino que sejam tantos assim
O problema não são só as demissões; lembro que, assim que a Amazon implementou RTO total, fui bombardeado por e-mails de recrutadores
Parece haver um clima de preconceito sobre a competência de engenheiros só por serem H-1B
Eu mesmo trabalhei com H-1B no passado e hoje voltei para a Índia para tocar meu negócio. Vim da Amazon. Era um lugar duro, mas em meados dos anos 90 ainda havia stock options, então valia a pena trabalhar lá
Aposto que eu programo melhor do que uma boa parte das pessoas aqui. E vários H-1B ao meu redor eram realmente muito bons
Não tenha preconceitos; avalie a habilidade diretamente. Subestimar a concorrência no fim só prejudica você mesmo
Agora é justamente a hora de reter os funcionários e dar a eles as melhores ferramentas para que possam trabalhar bem
As ferramentas de desenvolvimento estão melhorando todos os dias e, embora seja possível cortar pessoal no curto prazo, os efeitos não aparecem imediatamente
É trocar a sustentação do presente pelo crescimento futuro e pela sustentabilidade da organização. Não adianta se iludir achando que isso vai tornar o downsizing melhor-sucedido
Na prática, a estratégia parece estar funcionando. Demitiram um quarto dos principal engineers juniores, mas a ação subiu, e mesmo depois de uma grande falha a ação subiu de novo. Por enquanto, a estratégia deles parece estar funcionando
Até essas antigas big techs “novatas” estão entrando na fase de grandes corporações envelhecidas, como a IBM
Não é que eles não saibam que rotatividade alta é ruim; parece mais que, desde o planejamento da organização, estão nivelando toda a força de trabalho para um padrão mediano e transformando todos em recursos humanos intercambiáveis
Agora, até simplesmente ser muito competente já está sendo tratado como “cultura cowboy”
Foi bastante suspeito que o momento em que a resolução do incidente realmente começou coincidiu com o início do expediente na Costa Oeste dos EUA
Antes disso, a atualização só dizia “monitorando, trabalho de mitigação em andamento”, sem informações concretas
Pelo que eu saiba, a recuperação aconteceu por volta das 4h da manhã no horário de Seattle. O expediente normalmente começa às 9h, mas talvez em Nova York tenha começado por volta das 6h da manhã
O post que li no Reddit esta manhã agora parece fazer ainda mais sentido
A AWS continua sendo a nuvem que eu mais prefiro e eu a uso de forma muito eficiente
Também já pensei que gostaria de trabalhar na AWS pelo menos uma vez, mas fico com muitas dúvidas se algumas preocupações foram resolvidas
Se um futuro gerente não consegue proteger um candidato nem durante esse processo, fico preocupado que também não consiga protegê-lo em problemas culturais corporativos mais sérios
Há uma ideia que hoje vale para toda a FAANG: é preciso renovar constantemente a percepção de que esses são lugares onde pessoas realmente talentosas querem trabalhar
A Meta fez essa marca principalmente com salários mais altos e lançamentos open source e open hardware, enquanto o Google enfatizou superioridade técnica e uma cultura corporativa acolhedora (também conhecida como cultura de formação de recém-chegados, ainda que hoje mais formalista)
A AWS já tem muito talento técnico de que pode se orgulhar, e acho que precisa investir em atrair e reter essas pessoas, além de divulgar ativamente essa imagem para o setor
Já vi a mesma coisa acontecer em startups
Depois de uma aquisição, é comum os talentos-chave saírem quando suas ações vestem, ou serem expulsos para que a grande empresa coloque outras pessoas nos cargos
Os que realmente entendem a tecnologia vão todos embora e, no fim, sobra só uma base de código caótica e impossível de manter, com problemas que ninguém mais sabe corrigir
Gosto muito de como o El Reg acerta em cheio na essência da situação
Só agora percebi que quem escreveu a matéria foi Corey Quinn, que já escreveu bastante sobre AWS
Também gosto de como os autores escrevem com humor e personalidade
Essa gente sabe atingir o ponto central de qualquer assunto
“Após a ocorrência do problema, em 75 minutos a causa foi reduzida a um endpoint de serviço específico”
Isso demorou tanto assim? Eu não trabalho com desenvolvimento web, mas achar onde está o problema em 75 minutos me parece bem rápido
Quando eu trabalhava como engenheiro de firmware, muitas vezes levava semanas para descobrir exatamente onde tudo tinha quebrado
Se a frequência real do problema for de 0,01%, sem correlação alguma e desaparecer ao tentar de novo, aí de fato pode levar semanas
Mas isso normalmente não é um incidente de alta prioridade; em geral, os acidentes realmente urgentes são reproduzíveis e são casos em que algo que estava normal até uma hora antes de repente explode
De modo geral, num sistema crítico de negócio bem projetado, o diagnóstico não deveria levar mais de 75 minutos. Claro, consertar pode levar mais do que isso
Embora não dê para dizer que sistemas assim ideais sejam comuns no mundo real
Numa empresa comum, 75 minutos pode não ser muito. Mas quando estamos falando da maior nuvem do mundo e de boa parte da internet ficando paralisada, a conversa é outra
Na prática, embora o comunicado oficial dissesse “ainda estamos investigando”, internamente eles podem ter suspeitado da causa bem antes disso
É certo ter cautela, porque publicar atualizações cedo demais pode levar os usuários a interpretações desnecessárias
Na minha opinião, 75 minutos é praticamente velocidade de elite para diagnosticar qualquer problema grave
A Amazon é conhecida por ter infraestrutura de nível líder na indústria
Como tantas outras empresas dependem da infraestrutura da Amazon, espera-se que talentos de nível SRE consigam localizar esse tipo de incidente muito rapidamente
O conhecimento acumulado e a experiência prática que vão desaparecendo dentro de uma organização são justamente um valor realmente importante, difícil até de registrar numa simples planilha de Excel
Quando uma organização começa a priorizar pessoas que cultivam a própria marca ou contratações de fachada acima de gente realmente competente e de especialistas de longo prazo, o núcleo técnico que de fato entende o sistema começa a ser empurrado para fora
Quando esse desequilíbrio cresce num lugar como a AWS, celebridades do LinkedIn e contratações DEI de checklist passam a dominar os verdadeiros construtores, e a qualidade de execução, o senso de responsabilidade e a solidez técnica vão se enfraquecendo aos poucos
Agora está começando a ficar claro que a liderança de Andy Jassy não está funcionando, e talvez em breve Wall Street passe a exigir oficialmente sua substituição
Quanto à ideia de que o The Register é um veículo respeitado, na verdade dá a sensação de que eles próprios não gostariam de ser chamados assim…