> For the complete documentation index, see [llms.txt](https://weekly-essay.mikey.wang/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://weekly-essay.mikey.wang/pt-br/2025/w43-lessons-learned-from-the-aws-incident.md).

# W43-Lições do incidente da AWS

Na semana passada, a AWS sofreu uma falha grave de quinze horas. Mais de mil empresas no mundo tiveram serviços interrompidos, com perdas econômicas de bilhões de dólares. A lição é dura: nem o projeto de engenharia mais engenhoso resiste à dependência de um único ponto.

O incidente ocorreu na região mais importante da AWS, us-east-1. A causa foi uma condição de corrida na automação de gestão de DNS do DynamoDB, que apagou por engano os registros de IP do endpoint regional e impediu a resolução. us-east-1 não é um centro de dados comum: é o “sistema nervoso central” da infraestrutura global da AWS. Os planos de controle compartilhados de quase todas as regiões dependem dele, incluindo serviços essenciais como escalonamento do EC2, NLB e Lambda. Daí o colapso em cascata.

A ironia é que, 75 minutos depois do início, a página de status da AWS ainda dizia “tudo normal”. O CloudWatch também depende do DynamoDB, e o monitoramento ficou cego junto com o sistema.

A recuperação também foi difícil. Os registros DNS podiam ser corrigidos rapidamente, mas o DynamoDB é um nó central de controle. O escalonador do EC2 precisou reconstruir leases para dezenas de milhares de servidores; o gerenciador de rede teve de limpar congestionamentos e distribuir estados atrasados; e balanceadores removiam instâncias repetidamente por avaliações incorretas de saúde. No fim, a AWS precisou desligar verificações automáticas de saúde e failover. Só a intervenção humana impediu novas avalanches.

Depois de observar o incidente, vale olhar para nossos serviços. Os pontos únicos de falha sistêmica mais prováveis podem estar justamente nos serviços básicos que recebem pouca atenção nas iterações do negócio. Exemplos são o ponto de entrada de informatização e os serviços de verificação. O primeiro tem lógica simples, mas uma área de impacto enorme: concentra 80% do tráfego. Sua engenharia deveria seguir os princípios de dependência mínima e entropia máxima, mantendo clareza e simplicidade extremas.

Um componente pequeno como esse atrai engenheiros ambiciosos porque oferece desafios evidentes: manter várias versões para diferentes pilhas e lidar com ciclos longos de publicação, dependentes das páginas hospedeiras. Ao rever o que fizemos nele neste ano, acho necessário avaliar se escolhemos a direção correta. Para permitir atualização dinâmica, encurtar o ciclo de entrega e ganhar flexibilidade, fizemos muito trabalho de engenharia, acrescentamos dependências, desenhamos uma arquitetura mais complexa e também reduzimos a rapidez com que um rollback produz efeito. Seguindo essa direção, depois da atualização dinâmica talvez venham um componente dinâmico em todos os contêineres e a unificação das versões, com alto reúso e dinamismo. Mas, quando o componente passar pelo pico de iteração, as funcionalidades começarão a parecer dívida.

Percebo que minha atenção neste ano ainda esteve em treinar capacidade de engenharia e criar oportunidades para praticar técnicas vistosas. Não a antecipei o suficiente para melhorar a qualidade das decisões técnicas. Faltaram uma estrutura clara, evidências e raciocínio lógico na decisão. Acho que a única coisa que fizemos bem foi introduzir decisões democráticas e coletivas.

Todo engenheiro passa por uma fase em que rejeita redundância, abstrai tudo e valoriza complexidade como sinal de sofisticação técnica. Precisamos ter coragem de abandonar essa visão intermediária e buscar clareza e simplicidade depois de ponderar os compromissos. É o que ensina a filosofia Unix: desenvolver gosto por coisas de qualidade superior.