AWS S3 us-east-1 (2017): quando um typo derruba a internet

Na manhã de 28 de fevereiro de 2017, a equipe de engenharia do S3 estava investigando lentidão no subsistema de billing do S3 em us-east-1. Para auxiliar no diagnóstico, um engenheiro executou uma ferramenta interna de gestão de capacidade com o objetivo de remover um pequeno conjunto de servidores do subsistema Index — o componente responsável por manter os metadados de localização dos objetos armazenados e por coordenar operações de placement (onde novos objetos devem ser escritos).

O problema foi simples e devastador: o parâmetro passado ao comando especificava um número muito maior de servidores do que o pretendido. Em vez de remover uma pequena fração da capacidade de Index para fins de diagnóstico, o comando removeu uma porção substancial do subsistema inteiro. A ferramenta, por design, não possuía nenhum mecanismo de rate limiting ou validação de segurança que impedisse a remoção de mais do que um percentual seguro da capacidade em operação.

O subsistema Index do S3 é, por natureza, o ponto de coordenação central de todas as operações do serviço. Sem capacidade suficiente de Index, o S3 não consegue resolver onde os objetos estão armazenados (afetando GET e LIST), nem determinar onde novos objetos devem ser escritos (afetando PUT). O efeito foi imediato: taxas de erro dispararam em todas as operações do S3 em us-east-1.

A recuperação foi mais lenta do que o esperado por uma razão técnica importante: o subsistema Index, ao ser reiniciado com sua capacidade completa, precisou executar um processo de verificação de consistência e reparo de estado antes de poder aceitar tráfego de produção. Esse processo — necessário para garantir a durabilidade e consistência dos dados — levou significativamente mais tempo do que a AWS havia planejado em seus runbooks de recuperação, porque o subsistema Index não havia sido reiniciado em escala total por um período muito longo. O tempo de restart havia crescido junto com o volume de dados do S3, mas os procedimentos de recuperação não haviam sido revisados com a mesma frequência.

O que tornou este incidente particularmente instrutivo não foi a causa raiz em si — um erro humano em uma operação administrativa é banal — mas a amplitude do blast radius e as razões estruturais por trás dele.

Por que tantos serviços AWS falharam? O S3 em us-east-1 havia se tornado, ao longo de anos, uma dependência de infraestrutura de facto para uma quantidade enorme de serviços internos da AWS. Lambda armazenava pacotes de código de funções no S3. CloudFormation armazenava e lia templates do S3. ECS e Elastic Beanstalk dependiam do S3 para configurações e imagens. O próprio AWS Console usava S3 para servir assets estáticos. Muitas dessas dependências haviam sido introduzidas de forma incremental, sem uma análise sistemática de como uma falha do S3 se propagaria pelo ecossistema. O resultado foi um grafo de dependências implícitas que ninguém havia mapeado completamente até que o nó central falhou.

A ironia do Service Health Dashboard merece atenção especial. O mecanismo primário pelo qual a AWS comunica status de serviços aos clientes dependia do próprio serviço que estava falhando para renderizar sua interface. Durante as primeiras horas do incidente, o dashboard estava degradado ou desatualizado — exatamente quando os clientes mais precisavam de informações confiáveis. Isso não é apenas uma ironia operacional; é um anti-pattern arquitetural clássico: o plano de controle não deve depender do plano de dados que está monitorando.

Por que a recuperação demorou tanto? A AWS foi transparente neste ponto em seu post-mortem público: o processo de restart do subsistema Index havia crescido em duração ao longo do tempo, proporcional ao crescimento do volume de dados gerenciado pelo S3. O processo de verificação de consistência — essencial para garantir que nenhum dado fosse corrompido ou perdido — simplesmente levava mais tempo em 2017 do que levava quando os runbooks foram escritos. Ninguém havia testado um restart completo do subsistema em produção recentemente o suficiente para perceber o drift. Este é um exemplo claro de configuration drift em procedimentos operacionais: os sistemas evoluem, mas os procedimentos de recuperação ficam para trás.

A AWS publicou um post-mortem público detalhado e comprometeu-se com um conjunto de ações corretivas concretas. Vale analisá-las com olhar crítico.

1. Rate limiting e guardrails em ferramentas de gestão de capacidade. A ação mais direta: adicionar validações que impeçam a remoção de mais do que um percentual seguro da capacidade de qualquer subsistema em uma única operação. Esta é a correção óbvia e necessária — mas também levanta a questão de por que essa proteção não existia em um serviço da escala do S3. Ferramentas de operação que podem causar impacto catastrófico devem ter circuit breakers embutidos por design, não adicionados após um incidente.

2. Revisão e atualização dos runbooks de recuperação. A AWS comprometeu-se a revisar os procedimentos de restart de todos os subsistemas críticos, levando em conta o tempo atual de restart — não o tempo histórico. Mais importante: comprometeu-se a testar esses procedimentos regularmente. Isso é Game Day / Chaos Engineering aplicado a procedimentos operacionais: você só sabe quanto tempo leva o restart se você o executa periodicamente em condições controladas.

3. Redução das dependências do Service Health Dashboard no S3. A AWS reconheceu explicitamente o problema do dashboard e comprometeu-se a torná-lo mais resiliente a falhas do S3. O plano de controle precisa de um plano de dados alternativo — ou, idealmente, deve ser arquitetado para operar de forma completamente independente do serviço que monitora.

4. Auditoria de dependências internas no S3. Implícito no post-mortem está o reconhecimento de que o mapeamento de dependências internas era insuficiente. A remediação aqui é mais difícil: requer uma auditoria sistemática de quais serviços dependem do S3 para funções críticas de controle (não apenas de dados), e a introdução de fallbacks ou caches para reduzir o impacto de uma degradação futura.

O que a AWS não disse publicamente — mas que é uma consequência óbvia para arquitetos que leram o incidente — é que o design de um serviço global com um único ponto de coordenação centralizado (o subsistema Index) em uma única região cria um risco sistêmico que nenhum guardrail operacional elimina completamente. A resposta arquitetural de longo prazo é distribuição e isolamento de blast radius por design, não apenas por procedimento.