# AWS S3 us-east-1 (2017): quando um typo derruba a internet Em 28 de fevereiro de 2017, um engenheiro da AWS executou um comando de debug com um parâmetro incorreto e removeu uma quantidade muito maior de servidores do subsistema de indexação do S3 do que o pretendido. O resultado foi quatro horas de degradação severa em us-east-1 que afetou centenas de serviços dependentes — de ferramentas de monitoramento a grandes plataformas SaaS. O incidente expôs fragilidades estruturais em torno de dependências implícitas, ausência de rate limiting em operações destrutivas e a falácia de assumir que uma única região AWS seria suficientemente resiliente. - URL: https://fernando.moretes.com/studies/aws-s3-us-east-1-2017 - Markdown: https://fernando.moretes.com/studies/aws-s3-us-east-1-2017/study.md?lang=pt - Type: Post-mortem - Company: AWS - Domain: Resiliência - Date: 2017-02-28 - Tags: s3, aws, resiliência, postmortem, us-east-1, blast-radius, operações, dependência-implícita - Reading time: 10 min --- Um único comando mal parametrizado, executado por um engenheiro experiente durante uma investigação de rotina, foi suficiente para degradar o Amazon S3 em us-east-1 por quase quatro horas — e, com ele, uma fração significativa da infraestrutura de internet que o mundo ocidental usa diariamente. Não foi um ataque. Não foi uma falha de hardware. Foi um erro humano amplificado por ausência de guardrails em operações destrutivas e por décadas de dependências acumuladas em torno de um único serviço em uma única região. ## Ficha do Incidente - **Empresa / Serviço:** Amazon Web Services — Amazon S3 - **Data:** 28 de fevereiro de 2017 - **Duração total da degradação:** ~4 horas (início ~09:37 PST, recuperação total ~13:54 PST) - **Região afetada:** us-east-1 (US Standard) - **Subsistemas do S3 afetados:** Index (metadados/placement) e Placement — ambos com capacidade severamente reduzida - **Causa raiz:** Parâmetro incorreto em comando de debug removeu servidores em excesso do subsistema Index do S3 - **Impacto direto:** S3 GET, LIST e DELETE com alta taxa de erros; PUT indisponível em grande parte do período - **Impacto em cascata (exemplos públicos):** AWS Console, CloudFormation, Lambda, ECS, Elastic Beanstalk, Kinesis, SNS, SQS, RDS, EC2 (imagens/AMIs), Slack, GitHub, Quora, IFTTT, Trello, Medium, Docker Hub e centenas de outros - **Stack técnico relevante:** Amazon S3 (subsistemas internos: Index, Placement, Storage nodes); ferramenta interna de gestão de capacidade - **Ironia notável:** O próprio AWS Service Health Dashboard dependia de S3 para renderizar assets — ficou degradado durante o incidente ## O que aconteceu 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. ## Linha do Tempo 1. **~09:37 PST — Comando executado** — Engenheiro executa ferramenta interna de gestão de capacidade com parâmetro incorreto. Servidores em excesso são removidos do subsistema Index do S3 em us-east-1. O impacto é quase imediato. 2. **~09:40 PST — Primeiros alertas** — Taxas de erro do S3 disparam. Alertas internos da AWS são acionados. Serviços que dependem do S3 começam a reportar falhas — incluindo ferramentas internas de monitoramento da própria AWS. 3. **~09:45–10:00 PST — Cascata visível externamente** — AWS Console, CloudFormation, Lambda, ECS e dezenas de outros serviços AWS começam a falhar parcialmente. Clientes externos começam a reportar falhas em massa. O Service Health Dashboard demora a atualizar — seus próprios assets estão no S3. 4. **~10:00–11:00 PST — Diagnóstico e decisão de restart** — A equipe identifica a causa raiz. A decisão é tomada de restaurar a capacidade completa do subsistema Index. O processo de restart é iniciado, mas requer verificação de consistência de estado antes de aceitar tráfego — processo mais lento do que os runbooks antecipavam. 5. **~11:00–12:30 PST — Recuperação parcial do Index** — O subsistema Index começa a recuperar capacidade gradualmente. Algumas operações do S3 começam a funcionar de forma intermitente. O subsistema Placement, que também foi afetado, inicia seu próprio processo de recuperação. 6. **~12:30–13:54 PST — Recuperação total** — Capacidade total do Index e Placement é restaurada. Taxas de erro retornam ao normal. A AWS declara o incidente resolvido às ~13:54 PST. Duração total: aproximadamente 4 horas e 17 minutos. ## Fluxo de Falha: S3 us-east-1 O diagrama reconstrói o fluxo de falha em cascata a partir da remoção indevida de capacidade do subsistema Index do S3, mostrando como a degradação se propagou para serviços internos da AWS e depois para clientes externos. ### 🛠️ Operação de Debug (Causa Raiz) - Engenheiro AWS (debug session) (user) - Capacity Mgmt Tool (ferramenta interna) (compute) ### 🗄️ S3 Internals — us-east-1 - S3 Index Subsystem (metadados / placement coord.) (data) - S3 Placement Subsystem (onde escrever novos objetos) (data) - S3 Storage Nodes (dados em repouso — íntegros) (storage) - S3 API Layer (GET / PUT / LIST / DELETE) (frontend) ### ☁️ Serviços AWS Dependentes - AWS Console (assets em S3) (frontend) - CloudFormation (templates em S3) (compute) - Lambda (código de funções em S3) (compute) - ECS / Elastic Beanstalk (imagens / configs em S3) (compute) - Service Health Dashboard (assets em S3 — irônico) (frontend) - Kinesis, SNS, SQS, RDS... (dependências indiretas) (messaging) ### 🌐 Clientes Externos - Slack, GitHub, Trello Medium, Quora, IFTTT... (external) - Usuários Finais (impacto percebido) (user) ### Fluxos - engineer -> mgmt-tool: executa com param errado - mgmt-tool -> s3-index: remove servidores em excesso ⚠️ - s3-index -> s3-placement: sem coordenação de placement - s3-index -> s3-api: GET/LIST falham (sem metadados) - s3-placement -> s3-api: PUT falha (sem destino) - s3-api -> aws-console: erros 5xx - s3-api -> cloudformation - s3-api -> lambda - s3-api -> ecs - s3-api -> health-dashboard: dashboard cego 😬 - s3-api -> other-aws - aws-console -> saas-clients - other-aws -> saas-clients - saas-clients -> end-users: falhas visíveis ao usuário > **Causa Raiz:** Um engenheiro executou uma ferramenta interna de gestão de capacidade com um parâmetro numérico incorreto, removendo uma fração substancial dos servidores do subsistema Index do S3 em us-east-1 de uma só vez. A ferramenta não possuía nenhum mecanismo de proteção contra remoção de capacidade acima de um threshold seguro (ex.: máximo de X% da frota em uma única operação). O subsistema Index, sem capacidade suficiente, tornou-se incapaz de coordenar operações de leitura e escrita do S3. A recuperação foi prolongada porque o processo de restart do subsistema Index — que requer verificação de consistência de estado antes de aceitar tráfego — levou muito mais tempo do que os runbooks previam, pois o tempo de restart havia crescido proporcionalmente ao volume de dados do S3 sem que os procedimentos operacionais fossem atualizados. ## A Anatomia da Cascata 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. ## Remediação e Ações da AWS 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. ## Lições Técnicas - **Operações destrutivas exigem circuit breakers por design.** Qualquer ferramenta que possa reduzir a capacidade de um subsistema crítico deve ter um limite máximo de impacto por operação — configurável, auditável e não bypassável sem aprovação explícita. Isso não é burocracia; é engenharia de segurança. - **Dependências implícitas são dívida técnica de resiliência.** O grafo de dependências do S3 em us-east-1 havia crescido de forma não documentada por anos. Serviços de controle (console, health dashboard, ferramentas de deploy) não devem depender do mesmo plano de dados que servem — ou devem ter fallbacks explícitos e testados. - **O plano de controle não pode depender do plano de dados que monitora.** O Service Health Dashboard sendo degradado durante o incidente é o exemplo mais visível, mas o princípio se aplica a qualquer sistema de observabilidade, alerting e comunicação de status. Esses sistemas precisam de blast radius isolation explícita. - **Runbooks têm prazo de validade.** Procedimentos de recuperação escritos para um sistema de certa escala tornam-se imprecisos — às vezes perigosamente — à medida que o sistema cresce. Testar runbooks em produção periodicamente (Game Days, chaos drills) é a única forma de manter o tempo de recuperação estimado alinhado com a realidade. - **Multi-região não é apenas para disaster recovery.** Muitos clientes afetados tinham arquiteturas single-region em us-east-1. Um incidente de 4 horas em uma única região é tolerável se você tem failover para outra. Para cargas de trabalho críticas, multi-região ativo-ativo ou ativo-passivo com failover automatizado não é over-engineering — é o custo do SLA. - **Erros humanos são inevitáveis; sistemas resilientes os contêm.** A análise blameless não significa ignorar que um humano cometeu um erro — significa reconhecer que sistemas bem projetados não permitem que erros individuais causem impacto catastrófico. O erro foi o trigger; a ausência de guardrails foi a causa sistêmica. > **Perspectiva de Arquiteto Sênior:** Trabalhei com sistemas financeiros de missão crítica por mais de 16 anos, e o que me chama atenção neste incidente não é o erro em si — é o que o erro revelou sobre o estado das dependências internas da AWS em 2017. O S3 havia se tornado, silenciosamente, um ponto de falha único para uma fração enorme da infraestrutura de internet. Não por má intenção, mas por acumulação incremental de decisões razoáveis individualmente. Cada equipe que decidiu armazenar seus assets no S3 estava fazendo a escolha certa localmente. O problema é que ninguém estava olhando para o grafo global de dependências e perguntando: 'o que acontece se o S3 ficar indisponível por 4 horas?' Em sistemas financeiros, chamamos isso de **concentração de risco**. Reguladores exigem que você mapeie, limite e teste sua exposição a pontos únicos de falha — não apenas em hardware, mas em fornecedores, serviços e infraestrutura compartilhada. A indústria de cloud ainda está aprendendo a aplicar esse rigor. Se eu fosse redesenhar a arquitetura de qualquer serviço crítico afetado por este incidente, aplicaria três princípios imediatamente: **1) Blast radius budgets** — defina explicitamente qual é o impacto máximo aceitável de uma falha de qualquer dependência externa, e arquitete para não excedê-lo. **2) Control plane isolation** — ferramentas de observabilidade, health dashboards e sistemas de comunicação de incidentes devem ser deployados em infraestrutura completamente separada do serviço que monitoram. **3) Dependency graph audits** — mapeie e revise periodicamente todas as dependências de runtime, especialme ## Veredicto O incidente do S3 em fevereiro de 2017 é um caso de estudo quase perfeito sobre como sistemas complexos falham: não por uma única causa catastrófica, mas pela intersecção de um erro humano banal com ausência de guardrails, dependências implícitas acumuladas e procedimentos operacionais que não acompanharam o crescimento do sistema. A lição mais importante não é técnica — é organizacional. A AWS construiu, ao longo de anos, um ecossistema de serviços interdependentes sem um mecanismo sistemático para mapear e limitar a concentração de risco em torno de componentes críticos. Quando o nó central falhou, a amplitude do impacto surpreendeu até a própria AWS. Para arquitetos e engenheiros que leram este documento: **a pergunta que você deve fazer sobre sua arquitetura hoje não é 'o que acontece se minha aplicação falhar?', mas 'o que acontece se qualquer uma das minhas dependências externas ficar indisponível por 4 horas?'**. Se a resposta for 'minha aplicação também fica indisponível', você tem trabalho a fazer — independentemente de qual provedor de cloud você usa. A AWS se recuperou, aprendeu e publicou um dos post-mortems públicos mais honestos que já vi de um provedor de cloud de ## Referências - [AWS — Summary of the Amazon S3 Service Disruption in the Northern Virginia (US-EAST-1) Region](https://aws.amazon.com/message/41926/) ## Fontes do caso - [AWS — Summary of the S3 Service Disruption](https://aws.amazon.com/message/41926/)